4 ms·
Verilog definitely sucks but I think the problem with new HDLs (Clash, Bluespec, Chisel etc) is they don't necessarily make the hard bits of hardware design eas
by gchadwick 5y ago
Verilog definitely sucks but I think the problem with new HDLs (Clash, Bluespec, Chisel etc) is they don't necessarily make the hard bits of hardware design easier, they just help with the tedious stuff that whilst annoying ultimately doesn't take up much of your time.
For example a good type system definitely makes module interfaces cleaner, saves you having to dig through warnings/lint reports to find stupid errors and in general makes in easier to rapidly build a new system out of IP. However for your typical hardware project you're not normally wanting to radically configure things or continuously build whole new systems. You have a fixed or slowly evolving spec so when you first put things together and occasional need to add or change blocks there's a bunch of tedious error prone wiring to be done but ultimately improving that process makes your job easier but doesn't open up radical new ways to do it.
Significantly more powerful generation/parameterisation capabilities is another thing new HDLs can excel at. However for anything sufficiently complex (e.g. a cache) building something scalable that functions correctly and performs well across a broad parameter space is just incredibly hard. Perhaps a new HDL lets your build a wonderful crossbar for some interconnect protocol (e.g. AXI) for instance where you can have arbitrary numbers of ports, arbitrary data widths or each, clock domain crossing etc etc and it just handles whatever you throw at it and you get some nice elegant code that generates it all too. Though depending upon the actual configuration you want you'll want very different micro-architectures for it. The one size fits all approach will be a one size fits this corner of the parameter space in reality and if want a truly one size fits all you'll find your initially nice elegant code ends up with a bunch of special cases all over it to produce optimal designs. Also in reality you don't need something super flexible for all cases in any given project, building the thing your specific use case requires works fine. Then for the next project you can adapt it. A tedious process you'd love to see improved? Sure. One which is holding you back from doing amazing things? That I'm less convinced off.
There's also the downside in that it is important to have a reasonable idea of the circuit you actually produce and this is generally where the hard stuff happens. You have tricky timing paths to deal with, power issues to sort out, area to reduce etc. If you're working on secure hardware (like I do) you've got side channel and fault injection attacks to detect and defeat. Doing this requires a deep understand of how the HDL you're writing becomes standard cells on the chip.
With a new HDL mentally mapping some output of an implementation tool back to the original HDL can be very tricky and consequences of code changes can be surprising. This makes the hard stuff harder.
Ultimately hardware is not software, there's a different set of constraints you're working to and a rather different end product. There's plenty of good stuff to take from the software world to apply to hardware but it doesn't all just map across cleanly.
Of course some of the problems I talk about above can be solved by tooling, they're not inherent to the languages. Still that tooling needs to be created and may be very hard to build (how many times have you seen someone claim something will be amazing just as soon as the tools exist to make it useable?).
I think my perfect HDL right now would look rather like SystemVerilog but with a decent type system and restricted semantics so unsynthesisable (or synthesises but not into a circuit you'd ever actually want to build) code simply won't build along with improvements around parameterisation and generative capabilities.
Taking a step further from there is also perfectly possible but I think we need to do a lot of work around tooling and verification for more flexible designs first to understand how to do that well.
I do need to spend more time with new HDLs. The last serious project I did in one was a CPU (well two CPUs but both dervied from the same code base) in Bluespec around 10 years ago for my PhD. Bluespec has an opensource compiler now plus there's various languagues to explore. Maybe I'll try building a RISC-V core in each and seeing how it goes.
- cyber_kinetist 5y agoWow, didn't know that Bluespec was open sourced. I used in my Computer Architecture class for assignments 6 years ago, and my experience was that it was much much better than Verilog (the type system was far better) but there was too little learning material/documentation out there on the Internet.
- adrian_b 5y agoBluespec was not open sourced. There is now an open-source Bluespec compiler based on the little public information that is available about Bluespec. So it is likely that it is not compatible with the full Bluespec, even if can synthesize published examples of Bluespec. There are some research papers and the code at: https://www.cl.cam.ac.uk/~djg11/wwwhpr/toy-bluespec-compiler.html https://www.cl.cam.ac.uk/~djg11/wwwhpr/toy-bluespec-compiler...
- q3k 5y agobsc, the bluespec compiler, has been open sourced under the MIT license. It's the real deal, the same bsc that has been used in the industry for years now. I've been using it in my own personal projects for something something like two years.
- gchadwick 5y agoBluespec was open sourced slightly over two years ago: https://twitter.com/bluespec/status/1225184669978841090 https://twitter.com/bluespec/status/1225184669978841090 https://github.com/B-Lang-org/bsc https://github.com/B-Lang-org/bsc Indeed seems Bluespec Inc. has pivoted to RISC-V CPU IP. No obvious mention of BSV on their webpage (https://bluespec.com/ https://bluespec.com/)
- q3k 5y agoI've tried pretty much every 'NeoHDL' out there, and so far Bluespec was the one that actually made me feel like it's a step in the right direction, instead of more of the same. Its atomic transaction based modelling maps superbly well into hardware clock cycles, and after using it for a while you learn to visualize quite well what shape of RTL will be generated. Plus its standard library provides some really powerful _and practical_ interfaces/implementations that make building things fast and safe. Oh, and a lot of things you would generalize with fairly heavy-handed and bespoke abstraction in things like Chisel/Spinal/Migen/Amaranth just map directly into Bluespec's type system constructs, making interacting with existing codebases much less of a reverse engineering effort. The Bluespec SystemVerilog syntax is a bit... quaint, but if you're used to (System)Verilog you know the deal. I personally want to spend some time soon learning the Bluespec Classic/Haskell instead, but that's mostly because I already know some Haskell... Overall, highly recommend giving it another shot. It made me enjoy writing HDL code again after years of frustration with other offerings. It's one of the few languages out there that actually make me feel 10x as productive thanks to the strict type/runtime semantics.