DS160PR810: Question about ds160pr810

Hi Jimmy,

Please allow us an additional day to review your questions and provide feedback.

Best,
David

Hi David:

Thank you for your response. I have some further questions:

3. The redriver is a low latency device, adding only 90-120ps. I would not expect issues.

-- Yes, the latency of the Redriver is relatively low, but the routing of other parts is very long, resulting in high latency and significant losses. This is also the reason why we use Redriver. I think this will be a common problem encountered in scenarios using Redriver. Do you have any suggestions?

4. I do not believe this is characterized. However, PCIe spec allows for up to 1.25ns max lane-to-lane output skew at 16GT/s (PCIe 4.0), so I would not see much issue here.

-- This is a very important issue for us because the PCIE CEM protocol requires that the lane-to-lane skew on AIC should be less than 0.35ns, which is not sufficient for situations like ours where routing is very long. 1.25ns is the requirement for lane-to-lane skew on the system board. We need to know the lane-to-lane skew between any two Redrivers to control the entire link to meet the requirements of AIC.

Hi Jimmy,

3. This is typically not an issue when using a redriver in an AIC format. Please note this device was validated to PCI-SIG AIC standards and is listed on the PCI-SIG integrator's list: https://pcisig.com/developers/integrators-list?field_version_value%5B%5D=4&field_il_comp_product_type_value=All&keys=texas+instruments 

4. Apologies, I had listed the max system lane-to-lane skew. I still would not expect this to be an issue. Do you expect the routing of each lane to vary by > 2 inches on the AIC?

Best,
David

Hi David：

Thank you for providing the information for question 3. The answer to question 4 and the other two questions are as follows. Please help confirm:

4. Apologies, I had listed the max system lane-to-lane skew. I still would not expect this to be an issue. Do you expect the routing of each lane to vary by > 2 inches on the AIC?

-- We don't want the  routing  of each lane(x16) to vary by > 2  inches. To meet this requirement, I need to know the lane to lane skew caused by different Redrivers (also counted as routing length differences). Can you provide it?

5. Does the Redriver compensate for routing delay, lane to lane skew, or differential pair skew (P/N)? At present, when we consider the timing issue of AIC, we assume that Redriver is not working, so we require that the total latency and skew of the link from ASIC chip to Golden Finger, including PCB, connector, cable, and Redriver, should not exceed the requirements of PCIE protocol.
6. We also want to know the differential pair skew (P/N) of the Redriver to evaluate whether the link can meet the requirements of the PCIE AIC protocol. 

Hi Jimmy,

• The redriver is an analog device which applies CTLE and flat gain. The redriver does not compensate for routing delay or lane-to-lane skew. The channel's P/N should be tightly matched, less than or equal to 5 mils.
• The redriver's device lane-to-lane skew is as listed in the data sheet Table 6-6. As stated above, my understanding is that lane-to-lane skew between devices is not characterized.
• I will need to check internally to see if there is further data available.

Could you help us to understand your current estimated propagation delay on your AIC?

Best,
David

Hi David：

Do you have any information to share regarding the intra-pair skew(P/N) of Redriver and the delay differences between devices ?

The delay and insertion loss information of our application is shown in the following figure. Do you think there are any issues with this design?

Hi Jimmy,

David is out of the office so I will answer on his behalf.

Jimmy Huang said:

Do you have any information to share regarding the intra-pair skew(P/N) of Redriver and the delay differences between devices ?

We don't have this data on hand, I will ask but I don't think these parameters may be part of our typical characterization. I think they can be assumed to be very low.

Jimmy Huang said:

The delay and insertion loss information of our application is shown in the following figure. Do you think there are any issues with this design?

For insertion loss I see figures of 16 dB and 2 dB for the trace connections, however I don't see dB for the other system elements and you previously mentioned the total link loss is higher than 28 dB? This is important to know for examining the loss distribution.

I also see skew estimates, which I will check with my team, but I don't see numbers for time delay?

FYI, I don't recall any previous customers being concerned about or having problems from propagation delay in the past. Intra-pair skew is sometimes an issue on the board design when external P/N trace routing is not matched but we also haven't seen any concerns about the internal device P\N skews. May I ask what methods or equations you are using to calculate the delay and skew in the system?

Best,

Evan Su

hi David & Evan：

The distribution of 'AIC' (add-in-card) in my diagram is designed by us. We do not have data on the insertion loss of the system board. Since we need to adapt to common system boards, we can use the PCIE protocol requirement of a system board loss of 20dB to evaluate. Please help to evaluate if there are any issues?

I did not provide time delay because it usually does not have a significant impact on signal performance. For the AIC we designed, the estimated time delay is 3ns. We are not aware of the system board delay and have not found any relevant descriptions in the PCIE protocol.

Our method of evaluating delay and skew is through testing and simulation. Cables and connectors are obtained through testing, and the PCB routing part is converted into latency through simulation and line length differences.

If the P/N skew cannot be provided to us, please help to evaluate if there will be any issues?

The diagram I provided does not include the package insertion loss of ASIC, which is 3dB. This part should also be considered.

