--- Quote Start ---
Ok so, I got some more data.
--- Quote End ---
Great! Thanks.
These are reasonable waveforms.
Keep in mind that the FPGA offset cancellation routine only ever runs when the FPGA is first configured, eg., when its powered or reprogrammed via JTAG or another configuration source. After that point, the ALTGX_RECONFIG busy signal will not assert right after reconfig_reset or offset_cancellation_reset deasserts to indicate offset cancellation is running.
Note: that if you reconfigured your FPGA using JTAG, pressed the reset button, and then took the SignalTap II traces, you would see the ALTGX_RECONFIG busy signal asserted while offset cancellation is running, and PCIe reset would be deasserted (if you missed the 5ms low time of the signal).
--- Quote Start ---
So I think my signaltap in the earlier post shows that the pci reset occured long before the FPGA configuration finished and thats the reason I am not seeing reset being asserted in the waveform.
--- Quote End ---
Its possible. But if those plots were also showing offset cancellation running (busy high), the reset signal should be low (if it was a power-on SignalTap II trace).
--- Quote Start ---
That also means that I am not really getting a proper reset to my FPGA logic (except for the PCIe hard IP block) since all my logic resets are connected to the pcie reset (except for the altgx_reconfig block for which I generated a reset internally).
--- Quote End ---
5ms is more than long enough for a reset.
The PCIe reset should be passed through reset synchronizers that asynchronously assert and synchronously deassert for each of the clock domains in your design that PCIe reset is supposed to reset. Assuming all of these clocks are in the MHz range, 5ms is thousands of clocks.
Is the PCIe interface working in either or both of these reset sequences/conditions?
If the power-on-reset is not working, then probe CONF_DONE to see when your FPGA is configured relative to PCIe reset deasserting.
Cheers,
Dave
Honored Contributor
