DS320PR810: DS320PR810 RX_DET pin

Thank you David.

My concern was due to this:

"Rx CM impedance held at Hi-Z until detection Reset by asserting PD0/1 high for 200 µs then low"

In my system the PD0/1 are connected to the PRSNT# signal and not to inverted version of PERSTn. My concern is that  PRSNT# is held constantly LOW by the mother board so "asserting PD0/1 high for 200 µs then low" is not possible.

Hello Avi,

I understand, thank you for clarifying your concern.

Avi Avrahamy said:

In my system the PD0/1 are connected to the PRSNT# signal and not to inverted version of PERSTn. My concern is that  PRSNT# is held constantly LOW by the mother board so "asserting PD0/1 high for 200 µs then low" is not possible.

I believe that in your application, PRSNT# (tied to PD0/1) being held constantly low would just disable Power Down functionality of the DS320PR810 upon power-up. The 200us high / subsequent assertion low would only be needed to toggle the PD signals to the device.

Is PRSNT# connected to an equivalent PCIe endpoint PRSNT# pin? Or simply strapped to GND directly?

Best,
David

Hi David,

The PRSNT# signal (actually PRSNT1_n on pin A1 of the edge connector) is connected on my add-in board to PRSNT2n_x8 (pin B48 of the edge connector) to indicate to the root complex that an 8 lane add-in board is plugged. My add-in board does NOT connect it to GND since according to PCI standard only the system board should connect it to GND, and the Add-in board simply short it to the appropriate PRSNT2n_x pin.

In addition, this connection of PRSNT2n_x8 and  PRSNT# are connected to the PD0/1 pins. I made a measurement and it is in 0V.

The problem with my system is that sometimes it works and sometime does not. When it works properly, I get full PCIe Gen4 throughput  for hours so there is no signal integrity problem on the fast lanes. The issue is always upon reset or power down/up - sometimes the training does not succeed and I suspect that the PD0/1 or RX_DET are not properly connected. I suspect that the PCI Express Rx detection state machine of the DS320PR810NJXT fails. My setting is :

PD0=PD1=PRSNT# (I also tried constant GND).

RX_DET = L4 (float) .

Maybe the fact that I do not have the PERSTn (inverted) to the PD0/1 makes the state machine fails? Will it be better to disable it altogether (RX_DET = L0) even though this is not recommended for PCIe because I do not have proper PD0/1 connection?

Thanks,

Avi

Hi Avi,

Thank you for providing additional context to your questions. I understand your PRSNT# connection now.

In your system, are 2x DS320PR810 devices being used across a x8 PCIe link, or just a single DS320PR810 in one direction? Could you provide some additional information about your configuration? Have you observed any different behavior on the PRSNT# pin during successful link-up vs. failing cases?

Best,
David

Hello David,

My system looks like this:

I have 2 boards:

Board #1 is plugged into a PC edge connector. Board #2 is connected into Xilinx FPGA evaluation platform. The boards are connected between them with a cable (iPass).

I have 2 x DS320PR810 devices on each board - one in each direction for a complete 8 lanes solution.

Here is the data flow:

Root Complex PET -> DS320PR810 -> iPass connector -> iPAss cable -> ipass connector -> DS320PR810 -> Xilinx FPGA

Root Complex PER <- DS320PR810 <- iPass connector <- iPAss cable <- ipass connector <- DS320PR810 <- Xilinx FPGA

I know the iPass is not specified for GEN4 but I have the same issue with GEN3. Again, when the system boots properly, the dataflows without any errors so it is not an issue of signal integrity.

As for your question on the PRSNT# pin during successful link-up vs. failing cases. It is hard to say. I think the PRSNT# is constantly connected to GND on the mother board. On my plug-in card I connect it to PRSNT_2n. This signal also passes over the cable to the DS320PR810 on the other side (FPGA side).

The order of powering up is as follows:

