Re: Feliz Haridad
Patrick Gilliland wrote:
>
> Rich,
>
> This might be my last e-mail of 1999. More notes
> to your notes; see below.
> -------------------------------------------------
>
> >For a multi-level system, The AGC would have to be linear and capable
> >of maintaining equal effective BER's for all levels. In general, this
> >requires a far more sophisticated AGC than is commonly employed in
> >binary signaled systems.
> >
> >A carefully designed multi-level system would establish and maintain
> >an optimum dynamic range at the receiver by accurately controlling
> >the current applied to the laser for each level.
>
> Whatever the transmit power limits are, there most
> assuredly will be an AGC at the receiver. Perhaps
> there will be some relief in the AGC design if it
> operates over a narrower dynamic range - I can't think
> of any right now.
Multi-level links require an AGC function as do traditional binary signaled
links. However, the AGC implementation can be significantly different and may
not look anything like the AGC function you're familiar with.
----------------------------------------------------------------------
> >
> >Page 15 of the same tutorial discusses alternate modulation techniques
> >such as Optical QAM. My Kauai technology update further discusses
> >alternatives past PAM5. See page 24 of
> >http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/taborek_2_1199.pdf
> >
> I am looking it up now. One theme which comes to mind is
> linear FM. It is a fact the most linear characteristic of
> common lasers is their time domain, or phase performance. I
> did not want to have any missiles launched at me before Y2K, but
> QPSK or MPSK are more attractive alternatives to me than MAS
> in terms of their technical risks.
Once again, you're free to make any proposals to the P802.3ae that you like.
> -----------------------------------------------------------
>
> >> 1) Inclusion of HARI increases the jitter budget by your
> >> logic above because it increases the number of elements
> >> over the conventional serial approach.
> >
> >You are incorrect. Hari has its own jitter budget which is separate
> >from the PMD-medium-PMD jitter budget. A link architecture employing
> >Hari is significantly different than a conventional link architecture
> >such as GbE or 1/2 Gbps Fibre channel.
>
> I suspect we are discussing a semantic, rather than substantive
> difference here. Jitter should not be substantially altered
> in either case, unless a number of combinational stages are
> required to decode the HARI and encode the MAS driver should
> it in fact exist as an interface to the PMD/transceiver.
>
> What really counts is the total jitter at the transmitter port.
This issue as far from semantic in nature. Hari significantly revolutionizes the
architecture of a 10 Gbps link by supporting retiming at the PMD.
Since there are two PMDs in a 10 Gbps link, one in the local and one in the
remote device, the jitter budget in the PMD->medium->PMD link segment is
separate from the jitter budgets of the two MAC/PHY to PMD segments. A "perfect"
10 Gbps link implementation based on this architecture would allow a jitter
budget approaching 300% with 100% available to each link segment.
What really count is total jitter at the receiver. With a Hari based link, there
are 3 receivers in the link, each with a separate jitter budget.
> ---------------------------------------------------------------
>
> >> Keep in mind HARI reduces the transmission bandwidth by four,
> >> but it also multiplies the number of transmission lines by a
> >> factor of four. So while the EMI peaks have been reduced in
> >> frequency, they have the potential to be greatly increased in
> >> amplitude.
> >
> >Yes. But a 10-12.5 Gbps trace won't work on FR-4, CMOS, and for trace
> distances
>
> ------------------------------------------------------
> FR-4 is not the only choice. I do not know if it is a
> clear directive we should not entertain miniature coax
> for selected high speed lines. Like it or not, we have
> a microwave transmission problem on our hands even with
> HARI parallelism. Coax certainly does wonders for EMI
> -------------------------------------------------------
Think MAC/PHY to PMD interface. The MAC/PHY chip is (likely) CMOS. Most
equipment vendors want to use FR-4 PCBs to keep equipment costs down. Traces of
a foot or so will be common. Miniature coax is NOT a practical option.
> -----------------------------------------------------
>
> >> 3) A 10Gbit serializer/deserializer could be implemented any number
> >> of ways. The choices of technology are well established in this
> >> thread, but they include CMOS/SiGe, GaAs, SiGe, etc.
> >
> >Yes, but not economically. There's that darn Economic Feasibility
> >PAR Critter I'm trying to address. My personal belief is this this
> >is the most important but elusive critter.
>
> We have received commercial SiGe post amplifiers for
> 2.5Gbit/s receivers which are in the range of a Whopper
> with cheese. We can't use dollar signs here, can we?
You're making a great case for MAS and other signal rate reduction techniques
and seem to be implying and/or acknowledging that +10 Gbps parts will not be be
in the same ballpark.
> --------------------------------------------------------
>
> >> 4) The traditional serial approach has the advantage here over
> >> a HARI approach because of the removal of the MAS encode/decode
> >> logic at the serial output. This conclusion is consistent with
> >> your logic in (1) above.
> >
> >What?
> >
> ------------------------------------------------
> See response to (1). I will amplify if you like
> in the next millenium.
Please amplify. I can't relate this issue to (1) because of our different views
of the Hari architecture.
> Best Wishes to all for the next Thousand Years,
>
> Patrick Gilliland
> patgil@xxxxxxxxxxx
--
Best Regards,
Rich
-------------------------------------------------------------
Richard Taborek Sr. Tel: 408-330-0488 or 408-370-9233
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Email: rtaborek@xxxxxxxxxxxxx
2500-5 Augustine Dr. Alt email: rtaborek@xxxxxxxxxx
Santa Clara, CA 95054