Honored Contributor
Honored ContributorI sent an email to you.
--- Quote Start --- Ok, so this is a design "feature" then. This complicates the use of this board, since it will work in some motherboards, but not others. --- Quote End --- This board is not sold separately, but is part of a larger system, so it is integrated with a known (tested) motherboard in all situations. And since we are using hard IP, (which would be up and running at powerup), even though configuration is delayed, the PC is able to talk to the hard IP and get it enumerated once PCIe reset is deasserted (even though I am wondering how it is working with a late algx_reconfig_reset). EDIT : I think my statement not be true. Even though its a hardIP implemetation, FPGA reconfiguration has to be finished for the PCIe hardIP to respond to config read requests from the motherboard? --- Quote Start --- The board designer's responsibility is to perform a timing analysis (like the one in the doc I linked to) and as shown in this doc: http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf For example, see the timing diagram on p30 where 16-bit flash reads are used to program an FPGA in FPP mode. The flash read access timing is what limits the design. Using page-mode flash helps. Review your design. Perhaps the board has page mode flash, and you're not using that feature. That might allow you to speed things up slightly. Cheers, Dave --- Quote End --- Yes, I have M29EW flash device (micron), and it supports the page buffer read mode (with 25ns read access time), but seems like the PFL doesnt have that option. I only have a spansion page mode access (in advanced read mode) listed, which gave me a slight improvement in read latency, but it still takes more than 500ms to configure the FPGA. I found out why there is an added delay during powerup, it was because the configuration was only starting once the FPGA reset was deasseted (since the PFL was configured to reprogram on pcie reset), Once I removed it, the fpga programming takes about ~600ms, still outside the reset assertion. Thanks for sharing the document.
