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

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
>> >>