Re: [802.3_GEPOF] Jitter clarification presentation
Hi David,
I must admit that stacking presentations and back referencing creates a pretty hard to follow chain of presentations, especially if someone is trying to understand all details. Let me summarize here and see whether we can agree on the assumptions:
Observation 1: your PCS encoder (per http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf) takes 8 bits from TX_EN lines in GMII every GTX_CLK, and stacks resulting octets one after another forming the PDB.DATA per page 4 in http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf. What is not clear, though, is how you can assess, in advance, the TYPE information. It seems that you can only figure out whether the given PDB carries data or control after the last octet was received from GMII and you have a view of the whole frame. It would imply that TYPE needs to be located at the end of the frame. That is not clear. If I missed something obvious here, let me know, but I do not see how you can guess the type of PDB having not received the whole frame.
One obvious way would be to introduce a delay line of the size of PDB (8 octets long) and generate PDB with a fixed delay of 8 octets - this does not add jitter, but constant delay, which is acceptable and relatively small.
Observation 2:: your PCS encoder operates at the same clock rate as GMII at input, but output clock is 65/64 higher than GMII clock - that is the result of adding one bit of TYPE information to the PDB frame.
Observation 3: your jitter analysis on slide 12 in http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf makes sense to me, but not the latency analysis - that is the result of missing explanation on how TYPE field is generated. Once that is clarified, we might discuss the latency further.
Now, moving into FEC encoder with the input rate of 65/64 * 10^9 bits, I failed to find a single demonstration of the FEC encoder bit stream and how data from PCS encoder is then chopped and mixed with FEC data. http://www.ieee802.org/3/bv/public/Jan_2015/perezaranda_3bv_1b_0115.pdf is not very helpful here - it is rich in math and theory on how it is supposed to operate, but I think to better understand the operation of FEC encoder, I need to see what the expected frame will look like after FEC encoder. The way I see is that PCS encoder will be sending data to FEC encoder either in serial fashion (one bit at a time) or in 65 bit chunks. This is not defined right now. Please clarify ...
And finally, onto the presentation you attached. While I can agree that the PCS encoder does not add packet level jitter (it might add systematic delay - to be clarified per discussion above), I do not agree with the statement that per [1] there is no packet jitter. PCS encoder is not the only source of jitter in the stack. FEC encoder is another and that one is poorly defined right now.
I do not follow the need for flow control block on slide 3 - the way you defined PCS encoder in http://www.ieee802.org/3/bv/public/Mar_2015/perezaranda_3bv_1b_0315.pdf, there is no need for any flow control of any kind - you have 64/64 bit rate in, and 65/64 bit rate out and unless you are trying to clock both sides at the very same rate, there are no problems. I believe all designs I have seen so far assume that output from PCS encoder is not serial but rather block oriented, which takes away some of clock alignment problems (and adds other problems), but at least avoids the need for fancy flow control functions of any kind. Data is collected in 8-bit chunks at GMII clock rate, processed and then delivered to FEC encoder in 65 bit chunks every 8 GMII clock cycles.
Since there is no clarify on some items in PCS encoder and FEC encoder structure, I cannot really assess whether the analysis you show is correct or not. Furthermore, state diagrams would really help here - paper analysis is fun, but we need to get down to details and these will be hard to come by until we see state diagrams to examine and punch holes in.
Thanks for the presentation
Marek Hajduczenia, PhD
Network Architect, Principal Engineer
Bright House Networks
Office +1-813-295-5644
Cell +1-813-465-0669
-----Original Message-----
From: David Ortiz [mailto:david.ortiz@xxxxxxxxx]
Sent: Wednesday, March 25, 2015 11:22 AM
To: STDS-802-3-GEPOF@xxxxxxxxxxxxxxxxx
Subject: [802.3_GEPOF] Jitter clarification presentation
Dear all,
We have prepared a small presentation to clarify the doubts that were raised during the last plenary meeting regarding the packet jitter in 1000BASE-RH.
Please find it attached to this email.
We will be happy to answer any question/doubt that might arise.
Best regards,
David
--
Knowledge Development for POF SL
Ronda de Poniente 16, 2ºA
28760 TRES CANTOS (Madrid) - Spain
www.kdpof.com
email: david.ortiz@xxxxxxxxx