3 ms·

Very nice comment, I agree with it 100%. Being able to apply good software desgin at a RTL design is a killer feature of MyHDL in my opinion. The possibility t

by aprdm 12y ago

Very nice comment, I agree with it 100%. Being able to apply good software desgin at a RTL design is a killer feature of MyHDL in my opinion. The possibility to mix RTL and high level software is a very nice feature, for exemple: To make a FFT in Python in few lines and compare the output to your RTL FFT with asserts. And script it so you can loop through a different number of fixed bits width and check the TVE at each bit width. To do this in Python I used ~50 lines, in VHDL it would be a headache and I probably would end up needing to use matlab to compare the results.

ajross 12y ago
I guess I don't see this as such a big deal. My own experience is limited, but doing this kind of validation by iterating over the input space using e.g. perl to generate verilog is fairly straightforward. I've done exactly that with decent success; again it's a straightforward software problem, and I'm a software guy. I think the problems I had is sort of the converse: hardware is hard. Reasoning about hardware is hard. And having the representation of your hardware about which you much reason be expressed in the actions of an interpreted program (where the synthesis is a side effect basically) makes things harder than it has to be. The RTL ends up being polluted with simulation constructs and hiding the meaning I'm trying to see. And if anything MyHDL is actually worse at this than Verilog or VHDL.
- oelang 12y ago
  Because reasoning about hardware is hard it's important to be able to rely on simulation. I'm not saying that all issues can be caught/detected in simulation but many can. In most designs 90% of the code (typically the synchronous logic) can be fully debugged in simulation. Ok there is still a portion that can't be debugged, and you'll likely spend a large amount of time on that final 10% but the alternative is certainly worse. A good designer can avoid constructs that can't be or are very hard to simulate correctly. A good example is signals that have to cross clock domains, metastability is easily missed in simulation and the problems it causes in actual hardware are huge. Good hardware design tries to avoid or encapsulate these kind of constructs. Beyond this you still have to deal with the analogue world and that is often hard to simulate. Clock generators that misbehave, working with memory controllers (and buggy IP cores): it's not all under your control and that why hardware design often feels so hard. A lot of time is spend on these issues, but that's only because the rest is made easy by using VHDL.

by aprdm 12y ago

ajross 12y ago

I guess I don't see this as such a big deal. My own experience is limited, but doing this kind of validation by iterating over the input space using e.g. perl to generate verilog is fairly straightforward. I've done exactly that with decent success; again it's a straightforward software problem, and I'm a software guy. I think the problems I had is sort of the converse: hardware is hard. Reasoning about hardware is hard. And having the representation of your hardware about which you much reason be expressed in the actions of an interpreted program (where the synthesis is a side effect basically) makes things harder than it has to be. The RTL ends up being polluted with simulation constructs and hiding the meaning I'm trying to see. And if anything MyHDL is actually worse at this than Verilog or VHDL.

oelang 12y ago
Because reasoning about hardware is hard it's important to be able to rely on simulation. I'm not saying that all issues can be caught/detected in simulation but many can. In most designs 90% of the code (typically the synchronous logic) can be fully debugged in simulation. Ok there is still a portion that can't be debugged, and you'll likely spend a large amount of time on that final 10% but the alternative is certainly worse. A good designer can avoid constructs that can't be or are very hard to simulate correctly. A good example is signals that have to cross clock domains, metastability is easily missed in simulation and the problems it causes in actual hardware are huge. Good hardware design tries to avoid or encapsulate these kind of constructs. Beyond this you still have to deal with the analogue world and that is often hard to simulate. Clock generators that misbehave, working with memory controllers (and buggy IP cores): it's not all under your control and that why hardware design often feels so hard. A lot of time is spend on these issues, but that's only because the rest is made easy by using VHDL.