8 ms·
Spade Hardware Description Language
- ajross 1y agoHaven't looked at this one, but IMHO HDL's are sort of the ultimate existence proof that "DSLs Are Bad Design Smell". DSLs are great and elegant and beautiful for expressing a domain solution. Once. But real solutions evolve, and as they do they get messy, and when that happens you need to address that with software tools. And DSLs are, intentionally, inadequate to the tasks of large scale software design. So they add features[1], and we gets stuff like SystemC that looks almost like real programming. Except that it's walled off from updates in the broader community, so no tools like MSAN or whatnot, and you're working from decades-stale language standards, and everything is proprietary... Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot. More syntax isn't what's needed. [1] In what can be seen as an inevitable corollary of Greenspun's Tenth Rule, I guess.
- leonheld 1y ago> Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot. I worked a bit with VHDL and the parallelism aspect is - to me - so fundamentally different than what our sequential programming languages can express that I'm not sure I a layer of abstraction between this and that. How would that work?
- ajross 1y agoYou mean parallelism for simulation? Generate a simulator output from your input (in VHDL if you like) and run it in an appropriate runtime. You don't need to run Python/whatever to simulate and you don't need (and probably don't want) your semantic constraints and checks to be expressed in python/whatever syntax. But the process of moving from a parametrized design through the inevitable cross-team-design-madness and decade-stale-design-mistake-workarounds needs to be managed in a development environment that can handle it.
- nsteel 1y agoI don't think this is about simulation. Python requires an additional DSL layer in order to express parallelism. I've personally no interest in learning that, or anything like that stuck on top some other language that's similarly unfit for HDL purposes. Modern VHDL isn't too far off what we need. I'd rather see more improvements to that. But most crucially, we need tooling that actually supports the improvements and new features. We don't have that today, it's an absolute mess trying to use VHDL '19 with the industry's standard tools. We even avoid using '08 for fear of issues. I can't speak to how far off SV is.
- oasisaimlessly 1y agoSee e.g. Migen [1], a Python HDL. TL;DR: The hardware modules you're generating are represented as first-class objects that can be constructed from a DSL embedded within Python or explicitly from a list of primitives. [1]: https://m-labs.hk/gateware/migen/ https://m-labs.hk/gateware/migen/
- duped 1y agoI would argue that the prevalence of HDLs proves that DSLs are a good design for problem domains that scale in complexity. The alternative is point and click CAD, which has a ceiling on the scale of complexity you can reach. > Honestly my sense is that it's just time to rip the bandaid off and generate synthesizable hardware from Python or Rust or whatnot. More syntax isn't what's needed. People who think the problem is that they can't synthesize a program in hardware from something like Python completely misunderstand the purpose of an HDL. You do not write a program and press a button to get that program on hardware. You write a program to generate the design and verify its correctness. It is much less like writing an imperative or functional program and more like writing macros or code generation. Now if you want to write a Python library for generating the underlying data for programming an FPGA or taping out circuits that's actually a good idea that people have tried out - the problem you run into though are network effects. Generating designs is easy, verifying and debugging them is very hard. All the money is in the tooling, and that tooling speaks HDLs.
- adwn 1y ago> I would argue that the prevalence of HDLs proves that DSLs are a good design for problem domains that scale in complexity. The major HDLs (i.e., Verilog/SystemVerilog and VHDL) are not DSLs in any meaningful sense of the word. There exist HDLs which actually are DSLs, but they're mostly used by hobbyist and aren't gaining any significant traction in the industry.
- Surac 1y agoThere are already Verilog and VHDL based tools alvilable. i think nopne likes to learn a third HDL. Including specific ideas into the hdl makes it less attractive to people
- RetroTechie 1y agoEach HDL has its own strengths, weaknesses, tool support & application areas. So each has its place as long as -for specific designs/projects- it's better than alternative HDLs. Users can define "better" for themselves. Not to mention: existing designs already done in Verilog, VHDL or whatever. Converting such a design from one HDL to another may no be easy. So as always: use the best tool for the job.
- thezoq2 1y agoChisel, BlueSpec Spinal and Migen are already used quite a bit though of course much less so than Verilog. But we do need new languages, https://drops.dagstuhl.de/storage/00lipics/lipics-vol136-snapl2019/LIPIcs.SNAPL.2019.7/LIPIcs.SNAPL.2019.7.pdf https://drops.dagstuhl.de/storage/00lipics/lipics-vol136-sna... does a pretty good job at articulating why
- adwn 1y agoI'll take a closer look later, and I welcome anything that tries to bring concepts from modern programming languages to hardware design. But. The focus on "CPU" examples on the landing page (A 3 stage CPU supporting Add, Sub, Set and Jump, "You can easily build an ALU") is immediately discouraging. I implement and verify FPGA designs for a living, and the vast, vast majority of my work is nothing like designing a CPU. So my fear is that this new hardware description language hasn't been created by a veteran who has many years of experience in using HDLs and therefore knows what and where the real pain points are, but by someone who's ultimately a software developer – even a highly skilled and motivated software developer – and who has never designed, implemented, and verified a large FPGA design. And skilled, motivated software developers without a lot of domain-specific experience tend to solve the wrong problems. I would be happy to be proven wrong, though.
- thezoq2 1y agoSpade author here! That's a good reminder that I need to update the example on the website, I must have written that example almost 3 years ago at this point :) For more up to date motivation, my talk from LatchUp last year is probably the best one I have https://www.youtube.com/watch?v=_EdOHbY2dlg&t=277s https://www.youtube.com/watch?v=_EdOHbY2dlg&t=277s > So my fear is that this new hardware description language hasn't been created by a veteran who has many years of experience in using HDLs That's annoyingly quite close to the truth :D But I think I have enough experience now to not be completely stumbling around in the dark
- Philpax 1y agoIf you're curious why people keep wanting to reinvent HDLs, these posts by Dan Luu might be useful: - https://danluu.com/why-hardware-development-is-hard/ https://danluu.com/why-hardware-development-is-hard/ - https://danluu.com/pl-troll/ https://danluu.com/pl-troll/
- tails4e 1y agoSystemVerilog is a much better language than verilog. You can get pretty strong typed behaviour now, if you use the language parts that allow that. It's like C, if you use it poorly/the 'verilog way' it's got some serious footguns, but you can use it quite safely if you use the more modern features. That said, I'm all for better languages, of they really are better and as expressive
- wirybeige 1y agoTo add, even before SV we've had VHDL which is also strongly typed and has other nice features. But I do still like using SV more than VHDL :3. I'm not wholly convinced of these languages that have been popping up so far.
- thezoq2 1y agoSpade author here :) Coming from a functional programming adjacent background, the VHDL type system leaves a lot to be desired. Not supporting types with generics means you can't encode things like a genral purpose ready/valid stream. When you have those, you can start using methods to compose those streams which becomes even more powerful when you add higher order functions which allow you to transform the content of the stream without worrying about the stream details.
- IshKebab 1y agoIt's better than Verilog but it's still awful. If you thought C had footguns....
- tails4e 1y ago
- Symmetry 1y agoI wonder how it compares to Bluespec?
- grquantum 1y agoI think this commits the same sin many other new HDLs do -- it just tries to awkwardly smush the paradigm of clocked logic into a sequential software language. The abstractions just don't match, which means you lose the mental connection between the code and the generated Verilog, which makes debugging stuff like timing awkward. I'm a big Bluespec booster, and beyond the nice typing and functional programming you get I think the big advance it brings to the table is the Guarded Atomic Action paradigm, which simplifies reasoning about what the code is doing and means that it's usually not too painful to poke at the generated HDL too since there's a clear connection between the two halves. At $WORK$ we've been using Bluespec very successfully in a small team to quickly iterate on hardware designs. I don't want to denigrate the Spade developers since it's clearly a labor of love and nicely done, but I feel that unless the underlying mental model changes there's not much benefit to any of these neo-HDLs compared to SV or VHDL.
- fooblaster 1y agoWhere do you work that uses bluespec? Any open positions? Apologies for being forward.
- imtringued 1y agoI don't get what you're talking about. If I had to describe Spade it's just VHDL, but this time with Rust syntax instead of Pascal. The pipeline syntax is just syntax sugar and nowhere near full blown high level synthesis.
- thezoq2 1y agoSpade author here! The biggest difference is that BlueSpec uses a different abstraction than standard "RTL". That has significant advantages of course, but also means some overhead and a shift in mental model. With Spade my goal is to build new abstractions on top of RTL. That should allow you to operate at a higher abstraction level with minimal overhead most of the time, and dive down to regular RTL when necessary
- fjfaase 1y agoI thought that this was about the hardware description language Clash developed by some ex-colleagues, but it appeared to be something else. Clash [1] is based on the functional programming language Haskell and it can output to VHDL, Verilog, or SystemVerilog. Although the last official release mentioned on the website is from 2021, it is still actively developed on GitHub [2]. See also contranomy [3] for a non-pipelined RV32I RISC-V core written in Clash. [1] https://clash-lang.org/ https://clash-lang.org/ [2] https://github.com/clash-lang/clash-compiler https://github.com/clash-lang/clash-compiler [3] https://github.com/christiaanb/contranomy https://github.com/christiaanb/contranomy
- thezoq2 1y agoClash was the HDL that I used before starting Spade. I'm not a huge fan of haskell and wanted a few more hardware specific features which is why I didn't stick with it. That said, Clash is great and I know quite a few people at QBay. They don't seem to be slowing down any time soon!
- chrsw 1y agoOn the surface this seems like it strikes a nice balance between addressing issues with expressing digital design intent and not completely breaking the mental model digital designers are used to in traditional HDLs.
- deleted 1y ago[deleted]
- smallpipe 1y agoIf the output SystemVerilog is unreadable I'm unlikely to use this. SV is still the lingua franca for physical tools. I'm not debugging timing on something that looks like this: localparam[14:0] _e_953 = 0; localparam[14:0] _e_958 = 1; assign _e_956 = \count + _e_958; assign _e_955 = _e_956[14:0]; assign _e_948 = _e_949 ? _e_953 : _e_955;
- alain94040 1y agoFair, but it's just a tooling issue. You don't debug your Verilog anymore at the gate-level, do you?
- adwn 1y ago> just a tooling issue The word "just" is carrying the weight of the world on its shoulders…
- smallpipe 1y agoI do for the most sensitive path of the design, but only because it's needed. I don't want to have to look at it for day-to-day debugging, where it's just a distraction.
- variaga 1y agoWhen debugging/fixing timing problems, or trying to implement a functional change using only metal layers - yes, it is absolutely still necessary to debug verilog at the gate level. Also, "just a tooling issue" is a pretty big problem when you're talking about something that wants to be adopted as part of the toolchain.
- js8 1y agoI think any HDL that is more inspired by functional languages (with better composability) is good. But yeah there is lot of inertia in using existing tools.
- kayson 1y agoAnother new HDL: https://veryl-lang.org/ https://veryl-lang.org/ It'll be a long while before either gets enough traction to be serious competition to system erilog, even if SV is, compared to modern software languages, outdated.
- IshKebab 1y agoThis looks much more likely to succeed tbh. Similar enough to SV that you can piggy back off the features that you're likely never going to replicate (SVA, functional coverage, multiple clock domains, etc. etc.) but also fixes the footguns.
- dalance 1y agoAs the author of Veryl and an ASIC frontend engineer, I aim to enable smooth transitions from existing SystemVerilog projects, making it immediately applicable to ASIC projects. (In fact, it’s already being applied to an ASIC currently under design.) I see languages like Spade and SUS as HDLs for a slightly more future-oriented.
- raluk 1y agoHow one writes circular circuit, for example stream of fibonnachi numbers or IIR filter? For IIR filter it would be nice if it has protoype like iir(sig : T, a : vec<T, N>, b : vec<T,M>) -> T
- Lramseyer 1y agoLove to see this at the top of HN! I haven't written anything with this language yet, but I have met some of the developers of this language. They're pretty great and they are doing a lot of really good work in the open source hardware community. Another project they maintain is Surfer: https://surfer-project.org/ https://surfer-project.org/ The challenge of a HDL over a regular sequential programming (software) language is that a software language is programmed in time, whereas a HDL is programmed in both space and time. As one HDL theory expert once told me "Too many high level HDLs try to abstract out time, when what they really need to do is expose time."
- etep 1y agoSurfer deserves to hit the front page also. Much better than gtk wave. Nice work Spade & Surfer!
- VonTum 1y ago> As one HDL theory expert once told me "Too many high level HDLs try to abstract out time, when what they really need to do is expose time." Exactly! It's astounding how often the documentation of some vendor component has in the documentation: "data_out is valid 2 cycles after read_enable is asserted", and NOTHING in the actual module definition makes a mention of this. There's so much dumb and error-prone mental arithmetic designers have to do to synchronize such latencies. Spade does make a nod at this, with its pipelining notation. The issue I have with it is that it takes a too simplistic approach to said port timings. In a Spade pipeline you separate "pipeline stages" by adding a "reg;" statement on its own line. (It's an approach shared by another language called TL-Verilog.). A consequence of this style is that all inputs arrive at the sime time (say cycle 0), and all results are produced at a second time (say cycle 5). This is irrespective of if an input is actually only ever needed in a final addition in cycle 4. It'll insert the 4 extra registers regardless. Likewise, it leads to unnatural expression of subpipelines, where syntactically you can already see a value, but can only _access_ it 3 pipeline stages later. With SUS, I have a solution to this: Latency Counting. (Intro here: https://m.youtube.com/watch?v=jJvtZvcimyM&t=937 https://m.youtube.com/watch?v=jJvtZvcimyM&t=937). A similar philosophy is also followed by Filament, though they go a step further with adding validity intervals too. The gist of Latency Counting is that Instead of explicitly marking and naming "Pipeline stages", you annotate a statement to say that it "takes one cycle", and through exploring the dependency graph between your wires, it assigns a unique "absolute latency" to every wire, and places registers accordingly. (And now it can even infer submodule parameters based on this pipelining, in a bid to do HLS-style design in an RTL language).
- polalavik 1y agoIf a new HDL language doesn’t have simulation capabilities baked in its next to useless. See: hardcaml and amaranth. The hard part has never been writing HDL, it’s verifying HDL and making the verification as organized and as easy as possible. Teams spend something like 20% of time on design and 80%+ on verification allegedly (definitely true at my shop). Edit: I see it’s tightly integrated with cocotb which is good. But someone needs to take a verification-first approach to writing a new language for HDL. It shouldn’t be a fun after thought, it’s a bulk of the job.
- thezoq2 1y agoSpade author here! That is a good point, sadly I'm not experienced enough with verification to know what is actually needed for verification from a language design perspective which is why I just offload to cocotb. There are a few interesting HDLs that do focus more on verification, ReWire, PDVL, Silver Oak, and Kôika are the ones I know about if you're interested in looking into them Also, nitpick but amaranth does have its own simulator as far as I know
- IshKebab 1y agoThis is another good reason to generate clean SV with meaningful stable signal names etc. There's absolutely no way you are going to replace e.g. SVA and formal verification tools.
- polalavik 1y agoSorry hardcaml and amaranth were my examples of things with baked in sim features. Also great work with spade. I love to hate, but the hardware industry needs folks like you pushing it forward. I just fear most people are making toys or focusing a ton of effort on the wrong issues (how to write HDL in a different way) instead of solving industry issues like verification, wrangling hand written modules with enormous I/O, stitching IP together, targeting real FPGAs, auto generating memory maps, etc. some of that is a tough solve because it’s proprietary. [1] https://github.com/janestreet/hardcaml/blob/master/docs/waveforms.md https://github.com/janestreet/hardcaml/blob/master/docs/wave...
- VonTum 1y agoI've been wondering how long it'd take for it to show up here. I can attest to Frans (the lead dev) being a talented and highly active developer. It's frankly quite intimidating to be a competitor of his. (https://sus.rocks https://sus.rocks) Hopefully one day we'll break open the hardware design ecosystem. Verilog & VHDL still being de-facto industry standard is pathetic. And IMO the only reason is the white-knuckle grip Intel (Altera again?) and Xilinx have over what languages are accepted by their respective proprietary design tools.
- thezoq2 1y agoHehe thanks for the kind words! I think once Verilog and VHDL are de-throned there will be plenty of room for more than one new HDL :) Especially if we can figure out interoperability between languages
- deleted 1y ago[deleted]