I am working on a personal FPGA project and could use some advice from this awesome community. I am currently using an iCE40 chip, and I want to get the best possible debugging experience without too much hassle. I have been looking into different debugging tools, but I am not sure which one would be the best fit for my project.
Has anyone here used a good debugging tool with an iCE40 FPGA? I’d love to hear any recommendations or suggestions. Bonus points if it is something that’s beginner-friendly but still powerful enough for more complex tasks!
I haven’t got much experience debugging FPGAs, but I have debugged a number of FPGA projects. I always do my debugging in a simulator because that seems to be so much easier than working with hardware. I have used both iverilog and Verilator and I can recommend both of them. They work differently and they both have a bit of a learning curve. The learning curve is still better than trying to debug in hardware though.
The best thing about debugging in simulation is that you can create a custom initial state and that will reproduce your problem in just a few cycles, whereas with hardware you will have to wait for everything to be ready and you may be gathering vast amounts of useless debug data during this time.
Welcome to the forum!
As @lloyd mentioned the best way to debug your FPGA designs is to use simulation. Two commonly used tools for that is Icarus Verilog and Verilator.
The big difference between real hardware and using simulation is that you get full view of all signals inside your FPGA design at once. That said, depending on the size of your design, you might not want to simulate everything but rather individual modules. Simulation can take a while to run.
When debugging your designs on an actual FPGA, you have to add a module that brings out the signals you are interested to the outside world. You either use spare GPIO to expose internal signals, or in some cases you drop in a block that acts as a logic analyzer.
I personally found that in majority of cases, the issues inside the design become clear after running through simulation though. Using the on hardware debug techniques comes with challenges where the debug can affect timing of the whole design. But on the other hand some timing specific things might not be possible to simulate and expose the issue you are hunting for. So at the end it is a case by case choice which path to take.
