PCIe transceiver offset cancelation

--- Quote Start ---

For the purpose of Transceiver offset cancelation I am using the external alt_gx_reconfig. I have been using a PLL output to feed this clock and using the pll_locked as the reset generator. Like this,

altgx_reconfig altgx_0_reconfig (

.offset_cancellation_reset(~pll_locked), // pll locked

.reconfig_clk (pll_clk_50), // clock from PLL

.reconfig_fromgxb (reconfig_0_fromgxb),

.busy (busy),

.reconfig_togxb (reconfig_togxb)

);

This works perfectly.

--- Quote End ---

But it is wrong. You should not control the reset signal with a signal that is not deglitched, eg., see Altera's KB example

http://www.altera.com/support/kdb/solutions/rd12172009_309.html

and the SignalTap II traces in the PDF associated with this thread:

http://www.alteraforum.com/forum/showthread.php?t=35678

--- Quote Start ---

But I need to free up this PLL and use for another purpose and I am thinking of using a clock coming directly from the pin. And I am not quite sure what to do with the reset

--- Quote End ---

You could tie it to an on-board power-on reset source.

--- Quote Start ---

Now I am thinking the pcie reset could be connected to the altgx_reconfig. Like this,

altgx_reconfig altgx_0_reconfig ( .offset_cancellation_reset (~pcie_rstn), // PCIe reset

.reconfig_clk (clkin_50), // clock coming from a x'tal

.reconfig_fromgxb (reconfig_0_fromgxb),

.busy (busy),

.reconfig_togxb (reconfig_togxb)

);

But that did not work either. PCI express is not responding.

--- Quote End ---

That is because the PCIe core needs to start link training as soon as reset deasserts, eg., see p5 of this doc for the requirements.

http://www.ovro.caltech.edu/~dwh/wbsddc/ts4_power.pdf

You need to tie the reset to something that deasserts once the FPGA is configured, eg., a reset supervisor input, or an internally generated signal that asserts and then deasserts at power-on.

Cheers,

Dave

Thanks Dave! I had in fact gone through the document you mentioned about deglitching the reset, but I didn't experience any issues so far without it, I guess I was just lucky.

I will try to use an internally generated reset pulse and see if that works. I will post the results tomorrow. And I have to read this, good document http://www.ovro.caltech.edu/~dwh/wbsddc/ts4_power.pdf. Thanks!

Hmm.. Something is still wrong. I did create a power on reset type signal internally. I can see in signal tap that the reset to altgx_reconfig block is assserted (see picture) and kept for about 640ns, alt_gx_reconfig_busy is asserted and I also see that it is deasserted later on(not in the picture), dont know after how long(I am going to try to signaltap and see when the pci reset is asserted and when the busy is deasserted).

https://www.alteraforum.com/forum/attachment.php?attachmentid=7016

--- Quote Start ---

Hmm.. Something is still wrong. I did create a power on reset type signal internally. I can see in signal tap that the reset to altgx_reconfig block is assserted (see picture) and kept for about 640ns, alt_gx_reconfig_busy is asserted and I also see that it is deasserted later on(not in the picture), dont know after how long(I am going to try to signaltap and see when the pci reset is asserted and when the busy is deasserted).

--- Quote End ---

The Qsys PCIe thread that I linked to above has some SignalTap II traces.

I recently posted some ALTGX/ALTGX_CONFIG traces in this thread too:

http://www.alteraforum.com/forum/showthread.php?t=40144

http://www.alteraforum.com/forum/attachment.php?attachmentid=6985&d=1364498035

Cheers,

Dave

Ok, I think I got it to work. The issue was that the time the reset was asserted was too short. I increased it from 640ns to about 8.5us and looks like the PCIe interface is working. I will keep an eye on it and needs more verification, but looks like that was it. Thanks Dave for the documents and information.

https://www.alteraforum.com/forum/attachment.php?attachmentid=7030

Your SignalTap II trace still does not look correct. Your trace shows pcie_rstn high, i.e., deasserted. Offset cancellation should have completed long before reset deasserts, i.e., I would expect to see pcie_rstn low in your traces.

Cheers,

Dave

--- Quote Start ---

Your SignalTap II trace still does not look correct. Your trace shows pcie_rstn high, i.e., deasserted. Offset cancellation should have completed long before reset deasserts, i.e., I would expect to see pcie_rstn low in your traces.

Cheers,

Dave

--- Quote End ---

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.

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

6. PCIe enumeration... blah blah blah

7. PCIe pkt transfers goes on.

So pcie reset gets asserted after the 100ms time after powerup, 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? 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 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

Thanks again Dave!

Let me get back and do some more checking, I was thinking that the reset might be pulled up high at power-on and host asserts the reset once the BIOS chip is powered up and host starts its enumeration sequence. I will check more on the timing aspect of things and get back with more data,

And thanks for sharing the documents, its a really good one. I need to read that.

--- Quote Start ---

Let me get back and do some more checking, I was thinking that the reset might be pulled up high at power-on and host asserts the reset once the BIOS chip is powered up and host starts its enumeration sequence. I will check more on the timing aspect of things and get back with more data,

--- Quote End ---

Its quite possible that is the case, and it would probably be acceptable. Its worth poking around in your hardware to get a sense of what is going on at the system level, and then write your testbenches to match that and several other power-up sequences to see if your design behaves correctly.

Cheers,

Dave