Re: [802.3ae] XSBI - LVCMOS I/O's

["Tim Warland" <twarland@xxxxxxxxxxxxxxxxxx>]

Justin Chang wrote:

Hello all,

To help the audience in this round of comments, I would like to
highlight an open issue from the St. Louis meeting.

Regarding the I/O specification of the Sync_Err and the PMA_SI output
signals, draft 3.1 and previous drafts has this defined as LVCMOS

<snip>

Here are some things to note as you think about this issue.

1) SFI-4 (OIF document which XSBI is leveraged from) has their mandatory

    Sync_Err defined as LVPECL.

The mandatory Sync_Err signal is defined to be LVTTL
> 2) LVCMOS outputs would be compatible w/ LVPECL inputs.
This doesn't work. In fact for low speed signalling, this is the
worst combination. The minimum input voltage for a PECL gate
is 1490mV. As this is a minimum, it can't be driven from a
TTL type gate. However it's a moot point - since SFI-4 is LVTTL.
> 3) The specific LVCMOS standard to use is not defined
> in current draft.
Quick research on the ANSI site led to EIA/JESD8-B Interface Standard
for Nominal 3V/3.3V Supply Digital Integrated Circuits.  The good
news
is that this specification makes LVCMOS compatible with LVTTL.
(The original problem was lack of noise margin for an LVCMOS Vih
spec of 0.7*Vdd driven from LVTTL as discussed on page 4 of the
Standard).  Thus the clause could be editted to include a reference
to JESD8-B compatible Low Voltage signalling.

4) The intent of having XSBI as an optional clause in the standard is to

        allow implentors to use existing components built from the OIF
effort.
        It does not necessary mean we copy OIF exactly.

There are three options to choose from as we head into Portland and
draft 3.2.

1) Leave definition as is, i.e. LVCMOS. Allows newer technologies. Still

        need to define what LVCMOS levels to use.
 

As defined by JESD8-B
> 1) Revert to LVPECL as in OIF. This will insure compatibility
> w/
> components that
>         are out built upon SFI-4
> specs. There is still the question of
> what
> LVPECL
>         specs should be referenced.
delete this idea
>  
> 2) Leave the I/O type undefined. Problem here is that IEEE historically
> has not
>         done this for a physical
> instantiation description, i.e. I/O/s
>         have been defined.
A good second option. Since the signals are optional, is there a
requirement to define their compatibility?  Perhaps it is better
to allow the Multi-Source Agreements to define optional interface
signals.
-- 
Tim Warland     P.Eng.
Hardware Design Engineer  Broadband Products
High Performance Optical Component Solutions
Nortel Networks                (613)765-6634