RE: Clause 48: Data Delay Estimation
Rich,
I think that even if the maximum skew is 41 bits, the current delay
estimation is still on the boarder line:
Assuming about 4 samples in 156.25Mhz clock (Due to logic design and circuit
issues), at least 80 bits delay has to be added, as each sample with 156.25
clock adds 20 UI delay.
Some implementations will be based on third party SERDES device, and if this
is the case, you will always have at least one sample before you even "start
the work", so 4 samples are really not much.
But even so, you finish with 41+80=121 bits delay, which is about 40ns. I
don't know if a 78.125Mhz design is considered, but if so, you will get
twice the above value. I would not say that it has to be as large as 2x40ns,
but I think that it should be more than 40ns.
Regards,
Boaz
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Tuesday, November 21, 2000 8:58 PM
> To: HSSG
> Subject: Re: Clause 48: Data Delay Estimation
>
>
>
> Boaz,
>
> The Clause 48 maximum allowable lane-to-lane skew is <41 bits
> per table
> 48-4. 85 bits is the maximum skew that the ||A|| spacing protocol can
> handle. I roughly calculated the delay estimates based on the maximum
> allowable skew, not the protocol deskew capability. Please
> consider this
> information and tell me if you still believe that the delay
> estimate is
> too low.
>
> Best Regards,
> Rich
>
> --
>
> Boaz Shahar wrote:
> >
> > Hi Rich,
> > I think that the the data delay estimation in section
> 48.2.4.6 is slightly
> > optimistic:
> >
> > The maximal skew between lanes is said to be 85 bits (page
> 148 in D1.1). The
> > maximum delay estimation is 33.6n which is 105 UI. This
> leaves about 20 bit
> > delay for internal logic. If the architecture is based on
> 156.25Mhz clock,
> > any clock cycle is 20 bits. So you are left with only one
> extra sample!
> >
> > Even for lower skew estimation, I think that a delay
> estimation should leave
> > a gauardband for couple of samples, typically about 4
> samples due to logic
> > and circuit issues. 4 samples with 156.25 clock is
> additional 80 bits only
> > for implementation delay within the PCS.
> >
> > So, I propose to increase the number by about 80 bits to
> something around
> > 180 bits (about 60ns)
> >
> > Best Regards,
> > Boaz
>
> -------------------------------------------------------
> Richard Taborek Sr. Phone: 408-845-6102
> Chief Technology Officer Cell: 408-832-3957
> nSerial Corporation Fax: 408-845-6114
> 2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
> Santa Clara, CA 95054 http://www.nSerial.com
>
>