--- Quote Start ---
Hi, I think both replies miss the point that there is discrepancy of hardware behavior and RTL functional simulation.
--- Quote End ---
The 'HD' in VHDL stands for hardware description...all you're saying with your point is that the source code that was written does not describe the hardware that is built...don't blame VHDL for an incorrect description. At best, you could blame the synthesis tool for not synthesizing exactly what was described, but you probably won't get much support on 'fixing' that problem.
--- Quote Start ---
If one assume this only relate to flops that always reset to some value as I discussed in original post, this is not a problem. But the real flop in ASIC or may not behave this way. Correct behavior is undefined output from flops (sometimes 0, sometime 1, never known a priori). Therefore, coding this way with left most entry as default state does not address the issue of undefined output from real flop causing the post place and route and hardware behavior to not match RTL functional.
--- Quote End ---
Many things can be coded that cannot be synthesized and built reliably. Synthesis tools will accept the following statement, but not actually implement it.
a <= b after 10 ns;
Again, it's not the language that is the problem.
--- Quote Start ---
Granted, one can say this is reset bug, so that should be fixed. But functional simulation will not catch this kind of bug when all states are defined.
--- Quote End ---
The functional simulation will catch it. If it doesn't, this implies that your testbench was not adequate in coverage to catch it.
--- Quote Start ---
I supposed one can go a step further and define and undefined state as left most in type declaration just to catch not properly resetted state machine, but that's so kludgy...
--- Quote End ---
True...also keep this in mind if you ever use integers where the leftmost value is a big negative number...the list goes on.
I'm not trying to rake you over the coals, but just pointing out that VHDL as a language is a tool that can be used for design. It does not guarantee a correct design no more than a hammer guarantees correctly fastened 2x4s used to build a house. Use your tools properly, but don't expect them to catch your every error, even if you think it is something 'simple'. Instead, you need to know the limitations of your tools in order to now how to apply them correctly.
--- Quote Start ---
As for HW, I was testing an FPGA hardware in lab long ago, and it would only work after dozen or so power cycles. Now I think of it, I suspect the guy who did RTL did not reset his state machine written in VHDL.
--- Quote End ---
Or it could be an unsynchronized asynchronous reset input...or lots of things.
Kevin Jennings
Honored Contributor
