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.

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

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

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

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

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 thePMA and PCS inputs ...
setup and hold times. The PMA is spec'd at a minof 250ps while the PCS input is
spec'd for 300ps. The thinking at the timewas that the PMA technology would be
"better" and can take less setup andhold times (250ps vs 300ps), i.e. it
can latch faster.Upon recent further thinking, this asymmetry on the budget for
TX and RX doesnot make sense. I would say that the budget for the
PCB/connector/traceswould have to be the same in both directions. Thus ...
either the PMA outputwould need to tighten up or the PCS input would also have to
meet the 250pssetup and hold.I would think that the system
designer would opt for the maintaining a 600psallowance.

I asked my apps engineer
and looked in the OIF document that the XSBIwas based on. The numbers
look reasonable. The only thing I questionis 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.

Getting board skew to
600ps can be a challenge depending on yoursituation. 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 thetransmit> direction.>> I would like to get numbers
from some board/connector people. I don'tthink> 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
table51-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.>
>