Almost every couple of years (and once a decade for something "big") there is a new development in the area mostly driven either by clueless software guys that wandered outisde their turf into hardware territory, or some university chair that sits in the undefined limbo between hardware and software (usually doing something in the realm of CGRAs) that has to justify its existence by offering a PhD to some guy that will create a new RTL IR or another deadborn HLS.
Developing hardware is a solved problem. Has been for decades. And no, writing a sentence in your white paper that says something like "existing HDLs operate on gates and cycles and its not an appropriate level of abstraction for us" is not enough of a justification. If you need a fancy pseudo-DSL to hold your hand to be able to describe simple datapaths and FSMs for you then you wouldnt be able to develop anything hardware related that is remotely useful. You cannot abstract away the essence of this engineering task.
What we actually need is a tighter verification loops and better (and more accessible) verification methodology so that hardware development is less daunting in the first place, not another DSL-to-RTL translator (even if extensible, like in calyx case)
> Developing hardware is a solved problem. Has been for decades.
So we should have just stuck with schematic capture, then? Why were HDLs and logic synthesis developed (by those pesky "clueless" software engineers)? To increase productivity. Current HLS can (especially in certain domains like DSP) increase productivity. Sure, I'll agree that some of the hardware oriented DSLs probably weren't all that necessary if you consider the existence of things like generate statements in VHDL and SystemVerilog. But that doesn't mean that experimentation in increasing abstraction (and thus productivity) shouldn't take place. If yours was the reigning opinion in the software world we'd still all be programming in assembler.
2.2 Optimizing Accelerator Designs High-level specifications of accelerators encode a treasure trove of control flow information that is lost when lowering to a registertransfer level (RTL) language.
Author of Calyx here. I always find these arguments quite reductive but will nonetheless entertain them.
"Developing Hardware is a solved problem"
For which audience specifically? Maybe if you consider giant teams at large corps pouring in millions. Is it a solved problem for hobbyists, students, people who're just curious? Most people who're curious about software can go play with it in 15 mins. For hardware, it's more like months.
"If you need pseudo-DSL ..."
Weirdly gatekeepy. Why should hardware be only used by experts? There's lot you could've said about it being hard to optimize hardware well (which is challenging with HDLs too) but instead choose this argument.
"You cannot abstract away this engineering task"
The goal of research is to try to do things differently. We already know how to build hardware using HDLs, with waterfall models and giant teams. We want to figure out if there are better ways to do it.
The VLSI revolution wouldn't have happened if randos on the internet kept complaining about how "we already know how to do full custom design" and "you cannot abstract physics". We did before, and it changed the world. Let's have some optimism.
I think the developer did a great job for at least trying. I'm no hardware design expert, but the amount of work done shows. Plus it's reproducible research. If you're so sure about the quality and utility of the work done, you can get the artifacts, reproduce the toolchain, and write a nice rebuttal about it, and maybe even suggest improvements to the work done. Who knows.
I think, failure is a way better outcome than not trying in the first place.
It was not my intent to be discouraging towards the project, but rather than a frustration about a consistently misplaced attention from outsiders and science/research community.
But again, this notion of "outsiders" is very gatekeepy. There have been substaintial successes in using high-level programming models for hardware design.
The Google VCU paper explicitly mentions using such tools made them faster. All of these is enabled by people looking at problems with a fresh perspective
I don't have a horse in this race, and maybe the root comment came off as flippant and disparaging. But I'm not reading "outsiders" as being what you say "gatekeeping".
Maybe another perspective is that "outsiders" may not have the same view of the issue as experts in the field and may not (historically, in OP's experience) seem to want to work together with the experts to develop this view. Handwaving away complexities and not willing to get hands dirty is something I've seen as well so maybe I'm a bit more empathetic, but cold shoulders from "experts" towards newcomers is definitely a thing.
Both of which could help both sides - bring more depth to the fresh view of the "outsiders" and actually bring valuable freshness to the depth of the "experts".
"outsiders" can often bring a new perspective. There are many people who overlap both the hardware and software worlds (I consider myself one of them having started out in hardware and then moving over to the software side in EDA). Without those kinds of people you wouldn't have the kinds of EDA tools you have now.
> misplaced attention from outsiders and science/research community.
Come join the software side and work on the tools you want to see.
The fact that calyx has both parallel as well as sequential blocks means that it is significantly ahead of most HLS languages. That is not a tiny difference, mind you. It is a gargantuan one.
But that's a relative link, so if you're using HN via HTTPS that will be an HTTPS link as well. Downloading the paper redirects you to http://rachit.pl/files/pubs/calyx.pdf, a plain HTTP link.
Seems interesting - if I understand, this lets you get Verilog from a frontend you build. Can this be used to implement say a backend for pytorch? How does one link the generated verilog to software that can drive the design (in sim or actual FPGA/ASIC hardware)?
Or is that left to you to build a driver separately for?
My first instinct was to ask "Does this play well with CIRCT?" And thankfully they answer that right away in the README.
I'm personally of the opinion that there is a LOT of room for improvement in the hardware design tooling space, but a combination of market consolidation, huge pressure to meet deadlines, and an existing functional pipeline of Verilog/VHDL talent is preventing changes.
That's not to say "Verilog/VHDL are bad", because clearly they've been good enough to support nearly all of the wonderful designs powering today's devices. But it is to say, "the startup scene for hardware will continue to look anemic compared to the SaaS scene until someone gives me all of the niceties I have for building SaaS tools in software."
A huge amount of ideas (and entire designs) start off as software sims, which enables kernel/compiler engineers to start building out support for new hardware before it's manufactured.
There is some interesting work going on at SiFive building hardware with Chisel[1], as well as some interesting work lead by a professor at William and Mary to improve simulations[2].
From a glance: it seems like it is more specific for accelerators. Chisel deals in the general way, but Calyx seems to have primitives for wiring systolic arrays for example. If you plan to do an OoO CPU, choose Chisel. If you want to do a DSP or TPU, choose Calyx.
You can express full CPU designs in Calyx (in fact, we have) because it is a superset of a hardware description language. However, Calyx will probably not provide any substantial benefit in this case because there are not that many opportunities to optimize things.
The premise of Calyx is you're generating hardware designs from high-level code which has a lot more structure than arbitrary HDL code and the compiler will use that extra structure to automatically do optimizations that cannot be done over arbitrary HDL code.
I'm always interested in new hardware-oriented DSLs, so great to see effort and work here.
rachitnigam, do you have any example designs of "significant" complexity? I looked over the paper and saw your 2x2 array example -- I'm curious if you make this something like 100x100 or n x m, can that be done in parameterizable way? What about control-structures like bits to enable / disable functionality, etc?
Also, do you provide a way to do things like arbitrary insert pipeline registers and let your tools track that?
One comment when comparing to Vivado HLS, fundamentally HLS breaks all problems down into CSP-style designs (whether you want that or not) and it takes a lot of experimentation with #pragmas to get a more optimal design. Not claiming Vivado HLS will beat your tool, but it's possible with some tuning to get a "better" design.
HLS-like languages are an input to Calyx. For example, we're currently building a Vivado alternative using Calyx and the frontend there does the pipelining for us. Calyx then goes in and performs a bunch of other optimizations.
A big edge we have is that Calyx supports both statically-scheduled circuits (where the latencies of things are known) and dynamically-scheduled circuits (where latency is not known). Because of this, we have been able to do optimizations in this new flow that take advantage of both.
This is great to hear. It might be nice to bubble those examples up to your Github page along with some diagrams and logic/resource results after synthesis (i.e. how many LUTs, BRAM, etc).
It's easy for people to do a lot of naysaying, it's a lot harder to try and actually do something evolutionary, let alone revolutionary. Please keep posting with up-to-date results.
32 comments
[ 3.0 ms ] story [ 94.6 ms ] threadSo we should have just stuck with schematic capture, then? Why were HDLs and logic synthesis developed (by those pesky "clueless" software engineers)? To increase productivity. Current HLS can (especially in certain domains like DSP) increase productivity. Sure, I'll agree that some of the hardware oriented DSLs probably weren't all that necessary if you consider the existence of things like generate statements in VHDL and SystemVerilog. But that doesn't mean that experimentation in increasing abstraction (and thus productivity) shouldn't take place. If yours was the reigning opinion in the software world we'd still all be programming in assembler.
2.2 Optimizing Accelerator Designs High-level specifications of accelerators encode a treasure trove of control flow information that is lost when lowering to a registertransfer level (RTL) language.
"Developing Hardware is a solved problem"
For which audience specifically? Maybe if you consider giant teams at large corps pouring in millions. Is it a solved problem for hobbyists, students, people who're just curious? Most people who're curious about software can go play with it in 15 mins. For hardware, it's more like months.
"If you need pseudo-DSL ..."
Weirdly gatekeepy. Why should hardware be only used by experts? There's lot you could've said about it being hard to optimize hardware well (which is challenging with HDLs too) but instead choose this argument.
"You cannot abstract away this engineering task" The goal of research is to try to do things differently. We already know how to build hardware using HDLs, with waterfall models and giant teams. We want to figure out if there are better ways to do it.
The VLSI revolution wouldn't have happened if randos on the internet kept complaining about how "we already know how to do full custom design" and "you cannot abstract physics". We did before, and it changed the world. Let's have some optimism.
I think, failure is a way better outcome than not trying in the first place.
The Google VCU paper explicitly mentions using such tools made them faster. All of these is enabled by people looking at problems with a fresh perspective
Maybe another perspective is that "outsiders" may not have the same view of the issue as experts in the field and may not (historically, in OP's experience) seem to want to work together with the experts to develop this view. Handwaving away complexities and not willing to get hands dirty is something I've seen as well so maybe I'm a bit more empathetic, but cold shoulders from "experts" towards newcomers is definitely a thing.
Both of which could help both sides - bring more depth to the fresh view of the "outsiders" and actually bring valuable freshness to the depth of the "experts".
> misplaced attention from outsiders and science/research community.
Come join the software side and work on the tools you want to see.
What platform/browser has this problem?
But http://www.bbc.co.uk works.
http://rachit.pl/files/pubs/calyx.pdf fails. I suspect /PDF/.
Or is that left to you to build a driver separately for?
ASICs require a lot more work by either packaging on the same chip as a processor or building IO interfaces for their own package.
I'm personally of the opinion that there is a LOT of room for improvement in the hardware design tooling space, but a combination of market consolidation, huge pressure to meet deadlines, and an existing functional pipeline of Verilog/VHDL talent is preventing changes.
That's not to say "Verilog/VHDL are bad", because clearly they've been good enough to support nearly all of the wonderful designs powering today's devices. But it is to say, "the startup scene for hardware will continue to look anemic compared to the SaaS scene until someone gives me all of the niceties I have for building SaaS tools in software."
A huge amount of ideas (and entire designs) start off as software sims, which enables kernel/compiler engineers to start building out support for new hardware before it's manufactured.
There is some interesting work going on at SiFive building hardware with Chisel[1], as well as some interesting work lead by a professor at William and Mary to improve simulations[2].
1: https://www.chisel-lang.org
2: https://github.com/sarchlab/akita
The premise of Calyx is you're generating hardware designs from high-level code which has a lot more structure than arbitrary HDL code and the compiler will use that extra structure to automatically do optimizations that cannot be done over arbitrary HDL code.
rachitnigam, do you have any example designs of "significant" complexity? I looked over the paper and saw your 2x2 array example -- I'm curious if you make this something like 100x100 or n x m, can that be done in parameterizable way? What about control-structures like bits to enable / disable functionality, etc?
Also, do you provide a way to do things like arbitrary insert pipeline registers and let your tools track that?
One comment when comparing to Vivado HLS, fundamentally HLS breaks all problems down into CSP-style designs (whether you want that or not) and it takes a lot of experimentation with #pragmas to get a more optimal design. Not claiming Vivado HLS will beat your tool, but it's possible with some tuning to get a "better" design.
HLS-like languages are an input to Calyx. For example, we're currently building a Vivado alternative using Calyx and the frontend there does the pipelining for us. Calyx then goes in and performs a bunch of other optimizations.
A big edge we have is that Calyx supports both statically-scheduled circuits (where the latencies of things are known) and dynamically-scheduled circuits (where latency is not known). Because of this, we have been able to do optimizations in this new flow that take advantage of both.
It's easy for people to do a lot of naysaying, it's a lot harder to try and actually do something evolutionary, let alone revolutionary. Please keep posting with up-to-date results.