Comment by gchadwick | Hacker News Reader

Comment by gchadwick | Hacker News Reader

Parent Full thread

Yes, I actually built two CPUs in it (one a derivative of the other) for my PhD over a decade ago. That experience helped shape my view on new HDLs.

As a specific example Bluespec has this system of rules that define hardware behaviour. From a high level it's a very nice system describing the behaviour you want and the constraints and the compiler works out the details. In practice you have to think about the details and you've got to work out how the compiler will compose things. At least you do if you care about how many cycles something takes. I never did any frequency optimisations either which would also be harder as it'd be deeply coupled to the rule scheduling behaviour.

Ultimately like many new HDLs it's a nice language from an abstract perspective but very much feels like someone with little practical experience with building real world silicon just applying software language design to hardware. The non existent type system of SystemVerilog being viewed as a major problem rather than what it is in reality an annoyance that causes more medium than any real substantial issues.

Thanks; just the kind of response I was hoping for! Is the problem an inability to express real world design constraints in a high level HDL?

I think the inherent problem is abstraction just doesn't work in the same way as it does in software. Various things keep pulling you down to the circuit level so if you're too far above it you're going to have a hard time as you have to reason through all those abstractions you built to avoid thinking about it.

Closing timing (getting your design to pass timing analysis at a desired frequency) is a great example. Physical details like how many gates are on some path between flops, how far apart those flops are and how big the gates are (bigger gate, bigger drive, faster transitions) and what else is connected to them (more fan out more capacitance to drive, slower transitions) matter and in standard synchronous design this is pervasive across everything you do. Abstract too far from those details and closing timing becomes a nightmare.

Imagine you wrote some standard data structure in the language of your choice. Now imagine the more call sites you have for the methods that manipulate it the slower it goes everywhere every single time you call it. Imagine some tiny edge case buried deep in the logic calling it occasionally could massively slow down accesses every time from everywhere. How would that change the way you build abstractions?

Reply on news.ycombinator.com