I have a PC720 in a Linux system, and I'm trying to configure the FPGA via the JTAG interface.
Starting with the system running and a valid Stelllar IP application in the FPGA, I load a new FPGA configuration via JTAG. In this case, the configuration is that of the reference application supplied by 4DSP with our system ('pc720_fmc150_fmc150_325t', which demonstrates operation of the PC720 with two FMC150 cards). I observe:
- The PCIe bus remains enumerated. 'lspci' finds the board at 01:00.0 with "Xilinx Corporation Device eba3" - Running '4fm_reset PC720 0' produces "Successfully reset device 0" - Running '4fm_get_information PC720 0' produces "Could not read the constellation revision." - Other 4fm utilities as well as the reference software app 'FMC150TestApp' fail with "Could not read the constellation revision."
I then re-boot the host computer. After that, the utilities and reference software run normally, without errors.
Repeating this process (where I reconfigure the FPGA from exactly the same bitfile) produces the same results. It's necessary to reboot again in order to get the application to work.
Why is it necessary to reboot the host in this situation? I know that rebooting forces bus enumeration, but the bus is already correctly enumerated and basic PCIe communication is working. If the FPGA logic needs initialization, why is that not accomplished by'4fm_reset'? Is there a way to initialize the firmware correctly without rebooting?
about 2 years ago
This is completely normal behavior. I will try not to go in depth, but I have do provide some details anyway.
1) The PCI enumeration is done by the BIOS once, indeed. 2) The FPGA has the PCI engine so reprogramming the FPGA terminates the PCIe link, windows/linux loose its link, but it is still known by the operating system, the table handed by the BIOS are still existing and the memory mapped to the device by the operating system can still be used. This is what we call a phantom PCI device, it is still known by the OS, still mapped to the OS, you can write to the memory mapped and if you read from the memory mapped you get 0xFFFFFFFF, because the PCIe have no more configuration, BAR, etc.. 3) The 4fm_reset() actually writes on the PCI BAR, this cannot fail. 4) The other utilities will fail because the API only gets timeout values from the PCI (0xFFFFFFFF as value for all the reads)..
So yeah, the behavior you see if common for all operating systems; Windows, Linux and Vxworks and will be same for any programmable hardware having the PCIe link in it. In a way it makes sense, after reprogramming the FPGA you loose all the configuration, typically all the PCI configuration done by the BIOS is gone. BAR registers have 0 so any access to the previous address mapped by the OS will not reach the device, the link from virtual kernel memory down to the PCI BAR is simply broken
There might be low level hacks for that in the software but this should be properly tested. This is something we could investigate for you, please contact email@example.com if this is a path you wanna take.