Timeline for How to get a FPGA design that will definitely work on actual hardware
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 18, 2019 at 7:29 | comment | added | danmcb | yes. Actually just like other areas such as software or conventional hardware, the starting point is to break the problem into blocks, and then ask yourself "how will I know when that block works". Then do it. Build your design block by block, then put the blocks together and again test that what you get is what is expected. Sometimes you might realise that with a better block-level design it would be cleaner or easier, so you backtrack. | |
| Mar 2, 2016 at 17:12 | comment | added | Voltage Spike♦ | It could be done that way also, I found it useful to design a waveform on paper because it gave something to compare against. Like an ADC waveform, the timing was designed and then compared to the modlesim output, then verified physically. If the modelsim output is correct, then compare it to that. The code was strongly typed (I forgot to mention that), but that is really important. That is why I much prefer VHDL over verilog, there are less shortcuts you can take. And it makes the code much more readable. | |
| Mar 2, 2016 at 17:05 | history | edited | Voltage Spike♦ | CC BY-SA 3.0 |
added 131 characters in body
|
| Mar 2, 2016 at 14:32 | comment | added | user16324 | Quite good : to "rigorous design" I would add "using the type system". Example : an array index of appropriate type such as the array's range, no need to test for out of bounds condition. I would only disagree with "waveform compared with the designed waveform on paper " ... the designed waveform should be in VHDL by that stage, (or perhaps read from text file) and the simulator should perform the comparison. | |
| Mar 2, 2016 at 9:27 | comment | added | Paebbels | +1 for "s cubed" or \$ {simulation}^3 \$ | |
| Mar 2, 2016 at 6:58 | history | answered | Voltage Spike♦ | CC BY-SA 3.0 |