On Fri, Jan 03, 2020 at 09:27:18AM +0000, Russell King - ARM Linux admin wrote:
> Merely specifying "xfi" does not tell you what you need to do to achieve
> XFI compliance at the point defined in INF8077i. Plus, XFI can also be
> protocols _other_ than 10GBASE-R.
>
> Claiming that "XFI" properly defines the interface is utter rubbish. It
> does not. XFI defines the electrical characteristics *only* and not
> the underlying protocol. It is not limited to 10GBASE-R, but includes
> other protocols as well.
Let me quote from INF-8077i, which is the XFP MSA, the document
responsible for defining XFI:
3.1 INTRODUCTION
XFI signaling is based on high speed low voltage logic, with nominal 100
Ohms differential impedance and AC coupled in the module. XFI was de-
veloped with the primary goal of low power and low Electro-Magnetic-In-
terference (EMI). To satisfy this requirement the nominal differential signal levels are 500 mV p-p with edge speed control to reduce EMI.
3.2 XFI APPLICATIONS DEFINITION
The application reference model for XFI, which connects a high speed
ASIC/SERDES to the XFP module is shown in Figure 4. The XFI interface
is designed to support SONET OC-192, IEEE.Std-802.3ae, 10GFC and
G.709(OTU-2) applications. The SERDES is required to meet the applica-
tion requirements for jitter generation and transfer when interfaced with a
compliant XFP module through an XFP compliant channel. Modules or
hosts designed only for 10 Gigabit Ethernet or 10GFC are not required to
meet more stringent Telecom jitter requirements. XFI supported data
rates are listed in Table 5. XFP compliant module are not required to sup-
port all the rates listed in Table 5 in simultaneously.
Standard Description Nominal Bit Rate Units
OC-192/SDH-64 SONET 9.95 Gigabaud
IEEE std-802.3ae 10 Gb/s Ethernet LAN PHY 10.31 Gigabaud
INCITS/T11 Project 1413-D 10GFC 10.52 Gigabaud
ITU G.709(OTU-2) OC-192 Over FEC 10.70 Gigabaud
Emerging 10Gb/s Ethernet Over G.709 11.09 Gigabaud
So here, we can clearly see that it's possible to run SONET, 10GBASE-R,
10G Fiberchannel, OC-192, and G.709 over XFI, so XFI does not describe
_just_ ethernet. If we're going to be configuring a serdes to output
XFI, we need to know a lot more than just "XFI".
XFI Compliance points are defined as the following:
• A: SerDes transmitter output at ASIC/SerDes package pin on a DUT
board 3.6 and A.1
• B: Host system SerDes output across the host board and connector
at the Host Compliance Test Card 3.7.1 and A.2
• B': XFP transmitter input across the Module Compliance Test Board
3.8.1 and A.3.
• C: Host system input at the Host Compliance Test Card input 3.7.2
and A.2
• C': XFP module output across the Module Compliance Test Board
3.8.2 and A.3.
• D: ASIC/SerDes input package pin on the DUT board 3.6.2 and A.1.
ASIC/SerDes compliance points are informative.
So the electrical points that count are B, B', C and C'. A and D
are merely "informative". Hence, compliance with XFI is required
to take the entire platform into account, not just the output of
the serdes/asic. That means the performance of the PCB needs to
be described in DT if you want to achieve compliance with XFI.
phy_interface_t can't do that.
So, let me re-iterate: neither XFI nor SFI are suitable for
phy_interface_t. XFI defines merely a group of possible protocols
and an electrical specification. It doesn't tell you which of those
protocols you should be using.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
