Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'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.



Yes I did quite like bluespec, though after my time using it I drew two conclusions.

1. The extra power I had to build parameterisable/configurable designs didn't help as much as you'd hope as I said in my earlier post. Making something that can deal with a large parameter space still remains hard, the easier things look a lot nicer and are less fiddly to work with but on a practical level you're not gaining much.

2. One of bluespec's big ideas is you write the rules, with conditions and it works out the rest. The problems come when this maps to verilog and you need to start fixing implementation issues. I ended up having to develop good intuition around exactly how the compiler would schedule the rules so I could avoid issues (e.g. combinational loops). It felt like bluespec really pushed you into deep pipelining, rule does one thing result gets flopped another rule will take over next cycle. Fine for some designs but sometimes you've got a whole bunch of stuff you want to get in a single cycle (e.g. within a CPU) and there I felt like the rules construct ultimately just made it harder to build anything.

I do remember discovering some 'hidden' language features. Knowing it all turned into Haskell underneath via term rewriting I tried some syntactic constructs that weren't documented but I felt should work and often found they did! This gave some fairly powerful stuff to play with though never good to rely on undocumented features.

As I said it was over 10 years ago so my memory is hazy, things may have improved since there as has my skill and experience. I should really take another look now the compiler is open.


Agree Bluespec is great. In college we went from 0 to a Bluespec multicore RISC-V processor running Linux on an FPGA in a single undergrad semester, every step along the way felt intuitive.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: