PC works well after programming FPGA by JTAG for ML555 PCIE design. But if i program the FPGA again,the PC immediately is hung.
Power off and on ,after reprogramming FPGA and reboot pc,it works well. However,the result is same if i program the FPGA again,the PC immediately is hung.
This is expected behavior. Sometimes it will hang and sometimes not, it kind of depends on the system and what's going on at the time.
If you have a device that has been recognized by the system and enumerated, you can't reprogram it without issuing a system level reset or power cycle. If you use JTAG to reprogram the FPGA that was previously recognized, it will momentarily "disappear" from the pcie subsystem, plus it will lose its configuration space settings. At that point, the system can no longer communicate with the card. It will not remunerate it without a reset occurring. It may hang or it may not. I can do this with my bench system I use for test and debug and it does not hang, but the card is no longer recognized until I issue a reset. It could be that once you reprogram your application tried to access the card and since the card is no longer there from the systems point of view, it caused a completion timeout to occur which will often hang the system.
This sounds like a problem I am trying to solve. I intend to purchase a HiTech board that has a Virtex 5 device as the PCIe interface. I believe that this is very similar to the ML555 board as both have hard wired PCIe endpoints.
In our product we want to select, in software, from a number of possible FPGA configurations. Once the FPGA is programmed the software should be able to communicate with the board and its new configuration.
Is it possible to issue a reset or a rescan (remuneration?) of the PCIe subsystem and keep the PCs power on i.e. keep the software running?
I have been using the HTG boards very successfully, but have run into the same issue. We want to dynamically configure the FGPA and we have not found a way from Linux to re-enumerate the PCIe bus after the reconfiguration. Linux does not freeze up, but it no longer recongized the FPGA as a PCIe device after configuration. We can reboot Linux and the PCIe bus gets enumerated correctly, but we are looking for a way to do this without rebooting.
I know that the similar problems were solved for COMBOv2 platform (http://www.liberouter.org/hardware.php?flag=2), but unfortunately I am not realy sure about details of the solution (only that it is possible to change design on board without rebooting computer and of course software will comunicate with a new design through PCIExpress), so you may try to get some informations from project page.
Jan
mcmurtre wrote: I have been using the HTG boards very successfully, but have run into the same issue. We want to dynamically configure the FGPA and we have not found a way from Linux to re-enumerate the PCIe bus after the reconfiguration. Linux does not freeze up, but it no longer recongized the FPGA as a PCIe device after configuration. We can reboot Linux and the PCIe bus gets enumerated correctly, but we are looking for a way to do this without rebooting.
We are also trying to figure out a way to reconfigure the FPGA without requiring a system level reset as doing so is not very practical in our application. For demo, we are using the HTG-V6-240
So far, we are looking into the following solutions:
A special method in windows to save and restore the PCI enumeration states. In Linux, this approach utilizes the pci_save_state and pci_restore_state routines. We're stil looking for similar routines in windows...
Partial reconfiguration to keep the PCIe endpoint alive during configuration. This is not nearly as flexible and adds a layer of complexity that may not work well in production.
Dual FPGAs with one FPGA dedicated to the PCIe bus.
The liberouter solution poined out by Jan *seems* to simply utilize very fast reconfiguration. This is alluded to in the following presentation:
The configuration bus for the COMBO board uses a Spartan FPGA with fast RAM to configure the FPGA very quickly. Based upon the statement "Rapid design update through PSRAM+UserJTAG and background transfer to FLASH" on page 9, I assume that this happens so quickly that the computer/PCIe root complex probably doesn't know this even happened. This is only an assumption as I don't have any inside information. :-)
Has anyone come up with any other ideas for making this work?
Just to let you know we have been using your option 1 in Linux: saving and restoring the PCI state and have been able to utilize the PCIe bus after a reconfigure without problems. I explored option 2, but was not excited about the added complexity, especially since we already have some timing difficulties.
Thanks for the information. We found a somewhat comparable solution in windows. Testing revealed that “Scan For Hardware Changes” in Device Manager (and possibly uninstall/re-install of driver) was enough to bring the reconfigured FPGA back to a usable state without needing a reboot.
So we know it can be done in software, it’s just a matter of finding the best way to programmatically do the magic part of “Scan For Hardware Changes”.
