Re: Feliz Haridad
Patrick Gilliland wrote:
>
> >
> >Pat,
> >
> >My outstanding MAS proposal is PAM5x4 @ 5 Gbaud (2.5 GHz) to transport
> >10 Gbps of Ethernet data.
>
> ------------------------------------------------------------
>
> Rich,
>
> Most communication texts would recommend a bandwidth of .7xBR
> in order to optimize SNR. What is the reasoning behind your
> choice of .5xBR? Your proposal of 5Gbaud would result in a
> bandwidth of 3.5GHz nominally.
Patrick,
You're confusing signaling rate with bandwidth. The fastest signaling at the
transmitter for PAM5x4, that being an NRZ multi-level code, is 2.5 GHz. In my
MAS update presentation in Kauai, I specified the following Tx and Rx
bandwidths, which correspond to your numbers:
Laser BW ~1.1 Baud ~5.5 GHz
Rx BW ~0.75 Baud ~ 4 GHz
see:
http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/taborek_2_1199.pdf,
page 19
> -------------------------------------------------------------
> >MAS is laser wavelength independent. There are no problems with laser safety at
> >850 nm that I know that are MAS specific. I don't understand what your concern
> >is on this issue?
> -----------------------------------------------------------
>
> I am not advocating PAM10 or any other multi-level signalling
> scheme. It is useful as an in the example I mentioned to
> illustrate the greater availability of power at 1300nm. The
> accessible power level at 1300nm is greater than at 850nm by
> an order of magnitude. This would help in overcoming the SNR
> degradations occasioned by MAS.
I agree. This is the well known 1300 vs. 850 nm tradeoff, but has nothing to do
with MAS.
> The bit rate calculations at PAM10 and 1.25Gbaud or your
> preference, PAM5 and 2.5GHz, both require 4 fibers to achieve
> something like a 10Gb/s single channel. It really is a question
> of what data rate one is comfortable with. The laser safety
> issue I am addressing is for the 850nm case only.
I have no clue as to what you mean by PAM10 if it doesn't mean 10 levels, please
explain.
My PAM5x4 MAS proposal uses a single laser. The x4 stands for 4 Baud intervals
per byte. I think I'm beginning to understand your confusion and concern with
laser safety. The answer is that this is independent of MAS.
> I will go through the numbers. At present, we have -17dBm
> sensitivity for an 850nm receiver. The bandwidth is specified
> at .7xBR = 875MHz. In your proposal, the bandwidth is 3.5GHz
> in an apples-apples comparison. This should give us something
> like a 6dB electrical SNR degradation, or 3dB optical.
>
> This would put us at -14dBm for the reciever sensitivity. At
> present, our minimum transmit power is -10dBm. In order to
> maintain a 7dB link budget, we would need to raise this minimum
> power to -7dBm. The IEC safety limits we have adopted require
> the maximum power radiated to be less than -4dBm. Because all
> of the light which exits from the transmitter port is not
> coupled, the practical limit for the maximum power coupled into
> a fiber is something like -5dBm. Most transceiver manufacturers
> typically guardband like this to ensure compliance.
>
> Therefore, the range for coupled optical transmit power is only
> a narrow range of 2dB. This represents a drastic reduction in
> transmit coupled power limits for most of the optical transceiver
> manufacturers. If we were to discuss 1300nm as an option, there
> would not be any issue with raising the transmit power limit.
> I hope I have made this issue clear enough.
Before any calculations are made, we have to agree on signaling rates, receiver
bandwidth, number of fibers, etc. Otherwise, we're just pushing buttons.
> ----------------------------------------------------------------
>
> >Hari IS a chip-to-chip interface. It makes no sense to use Hari between the
> >SerDes and the MAC unless the SerDes you're talking about is part of the
> >transceiver and the other side of the SerDes is in the MAC (integrated MAC/PHY).
> >Pictures always speak 1000 words. Please allow me to illustrate the potential
> >elements (chips and such) in a 10 GbE LAN PHY:
> >
> >+-----------+ XGMII +--------------+
> >| +-------> | +------------------+
> >| | . | E S| Hari |S (E) |
> >| 10 GbE | . | 10 GbE n e+------------->e (n) Transceiver |Medium
> >| | 36 | D r+------------->r (D) Module +------------>
> >| MAC | . | PCS/PMA e D+------------->D (e) (PMD) | 1-4 fibers
> >| | . | c e+------------->e (c) |
> >| | . | s| FR-4 PCB |s |
> >| +-------> | Traces +------------------+
> >+-----------+ short +--------------+ <=20"
> >
> >Figure 1 - Location of Hari, MAC and discrete PCS/PMA Chip within a 10 GbE
> >Device
> >
> >+--------------+
> >| | +------------------+
> >| E S| Hari |S (E) |
> >| 10 GbE n e+--------------->e (n) Transceiver | Medium
> >| D r+--------------->r (D) Module +------------>
> >| MAC/PHY e D+--------------->D (e) (PMD) | 1-4 fibers
> >| c e+--------------->e (c) |
> >| s| FR-4 PCB |s |
> >| | Traces +------------------+
> >+--------------+ <=20"
> >
> >Figure 2 - Location of Hari and Integrated MAC/PHY Chip within a 10 GbE Device
> >
>
> -------------------------------------------------------------------
>
> The following picture illustrates what I have been suggesting
> as an alternative which makes some sense. It helps define the
> question of where to partition a little better.
>
> +--------+ XGMII +-------------+
> | +-------> | +------+ +-- -----+
> | | . | E S| Hari |S (E) | | Trans- |
> |10 GbE | . | 10 GbE n e+-------->e (n) | | ceiver | Medium
> | | 36 | D r+-------->r (D) |1 line | Module |
> +--------| | | | |-------| |
> | MAC | . | PCS/PMA e D+-------->D (e) | 10Gb | (PMD) | 1 fiber
> | | . | c e+-------->e (c) | | |
> | | . | s| FR-4 |s | | |
> | +-------> | Trace +------+ +--------+
> +--------+ short +-------------+ <=20"
>
> Figure 1 - Recommended partitioning of a transceiver module.
>
> +--------------+
> | | +-----+ +--------+
> | E S| Hari |S (E)| | Trans- |
> | 10 GbE n e+--------------->e (n)| 1 line | ceiver | Medium
> | D r+--------------->r (D)|--------| Module +------------>
> | MAC/PHY e D+--------------->D (e)| 10Gb |(PMD) | 1 fiber
> | c e+--------------->e (c)| | |
> | s| FR-4 PCB |s | | |
> | | Traces +-----+ +--------+
> +--------------+ <=20"
>
> Figure 2 - Preferred partitioning of Hari and Integrated MAC/PHY Chip
> within a 10 GbE Device
>
Now I understand. You actually agree with Hari as a Protocol (MAC) to PMD
interface! You are merely focusing on only one of the 4 PMDs I was illustrating,
the Serial PMD. My point all along is that Hari is the "best" interface back to
the MAC/PHY. Besides that, you're figures 1 and 2 have the following
disadvantages with respect to mine (above)
1) More elements in the path, specifically in your (semi) Integrated MAC/PHY
case
2) High speed signals not contained within the transceiver module running around
on the board create huge EMI problems
3) What technology do you plan to implement your Hari-to-10Gb chip in? How much
power does it consume
4) Significant jitter between the Serdes to PMD connection. This is the same on
both side and leave the medium with very little jitter budget to play with.
My Serial PMD simply has your 1 line interface within the PMD.
> ------------------------------------------------------------------------
>
> >Note that one of the primary purposes of Hari are to reset the link jitter
> >budget within the Transceiver Module (PMD) allowing the PMD-medium-PMD jitter
> >budget to be independent to that of all components from each PMD back to it's
> >respective PHY.
>
> ------------------------------------------------------
>
> Why do you feel independence is such an important goal?
> I believe the lowest total jitter should be the goal.
If jitter budgets are independent (they really won't be completely independent)
then it's easier to meet the jitter requirements for any link interface. This
makes for system solutions that are easier to engineer and more interoperable.
> --------------------------------------------------------
> >
> >Given your answer, what interface do you then propose between the SerDes back to
> >the protocol chip (e.g. MAC, PCS, etc.)? The general requirements for this
> >interface are:
> >
> >- Interface reliability;
> >- 10 Gbps data transport;
> >- Protocol and PMD independence;
> >- Low pin count to enable high port density protocol ASICs, removable
> >Transceivers, reasonable routing of high-speed traces through FR-4;
> >- Jitter budget independence from the link medium jitter budget;
> >- CMOS friendly, at least to 0.25 micron;
> >- FR-4 friendly;
> >- Reasonable distances (to 20");
> >- Scalability to higher speeds.
>
> ---------------
> See above.
Your interface DOES NOT go to the protocol chip. You seem to agree with Hari and
the only argument left is with the definition of what a PMD is.
> ---------------
>
> >- Interface reliability due to 8B/10B error control;
> >- 10 Gbps data transport;
> >- Protocol and PMD independence;
> >- Low pin count to enable high port density protocol ASICs, removable
> >Transceivers, reasonable routing of high-speed traces through FR-4;
> >- Jitter budget independence from the link medium jitter budget;
> >- CMOS friendly, at least to 0.25 micron;
> >- FR-4 friendly;
> >- Reasonable distances (to 20");
> >- Scalability to higher speeds.
> >
> >As an architect, I always try to ensure that the whole system works. I believe
> >that you have only addressed a small and portion of my question adequately. That
> >is, you have addressed the 10 Gbps SerDes to PMD issue by backing the "SerDes up
> >directly against the optical transceiver". I believe that this is already the
> >way it is. Now please consider the path all the way back to the protocol ASIC.
> >If your answer is that the latter interface is Hari, then I believe that we
> >agree, since this is what I show in figures 1 and 2 above, and all your logic
> >plus Hari logic is part of the PMD.
> ----------------
> Again, see above.
So your answer is Hari is the interface to the protocol ASIC.
> -----------------
>
> >Yes. It is clearly a question of partitioning. However, the partitioning being
> >proposed is not indiscriminate and is intended to provide a workable and
> >interoperable architecture. The principal purpose of Hari interfacing the PMD to
> >the MAC/PHY is to separate the PMD-to-PMD jitter budget from the rest of the
> >system. I consider this Hari attribute to be of paramount importance to the
> >development of a successful and cost-effective 10 GbE standard.
> >
>
> ------------------------------------------------------------------
>
> I would like you to explain why you feel the separation of jitter
> budgets is so important. Maybe you can point me to a section
> in one of your presentations which makes this point better.
> It seems to me the lowest total jitter should be the overriding
> goal.
See ftp://ftp.t11.org/t11/pub/fc/pi-2/99-741v0.pdf pages 10 and 11
> -------------------------------------------------------------------
> >
> >Your thoughts are not borne out by the datacom and communications industry in
> >general. For example, multi-level signaling AND multiple channels have been used
> >is scaling Ethernet from 10 Mbits to 100 and then 1000. As a matter of fact,
> >1000BASE-T uses PAM5, 4 pairs of wire and supports simultaneous full-duplex
> >traffic over each wire pair. The same is true in most wireless and wired
> >systems. Kestrel Solutions is offering an 0C-192 optical solution employing
> >Frequency Shift Keying.
>
> --------------------------------------------------------------------
>
> I will argue this point with you. I believe there are more examples
> of true serial networks. Comparing the numbers between the installed
> base of optical GbE over fiber and the number of copper multi-amplitude,
> multi-wire GbE connections is instructive. The preponderance of GbE
> connections are true serial and are not skew compensated multi-wire
> systems.
Most optical serial networks use binary signaling. Most high-speed copper serial
networks are multilevel. Optical networks are slowly moving to alternate
solutions including WDM, multilevel is another bandwidth increasing technology.
>
> Feliz Haridad,
>
> Pat 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