1. Both boards are plugged into thier platforms (one to the PC and the other to the Xilinx) while the platforms are OFF.
2. I power up first the Xilinx, which is the PCIe end point. Waits for the Xilinx to load its code and be ready for enumeration.
3. Once Xilinx is ready, I power up the PC. Enumeration some times succeeds and sometimes does not.

One more hint - I have 2 similar board adapters which are totally passive: no redriver whatsoever. It is a simple wire connection between PC edge connector to iPass connector and the same on the Xilinx side. IN this configuration and when working on GEN3 (GEN4 is too fast for this), the system always works. This is one more reason why I suspect the PD0/1 or the RX_DET.

Thanks for your more than generous help,

Avi

Hi Avi,

Thank you for your detailed reply.

I would like to start by pointing out that we typically do not recommend cascading redrivers for a couple of reasons, which are outlined in this E2E FAQ.

• What is the EQ Index which each DS320PR810 device?
• Once the link is established at Gen4 in your system, are you able to successfully run link stability tests without errors? I noted that you said the link is able to stay up for hours at a time, but am curious to understand if the link is being stressed in these cases or not.

Avi Avrahamy said:

As for your question on the PRSNT# pin during successful link-up vs. failing cases. It is hard to say. I think the PRSNT# is constantly connected to GND on the mother board. On my plug-in card I connect it to PRSNT_2n. This signal also passes over the cable to the DS320PR810 on the other side (FPGA side).

Based on this comment, it sounds like all DS320PR810 devices receiving the same PRSNT2# signal. Is this correct?

Avi Avrahamy said:

The order of powering up is as follows:

1. Both boards are plugged into thier platforms (one to the PC and the other to the Xilinx) while the platforms are OFF.
2. I power up first the Xilinx, which is the PCIe end point. Waits for the Xilinx to load its code and be ready for enumeration.
3. Once Xilinx is ready, I power up the PC. Enumeration some times succeeds and sometimes does not.

Are you able to access any of the DS320PR810's registers via SMBus? It would be helpful to know whether or not the devices are seeing RX Detection properly via register. Note the design documents for this device can be requested using the "Request Now" button on this product's ti.com webpage.

Best,
David

Thank you David.

Since our system has a 50cm cable between the PC and the end point, I thought it would be a good idea to have a redriver on both sides do the signals that get to each RX pin are equalized after the long cable. I did not think that having a redriver on the TX path (on both ends) will matter. From your suggestion I understand that I need to have the redriver only near the RX pins of the Root Complex and near the RX pins of the end point, right?

David Waier said:

What is the EQ Index which each DS320PR810 device?

I use Flat Gain (GAIN pins float at L4 state) and EQ0_0/1 EQ1_0/1 at L0 (1K to GND). We work in pin mode only. No access to the SMBus.

David Waier said:

Once the link is established at Gen4 in your system, are you able to successfully run link stability tests without errors? I noted that you said the link is able to stay up for hours at a time, but am curious to understand if the link is being stressed in these cases or not.

Yes, the link is stressed with traffic. We deliver A/D data from side to side at high rate that occupies about 70% of the bandwidth.

David Waier said:

it sounds like all DS320PR810 devices receiving the same PRSNT2# signal. Is this correct?

Yes. This is correct. 

It seems that my system is not designed 100%. It might be that the lack of PERST# to the redriver PD0/1 is the root cause to what I see. It might be a good idea in this case to disable the PCIe RX detect state machine and use the DS320PR810 as a simple buffer with equalization. What do you think?

Hi Avi,

Please allow us to review your replies and get back to you as soon as possible.

Best,
David

Hi Avi,

Avi Avrahamy said:

It seems that my system is not designed 100%. It might be that the lack of PERST# to the redriver PD0/1 is the root cause to what I see. It might be a good idea in this case to disable the PCIe RX detect state machine and use the DS320PR810 as a simple buffer with equalization. What do you think?

I think that your proposed test would be a good test to see if link instability is being directly caused by RX Detection. For this experiment, I would propose to set the RX_DET pin to L0 to disable the RX Detect state machine of all 4 redrivers in your system.

Best,
David