Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Clause 44 Question




Pat,
I'm totally agree with your assertions: My calculation are not very accurate
and can be improved. But, with such a big delay consumed by the MDI itself,
why shouldnt we give a bigger guardband for the devices delay and enable an
easier implementation?

Boaz
> -----Original Message-----
> From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> Sent: Thursday, March 29, 2001 7:31 PM
> To: boazs@xxxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
> Subject: 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
>