--- Quote Start ---
Let me see if I understand this correctly. I think the sequence of events is,
1. Powerup of FPGA (PCIe reset is not yet asserted)
2. FPGA Config done
3. altgx_reconfig block gets the reset and goes busy (as in my signaltap) and starts the transciever calibration.
4. altgx_reconfig busy gets deasserted. ready for PCIe handshke with root complex.
--- Quote End ---
The ts4_power.pdf I linked to has the power-on sequence. PCIe is supposed to be asserted by the host. It should asserted for steps 1-4
--- Quote Start ---
5. All these steps up until now shouldnt take more than 100ms. Now the PCIe_rst_n is asserted. And the PCIe hard IP resets and ready for transfer
--- Quote End ---
They won't take less than 100ms, but they could take longer - again, look at the diagram I have already referred you to.
--- Quote Start ---
So pcie reset gets asserted after the 100ms time after powerup
--- Quote End ---
PCIe reset should be asserted any time you trigger from power-up - see the diagram on p5 of the doc.
--- Quote Start ---
my signaltap show the activity just after the fpga config done where pcie reset should be deasserted and will be asserted later on. Am I Correct?
--- Quote End ---
Its possible that your host does not assert reset at power on, even though it should. This would be analogous to what would happen if you just hit the reset button on your host CPU. But even in that case, the host should assert the reset in the sequence shown in the diagram I linked to. The document lists all the references to the specifications that have those timing requirements listed.
--- Quote Start ---
Or were you asking why I dont have the pcie_rstn low in my signaltap towards the end of it? I only have only captured 8k samples after powerup(160us)
--- Quote End ---
Grab an oscilloscope and look at the timing of your reset.
Its not necessarily wrong, its just something that is worth looking at and paying attention to. This will save you from debugging a problem with your hardware, when infact its your host that is in violation of the specifications.
Note: If you do always see PCIe reset deasserted in your traces, then check the timing of your FPGA configuration controller. If the configuration controller for this board was designed incorrectly, the FPGA may be taking too long to configure. For example, the FPGA should be configured via Fast Passive Parallel or Passive Serial (with a faster clock than Active Serial), and almost never via Active Serial (since it takes too long)
Cheers,
Dave
Honored Contributor
