01-06-2015 04:26 AM
I have a urgent problem at hand using the VC709. I followed this video tutorial -> http://www.xilinx.com/training/vivado/axi-pci-express-mig-subsystem-built-in-ipi.htm
to create a block design, containing a MIG and the AXI PCIe Gen.3 Bridge IP to access the RAM on VC709 by PCIe.We had it running for the last 3 weeks.
I modified the example by addressing not 2 BARs at 128MB, but 1 BAR at 4GB and changed the PCIe Vendor information. The result is, that the PC won't boot or even show a BIOS screen, while the user_linkup, routed on a LED, is active. If I hold the FPGA in reset, so that linkup is inactive, the PC boots normally.
Taking a turn for the worse, using a quite expensive Dell workstation, that is needed in our application, we encountered that the PC won't start, but also won't recover even if the VC709 has been removed. This happened before, but we thought it to be just a coincidence, but the same situation reappeared today, leaving us with another dead motherboard. The PC was running normally, I programmed the boot flash on the VC709 and rebooted the PC for the changes to take effect.
Has anyone an idea on the cause of this behaviour (not booting), and on a possible damaged motherboard? Looking at the schematic, there should be no issue, since only signal lanes, clock, perst, present and GND are on the connector. There should be no possibility to generate a fatal short circuit or so.
01-06-2015 09:01 AM
Regarding the PC's that won't boot when the device is in place - I'm not sure of all the details - but it's not booting because the BIOS is unable to MAP the full 4 GB of address space that the BAR requires.
We've found that typical PC's won't map more than around 256 MB worth of address space. Above this and the BIOS just barfs, and the PC refuses to boot.
Since the BIOS is basically a black box, there's little you can do. You'll have to live with that limitation.
Maybe someone else who has more knowledge of BIOS design and OS interaction can chime in an offer more details as to what's happening here. I've found this limitation to be, well, silly, and a hinderance. FPGA's these days (with large DDR's often hanging off of them) can easily occupy a much larger address map.
As to why some of your PC's don't recover after you've removed the offending device... I don't have any explanations.
01-06-2015 11:40 PM
we managed to get a version with PCIe Gen.3 x8 and 8GB mapped DDR RAM to run in the week before christmas. It worked on both our system plattform (using the Dell workstation with a UEFI) as well as on our old test system (no 64bit CPU, PCIe Gen1 or Gen2), that runs with a plain old BIOS. Yesterday, I just changed the Vendor ID and device class in the PCIe IP in this previously working project, to work with our new driver, synthesized and implemented it as before, with the effect, that both PCs were not able to boot from it.
As of yesterdays test, after flashing back to the old, working mcs-file, the test system would not recover either. A bios reset/removing the battery made no difference here, too. So I'm now quite convinced, that either the process of flashing a new configuration or the reboot with certain configurations in fact killed the motherboard on some level. Weird thing: the linkup indicator still goes high shortly after power up, when the card is inserted, but no BIOS etc. appears.
Our main goal using the VC709 was to cut down development and reduce risks (also for the PC system), by using tested hardware directly from Xilinx...
01-07-2015 12:46 AM