RE: Clause 44 Question
Boaz,
Your calculations start out with an assuption that the receiver is given
half the delay budget for XGXS. The transmitter has little delay. It doesn't
have to deskew and it doesn't have the "push back." It may have clock
compensation and it has 1 or 2 bytes for encoding and serialization of the
data. Therefore, the transmitter needs less than half the budget and the
receiver can use more than 512 bits. If the transmitter has 128 bits (4
bytes per channel) of delay, then the XGXS or PCS receiver can use 896 bits
or 28 bytes per channel.
The purpose of specifying only the round trip delay is to allow implementers
to choose how to trade off delay between the transmitter and the receiver.
I agree that the delay numbers should be set so they are not tight. However,
a calculation to justify increasing the numbers should take into account the
sharing of the delay between transmitter and receiver.
Regards,
Pat
-----Original Message-----
From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
Sent: Thursday, March 29, 2001 4:43 AM
To: HSSG (E-mail)
Subject: Clause 44 Question
Hi,
Regarding the "delay constraints" in Chapter 44:
What is the reason for the delay requirements? Is it just the size of the
buffer that is required in the MAC for the implementation of the PAUSE
protocol? According to table 44-3 (D2.3), even the delay of a fiber as
short as 1km is about 80K bit. And probably many applications will have much
longer fiber path.
For instance, the delay of the XGXS is 1K bit, for Tx+Rx. Assuming 512 bits
for Rx, this is 128 bit / channel, or 16 bytes, from PMA to XGMII. As max
skew is 41 bits, a deskewing FIFO has a depth of more then 4, say 5 Bytes.
The PMA itself has 1-2 samples. Additional gap must be provided for clock
tolerance, creating additional, say, two samples. The "Copy back" / "Push
back" function requires at least additional one. Now if the implementation
is with 312.5Mhz clock, it seems fine. However, if we do not want to force
the user to do it with such fast clock, then with 156.25 Clock any sample
means 16 bits, or 2 bytes, and we are out of budget. And there are more
things to do: State Machines, 8B/10B etc.
I think that in this frequency it is somewhat problematic constraint, and in
order to enable more implementation options, should be enlarged (Easier to
implement). Especially if one needs a x100 times bigger buffer because of
MDI delay anyway.
Boaz