I too wish
to speak in favor of XLAUI and CAUI
including chip-to-module specifications.
The specifications should align, or at least not be in
the likely instantiations to be found in the market. A
chip-to-chip specification should also
still be made. I hope there is a
way to cover the signal integrity issues of a connector without
specifying its exact
mechanical nature. Can something similar
be done as was for PPI?
Jeffery J. Maki, Ph.D.
Principal Optical Engineer
Juniper Networks, Inc.
1194 North Mathilda Avenue
(Please leave messages by
IEEE 802.3 voter, OIF
voter, & EA alternate voter
Member of OSA, LEOS,
is that specifying a chip to
chip implementation sets one set
requirements focused on low signal
power, low emissions, and fairly
definitions. A chip to module implementation
requirements focuses on slightly
greater signal power, controlled
managed pre-emphasis and
equalization, and a broader range
definitions that include
succeed in a chip to chip
implementation that does NOT have
the chip to
requirements considered, then all
will require intermediate
transceivers on the motherboard
protocol ASIC and the module,
complexity, reliability, and
power. XFI was focused specifically
on chip to
ASIC implementations, using a
module CDR to improve the jitter
the tightly constrained SR
environment. As such, it may be a
It would be
better to have no chip to chip
implementation in this revision
standard if that implementation
precludes chip to module implementations
single definition of ASIC I/O
Sent: Monday, December
Subject: Re: [802.3BA]
CAUI Ad Hoc
right that the nAUI chip to chip
specification methodology in draft 1.1 can be leveraged to build
modules. It just requires writing a chip to module specification
which specifies test points at the modules pins. The presentation you
an excellent starting point for this and a lot of the XFI interface
can be leveraged in writing the nAUI chip to module specifications.
for the New Year to Everyone
This is an
important discussion which
needs to get resolved quickly.
I would like
to ensure that XLAUI / CAUI
maintains its broad market applicability as a simple retimed
don’t think the current specification methodology prevents it from
leveraged to build retimed modules. I’ve put together the attached
material to show how retimed interfaces were specified in the past
XFI). In XFI, you’ll notice that the Before Connector and After
Connector specs are similar. 40/100GbE modules may have an analogous
situation, depending on their size and electrical characteristics.
If we need
to change the XLAUI / CAUI
specification, we need solid contributions on what needs to change.
I just wanted to illustrate the difficulty members of 802.3ba would
defining host-module interface for 100GBase-LR4/ER4 based on
publicly available information rather than in any way pointing to you
argument you did not make.
You also say that specific implementation detail are inappropriate for
IEEE, but CR4/CR10, SR4/SR10 are based on very specific set of
assumptions. The presentation I gave in Dallas, I made some very specific
on the module-host implementation which may be correct
or completely wrong, but we have to make some specific assumption
page 5 http://www.ieee802.org/3/ba/public/nov08/ghiasi_01_1108.
Currently xAUI adhoc is defining transmitter mask instead of testing
transmitter with compliance channel, in case the group decides to define
module-host compliance points then a 2nd transmitter mask must be
the output of module compliance board (see 2nd diagram on page 5).
In summary we have to replicate xAUI transmitter and receiver table for