| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Ragnar, Thanks for your review of those numbers, at this point they are the same numbers used in the previous comments against D2.0.
I have been working on an update to 192.12 based on some of the comments against D2.0 and D2.1 on the topic of how to specify delay constraints for asymmetric PHYs, but had not gone back to check these numbers yet. I agree that they require
an update. 7.5G+1000 The maximum delay in ns is sufficient, and while I would propose a slightly lower total delay we can use that for discussing the arithmetic. 4096 ns for 7.5 Gb/s is 30 720 BT or 60 pause_quanta. We are on the same page there. 5G+1000 The 3072 ns was based on pause_quanta scaling, which is not sufficient. I can follow your general approach, but it is also too low. Without going into all the detail, the gap between the portions of the burst payload for 5G+1000 that
carry 64B65B data is over 3900 ns alone, and RS-FEC superframe arrival time is over 200ns, so a total maximum delay of 4096ns is also too low.
I wouldn’t suggest that implementation budgets can be directly derived from the delay constraints, so we can discuss that further when I provide the update. Best regards, Scott From: Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx>
EXTERNAL EMAIL:
Do not click links or open attachments unless you know the content is safe
Hi Scott, I have been reviewing the delay constraints in subclause 192.12 (Table 192-27). While looking at the proposed entries for the 1 Gb/s configurations, a few apparent arithmetic and budgeting discrepancies caught my attention. Could you provide some additional background or share the rationale used to derive the current values for these new modes? Specifically, I am trying to reconcile two key areas: 1. Arithmetic consistency in the 7.5G+1000 row In Table 192-27, the row for
Checking the standard conversions (1\text{ pause\_quantum} = 512\text{ BT}):
It looks like the intent may have been 30,720 BT and 60 pause_quanta to match 4,096 ns—could you confirm if that was the case? 2. Physical implementation margin for 5G+1000 Looking at the physical lower bounds on latency across TDD cycles, moving the return path from 100 Mb/s to 1 Gb/s reduces the High-Speed transmit
window from 8,693.33 ns down to 6,949.33 ns (to accommodate the larger LS burst). This expands the worst-case HS transmitter silent/buffer wait time by 1,744 ns (from 906.67 ns to 2,650.67 ns). When factoring in the minimum RX FEC decode latency (L \times \text{codeword duration}):
This provides barely a third of the implementation budget allowed for the other modes, which could make it difficult for standard digital pipelines, sync FIFOs, and clock domain crossings to achieve compliance using shared silicon architectures. If we applied
the same ~1,100 ns margin used in I would appreciate any insight into how the 3,072 ns ceiling was modeled or whether there were specific system-level constraints driving that number. Best regards, To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1 |