1

Im 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?

yonigo
  • 987
  • 1
  • 15
  • 30
  • 2
    I think this should be moved to [ElectronicsSE](http://electronics.stackexchange.com/) as it is mainly about debugging hardware. – Morgan Jul 03 '14 at 15:42
  • 3
    Search for "PCIe BFM" (Bus Functional Model). This is what you use when you want to simulate one side of a bus protocol. I don't know if you'll find one, but something may be out there. – Tim Jul 03 '14 at 16:30
  • What layer of PCIe are you implementing? Many FPGAs have hard IP cores and expose streaming interfaces for TLPs... – Chiggs Jul 03 '14 at 20:49
  • 1
    @Morgan the question is actually asking how to move away from hardware and debug in simulation, which has historically been an acceptable topic for SE. – Chiggs Jul 03 '14 at 20:50
  • @chiggs, that is not how I understood the question, I was focusing on this line `Is there an easier way to debug an fpga connected to pcie` but I think the OP really just wanted to debug the design. – Morgan Jul 04 '14 at 07:54
  • You can use coregen to generate a Integrated block for pci-e. When you do that you will also get a simulation model for the generated pci-e. You could modify it to suit your needs. – brano Jul 04 '14 at 08:11

2 Answers2

0

One thing you can do is to capture a trace of the PCIe transactions into a buffer, then read that out and replay it as the stimulus in a testbench during simulation.

You can use a BRAM or possibly FPGA-attached DRAM for the buffer.

You will probably need an alternate path for reading out the buffer. Xilinx has a JTAG to AXI master that you could use to read out the buffer. Or if your PCIe is stable you can read it out that way.

Jamey Hicks
  • 2,340
  • 1
  • 14
  • 20
0

As mentioned in several comments, you want to do detailed debugging in simulation rather than in hardware. The loop time to debug via chipscope, determine the problem, come up with a new set of signals to probe, recompile, and push new code into the FPGA. This is a very painful process compared to debug in simulation.

If you are trying to debug PCIe, you can either get a PCIe BFM from a commercial vendor or possibly off of OpenCores, or you can use the capture buffer described.

If you are trying to debug your own logic and PCIe only comes in because that is the interface to the device, you are best off writing your own BFM that drives transactions to your internal logic as if it were the PCIe core. Reproduce the problem in sim, debug there, then go back to the FPGA once you have good code coverage and a decent suite of passing tests.

Guy
  • 167
  • 9