RE: XSBI: cls51 PCS output timing
Vinu,
I'm not sure I follow your math, but I like the numbers.
See you in Irvine.
Regards,
Henning
-----Original Message-----
From: Vinu Arumugham [mailto:vinu@xxxxxxxxx]
Sent: 5. januar 2001 21:28
To: Lysdal, Henning
Cc: stds-802-3-hssg@xxxxxxxx; Jscquake@xxxxxxx;
brian.cruikshank@xxxxxxxxxxxx; david.lockart@xxxxxxxxxxxx
Subject: Re: XSBI: cls51 PCS output timing
Henning,
Clock sources in the 150 - 300 MHz range have a period jitter
specification of 100ps (peak-peak) or better.
It may therefore be reasonable to specify PMA_TXCLK_SRC period jitter as
275 ps (p-p).
Alternately, PMA_TXCLK_SRC tPERIOD-LAN = 1.55 ns +/- 137ps.
This implies PMA_TXCLK tPERIOD-LAN = 1.55 ns +/- 225ps.
To maintain symmetry, specify PMA_RXCLK tPERIOD-LAN = 1.55 ns +/- 225ps.
Thanks,
Vinu
"Lysdal, Henning" wrote:
> Vinu,There are a number of reasons:1) It's really SerDes
> implementation specific, since the SerDes provices the clocks for
> everything else (PMA_TXCLK_SRC and PMA_RX_CLK).2) There are a number
> of options: if we copy the OIF spec (as the intention was from the
> Blue Book) we end up with 644.53 MHz reference clock in LAN mode. For
> cost reasons we wanted to allow slower reference clocks like 156.25MHz
> and 161...MHz. Basically we couldn't agree, and since it is SerDes
> implementation specific, it doesn't matter.You could specify
> PMA_TXCLK_SRC jitter relative to its own average. This is in fact
> similar to when you specify the jitter of a serial input for a clock
> recovery. In this case you also don't have a clock for timing
> reference.Regards,Henning
> -----Original Message-----
> From: Vinu Arumugham [mailto:vinu@xxxxxxxxx]
> Sent: 5. januar 2001 00:36
> To: Lysdal, Henning
> Cc: stds-802-3-hssg@xxxxxxxx; Jscquake@xxxxxxx;
> brian.cruikshank@xxxxxxxxxxxx; david.lockart@xxxxxxxxxxxx
> Subject: Re: XSBI: cls51 PCS output timing
> Henning,
>
> What is the reason for not specifying the REFCLK? I am not sure how
> PMA_TXCLK_SRC jitter can be specified if the REFCLK from which it is
> derived is left unspecified.
>
> Thanks,
> Vinu
>
> "Lysdal, Henning" wrote:
>
>> Vinu,Thanks. I see you're point. How do you propose we specify this.
>> I've been reluctant to put this in, because a lot of people when
>> reading a jitter spec assume an absolute timing reference, and we
>> don't specify a reference clock for the PMA (with good reason). In
>> this case the timing reference for the PMA_TXCLK_SRC jitter would be
>> its own avarage.Agree?Henning
>> -----Original Message-----
>> From: Vinu Arumugham [mailto:vinu@xxxxxxxxx]
>> Sent: 3. januar 2001 19:29
>> To: Lysdal, Henning
>> Cc: stds-802-3-hssg@xxxxxxxx; Jscquake@xxxxxxx;
>> brian.cruikshank@xxxxxxxxxxxx; david.lockart@xxxxxxxxxxxx
>> Subject: Re: XSBI: cls51 PCS output timing
>> Henning,
>>
>> The transmitter's available data valid window less the receiver's
>> required data valid window gives the time available for board
>> interconnect imperfections. The receiver requirement is specified as
>> tSETUP+tHOLD=600ps. However, the board interconnect designer cannot
>> compute the transmitter data valid window, if PMA_TXCLK_SRC jitter
>> is not in the standard.
>>
>> Thanks,
>> Vinu
>>
>> "Lysdal, Henning" wrote:
>>
>> > Vinu,That would be the minimum period (LAN: 1552ps) less the jitter
>> > on PMA_TX_CLK.The jitter on PMA_TX_CLK would be a combination of
>> > the PCS jitter transfer at high frequencies (175ps) and the
>> > PMA_TXCLK_SRC jitter.The data valid window would need to be
>> > calculated by the PMA designer, so he can design his input latches.
>> > Obviously he should also know the jitter his part generates at
>> > PMA_TXCLK_SRC.Do you agree?Is the information need by others? if
>> > not it's PMA implementation specific, and need not be in the
>> > standard.Regards,Henning
>> > -----Original Message-----
>> > From: Vinu Arumugham [mailto:vinu@xxxxxxxxx]
>> > Sent: 2. januar 2001 22:26
>> > To: Lysdal, Henning
>> > Cc: stds-802-3-hssg@xxxxxxxx; Jscquake@xxxxxxx;
>> > brian.cruikshank@xxxxxxxxxxxx; david.lockart@xxxxxxxxxxxx
>> > Subject: Re: XSBI: cls51 PCS output timing
>> > Henning,
>> >
>> > In the current specification, the valid data window is a function
>> > of PMA_TX_CLK's tPERIOD. It is not clear to me how one can compute
>> > tPERIOD min. from the information in the spec.
>> >
>> > Thanks,
>> > Vinu
>> >
>> > "Lysdal, Henning" wrote:
>> >
>> >> Vinu,Could you please explain your point (the problem part) in a
>> >> little more detail. The transmit data timing is reference to
>> >> PMA_TX_CLK, so as I see it the worst case situation is the
>> >> setup/hold times required on the PMA input. Since the PMA
>> >> provides the master clock (PMA_TXCLK_SRC) the PMA input is
>> >> completely defined by the PCS jitter transfer (PMA_TXCLK_SRC to
>> >> PMA_TX_CLK), the PCS PMA_TX_CLK to data out delay and the board
>> >> variations. Regards,Henning
>> >> -----Original Message-----
>> >> From: Vinu Arumugham [mailto:vinu@xxxxxxxxx]
>> >> Sent: 27. december 2000 00:26
>> >> To: stds-802-3-hssg@xxxxxxxx
>> >> Cc: Jscquake@xxxxxxx; brian.cruikshank@xxxxxxxxxxxx;
>> >> david.lockart@xxxxxxxxxxxx
>> >> Subject: Re: XSBI: cls51 PCS output timing
>> >> There does not appear to a be a jitter spec. (period jitter) for
>> >> the PMA_TX_CLK (and PMA_RX_CLK). The 175 ps number used in one of
>> >> the posts below does not seem to be the correct parameter for the
>> >> timing calculations on this interface. As a result, the worst
>> >> case data valid window cannot be accurately calculated.
>> >>
>> >> I suggest that the specification be simplified by using the XGMII
>> >> format to specify timing. This will preclude the need to specify
>> >> jitter separately for this interface (A jitter spec. for the
>> >> PMA_TXCLK_SRC signal is needed).
>> >>
>> >> Specify output Tsetup+Thold=930 ps (60% of 1/644.5321258).
>> >> Specify input Tsetup=Thold=230 ps (15% of 1/644.5321258).
>> >>
>> >> Please see attached document. The document discusses frequency
>> >> independent timing specification for DDR and is easily
>> >> applied to non-DDR source synchronous interfaces. This was used
>> >> as the basis for the XGMII timing specification.
>> >>
>> >> Thanks,
>> >> Vinu
>> >>
>> >> Jscquake@xxxxxxx wrote:
>> >>
>> >> >
>> >> > Hello Brian,
>> >> >
>> >> > The difference in the XSBI spec is not in the PCS, PMA output
>> >> > but rather the
>> >> > PMA and PCS inputs ... setup and hold times. The PMA is spec'd
>> >> > at a min
>> >> > of 250ps while the PCS input is spec'd for 300ps. The thinking
>> >> > at the time
>> >> > was that the PMA technology would be "better" and can take less
>> >> > setup and
>> >> > hold times (250ps vs 300ps), i.e. it can latch faster.
>> >> > Upon recent further thinking, this asymmetry on the budget for
>> >> > TX and RX does
>> >> > not make sense. I would say that the budget for the
>> >> > PCB/connector/traces
>> >> > would have to be the same in both directions. Thus ... either
>> >> > the PMA output
>> >> > would need to tighten up or the PCS input would also have to
>> >> > meet the 250ps
>> >> > setup and hold.
>> >> > I would think that the system designer would opt for the
>> >> > maintaining a 600ps
>> >> > allowance.
>> >> >
>> >> > Justin
>> >> >
>> >> > In a message dated 12/12/00 6:58:56 PM Pacific Standard Time,
>> >> > brian.cruikshank@xxxxxxxxxxxx writes:
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> Justin,
>> >> >>
>> >> >> I asked my apps engineer and looked in the OIF document that
>> >> >> the XSBI
>> >> >> was based on. The numbers look reasonable. The only thing I
>> >> >> question
>> >> >> is why have a difference between the PCS output and PMA
>> >> >> output.
>> >> >>
>> >> >> - Board traces can be long. Customers will push the limit.
>> >> >> We have seen 15 inches used. Board trace on the system
>> >> >> board,
>> >> >> board trace on a module. If you delay the clock by trace,
>> >> >> this
>> >> >> also adds ~5" trace length. There is variability between
>> >> >> layers
>> >> >> which makes for skew. With +/- 10% FR4, the skew is about
>> >> >> 15% in
>> >> >> time which could be 350+ ps.
>> >> >>
>> >> >> - clock jitter (175 ps according to the specification)
>> >> >>
>> >> >> - connector will add noise, crosstalk, and skew. (50-100ps)
>> >> >>
>> >> >> - clock duty cycle if inverting the clock. (160ps with 40/60
>> >> >> duty cycle)
>> >> >>
>> >> >> Total board skew could be 350+175+100+160=785ps by inverting
>> >> >> the clock.
>> >> >> Total board skew with etch delay could be 350+175+100=625ps.
>> >> >>
>> >> >> With VERY optimistic numbers (5" clock delay+ 2.5" trace
>> >> >> delay)
>> >> >> and not inverting the clock:
>> >> >> 175+175+100=450ps.
>> >> >>
>> >> >> Getting board skew to 600ps can be a challenge depending on
>> >> >> your
>> >> >> situation. Especially in production.
>> >> >>
>> >> >> /Brian Cruikshank
>> >> >>
>> >> >> Jscquake@xxxxxxx wrote:
>> >> >> >
>> >> >> > Hello,
>> >> >> >
>> >> >> > Below is a msg string in regards to PCS and XSBI timing,
>> >> >> specifically the
>> >> >> > setup and hold numbers that are currently in Draft 2.0. I
>> >> >> would like to
>> >> >> > solicit
>> >> >> > the system board designers inputs on the discussion below.
>> >> >> Thanks in
>> >> >> > advance for your assistance.
>> >> >> >
>> >> >> > Justin Chang
>> >> >> > Quake Technologies, Inc.
>> >> >> > 50 Airport Parkway, San Jose, CA. 95110
>> >> >> > Tel: 408-437-7723 email: justin@xxxxxxxxxxxxx
>> >> >> > Fax: 408-437-4923 internet: www.quaketech.com
>> >> >> >
>> >> >> > ------
>> >> >> > Justin,
>> >> >> >
>> >> >> > On the PCS output it's not the 600ps board spec that's
>> >> >> tight. It's the
>> >> >> > 1100ps PCS output spec.
>> >> >> >
>> >> >> > As you point out, we want more setup/hold time for the PCS
>> >> >> in the other
>> >> >> > direction. Similarly we need to allow more slack to the PCS
>> >> >> in the
>> >> >> transmit
>> >> >> > direction.
>> >> >> >
>> >> >> > I would like to get numbers from some board/connector
>> >> >> people. I don't
>> >> >> think
>> >> >> > they need 500ps-600ps.
>> >> >> >
>> >> >> > Henning
>> >> >> >
>> >> >> > -----Original Message-----
>> >> >> > From: Jscquake@xxxxxxx [mailto:Jscquake@xxxxxxx]
>> >> >> > Sent: 7. december 2000 03:10
>> >> >> > To: henning.lysdal@xxxxxxxxx;
>> >> >> stuart_robinson@xxxxxxxxxxxxxxxx
>> >> >> > Cc: steen.christensen@xxxxxxxxx
>> >> >> > Subject: Re: cls51 PCS output timing
>> >> >> >
>> >> >> > Hello Henning, Stuart,
>> >> >> >
>> >> >> > If the 600ps is tight then the return path PMA to PCS is
>> >> >> even tighter.
>> >> >> That
>> >> >> > is spec'd with a 500ps margin ...
>> >> >> >
>> >> >> > PMA output 1500-400=1100ps
>> >> >> > PCS setup 600ps
>> >> >> > ----
>> >> >> > total left for margin is 500ps
>> >> >> > The point of the asymmetry was to give more setup and hold
>> >> >> for the CMOS
>> >> >> > PCS IC. I agree that we should hear from the system
>> >> >> designers on this one.
>> >> >> > The place where we could cut back are
>> >> >> > 1) setup and hold for the PMA input (better technologies)
>> >> >> ... change to
>> >> >> > +/-200ps
>> >> >> > 2) setup and hold for PCS (overly generous w/ 300ps?) ...
>> >> >> change to 200ps
>> >> >> > as well ... this would make everything symmetric
>> >> >> > Total budget in both directions would be 1550-800=750ps for
>> >> >> the board
>> >> >> > designer (connector and traces). Thoughts?
>> >> >> >
>> >> >> > I think I would put this out on the reflector?
>> >> >> >
>> >> >> > Justin
>> >> >> >
>> >> >> > In a message dated 12/1/00 3:09:10 AM Pacific Standard Time,
>> >> >>
>> >> >> > henning.lysdal@xxxxxxxxx writes:
>> >> >> >
>> >> >> > > Our CMOS designers have informed me that the PCS output
>> >> >> timing is pretty
>> >> >> > > strict.
>> >> >> > >
>> >> >> > > Looking at the numbers:
>> >> >> > > Period approx. 1.5ns (LAN mode)
>> >> >> > > PCS output data valid: 1100ps (1500ps - Tcq_min-Tcq-max,
>> >> >> from table
>> >> >> 51-3)
>> >> >> > > PMA input valid requirement: 500ps (tsetup+thold, from
>> >> >> table 51-4)
>> >> >> > >
>> >> >> > > Margin for board and connectors: 600ps
>> >> >> > >
>> >> >> > > I think we should get a realistic estimate from a system
>> >> >> implementer on
>> >> >> > the
>> >> >> > > required margin for the board before we finalize these
>> >> >> numbers. If not,
>> >> >> > we
>> >> >> > > end up putting tough restrictions on the PCS design for no
>> >> >> appearant
>> >> >> > reason.
>> >> >> > >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Justin Chang
>> >> > Quake Technologies, Inc.
>> >> > 50 Airport Parkway, San Jose, CA. 95110
>> >> > Tel: 408-437-7723 email: justin@xxxxxxxxxxxxx
>> >> > Fax: 408-437-4923 internet: www.quaketech.com
>> >>