Missing MAS in Maui
Rich,
The weather is really starting to get cold here.
They are going to find me with my fingers frozen
to the keyboard. It's 10 degrees F outside. I
have some comments. See below for details.
>
>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:
>
-------------------------------------------------------
I apologize for the confusion on my part; when one uses
the "GHz" symbol I understand it to mean frequency.
-------------------------------------------------------
>Laser BW ~1.1 Baud ~5.5 GHz
>Rx BW ~0.75 Baud ~ 4 GHz
>
---------------------------------------------
A little preemphasis on the laser is often a
good idea. The receive channel at ~.75BR is
recommended as well.
---------------------------------------------
>see:
>http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/taborek_2_1199.
pdf,
>page 19
>
----------------------
text omitted
----------------------
>> 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.
>
-------------------------------------------------
From my point of view it has a lot to do with MAS.
MAS is the reason behind any SNR degradation at the
transmitter. With 1300nm, there is room below the
laser safety limit to increase transmit power and
therefore offset the SNR degradation occasioned by
MAS.
---------------------------------------------------
>
>I have no clue as to what you mean by PAM10 if it doesn't mean 10 levels,
please
>explain.
>
------------------------------------------------
Yes. By PAM10 I do mean 10 levels. It would
be one way to cram an additional bit into the
baud rate. However, I introduced the PAM10
example as an illustration of the additional
transmitter power available at 1300nm over 850nm.
I do not advocate the use of MAS at this time.
I believe there are numerous difficulties which
have yet to be overcome. If the technical challenges
to MAS can be overcome, I reserve the right to change
my opinion.
-----------------------------------------------------
>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.
>
----------------------------------------------------------
At the risk of beating this horse again, I am assuming
you mean 4x1.25Gbaud in your reference to 4 baud per byte.
I will admit my understanding of your HARI/MAS proposal has
metamorphosized over the weeks of this thread. Part of the
reason for this is some perceived inconsistencies in your
statements, and/or at minimum, terminology.
In a proposal I have open in front of me entitled
"Multilevel Serial PMD Update" you refer to a serial line
rate of 2.5GHz. In the proposal you seem to be emphasizing
the rate reducing features of MAS. Above you mention a 5.5GHz
rate. It is also possible your proposal has evolved. I might
be reading from the wrong sheet of music. I hope this is what
you call "Maui". I can only assure you I am not smoking it.
I do not agree that MAS and laser safety are independent for
the case of the 850nm lasers I cited in my previous posting
which I have left in below.
------------------------------------------------------------
>> 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.
>
----------------------------------------------------------------
I believe your proposal must address the entire system including
the transceiver, optical link budget, and laser safety in
order to have a complete proposal. Your 5.5GHz figure for
the transmitter bandwidth is much closer to the truth for
a real multimode optical link. The dispersive nature of the
multimode fiber often can be compensated for by a small pre-
emphasis and the link length may be extended.
---------------------------------------------
>> 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 +-------------+
>> | +-------> | Hari, +------+ +-- -----+
>> | | . | E S| et.al. |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)
>
-----------------------------------------------------------
Actually I do not agree or disagree with HARI as a protocol
(MAC) interface. I disagree with HARI as a PMD interface
because it anticipates multi-level or multi-color PMD options.
HARI is unnecessary as a PMD interface for the serial case.
-----------------------------------------------------------
>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.
>
-----------------------------------------------------------
If one insists on HARI as the parallel-serial technology of
choice, then 1-4 above are not dependent on where we choose
to partition the system.
-----------------------------------------------------------
>
>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.
>
-----------------------------------------------------
It is a nice goal if jitter independence can realized
without creating greater total jitter.
--------------------------------------------------
>
>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.
>
----------------------------------------------------
HARI may have it's place. I have no desire to enter
the word-striping vs. byte striping debate. I do not
think it is necessary as a PMD interface.
-----------------------------------------
>
>So your answer is Hari is the interface to the protocol ASIC.
>
---------------------------------------------
Might be if you and the other system architects
agree and the members vote with you. I would
prefer a 10x1Gbit architecture, but I recognize
what seems natural to me does not a standard make.
----------------------------------------------
>
>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.
------------------------------------------------------
Wavelength services are a well known solution to the
information bandwidth crunch. However, the economics
favor applications where the cost of installing additional
fiber is prohibitive (i.e. long distances, or buried fiber).
I would not lump multilevel in with WDM because WDM is a
mainstream technology, widely deployed, and well character-
ized. Multilevel optical signalling has not been deployed
anywhere to my knowledge.
-------------------------
Best Wishes,
Pat Gilliland
patgil@xxxxxxxxxxx