Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Steve – we have been discussing repartitioning the end-to-end budget for CR… Maybe reduce the cable length & give some back to the host PCB channel segment…
so if we are going to put a reach objective in for CR we need to finish that debate first. The other suggestions for CR objective wording kept things vague enough that we could work the partition later. From: Trowbridge, Stephen J (Steve) [mailto:steve.trowbridge@xxxxxxxxxxxxxxxxxx]
Hi all, I think you guys are getting into the weeds here considering that this is the Study Group phase. I believe that the objectives can be much higher level than
you are proposing and you can trust the task force to do the right thing, because this isn’t a waterfall thing where you are creating a set of objectives and throwing them over the fence to a totally disjoint group of engineers who you don’t trust to do the
right thing unless you tie their hands: the task force will be YOU, and if you can’t trust yourself, who can you trust? The only reason the later iteration of the P802.3bj objectives got into channel details was that they were trying to generate distinct identity for doing two
backplane PHYs, otherwise they could just have left it as “up to 1m over a backplane”. Assuming you are intending to specify a single backplane PHY rather than having KR and KP variants, I think you could leave it as: ·
Define a single lane 25 Gb/s PHY for operation over links consistent with copper traces (as specified by P802.3bj) with lengths up to at least 1m. ·
Define a single lane 25 Gb/s PHY for links consistent with copper twinaxial cables with lengths up to at least 5m.
Regards, Steve From: Vineet Salunke (vineets) [mailto:vineets@xxxxxxxxx]
Matt, I agree, staying with CR4 specs would be best, but I am trying to understand the need for larger host loss. The main volume would be “SFP” ports used on both switch and server, so we should optimize for that. QSFP switch ports will not be able to use the larger loss, but can still provide 4x25G CR breakout. --vineet From: Matt Brown (APM) [mailto:mbrown@xxxxxxx]
Hi Vineet, I think it makes a lot of sense to retain the 802.3bj host loss. The case in point would be a switch with 4x25G connectors that may be used for either a signal
100G Ethernet port (100GBASE-CR4 per 802.3bj) or four 25G Ethernet ports (25GBASE-CR per new 25G project). From: Vineet Salunke (vineets) [mailto:vineets@xxxxxxxxx]
Chris, We heard on the call yesterday, at least 3 demands that do not exactly match Clause 92. ·
Need to reduce the host loss on the server side, to reduce total loss and avoid use of FEC. ·
Need to further optimize around 3m cables for above. ·
And I also heard need to allow larger host loss for the TOR switch side (when using RS-FEC). So can we avoid the direct reference to Clause 92 specifications ? --vineet From: Christopher T. Diminico [mailto:00000025925d7602-dmarc-request@xxxxxxxx]
Rich,
Hopefully this addresses both you and George.
Given the intent is to operate over channels consistent with the channel (TP0-TP5) specified in IEEEStd802.3bj-2014 Clause92.
•Define a single-lane 25Gb/s PHY for operation over channels consistent with the channel specified in IEEEStd802.3bj-2014 Clause92 (Fig 92-2 - TP0-TP5) Regards, Chris DiMinico
-----Original Message----- Both suggestions allude to a specific host/module budget which I believe needs to re-evaluated in task force. Perhaps: Define a single-lane 25Gb/s PHY for operation over copper twin-axial cables, host channels, and module channels consistent with channels (TP0-TP5) specified
in IEEEStd802.3bj-2014 Clause93 This sort of reinforces a single silicon solution. From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
Chris – Clause 92 has a lot of non-channel stuff in it, and the parenthetical insert, while clarifying to those who know clause 92 intimately, isn’t perhaps as clear as
you could be. Pointing to the correct subclause, a figure or a table would be a lot better. The wording itself leads to confusion because it says “over copper twinaxial cables consistent with”, but TP0 to TP5 includes more than the twinax cables, as you
know. We end up with a couple of choices: 1) Just identify the cables in clause 92, or 2) Say operate over the whole TP0 to TP5 channel in clause 92 (I apologize because I have another call which conflicted with yesterday’s meeting – I don’t have an opinion on whether using the whole channel from TP0 to TP5
is in fact the correct objective, or whether you want to do just the cables) If you just want to do (1) just the cables, the cable assembly is specified in 92.10 (and references elsewhere), I would suggest stating •Define a single-lane 25Gb/s PHY for operation over copper twin-axial cables consistent with cable assemblies specified in IEEEStd802.3bj-2014 Clause92.10 And, if you want to do the whole channel, including the PCB, as you stated, from TP0 to TP5, Clause 92.9 clearly specifies this (by referencing other subclauses) •Define a single-lane 25Gb/s PHY for operation over copper twin-axial cables consistent with cable assemblies specified in IEEEStd802.3bj-2014 Clause92.9 Note I’m looking at draft 3.2 of the 802.3bj, and don’t have the final published version. George Zimmerman Principal, CME Consulting Experts in Advanced PHYsical Communications Technology 310-920-3860 (PLEASE NOTE NEW EMAIL ADDRESS. THE OTHER WILL STILL WORK, BUT PLEASE USE THIS FOR CME BUSINESS) From: Christopher T. Diminico [mailto:00000025925d7602-dmarc-request@xxxxxxxx]
Colleagues,
Based on the discussions of the objective given on slide 9 second bullet in
http://www.ieee802.org/3/25GSG/public/adhoc/architecture/nowell_081214_25GE_adhoc.pdf
during the ad-hoc yesterday, I suggest we explicitly identify 802.3bj channel by adding (TP0-TP5).
Change from •Define a single-lane 25Gb/s PHY for operation over copper twin-axial cables consistent with channels specified in IEEEStd802.3bj-2014 Clause92 To •Define a single-lane 25Gb/s PHY for operation over copper twin-axial cables consistent with channels (TP0-TP5) specified in IEEEStd802.3bj-2014 Clause92 Regards,
Chris DiMinico -----Original Message----- Sorry everyone – calendar screw up on my side around the re-arranged architecture ad-hoc meeting. Will update soon with improved logistics. Mark On 8/19/14, 5:42 PM, "Mark Nowell (mnowell)" <mnowell@xxxxxxxxx> wrote: Dear 25Gb/s Ethernet Study Group Members, A few reminders and updates: 1)
Optical Ad-hoc is tomorrow Wed 8/20 @ 9am PST. Dial in details are here: http://www.ieee802.org/3/25GSG/public/adhoc/index.html 2)
Architecture ad-hoc meeting next week has moved to Wed 8/27 @ (am PST (shifted from Tues). Dial in details are here: http://www.ieee802.org/3/25GSG/public/adhoc/index.html 3)
Reminders on Call for presentations and September Meeting planning. Presentation request deadline is Friday Aug 29th. Please see my original email for details on meeting logistics and travel planning (We meet all-day Thurs and Friday). http://www.ieee802.org/3/25GSG/email/msg00004.html As a reminder, the September Study Group meeting has limited meeting time and the presentations will be focused on the Study Group work of building objectives,
developing responses to the CSD (5 Criteria) and PAR. Presentations outside of the scope of those priorities will be given time on agenda as possible. Regards…Mark |