I'm working on an FPGA controller connected through PCIe. The only way I can debug the hardware is using chipscope. So I execute commands through my driver and check out the signals from the FPGA.
The problem is that it takes a lot of time to build the project and load it to the FPGA every time I want to check a signal to debug the project.
Is there an easier way to debug an FPGA connected to PCIe?
Is there a way I can simulate all the PCIe signals and not have to run the FPGA at all?
To be more specific, I would like some kind of infrastructure that I can write a command through the linux driver (writeq) and TLP packets would be sent to my verilog design..
Best Answer
Yes - you should be debugging in simulation rather than using chipscope on the hardware. For complex designs you will almost certainly save time in the long run by simulating.
Xilinx provide some help for simulating PCIe, you should first try and simulate the example designs (see here for Virtex 7 or this Answer Record for 6 series).
Since you are probably using a hard IP core you likely don't want to verify the PCIe core itself, you just want to co-simulate your driver software with your RTL. Essentially you want to run your driver code to create TLPs in your simulation to debug the interaction between your driver and the hardare?
The best way to achieve this depends on your driver. For example I've done something similar for a userspace
mmapbased driver: source code is available on Github. If you want to co-simulate kernel drivers you may want to investigate QEMU or similar. Alternatively you could mock the kernel calls.The best option really depends on precisely what you are trying to achieve. To validate your hardware, you may be best off building on the Xilinx examples, driving the BFMs and not trying to co-simulate your driver. If you want to develop software against hardware then investing time in co-simulation may be beneficial.