| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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-----Henning,
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
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-----Henning,
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 timingIn 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-----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.
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 timingI 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,
VinuJscquake@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