--- Quote Start ---
You are right, I had it that way before, but faced some issues with binary update at site when the host PC just does a warm boot after a system update. So now I just put it to update every time there is a PCIe reset.
--- Quote End ---
This "fix" is causing you other problems, so really you need to fix this problem first.
--- Quote Start ---
I would like to understand how to do that(in linux), Can you please point me to any docs? or give some more info, Thanks! We have PC platform, but I may get some idea.
--- Quote End ---
Send me an email to my forum name and I'll forward an email discussion that I had on this topic.
--- Quote Start ---
I had to check it.. Its taking about 600ms, and since there is an internal delay or something on a powerup, it takes more than a sec (1100ms) after powerup before the FPGA is programmed and ready.
--- Quote End ---
This is not good. You need to determine all of your power on timing delay sources, eg., look at your on-board power-supplies, their ramp times, etc. Your board may be violating the power-on-requirements of the FPGA, i.e., hiding even more issues.
--- Quote Start ---
So definitely I am missing the pcie reset (in both cases, PC Cold Boot/Warm boot) I attached the waveforms as well. So, I am going to generate a reset after the PCIe reset and the reconfiguration.
--- Quote End ---
Generating another reset is not going to help. What you are not looking at in these traces is the PCIe bus activity. Your PCIe end-point will miss the traffic on the bus that configures it. If its working in this motherboard, then its just luck. The next motherboard you plug it into, it may not work.
The "solution" is to;
1) Configure the FPGA at power-on "as fast as possible", ideally within 100ms, but if you cannot achieve that, then faster than the deassertion of PCIe reset.
2) Do not reconfigure when PCIe reset asserts. There is no reason to. The FPGA just needs to treat the PCIe reset as a reset source. You don't have to reset all logic within the FPGA if you do not want to, eg., you can have a "last reset reason" register that sets a power-on bit at power on, and a PCIe reset bit when PCIe reset occurs (of course if your FPGA configures faster than PCIe reset deasserts, then you'll only ever see the PCIe reset bit set).
Cheers,
Dave
Honored Contributor