Hi Jimmy,

Jimmy Huang said:

The distribution of 'AIC' (add-in-card) in my diagram is designed by us. We do not have data on the insertion loss of the system board. Since we need to adapt to common system boards, we can use the PCIE protocol requirement of a system board loss of 20dB to evaluate.

Jimmy Huang said:

The diagram I provided does not include the package insertion loss of ASIC, which is 3dB.

So in the diagram is its reasonable to assume 8 dB of additional loss for the ASIC, and 20 dB for the loss of the system on the Gold Finger side?

Jimmy Huang said:

I did not provide time delay because it usually does not have a significant impact on signal performance. For the AIC we designed, the estimated time delay is 3ns. We are not aware of the system board delay and have not found any relevant descriptions in the PCIE protocol.

I am confused because earlier you mentioned the "the delay and insertion loss information of our application is shown in the following figure" and previously had a concern about delay:

Jimmy Huang said:

3. The PCIE4.0 CEM protocol requires that the board routing delay Delay cannot exceed 750ps, as shown in the figure below. Our link is long (which is why we need to add a Redriver), plus the delay of the Redriver, it will definitely exceed this requirement. Will there be any problems? Does your company have experience in dealing with similar problems?

Is this "board routing delay" different from "time delay"?

Best,

Evan Su

Hi Evan：

 So in the diagram is its reasonable to assume 8 dB of additional loss for the ASIC, and 20 dB for the loss of the system on the Gold Finger side?

--> No. The insertion loss of ASIC is 3dB. There are two sections between ASIC and Goldfinger, as shown in my diagram, which are 16dB and 2dB respectively. This part is usually called AIC. The chip from the golden finger to the other end is generally referred to as the system board, and the insertion loss is 20dB according to the protocol.

I am confused because earlier you mentioned the "the delay and insertion loss information of our application is shown in the following figure" and previously had a concern about delay:

--> Sorry about this. Our chip designers believed that transmission delay(not lane-to-lane skew or P/N skew) should not cause any problems, so I did not provide this information later . But for the Redriver application, can you help confirm again.  We are still concerned about lane-to-lane skew and P/N skew.

Is this "board routing delay" different from "time delay"?

--> No. They are the same. The time delay is caused by board routing. This is the description of the protocol that I paraphrased.

Hi Jimmy,

Jimmy Huang said:

Our chip designers believed that transmission delay(not lane-to-lane skew or P/N skew) should not cause any problems, so I did not provide this information later

OK, I will disregard the delay questions.

Jimmy Huang said:

--> No. The insertion loss of ASIC is 3dB. There are two sections between ASIC and Goldfinger, as shown in my diagram, which are 16dB and 2dB respectively. This part is usually called AIC. The chip from the golden finger to the other end is generally referred to as the system board, and the insertion loss is 20dB according to the protocol.

OK, so with these numbers the ASIC --> system board data direction has ~19 dB loss before the redriver and ~22 dB after the redriver, and the opposite system board --> ASIC data direction has ~22 dB before the redriver and ~19 dB after the redriver. So the total would be ~41 dB. This is approaching the 42 dB total suggested in the datasheet so the link performance could be marginal, success or problems could depend on non-redriver factors such as the RX equalization performance of the endpoint and system. I would suggest running a detailed high-speed simulation with the redriver IBIS-AMI model and ideally a simulation model of the ASIC TX/RX, if the ASIC model is known, to investigate how much margin the redriver could achieve.

Jimmy Huang said:

But for the Redriver application, can you help confirm again.  We are still concerned about lane-to-lane skew and P/N skew.

I am still talking with some of our designers and will try to confirm tomorrow, but as I said earlier, it is likely to be very small. Because the traces on the board are much bigger than the signal routing inside the redriver, the major source of such skews is from the board design. Our layout recommendations for example say that board P/N trace matching should be controlled within 5 mils. Normally P/N can be length matched very well on a board without any negative effects, is there something in your design that is preventing this?

Regarding lane-to-lane skew, did you see this comment from David earlier?

David Waier said:

The redriver's device lane-to-lane skew is as listed in the data sheet Table 6-6. As stated above, my understanding is that lane-to-lane skew between devices is not characterized.

Best,

Evan Su

Hi Evan：

I would suggest running a detailed high-speed simulation with the redriver IBIS-AMI model and ideally a simulation model of the ASIC TX/RX, if the ASIC model is known, to investigate how much margin the redriver could achieve.

--> Ok, we are using Redriver and ASIC's IBIS-AMI model for simulation. If there are any issues, we will communicate with you.

Our layout recommendations for example say that board P/N trace matching should be controlled within 5 mils. Normally P/N can be length matched very well on a board without any negative effects, is there something in your design that is preventing this?

--> This is mainly because the cable cannot achieve this accuracy. We used a section of cable between ASIC and Redriver, but the cable design accuracy usually cannot reach+/-5mil of PCB routing, which is a process limitation. I understand that the P/N Skew that an IP can tolerate is generally larger, but I don't know how much. Due to process limitations, cables have significant P/N skew issues, but in practical applications, cables can achieve normal functionality.

