| Very impressive work. I've only spent about an hour going through this post and its predecessor. I'm a career software engineer, although I've been working very closely with a team of FPGA developers for the last couple of years. HDL engineers have a very strong preference to see the types of all nets and registers clearly defined. The pain points are mostly in organizing and stitching together larger projects out of smaller modules. You see this reflected in common project structures, where leaf nodes are in straight VHDL or [System]Verilog but larger structures may be stitched together with TCL or some custom in-house tooling. HDL replacement technologies have a tendency to throw out both the low-level language and the abstraction language. IMO this is in part because they are being built by software engineers who have a hard time with the low-level parts of the standard HDLs. But its not the low-level parts (eg, process blocks, type system, and arithmetic expressions) that are busted. Its the organization and abstraction parts (eg, the module systems) that are busted. I know this sounds counter-intuitive, because as a Schemer I know you're used to building systems where its more or less the same abstraction "all the way down" using a general model of computation as the base. But the practicing hardware engineers I know don't care. They are fully aware of the message-passing model that backs the HDLs. To them that model is an obstacle to be overcome on the way to building circuits. Caveat: my HDL colleagues are all from the US aerospace/defense sector. They are firmly on the side of preferring VHDL over [System]Verilog based on the former's strictness and explicit behavior. So my perspective and feedback is inherently biased in that direction. |
Can you expand on this? I don't quite understand what you mean by "message passing model" in the context of HDL. Signals are sort of like messages in the no shared memory sense but there is still plenty of spooky action at a distance when synthesizing.
Unless your level of abstraction is at the interconnect level like AXI, timing is always a huge pain and small changes in design can have significant downstream impact as signals are rerouted. Sure you could create a data structure that represents a complex module but it'd be a monstrosity that accepts dozens if not hundreds of closures to enable tweaks like "delay this half of the bus by n and the other half by 2n" that will have to be modified anytime there is a significant refactor that reorganizes the modules.
The core problem of applying software abstractions to FPGAs is that while HDL describes logic, it compiles nondeterministicly (to humans) into a format where physical placement and fit makes or breaks that logic. At that point, it's not really an abstraction as programmers see it but as, say, cabinet makers see it: there is a variety of well characterized off the shelf parts that they can order and they have a suite of power tools like grinders and routers to modify that part to fit their specific use case. The "arguments" or input for the abstraction have to be incrementally discovered by first grinding or cutting, then trying the part out to see if it fits, then mixing some sawdust with glue to fill in some spot, then grin or cut some more, and so on - rinse and repeat until all parts fit together correctly.