| ▲ | variadix 10 hours ago | |||||||||||||||||||||||||
I’m not exactly sure what you’re getting at, but I think I’ve had a similar question: why don’t HDLs have language elements more representative of what digital circuits are constructed from, namely synchronous and asynchronous circuits, rather than imperative input triggered blocks (processes IIRC, it’s been a while)? I always thought it was confusing to design a circuit mentally (or on paper) out of things like muxes, encoders, flip flops, etc. and not have language-level elements to represent these things (without defining your own components obviously). I remember looking this up, and I believe it’s because the languages were originally designed for simulation and verification, and there are things you might want to do in a simulation/verification language for testing that are outside of what the hardware can do. Mixing the two is confusing IMO, but clearly demarcating the hardware-realizable subset of the language would be better than the current state. | ||||||||||||||||||||||||||
| ▲ | nickelpro 9 hours ago | parent [-] | |||||||||||||||||||||||||
Because it's both slow and terrible? You generally do not want to simulate or describe raw gate-level netlists. Both languages are capable of that. Old school Verilog (not SystemVerilog) is still the defacto netlist exchange format for many tools. It's just aggravatingly slow to sim and needlessly verbose. Feeding high-level RTL to Verilator to do basic cycle-accurate sim has exceptionally fast iteration speed these days. | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||