Hur vet man om man behöver lika långa linjer på ett kretskort för signaler?

[DanielM]

Jag håller på dra linjer till ett ehternet PHY som heter

RTL8211F-CG.pdf

. Det är en RGMII ethernet PHY.

Skärmbild 2024-04-09 090334.png

Om vi tittar lite på kommunikationsbussen mellan PHY och uP. Då finns det pull-ups på RX-bussen. Men på TX-bussen finns det inga pull-ups eller pull-downs. Däremot på ETH_MDIO (Data input output), ETH_MDC (Data clock) och ETH_MDINT (Data interupt) så finns det inga pull-ups och pull-downs.

Skärmbild 2024-04-09 090740.png

Dom enda linjerna som jag har försökt få lika långa är kristallen på 25 MHz. Jag har tyvärr inget program som kan göra dessa "ormar" på ett kretskort. Jag använder Alium CircuitMaker. Programmet tycker jag verkar ha ändå allt.

Skärmbild 2024-04-09 091157.png

Skärmbild 2024-04-09 094150.png

Men dom enda linjerna som är exakt lika långa är faktiskt databussen från PHY till RJ45 kontakten

Skärmbild 2024-04-09 091445.png

Men då kommer vi in på lite teori:

Timing for this interface will be such that the clock and data are generated simultaneously by the source of
the signals and therefore skew between the clock and data is critical to proper operation.
Figure 14 shows the effect of adding an additional delay to TXC via the PC board (upper side) or by
transmitter internally (lower side) when in RGMII mode.

[...]

Figure 15 shows the effect of adding an additional delay to RXC via the PC board (upper side) or by
transmitter internally (lower side) when in RGMII mode.

Skärmbild 2024-04-09 093856.png

Frågeställning:

Hur vet jag om jag har behov utav att alla linjer ska vara lika långa?
För det står ju att det finns något som påverkar om man lägger till fördröjning.

[rvl]

För just kristallen skulle jag inte sätta nån större prioritet på att få ledningarna lika långa, men däremot på att få dem så korta som möjligt.

[Klas-Kenny]

I största allmänhet:

Har du en kommunikation som bygger på en klocksignal och en eller flera data-signaler, så måste klocksignalen och dess tillhörande datasignaler vara ungefär lika långa.

Sen är det bara en fråga om vad "ungefär" innebär, vilket beror på timingkraven i protokollet i fråga, och hänger i regel starkt ihop med datahastigheten.

Tar du en SPI-buss på 10 MHz så är det inte så himla noga, några millimeter hit eller dit spelar ingen större roll. Men drar man det till sin extrem, så finns exakt samma krav där. 10 MHz->100ns klockcykel. Ponera att du har en så lång ledare att det tar 100 ns längre för data-signalen att komma fram, så kan du ge dig på att det blir problem då datat i mottagande ände ligger en hel klockcykel fel. (Nu kommer man i praktiken ha andra problem också om man slänger på typ 15 meter ledare som krävs för den fördröjningen, men för principen).

Den förskjutning som är tillåten beror i regel på när mottagaren samplar data, i förhållande till när klocksignalen har kommit in. Om mottagaren samplar 1 ps efter flank på klockan, så får längdmatchningen max ge 1ps fördröjning av datat, osv. Och för det allra mesta så är det okej att ha en klocksignal som är litet längre än datasignalerna, men inte vice versa. För är klocksignalen längre så har datat kommit fram innan klocksignalen, och då är allt OK. Förutsatt att det inte är så mycket längre att datat börjat övergå i nästa bit som som skall överföras, vilket med tillräckligt hög överföringshastighet är en reell möjlighet.
Sen har många enheter och protokoll stöd för att lägga på delayer i mjukvara, för att kompensera för en viss mängd av längdskillnader.


Lyckligtvis behöver man sällan bry sig om den ingående teorin eller att sitta och räkna på olika protokoll. Svaren på alla dessa frågor hittar man i specifikationer för varje protokoll.
Googla exempelvis "RGMII Routing Guidelines" så kommer du hitta rekommendationer ifrån allehanda tillverkare av sådan utrustning, som berättar för dig vilka krav som gäller. Lämpligen tar du guidelines för den processor och PHY du tänker använda.

[DanielM]

För just kristallen skulle jag inte sätta nån större prioritet på att få ledningarna lika långa, men däremot på att få dem så korta som möjligt.

