Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20721 Discussions

Calculate skew timing with Cyclone V and ksz9031

qwitza
Beginner
3,437 Views

hello,

i have troubles with the ethernet bandwith and retransmissions (ack). after some diagnostic i think it is an timing issue.

the wire length  from the fpga -> knz9031 is:

  mil mm m delay delay
RX_DV 1692,83 42,997882 4,30E-02 227,5E-12 228ps
RX_CLK 1649,35 41,89349 4,19E-02 221,7E-12 222ps
RXD0 1684,72 42,791888 4,28E-02 226,4E-12 226ps
RXD1 1648,24 41,865296 4,19E-02 221,5E-12 222ps
RXD2 1681 42,6974 4,27E-02 225,9E-12 226ps
RXD3 1677,12 42,598848 4,26E-02 225,4E-12 225ps
           
TX_EN 1625,87 41,297098 4,13E-02 218,5E-12 219ps
GTX_CLK 1629,75 41,39565 4,14E-02 219,0E-12 219ps
TXD0 1633,94 41,502076 4,15E-02 219,6E-12 220ps
TXD1 1657,65 42,10431 4,21E-02 222,8E-12 223ps
TXD2 1657,33 42,096182 4,21E-02 222,7E-12 223ps
TXD3 1655,12 42,040048 4,20E-02 222,4E-12 222ps

 

all wires are the same length, in every wire is an 22r resistor. the design is bought and not designed by us.

i found the following knowledge base entry:

https://www.intel.com/content/www/us/en/support/programmable/articles/000079123.html

=> TX_CLK to TXD/TX_CTL output data delay is specified as -0.85 to 0.15 ns

Datasheet 9031:
For the receive path (KSZ9031RNX to MAC), the KSZ9031RNX adds 1.2 ns typical delay to the RX_CLK output pin,
with respect to RX_DV and RXD[3:0] output pins.

 

We use kernel v4 with u-boot and devicetree, after a lot of measuring and test,

i got the best result with this skew timing:

&gmac1 {
	status = "okay";
	phy-mode = "rgmii";
  /* 0 bis 900*/
	rxd0-skew-ps = <420>;
	rxd1-skew-ps = <420>;
	rxd2-skew-ps = <420>;
	rxd3-skew-ps = <420>;
	rxdv-skew-ps = <420>;

	txd0-skew-ps = <360>;
	txd1-skew-ps = <360>;
	txd2-skew-ps = <360>;
	txd3-skew-ps = <360>;
	txen-skew-ps = <360>;
/* 0 bis 1860*/
	rxc-skew-ps = <1680>;
	txc-skew-ps = <1740>;

	max-frame-size = <3800>;
};

 

But how could i calculate the skew timing?

Which timing should be the best, with mathematics

 

Thanks

0 Kudos
35 Replies
Nurina
Employee
1,104 Views

Hello,


I have sent you an email. Please search for an email with subject "RE: Intel Customer Support - Case #: 05709344"


Thanks,

Nurina


0 Kudos
Nurina
Employee
1,093 Views

Hello,


Thank you for sending your .qar file, I have sent this to internal team and they will give suggestions soon.


Regards,

Nurina


0 Kudos
Nurina
Employee
1,083 Views

Hello,


The wire lengths in your PCB are all the same right?

Is there resistors in every wire? Where do you have this resistor?


Regards,

Nurina


0 Kudos
qwitza
Beginner
1,070 Views

Hello,

the wire length is in my first post, and yes they have all very near the same length.

the ksz9031 and the cyclone v are on the top layer, the resistors are on the bottom layer. the resistors are placed near the ksz9031.

 

thanks for your work, and answer

0 Kudos
Nurina
Employee
1,053 Views

Hello,


I am had problems trying to add comment on here so I have sent you a response through email.

Please let me know if it helps.


Regards,

Nurina


0 Kudos
qwitza
Beginner
1,049 Views

Hello,

i ve got only one e-mail with same message above, nothing else.

i ve no problems to comment here.

 

greetings

0 Kudos
qwitza
Beginner
1,049 Views

Hello,

the e-mail was in the spam folder.

 

thanks

0 Kudos
Nurina
Employee
1,032 Views

Hello,


Can you provide some updates?


Regards,

Nurina


0 Kudos
Nurina
Employee
1,014 Views

Posting the solution here for the community's future reference.

Regarding the PCB traces, resistors etc.

Typically we take into account the track lengths on PCB, line impedance and capacitive loading. All of which are inter-related. The track delay data you have is quite impressive and has pretty high tolerance to variations. Therefore, track delay can be ignored from analysis.

TX Timing

Examining the RGMII 2.0 spec:  (see attached)

 

Nurina_0-1678698623741.png

 

At the transmitter, TX_CTL & TXD are sent edge-aligned to TXC by the transmitter.  However at the receiving end, the TXC signal is center-aligned to data.  According to the spec, the skew can be achieved by PCB trace routing or by an internal delay in the transmitting or receiving node.

 

