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

A SON-NET by any other name...


I have to disagree about HARI as an interface
for the optical PMD.  I do not believe it is
the right choice for the optical transceiver
interface.  I believe a serial input at the
full line rate is in order here, unless one 
utilizes a Multi-Amplitude-Signalling approach
to the 10Gb transmission problem.

I have not seen any postings from you on MAS, nor
did you follow up my last note on the use of MAS
being the best justification for a parallel inter-
face to the optical PMD.  So I am wondering if you
are in any way backing away from MAS as your preferred
solution to 10Gb optical transmission.  For the rest
of my comments please see my stanzas below your text:


At 11:20 PM 12/2/99 -0800, you wrote:
>Answer below your questions.
>The distance I quoted is a maximum. One would not do this if one didn't
need to.
>However, in large switches/routers, this will indeed be the case for some
of the
>ports after a "best effort" placement. In any case, you need to provide an
>alternative that gets out to a foot or two. I'll make it easy on you and
just set
>the goal at 8". How can you make a 10-12.5 Gbps trace work at this
distance in
>FR-4? Even if place your SerDes "on top" of the transceiver, how do you
get the 74
>signal XMII bus to go 8" back from your SerDes to the MAC? 

I am not sure what the choices are here interms of the MAC/XMII
interface.  Can the XMII/MAC interface benefit from Hari
encoding?  I do not see why a HARI or other interface might 
not be used between SERDES and MAC.  Or maybe a HARI would fit
between the SERDES and the optical transceiver.

All I am saying is the optical transciever does not want a 
HARI.  It solves no problem in the optical transceiver.
Therefore, let's put HARI to use where is does some good.


>Please consider the
>entire path from the MAC to the transceiver in typical 10 GbE switch/routers.
>We're not talking about TIA's and laser drivers that contain handfuls of
>transistors. We're talking about quite a bit of digital as well as mixed
>logic to support wide data paths, SerDes, clock tolerance compensation
>retimers/repeaters, encoding/decoding, state machines to control the link,
>management functions, etc.
>SiGe is neither low cost nor commonly available at this point in time or
the near


Again, I must disagree with your statement on SiGe.  Both
IBM and Lucent are foundry sources for very capable SiGe
silicon designs.  This approach is cost effective and has
many designs going forward.  AMCC is already offering
commercial SiGe products for 10Gb/s TIA and laser drivers.
The TIA has been a stronghold of GaAs for quite some time
at these bit rates.  Therefore, I must conclude your above
statement does not reflect these realities due to some 
oversight on your part.  

Also, cost effective TIA and laser driver solutions abound
in GaAs at the 10Gb/s rate.  I would point you to the web 
sites of Anadigics, Triquint, and Vitesse.  In my role
in developing advanced transceiver designs, I see an ever
growing variety of product offerings.  I am also seeing
drastic price reductions in mature GaAs building blocks
such as TIA, post amplifers, laser drivers.  The SiGe 
products will have to hit these targets, and the increased
availability will prove decisive.


>Remember also that if you place your SerDes "on top" of the transceiver in
>order to make the 10-12.5 Gbps trace to it work, then you're stuck with
getting 10
>Gbps of data from the MAC to the SerDes. What interface are you using
here? is it
>the Parallel GMII? is it he 622 MHz  16-bit + clock parallel bus? How far
can this
>interface go in FR-4?


Actually, 16X622Mbps or 10X1.25Gbps sound very exciting.
The distance achievable would be even greater than HARI
at 2.5Gb/s if we decide to standardize on one of these 
alternatives.  There might be some synergy in the 10X1.25Gb/s 
since it is also the data rate for 10 standard 1.25Gb/s
Ethernet channels.


> Where is the encoding done (8B/10B or scrambling or other)?
>If it's in the same ASIC as the Serdes and in GaAs or SiGe, it's not going to
>compare favorably with a Hari CMOS solution in terms of power and cost.


Please refer to an article in EE Times of November 29, 1999
entitled "Lucent to show SiGe process for 10-Gbit Sonet"
(Shakespeare never wrote a 10-Gbit Sonnet).
It describes a process whereby the SiGe bipolar transistors
can be easily added to the existing CMOS process as a 
selective epitaxial growth.  A mixed technology ASIC with
portions capable of 10Gb/s is just what is needed to respond
to your concerns above.  

And, you get your CMOS right where it belongs.

> How do you
>later integrate this into the MAC to cut costs? Once again, please
consider the
>entire path from the MAC to the transceiver in typical 10 GbE switch/routers.
>I'm out of my league here. I'll leave this to the Ron Miller's, Joel
>Michael Fogg's, Rich Feldmen's, etc. for comment.
>The connection distances you're talking about in an Optical Sub-Assembly are
>typically 1 to 2 orders of magnitude shorter than those leaving the OSA and
>threading their way back to the system. In addition, you have the luxury
of not
>having to use FR-4 within the transceiver since transceiver PCB costs are
>significantly less than that of a terabit router.


Are you trying to say my job is easy?  Management here
has been saying that for several years now.

