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

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

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

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
        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
        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
Tim Warland     P.Eng.
Hardware Design Engineer  Broadband Products
High Performance Optical Component Solutions
Nortel Networks                (613)765-6634