[HN Gopher] Calyx: Intermediate Language for Hardware Accelerators
___________________________________________________________________
Calyx: Intermediate Language for Hardware Accelerators
Author : nateb2022
Score : 42 points
Date : 2024-02-26 12:59 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| artemonster wrote:
| 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)
| UncleOxidant wrote:
| > 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.
| chrisjj wrote:
| Check out
|
| 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.
| artemonster wrote:
| Can you elaborate how is that information is helpful in any
| regard? I.e. resource scheduling, area optimization, timing?
| rachitnigam wrote:
| All of those things. Most HLS tools use the CDFG to
| generate optimized resource bindings and area-aware
| optimizations.
| rachitnigam wrote:
| 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.
| artemonster wrote:
| Good luck! :)
| bayindirh wrote:
| 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.
| artemonster wrote:
| 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.
| rachitnigam wrote:
| 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
| wavelander wrote:
| 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".
| UncleOxidant wrote:
| "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.
| chrisjj wrote:
| https://calyxir.org/ shows me a Paper button where a click does
| nothing but grey it.
| rachitnigam wrote:
| Odd, it works correctly for me:
| https://rachit.pl/files/pubs/calyx.pdf
|
| What platform/browser has this problem?
| chrisjj wrote:
| Android Chrome.
| jolmg wrote:
| Chrome on Android for me. Works on Firefox on Android.
| None4U wrote:
| do you have HTTP links blocked?
| chrisjj wrote:
| No e.g. reply on HN works.
| dpassens wrote:
| 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.
| buildbot wrote:
| 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?
| rachitnigam wrote:
| Author of Calyx here. Good question! Usually, you can use
| OpenCL based drivers to interface with standard memory
| interfaces on FPGAs.
|
| ASICs require a lot more work by either packaging on the same
| chip as a processor or building IO interfaces for their own
| package.
| dwrodri wrote:
| 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].
|
| 1: https://www.chisel-lang.org
|
| 2: https://github.com/sarchlab/akita
| ipsum2 wrote:
| How does this compare to chisel?
| vrinsd wrote:
| 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.
___________________________________________________________________
(page generated 2024-02-26 23:01 UTC)