Tackar.
Jag vet inte hur långt ifrån en kristall får vara. Men jag har hört att den ska vara så nära som möjligt.
Det fanns lite utrymme kvar.

Skärmbild 2024-04-09 120557.png

I största allmänhet:

Har du en kommunikation som bygger på en klocksignal och en eller flera data-signaler, så måste klocksignalen och dess tillhörande datasignaler vara ungefär lika långa.

Sen är det bara en fråga om vad "ungefär" innebär, vilket beror på timingkraven i protokollet i fråga, och hänger i regel starkt ihop med datahastigheten.

Tar du en SPI-buss på 10 MHz så är det inte så himla noga, några millimeter hit eller dit spelar ingen större roll. Men drar man det till sin extrem, så finns exakt samma krav där. 10 MHz->100ns klockcykel. Ponera att du har en så lång ledare att det tar 100 ns längre för data-signalen att komma fram, så kan du ge dig på att det blir problem då datat i mottagande ände ligger en hel klockcykel fel. (Nu kommer man i praktiken ha andra problem också om man slänger på typ 15 meter ledare som krävs för den fördröjningen, men för principen).

Den förskjutning som är tillåten beror i regel på när mottagaren samplar data, i förhållande till när klocksignalen har kommit in. Om mottagaren samplar 1 ps efter flank på klockan, så får längdmatchningen max ge 1ps fördröjning av datat, osv. Och för det allra mesta så är det okej att ha en klocksignal som är litet längre än datasignalerna, men inte vice versa. För är klocksignalen längre så har datat kommit fram innan klocksignalen, och då är allt OK. Förutsatt att det inte är så mycket längre att datat börjat övergå i nästa bit som som skall överföras, vilket med tillräckligt hög överföringshastighet är en reell möjlighet.
Sen har många enheter och protokoll stöd för att lägga på delayer i mjukvara, för att kompensera för en viss mängd av längdskillnader.


Lyckligtvis behöver man sällan bry sig om den ingående teorin eller att sitta och räkna på olika protokoll. Svaren på alla dessa frågor hittar man i specifikationer för varje protokoll.
Googla exempelvis "RGMII Routing Guidelines" så kommer du hitta rekommendationer ifrån allehanda tillverkare av sådan utrustning, som berättar för dig vilka krav som gäller. Lämpligen tar du guidelines för den processor och PHY du tänker använda.

Tackar för ett bra inlägg. Jag förstår motiveringen nu varför klocksignalen bör helst vara längre än datasignalen.
Jag ska kontakta ST och kolla med dom om de har några rekommendationer.

Tittar jag i deras exempel så vandrar den blåa RX-linjen mellan 68-72mm för alla de olika RX-linjerna.
För min del är det lite högre spridning. Runt 20-30 mm.

Skärmbild 2024-04-09 125017.png

Det enda dom säger är följande här hos ST och att dom säger att det ska vara 50 Ohm ledningar mellan PHY och RJ45.

Gigabit Ethernet
Note: A good signal integrity is dependent on board, GPIO strength settings (GPIO_OSPEEDR registers) and VDD
voltage.
When using VDD = 1.8 V, a setting in the OTP bit product_below_2v5 and the register SYSCFG_HSLVEN2R
(HSLVEN_ETH1 bit) and/or SYSCFG_HSLVEN3R (HSLVEN_ETH2 bit), is required to ensure the best speed on
pads used on Ethernet outputs.
Warning: HSLVEN must not be set when VDD is above 2.7 V, otherwise permanent device damage
may occur.
If needed, the impedance matching resistors must be placed as close as possible of the output driver pin. Values
in the example below works in most cases, but can be tailored to each side I/O drive strengths and PCB
impedance.
As the RCC cannot provide the 25 MHz reference clock to the PHY during low power modes, the dedicated
25 MHz crystal is required on the PHY in case wakeup on LAN (WOL) is needed for the platform.
Setting the RCC PLLs to get 25 MHz output for PHY could const

Skärmbild 2024-04-09 125718.png

Detta har jag mätt upp.
För TX-linjerna så kommer detta säkert blir ett problem.

• ETH_GTX_CLK = 11.274 mm
• ETH_TXD0 = 16.457 mm
• ETH_TXD1 = 17.325 mm
• ETH_TXD2 = 19.521 mm
• ETH_TXD3 = 20.527 mm

[DanielM]

Så där!
En uppdatering!
viewtopic.php?p=1800962#p1800962