Assuming the following:

 

  • With the HPS we can’t add 2.0 ns of delay to TXC
  • The customer hasn’t added the skew via PCB
  • All tracks on PCB are delay matched
  • Paths are delay matched within the PHY package

 

Then the only option is to add the delay within the PHY.

 

Here’s what we publish wrt TX:

Nurina_1-1678698623743.png

 

 

The PHY allows for internal delays on TX_CLK via MMD register 2.8.  The goal would be to center-align the signals to TX_CLK by delaying TX_CLK.

 

Nurina_2-1678698623745.png

 

 

As a default, the PHY adds a 15*0.06ns = 0.900 ns delay to TX_CLK.  However to center-align, TX_CLK should be delayed 1.65 ns.

 

Nurina_3-1678698623746.png

 

 

Therefore if the customer sets MMD register 2.8[9:5] to int(1.65/0.06) = 27 or 1.62ns.  This will provide a Tsu of 1.47 ns and Th of 1.53 ns.  This should easily meet the TsetupR & TholdR requirements of 1.0 ns.

 

 

RX Timing

Examining the RGMII 2.0 spec:

Nurina_4-1678698623747.png

 

Like the Tx timing, the PHY sends its data edge aligned to RXC.  At the receiving end, the RXC signal is center-aligned to data.  According to the spec, the skew can be achieved by PCB trace routing or by an internal delay in the transmitting or receiving node.

 

Assuming the following:

 

  • With the HPS we can’t add 2.0 ns of delay to RXC
  • The customer hasn’t added the skew via PCB
  • All tracks on PCB are delay matched
  • Paths are delay matched within the PHY package

 

Then the only option is to add the delay within the PHY.

 

Here’s what we publish wrt RX:

Nurina_5-1678698623749.png

 

 

As before, the PHY allows for internal delays on RX_CLK via MMD register 2.8.  The goal would be to center-align the signals to RX_CLK by delaying RX_CLK. 

 

Examining Table 4-6 from above, as a default, the PHY adds a 15*0.06ns = 0.900 ns delay to RX_CLK.  However to center-align, RX_CLK should be delayed 2.00 ns.  Therefore if the customer sets MMD register 2.8[4:0] to int(2.0/0.06) = 33 or 1.98ns.  This will provide a Tsu of 1.98 ns and Th of 2.02 ns.  This should  easily meet the TsetupR & TholdR requirements of 1.0 ns.

 

Final Notes

The above analysis is fairly simplistic.  It doesn’t take into account duty-cycle distortion, jitter, IO skew, PCB skew, or variations over PVT.  Here’s a TI appnote the tries to address some of these concerns.

 

https://www.ti.com/lit/an/snla243/snla243.pdf

 

Lastly, the customer can scope these signals & validate the clock-data relationships.

0 Kudos
Nurina
Employee
1,003 Views

Hello,


We do not receive any response from you on the previous question/reply/answer provided. Please login to https://supporttickets.intel.com , view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


p/s: If any answer from community or Intel support are helpful, please feel free to mark as solution, give Kudos and rate 4/5 survey

 

Regards,

Nurina


0 Kudos
qwitza
Beginner
989 Views

Hello,

thanks a lot for the great answer and all the work!

 

I ve test a lot of different skew parameter. I started with the calculated skew parameter.

procedure:

  1. send an file pc => cyclone 5 processor
  2. count the ack errors with wireshark
  3. receive  an file pc <= cyclone 5 processor
  4. count the ack errors with wireshark
  5. if number of tries < 10 goto 1
  6. else change the skew parameter goto 1)

the file is 1gb big, and i ve get the best skew values with:

rxdX 420
txdX 360
rxc 1680
txc

1740

 

i think i can only verify the parameter with an oscilloscope, but at the moment i have not the necessary equipment for that.

 

thanks again for the support and the endurance.

0 Kudos
Nurina
Employee
985 Views

Hello,


I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, please login to https://supporttickets.intel.com , view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


p/s: If any answer from community or Intel support are helpful, please feel free to mark as solution, give Kudos and rate 4/5 survey


Regards,

Nurina


qwitza
Beginner
957 Views

Hello,

i have additional questions.

 

we tested now more than 10 boards with our new device tree, and have the following result.

 

File embedded system => PC:

if we copy an file from our embedded system to the pc, we have no or less retransmission, < 5 retransmission per copy.

all 10 boards have the same result

 

File PC => embedded system:

8 boards:

if we copy an file from our embedded system to the pc, we have no or less retransmission, < 55 retransmission per copy.

2 boards:

have really a lot of > 400 ack retransmissions, and ack fast retransmissions.

 

Result:

the ack retransmission error is always from pc to our embedded system, which connection is bad.

 

Where can we start troubleshooting?

 

0 Kudos
Nurina
Employee
942 Views

Hi,

 

This thread has already transitioned to community support.

Please post a new thread for Intel support.

 

Thanks,

Regards,

Nurina

0 Kudos
qwitza
Beginner
779 Views

Hello,

the retransmission error results from an to low voltage supply for the ksz9031.

DVDDL was 0,1mV to low.

 

thanks for your support.

0 Kudos
Reply