But I am planning to use FR-4 as the substrate of choice 
for our 10Gb/s optical transceiver designs, so I am 
perfectly happy with the short distance connections < 1-2".


>You are proposing extending
>these 10-12.5 Gbps connections significantly outside the transceiver module
>another 1 to 2" back to the SerDes. This layout will be very difficult to
>and a signal integrity nightmare.


Again, I disagree.  the worst we can expect is a little
lossy behavior which sometimes works in favor of the
signal termination issues.


>Hari offers a cost effective solution with the highest signal integrity
due to low
>signaling rates (relative to 10-12.5 Gbps) and the shortest high speed
>connections. A CMOS chip inside a transceiver can be located very, very
close to
>the O/E components. 


But I don't want a CMOS HARI chip in my transceiver.  It
doesn't solve any problem inside the transceiver.  And if
it doesn't solve any problem inside the transceiver, we are
not putting it in there just for fun.  

And besides, which CMOS technology is going to put out the 
12.5 Gbaud serial signal? If CMOS is not capable of this, it 
is implied I will have another multiplexer chip inside the 
transceiver to undo what the HARI has done for me (i.e. "solved" 
the problems of high speed serial interfaces by making them
parallel again).  And this implied chip will have to be GaAs 
or SiGe in order to drive the laser and act as the interface 
to the TIA and post amplifier.

I do not see any value to adding such a CMOS HARI chip 
inside the optical PMD definition.


Your worst signal integrity problem is with the Hari
>interface. This problem is manageable.
>Please allow me to give you an idea of how cost effective a 10 Gbps LAN
port can
>be in the future. I'll list the port element form the MAC forward and
leave you to
>run the numbers. Please feel free to compare it to any other
>1) 10 GbE MAC is part of a multi-port, say 8-port chip. This is standard 0.25
>micron CMOS.
>2) The Parallel 10 GMII, PCS, and PMA is integrated into the multi-port
chip and
>available as a core. No change to the chip technology is required. However
>cost/power savings result from going to a better process like 0.18 micron
>better. The interface out for each port is Hari.
>3) The PCB is FR-4, the traces to the transceiver can easily be 20-24".
>4) At the end of the trace is a transceiver/PMD. This can be any 10 GbE PMD
>including Serial, which I'll focus on to reduce your costs. First we have
>chip in the transceiver which interfaces with Hari, cleans us the hari and
>jitter, deskews Hari and the medium , compensates for clock tolerance
>if multiple clock domains exist, controls Hari's serial lanes, provides
>functions, provide endec functions to achieve the lowest possible line rate,
>interfaces to high speed logic signal logic. Optional functions such as
smart link
>control, Optical Auto-Negotiation , MAS provide significant additional
>but I'll ignore those for this exercise. Bottom line is that this is a
CMOS chip
>which significantly reduces what the remaining high-speed logic needs to do.
>Therefore, reducing the complexity and power consumption of that logic.
>5) High-speed mux/demux and CDR for 10 Gbps (BiCMOS, SiGe or GaAs)..
>6) Optoelectronics including Laser driver, Laser, PIN, TIA and Post-AMP
for 10
>7) Transceiver packaging and connectorization through a front panel
>Given the above. I can envision a 3.5X GbE port cost at maturity by just
>to the corresponding GbE bill of materials.
>I'd be interested in seeing the bill of material for your proposed
transceiver to
>MAC path.


I won't try to compete with you here.  I disagree with 
the features you have included in the optical PMD.  If
you remove items 4) and 5) from the transceiver you define
above(the HARI chip and the mux) we have a deal.  Everything 
which belongs in the transceiver is items 6) and 7).

Otherwise, you have defined a typical telecomm style 
transceiver (translation: communications subsystem)
which does not work for low cost data-centric networks.

Low cost transceiver designs are often multi-platform
and multi-protocol.  The best way to achieve this goal
is what the industry has already decided.  Produce optical
transceivers which can handle traffic at a given bit rate
or range of bit rates.  Make this same transceiver serve
multiple markets as we do today.

Presently, one transceiver design accomodates the four main
markets with only minor testing and tuning variations.  
The Gigabit Ethernet, Fibre Channel, ATM and central office
cross connect (SONET-lite) applications are all leveraging
the same set of components and vendors.  All enjoy the 
benefits of the significant volumes.  I daresay the SONET
guys won't be putting the same type of parallel interface
into their transceiver definition anytime soon.  This means
any 10GbE transceiver with a HARI interface will be a special 
for the GbE switch market.

Additionally, your desire to include HARI in the optical
PMD does not address the needs of hub and other traffic 
forwarding equipment designs.  For this application where
the design needs to take in 10-12 GbE lines and trunk them
up to a 10GbE serial rate, you would require them to first
convert each line to the parallel HARI format and then 
reconvert to serial 10GbE in order to accomodate your 
wishes to include HARI in the optical PMD.  The trunking of 
ten 1.25Gbaud lines need not be such a cumbersome task.

Exit stage left.

Best Regards,

Patrick Gilliland