Hi Evan：

Here is a problem related to lane to lane skew that needs double confirmation. 

The datasheet specified the lane to lane skew is -20ps ~ 20ps. Does it mean that the skew between longest and shortest lane is |20| ps, or 40ps? 、

Hi Jimmy,

As Evan and David are out of office I'll take over. 

The meaning of the datasheet value is the the minimum lane to lane skew between any two lanes is -20 ps and the maximum is 20ps. So its |20| ps.

Best,

Nick

Hi Nick：

Thank you for your feedback

We are working on the channel simulation with the redriver IBIS-AMI model and meet a problem.

The simulation result doesn't match with the result shown in IBIS AMI Model UG, could you give us any comments on this mismatching?

The workspace was dowmloaded from TI website, and I just run the simulation of the given example.

The UG shows the result of this setup. The eye is opening on the redriver output.

However, the result of the real running shows here, the eye of redriver output (the right one) is totally closed.

Hi Jimmy,

Can you share more of what your schematic looks like in the given example? Any differences from the example? 

As to the earlier conversation about intra-pair skew 

I see the max intra-pair skew that you see from traces is 3.5ps. What is the ps/inch delay of the PCB material that you are using? 

Keep in mind that for gen 4 speed 1 UI is 125 ps. For your case the intra-pair skew would be (3.5/125) *100 = 2.8% of a UI.

Best,

Nick

Hi Nick：

The model I used was just the example given in the workspace. Please refer to the attached file.

As for the intra-pair skew, the delay of the PCB is about 157ps/inch. 

May I correct you that Gen4 speed 1UI should be 62.5ps? So the equation should be 3.5/62.5*100%=5.6%, do you have any concern about this margin?

(Redacted - DS160PR810 IBIS-AMI Model v1)

(Redacted - DS160PR810 IBIS-AMI Model User's Guide)

Redacted model and user's guide as these are under secure resources only and cannot be shared on the public forum..

Hi David & Nick:

Ok, I remove Redacted model 

The model I used was just the example given in the workspace. Please refer to the attached file.

As for the intra-pair skew, the delay of the PCB is about 157ps/inch. 

May I correct you that Gen4 speed 1UI should be 62.5ps? So the equation should be 3.5/62.5*100%=5.6%, do you have any concern about this margin?

Hi Jimmy,

My mistake I used Ghz instead of Gbps.

It looks like with 157 ps/inch you are seeing 0.157 ps/mil and with an intra pair skew of 3.5ps that mean that if you divide the intra-pair skew we can see that 3.5/0.157 = 22.2 mils difference between the two pairs. This is above our recommended range of 5 mils. Is there any way to make adjustments at this point the layout to match the P and N traces?

As for the simulations. I don't know why you are seeing issues using the example model. If you accept my friend request, I can send you the working model I have.

Best,

Nick

Hi Nick：

Do you mean the limit of the intra pair skew for the redriver input is 5 mils? What if it exceeds? Will it affect signal processing in the redriver?

I have sent you model by private.  I'm wondering if you meet the same result as me. But anyway, it'll be great to use a comfirmed model from you to go on my furthur simulation. Thanks!

Hi Jimmy,

TI follows under 5 mils rule in our PCIe redriver EVMS to reduce common mode noise and duty cycle distortion.

I will also send a layout file for our EVM so that you can compare how we do our intra-pair skew.

Best,

Nick  

Hi Jimmy, 

When I run the model you sent I get an error. I will send you a version that works for me.

best,

Nick

Hi Nick：

I ran the example you provided, but the eye is still closed, which is different from your simulation result.

The channel topology shows here, I didn't do any change to either EQ setting or channel S parameter. I only remapped the ibis ami model and snp files to my local dictionary.

Hi Jimmy,

I was seeing the same issue as you were until I change the AMI variables.

The comment in the image above says "

"Set the Var Setting in the AMI model AMI section, Change the Rx AMI parameters to User specified, then update the variable to match the name in the red box" 

Also, if your application is with the 810, you should use that model. My apologies for sending the 410. Let me know if there are more questions.

Best,

Nick

Hi Nick：

The datasheet of ds160pr810 defined the crosstalk limitation of transmit side and receiver side. May I know which kind of crosstalk it specified, NEXT or FEXT?

Hi Jimmy,

Please allow us some additional time to field your question and get back to you.

Best,
David

Hi Nick：

Thanks for your detailed reply. But I still have a little confusion. Let's use the picture you sent for further clarification.

I numbered each port.

Case1:Let's assume the left side ports are belonged to redrive, the right side ports are interconnection peer's. 

Should the receive-side pair-to-pair isolation (NEXT) be SDD31 or SDD35?

Case2:Let's assume the left side ports are belonged to interconnection peer, the right side ports are redriver's. 

Should the transmit-side pair-to-pair isolation (FEXT) be SDD42 or SDD32?

Hi Jimmy,

Thanks for your interesting question.

For case 1 my answer is SDD35 and for case 2 my answer is SDD32. I answer this way because FEXT and NEXT are measured at the receiver.

Best Regards,

Nick