Part Number: DP83867IR
I am seeing around 200 pS of skew between signals that comprise the TX interface in signal integrity simulations. The signals are tightly matched and extracted using HFSS. This skew, I believe, is due to most signals having GPI inputs while the TX_D0 and TX_D1 signals have a GPIO_SGMII_IN input buffer. I haven't done any timing analysis at this point but am concerned that 200 pS removed from the overall margin may be significant. Does anyone have any experience with this concern?
Can you please share your simulations that you have performed?
I will need to investigate this further with my team internally to understand if this timing is a concern.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Cecilia Reyes:
Below are two waveforms; one with correct input models “as designed” and one with all inputs in the TI device set to the exact same inputs (not real).
My best regards,
Stephen P. Zinck
"Specializing in ANSYS HFSS, SIwave, Icepak and Designer SI"
Interconnect Engineering, Inc.
High-Speed Signal and Power Integrity Consulting Engineer
10 Old Route 9
North Berwick, ME 03906
Phone - (207) 384-8280
Email - email@example.com
Web - www.interconnectengineering.com
In reply to Stephen Zinck:
In your comment about knowing about the GPIO_SGMII_IN input buffer how were you able to get this information for your simulation?
The 200ps is due to different loading on this line. If you want to offset this you would be able to use the RGMII TX skew delay to take into account the 200ps you are seeing.
Attached is our app note that goes into more details on the RGMII timing budget that you can review. Let me know if you have further questions about it.
Thank you for the information. I will review.
The input information is detailed in the IBIS model provided on the website.
If it is possible to delay some bits in the interface, such as TX_CLK, TX_CTRL, TX_D2 and TX_D3, then this will be a solution. TX_D0 and TX_D1 can't have any delay added as they are the more heavily loaded lines.
Hello again Cecilia,
I did not find the attachment.
Apologies on missing the attachment. Here you go!
Thank you Cecilia,
In my review of the document you linked, it looks like the only thing that can be delayed is the TX_CLK. If TX_D0 and TX_D1 are delayed by 200ps versus TX_D2 and TX_D3, should I be concerned?
The 200ps should not be of concern if you can offset with the RGMII skew.
When you say "offset with the RGMII skew", what does that exactly mean?
If the TX_CLK, TX_CTRL, TX_D2 and TX_D3 flight times are exactly the same and TX_D0 and TX_D1 are delayed by 200pS, I can move the TX_CLK delay tap to 250pS (this is the smallest increment). This means TX_D0 and TX_D1 are now 50pS away from TX_CLK, but TX_CTRL, TX_D2 and TX_D3 are now 250pS away from TX_CLK. Is this enough to ensure the interface will work? This is an important element of the design. If this device does not come up working correctly, the whole project is broken.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.