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

RE: Clause 51 (XSBI) questions

Justin, Erik,

Much as we agree on must issues Justin, I have to disagree when you state
that "It is not required that one uses the PMA_TXCLK_SRC".

It is not required that the PCS use a specific edge of the PMA_TXCLK_SRC.
However, PMA_TXCLK_SRC is the primary clock source for the PCS (remember
that the reference clock for the PMA is not specified). Furthermore, if the
PCS does not use the PMA_TXCLK_SRC, you open the loop thereby ruling out a
PLL based timing control.



-----Original Message-----
From: Jscquake@xxxxxxx [mailto:Jscquake@xxxxxxx]
Sent: 13. oktober 2000 02:22
To: erikt@xxxxxxxxxxxxxxxxxx; Lysdal, Henning; stds-802-3-hssg@xxxxxxxx
Subject: Re: Clause 51 (XSBI) questions

Hello Erik,

Thanks Henning for your responses. FYI ... Henning is "officially" signed up
to help on clause 51. Added comments/responses to your questions

1) max delay variation: The 30ns max number is open to discussion (of
    I believe this value (>15UI) was a request by an attendee at the adhoc 
    discussion group in La Jolla. The condition for <1KHz is as stated by
    Henning ... a cooling fan fails, temperature fluxuations, etc...

2) section 51.3.1: Agreed that this statement is not needed. Can remove this

    from the next draft. The PMX_TXCLK_SRC is provided help to the PCS to
    generate the proper timing for fig 51-4. It is not required that one

3 & 4) timing for input and output (PMA & PCS)
    As was stated by Henning, the XSBI targetted to only spec the
    PMA input (transmit direction) and the PCS input (receive direction). 
    is not a direct translation from OIF (SFI-4). Most notably is the 
    non-inversion of the clock from the PMA to the PCS. 

    While this "helps" the systems vendor to not have to do an inversion on
    the board. It does make it inconsistent with the transmit side,i.e. data

    latched in on the rising edge of the clock. The transmit side, following

    OIF would still warrant the system vendor to do an inversion on the
    I don't have a strong position on this but I think it would be
    try and have a consistent edge for both transmit and receive. 


In a message dated 10/12/00 12:50:41 AM Pacific Daylight Time, 
henning.lysdal@xxxxxxxxx writes:

>  Erik, all,
>  Being one of Justins "et al"'s, I've filled in some answers below.
>  Kind regards
>  Henning Lysdal
>  Henning Lysdal           Tel.: +45 70 10 10 62
>  Datacom Design Manager       Direct: +45 44 54 61 54
>                   Fax: +45 70 10 10 63
>  GiGA ApS - an Intel Company
>  Mileparken 22            e-mail: henning.lysdal@xxxxxxxxx
>  2740 Skovlunde           web:
>  Denmark        
>  -----Original Message-----
>  From: Erik Trounce [mailto:erikt@xxxxxxxxxxxxxxxxxx]
>  Sent: 11. oktober 2000 23:29
>  To: HSSG
>  Subject: Clause 51 (XSBI) questions
>  Justin, et al
>  I have some comments and questions regarding clause
>  51, the XSBI interface.
>  1. Table 5-6 of the draft 1.0 specifies a maximum delay
>  variation of 30 ns p-p.  Does the condition (frequency <
>  1kHz) refer to the frequency of the delay variation
>  changing? or is there some other meaning.
>  <<<<<<<<<< ANSWER >>>>>>>>>>
>  The condition refers to the frequency of the delay variation. The < 1kHz
>  range contains delay variations over such phenomena as temperature and
>  process (static, but different for each PCS chip).
>  <<<<<<<<<<<<<<<<<<<<<<>>>>>>
>  2. In section 51.3.1 it says: "The falling edge of
>  PMA_TXCLK_SRC<0,1> is used by the PCS to derive
>  PMA_TX_CLK<0,1>.  Does this mean we are meant to invert
>  PMA_TXCLK_SRC to create PMA_TX_CLK?  or is it meant to be
>  a requirement that if a PLL is used, the PLL uses the
>  negative TXCLK_SRC edge for phase alignment?
>  <<<<<<<<< ANSWER >>>>>>>>>>>>
>  Good point. This specification is not necessary. As long as you meet the
>  timing requirements shown in figure 51-4 the system is supposed to work.
>  suggest we remove this sentence and also that we do not specify the
>  of PLL operation. This is sufficient to ensure interoperability and
>  room for innovative implementations.
>  <<<<<<<<<<<<<>>>>>>>>>>>>>>>
>  3. The draft spec specifies the transmit direction timing
>  at the PMA inputs.  There are no numbers for the PCS outputs.
>  Furthermore, the values given for setup and hold are 50 ps
>  smaller than OIF SFI-4 specifies at the SERDES input.  Will
>  802.3 ever specify timing constraints at the PCS output for
>  the transmit direction and PMA input for the receive direction?
>  <<<<<<<<<<<< ANSWER >>>>>>>>>>
>  The interfaces are specified at the PMA input for transmit and the PCS 
>  for receive. The input timing (on both PCS and PMA) is described using 
>  and hold times. If we choose to add an output timing this should be
>  specified in terms of ck-data delay. The details of the timing 
>  are of course subject to discussion. In the draft we have chosen to
>  the requirements for the PMA and leave a larger timing-budget for the PCS
>  and the board. The PMA devices are fabricated in high-speed technologies
>  whereas the PCS is standard CMOS or FPGAs.
>  <<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>
>  4. Is there a reason the edges are reversed between OIF SFI-4
>  and the draft 1.0?  Specifically, SFI-4 specifies the Rx data
>  valid around the RX_CLK positive edge while the draft
>  specifies Rx data valid around the RX_CLK falling edge.  I
>  realize you can simply switch your differential inputs to
>  achieve the switch.
>  <<<<<<<<<<<<<< ANSWER >>>>>>>>>>>>
>  The interface timing is specified as an input timing requirement using 
>  and hold times. Positioning the falling edge of the clock in the center
>  the databit implies that data is latched out of the PMA device on the 
>  edge. The OIF framer input and SerDes output spec requires system
>  implementors to invert the recieve clock on the board. For clarity we
>  chosen to change the sign in the actual specification, so no
>  clock-inversions are required by system implementors.
>  Cheers,
>  Erik Trounce

Justin Chang
Quake Technologies, Inc.
50 Airport Parkway, San Jose, CA. 95110
Tel: 408-437-7723       email: justin@xxxxxxxxxxxxx
Fax: 408-437-4923       internet: