RE: ONLY one ref multiplier?: PMA clock reference
Stuart,
I agree we should allow more reference frequencies due to the trade-offs you
mention. My comment was aimed at Rich's proposal to have only one CMU ratio.
I would guess a transceiver board designer would like a 622.08 MHz reference
(x16 CMU) in a WAN PHY. In a LAN PHY you might get away with relaxed jitter
specs. This allows you to use a 156.25MHz reference (x66 CMU). Again, my
point is that you will need the 156.25MHz anyway in the PCS, so why not use
it for the SerDes (if jitterbudget allows). This way you save a crystal (and
clock tolerance compensation) or a PLL making your board smaller and
cheaper.
The original proposal for taking the OIF interface into 10GE specified a
644.53 MHz reference clock in the LAN case (see
http://grouper.ieee.org/groups/802/3/ae/public/may00/robinson_1_0500.pdf).
Like you, I suggest we leave more options open (e.g. the 156.35 MHz for
LAN).
The bottom line is that we need to allow at least two reference frequencies
since we have two different signaling frequencies (10.3125 GHz 9.95328 GHz).
In the LAN case we have a special oportunity to make the transceiver board
smaller and cheaper using a x66 CMU in the SerDes (156.25MHz ref). To meet
the overall cost target of 10GE we should not rule out this option.
Regards,
Henning
P.S. a large number of telecom companies worldwide use Giga SerDes
succesfully with both the 155MHz and the 622MHz reference clock option.
Please mail me directly outside the IEEE reflector, if you require the
assistance of a Giga applications engineer.
-----Original Message-----
From: Stuart Brorson [mailto:sdb@xxxxxxxxxxxx]
Sent: 20. juni 2000 14:57
To: 'Lysdal, Henning'; 'Jscquake@xxxxxxx'; rtaborek@xxxxxxxxxxx;
stds-802-3-hssg@xxxxxxxx
Subject: RE: ONLY one ref multiplier?: PMA clock reference
Please allow me to make a quick comment about 155 vs. 622 MHz clocks here.
I was involved in OC-192 IO card design at my former employer, Nexabit
Networks (now Lucent Technologies), and have had some experience in this
department.
It is not my desire to disparage the fine products of Giga here, so please
accept my apologies in advance. However, the 10 Gig SERDES products from
Giga (i.e. GD16555 and GD16554) had jitter gen problems, even on the
company-supplied test board. Amongst other problems, Giga's test board
incorporated a 155 MHz clock. Designing a low jitter PLL/SERDES chain is
not very easy.
It is noteworthy that the OIF has speced a 622 MHz reference clock freq for
the 10 Gig framer/SERDES. That means that clueful PLL vendors have every
reason to design low-jitter 622 MHz clock modules which can be used -- or
modified for use -- with 10GigE also.
In any event, most vendors with whom I am aware -- including Giga -- allow
the user to select either a 155 or a 622 MHz reference clock. This allows
the board designer freedom to choose the design problem he wants to tackle:
either a lower speed 155 MHz PLL with stringent jitter specs (and a very low
jitter SERDES), or a higher speed 622 MHz PLL with all the intricacies of RF
design, but perhaps with an easier jitter (i.e. board noise) problem.
Why not allow two clock frequencies and leave the board designer the freedom
of choice?
Stuart Brorson
Axiowave Networks
Marlborough, MA 01752
-----Original Message-----
From: Lysdal, Henning [mailto:henning.lysdal@xxxxxxxxx]
Sent: Tuesday, June 20, 2000 5:17 AM
To: 'Jscquake@xxxxxxx'; rtaborek@xxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
Subject: RE: ONLY one ref multiplier?: PMA clock reference
Justin,
In answer to your question:
My company (formerly Giga) has been shipping OC-192 SerDes since 1997 and
the majority of our customers use 155.52 MHz reference clock.
Regards,
Henning
-----Original Message-----
From: Jscquake@xxxxxxx [mailto:Jscquake@xxxxxxx]
Sent: 20. juni 2000 00:18
To: rtaborek@xxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
Subject: ONLY one ref multiplier?: PMA clock reference
Hello Rich,
Your proposal sounds good,i.e. to have only a single clock multiple
(1/4 division) for the reference clock, but I am not sure if this is wise.
Using
a lower rate frequency clock autmatically implies worse jitter performance
for
the PLL's. This is not as much of an issue for the WDM case as it is for
serial
but every psec (or even sub-ps) counts for the serial versions. So I would
opt
to be NOT too restrictive in saying only 155-156Mhz xtal osc are allowed.
Note that the present community of OC192 people use the higher clock rate
for the reference. Are there any that uses the 155MHz as a reference for
OC192? Having said all this ... are there readily available
644.53125MHz xtal osc.?
Justin
In a message dated 6/16/00 1:03:26 AM Pacific Daylight Time,
rtaborek@xxxxxxxxxxxxx writes:
> Henning,
>
> Sorry about the confusion. I did mention in my note that there would have
to
> be
> two optional clock references specified in the XBI, one for the LAN PHY
and
> the
> other for the WAN PHY.
>
> What I should have said is that only one clock MULTIPLE be specified. For
> example, 161.1328125 MHz is 1/4 of 644.53125 MHz and 155.52 MHz is 1/4 of
> 622.08
> MHz. One fourth is a good multiple to use. This means that other
multiples
> should not be required anywhere in the standard, even optionally (i.e.
1/8,
> 1/2,
> 1/16, 1/1, etc.)
>
> Best Regards,
> Rich
>
> --
>
> "Lysdal, Henning" wrote:
> >
> > Rich,
> >
> > I don't see how you can avoid having separate reference clocks for LAN
and
> > WAN (with realistic PLL design).
> >
> > In the LAN case there are several options
> > 156.25 MHz (seems to be prefered among serial folks)
> > 161.1328125 MHz
> > 644.53125 MHz
> >
> > In the WAN case the OIF specifies 622.08 MHz. I know of a lot of people
> who
> > also like 155.52 MHz
> >
> > Now the problem is: how do you synthesize 9.95328 GHz and 10.3125 GHz
from
> > the same reference. If you use a 10 kHz reference, it's easy, but you
will
> > most likely have problems with transmit jitter.
> >
> > So I haven't been discussing the WAN case at all, since I was under the
> > impression that WAN PHYs will use existing SONET SerDes using 622.08
MHz
> > refck.
> >
> > Regards,
> >
> > Henning
> >