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

Give me serial 10GbE or.......




Rich,

I have questions about some of the assumptions you are making.
I do not believe all of these assumptions are required to 
achieve the design goal as I understand it to be.  See below 
for detailed comments:

------------------------------------------------------

At 04:10 AM 12/2/99 -0800, you wrote:
>
>Pat,
>
>The inherent reasons are:
>
>a) The ability to locate a transceiver a significant distance (a foot or two)
>away from the protocol ASIC(s);

--------------------------------------------------------
Why locate the transceiver a foot away from the ASIC?
This is a bad idea even at 1.25Gbit.  In fact, most
FC and GbE gigabit layouts I have seen have this distance
managed very well.  Typically, we have seen this separation
at less than one inch.  There is nothing to be gained by
separating the ASIC and the transceiver any further, so I
must say I see nothing compelling in "a)" above.
---------------------------------------------------------- 

>b) The ability to use a low-cost technology (e.g. CMOS) to drive the
>transceiver;

----------------------------------------------------------
I agree with the goal but not the assumption CMOS is the
only low cost technology enabling this 10G proposal.  There
is of course now Silicon Germanium technology which has
already made it's way into a number of commercial trans-
impedance amplifiers (TIA) and laser drivers.  There is also
a 10G SONET mux available in SiGe.  GaAs is proven in both
driver/mux and TIA applications at 10G.
------------------------------------------------------------

>c) The ability to use common PCB material to to build 10 Gbps products;

-------------------------------------------------------------
No problem.  If we obey the "short is good" rule of RF
and microwave layout, runs of 1-2 inches can be accomodated
between the transceiver and the ASICs.  If one makes use of
buried stripline and blind vias, one extends this a bit further
without difficulty.  FR-4 will support this just fine.
-------------------------------------------------------------

>d) The desire to keep microwave technology, if required at all,  isolated
to a
>small part of the transceiver;

-------------------------------------------------------------
You can not reduce the minimum number or nature of the
10G connections inside a transceiver anyway.  You must have 
these connections between photodetector and preamplifier, pre-
amplifier and post amplifier on the receiver.  The 10G lines
must also connect laser diode to laser driver.  We also need 10G
input connections from the laser driver to the outside world
similar to those needed by the receiver.  So what I am proposing
is exactly the minimum number of these RF/microwave connections.
I am absolutely confident in our abilities to accomplish this 
task within the cost goals of the Ethernet community.
--------------------------------------------------------------

>e) Per port cost. What is your cost target at maturity with the interconnect
>technology your proposing? Please consider all costs. Is is 3.5X GbE port
cost
>at maturity? If not. This is the primary reason for a low-cost ubiquitous
>interface like Hari.
>

--------------------------------------------------------------
I have seen the cost targets and the performance goals and I
do not believe either is unrealistic.  I must point out you 
failed to mention the best argument for HARI on an optical 
PMD - the possible use of MAS.  Though this topic has not been
debated recently, I believe it has tremendous potential if we
are able to pull it off.  However, until I see a demonstration,
I do not think we should burden our transceiver PMD interface
with HARI.  It does not appear to be necessary except to facilitate
MAS bandwidth reduction.  I do not believe MAS will be useful 
outside the LAN anyway, so I am not positive about HARI for the
optical PMD interface. 
-----------------------------------------------------------------

Warmest Wishes,

Pat Gilliland
patgil@xxxxxxxxxxx