How to debug FPGA designs

This is supposed to be a followup to my previous question how to get a FPGA design that will definitely work on actual hardware. I have made a lot of progress since I asked the above question (thanks to amazing advices and comments). I have now moved on to designing much larger FPGA designs, and have learnt a lot, and am now facing much more difficult to solve problems (nothing that I don't like, but some occasional advice is always good).

I am now very familiar with the various design methodologies and practices that need to be undertaken while designing FPGA circuits. However, once in a while I manage to screw things up by writing something stupid in the code that costs me a lot of time and energy. Also, as my designs have been getting much more complicated (recently I have been working on using the Memory Controller inside the Xilinx Spartan 6 FPGA and writing a traffic generator for the same) and the simulation in Xilinx ISim now takes a hell lot of time (sometimes I have to wait for half an hour to check whether my design works, only to find that I made some stupid mistake, and start over again).

This has become frustrating now, and I need some advice. Until now, the fool proof plan I used to ensure everything in my design works properly was to check the value of each and every register and wire in my design and checking if their values are as expected, and sometimes looking at the RTL schematic. It has become very tedious now (because of the reason stated above) and I am wondering whether there are better ways to debug an FPGA design, and ensure that they work properly :

• maybe a better way of debugging circuits
• maybe a better simulation software

The advice that I have gotten on similar topics in the past has been gold, and I thank you all for your efforts.

• Are you writing test benches or just eyeballing things in the simulator? – Willis Blackburn Mar 12 '16 at 18:49
• A hint : Somewhere on the MIG simulation model you can turn OFF the initialisation process (saving about 100us sim time or many minutes clock time) for simulation but ensure it is ON during synthesis. – Brian Drummond Mar 12 '16 at 19:06
• @BrianDrummond Thanks for the amazing advice. After looking only for a minute or so, I found the exact place where I could turn off the initialisation process. The MIG made it very simple to do so. I just had to se the C3_SIMULATION_PARAMETER parameter (in the top level module that MIG provides) to TRUE which would automatically ignore the initialisation process. I can clearly see that when C3_SIMULATION_PARAMETER set to TRUE, the memory controller starts working at about 150 ns (after 100ns of global reset time). – ironstein Mar 13 '16 at 3:02

The key to reduce the simulation time is splitting the design into smaller sub-modules which can be simulated or even verified much faster. Thus, you will identify and fix bugs even faster.

Of course, at some point you have to simulate the overall design (or larger parts of it). But, if you design the interface of the sub-modules carefully, then only a small number of bugs will usually need to be fixed. And every indentified bug in the larger design can be used to improve the testbench for the sub-module.

Yes, the simulation of the Xilinx Memory Controller takes up a lot of time, but it is worth. Debugging a design by using the on-chip logic analyzer (Xilinx Chipscope, or Xilinx Vivado) is also possible, but you will have to place & route your design every time, you are adding a signal to the logic analyzer to identify the bug at first. Then to fix the bug, you have to synthesize it again. This is often more time consuming, then simulating even a compelx design.

Great to see that you have reached this stage! From now on you must try to fathom this very well known fact that says: "writing test-benches is truly an art."

You must be aware of "self checking test benches", the technique helps you to automate some testing procedures.

Remember even big companies like Intel could not get the mastery on the art of testing and e.g. produced defected Pentium processors in 1994 that could produce wrong results when doing advanced floating point calculation.

Testing is tough, it is an art.