Duane,
I believe that the argument NOT to exceed current allocation budget (~82ns) was that larger skew would imply grave issues in the system implementation. Also, we cannot support infinite skew between channels we support in Nx25G-EPON nor does it make a practical sense to do so. Given the current nominal PON distance and power budgets we have to work with, as well as worst case scenario center channels we picked, we should be more than OK with the existing budget allocation. If you believe ~82ns is insufficient, it would be good to present justification for a larger number, as well as the value you believe is sufficient to address the target scenario we need to work with. At least that would give us something to look at and discuss.
As far as where and how to specify delay – Clause 141 shows all test points in the system (shown below for reference) – I question the purpose of specifying delay through layers that do not have exposed testable interfaces between them, because even if the value is broken down, there is no need to verify whether the implementation is compliant or not. Looking at the figure below, we can really specify (and verify) delay through the whole PHY (at TP7/TP2) with all layers included, and then at TP1/TP8. Now, we could place the delay budget specification in Clause 141 as well, given that it is the first Clause in the amendment, and back reference from other clauses where delay budget is needed / discussed. Any location within the amendment can be easily implemented and back referenced anywhere in the draft.
Marek
From: Duane Remein <Duane.Remein@xxxxxxxxxx>
Sent: Monday, October 1, 2018 9:39 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGEPON] Delay constraints
I would like to begin an open discussion regarding how we specify Delay constraints in our draft (also see comment #434 againsse D1.2 from the Spokane meeting).
When I crafted this proposal I made the assumption that a supplier may be providing one or more layer functions and would need to know the amount of delay variation allocated to the partial system they were supplying. Thus the proposed table provided allocations for everything from any single layer/sub-layer to an entire system. I broke the entire transmit data path into MAC/MAC Control/ MCRS (labeled MCRS for simplicity), PCS/PMA, PMD, PHY and MAC to PHY (i.e., the entire tx path).
One of the arguments against this idea was that our skew management system will remove any potential delay variation. This is true up to a point, that being the amount accommodated by the 32 slots in our receive skew buffer or 81.92 ns total. While it is true that the receiver will remove this skew we still need to constrain the transmitter so that the total skew is less than this 81.92 ns.
It was also argued that a PMD designer should not have to look in the MPCP clause to get a requirement. I find this argument somewhat contradictory as we often write specifications that reference other clauses in the 802.3 book. We even reference other specification when it is appropriate (for example we don’t spec the fiber itself). So pointing to another clause should not be a problem. I’m not at all opposed to moving the proposed allocation table to Cl 141 but we need it somewhere with proper cross-references form other layer clauses.
I’m also very open to discussing the actual values in the table. For your convenience I’ve included the proposed table below.
Assuming we can come to an agreement I will re-submit a comment on this topic against D1.3.
Best Regards,
Duane
Table 144-x Delay variation allocation in Nx25G-EPON | |
Layer/Sub-layer | Allowed Delay variation (EQT) |
MCRS | 1 |
Nx25G-EPON PCS/PMA | 2 |
Nx25G-EPON PMD | 1 |
MAC to PHY(1) | 4 |
PHY(2) | 3 |
Notes: | |
1) Total delay variation for an Nx25G-EPON implementation covering both MAC and PHY layers. | |
2) Total delay variation for an Nx25G-EPON implementation including PCS, PMA and PMD. | |
3) Total expected delay is declared as specified in {Cl 45 PMA/PMD Ref} and {Cl 45 PCS Ref}. Implementations which combine MCRS, PCS, PMA and PMD may use either one or both of these mechanisms. | |
Editors Note: we will need to determine how to declare MCRS total delay which may affect Table 144-x" | |
FutureWei Technologies Inc.
Director, Access R&D
919 418 4741
Raleigh, NC
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1