Eric P.
Guest
|
 Posted:
Fri Feb 18, 2005 10:12 pm Post subject:
Re: Self restarting property of RTOS-How it works? |
|
|
del cecchi wrote:
| Quote: |
"Eric P." <eric_pattison@sympaticoREMOVE.ca> wrote in message
news:42113E99.61EAB8B6@sympaticoREMOVE.ca...
I can see that it would take a while if you have to completely learn a
frequency because you have to slew the Voltage Controlled Oscillator.
So at power up this might take a few milliseconds.
But if the reference frequency is already correct, or almost correct,
and all you are trying to do it sync to the edge transitions of the
inbound data stream then that seems like it should be very fast.
I'm thinking here of dividing down a 16 or 64 times reference clock,
so it might sync to the edge in 1/16th or 1/64th of a data clock.
Is that too optimistic?
dividing down a clock to sample a 2Gbit line (pci express, fibre
channel, InfiniBand) or a 3.125 Gbit line (xaui) is typically not done.
Rather the transitions in the data drive a phase detector in a classic
pll. And after a few seconds with no transitions, who knows were the
filter voltage has drifted off to.
|
I was curious how long the PLL has to lock on so I poked about a bit.
10BaseT ethernet uses a 64 bit '01' Manchester encoded preamble
at 20 MHz to train the clock, so 64 * 50 ns = 3200 ns.
I assume the 100BaseT preamble is the same. Its' 4b/5b NRZi
encoding uses a 125 MHz clock, so 64 * 8 ns = 512 ns.
I found a 1998 datasheet on a 2.5 Gb/s 8b/10b transceiver designed for
switched serial links and Fiber Channel applications. At power up it
is given a 125 MHz reference clock signal and can take up to 1 ms for
the PLL to lock on. But after that it takes a max of only 80 clocks
to lock onto a data stream provided it is within 100 ppm of 20 times
the 125 MHz reference signal, so 80 * 0.4 ns = 32 ns.
(They don't say what happens if it is not within 100 ppm.)
So the overhead for training does not look _that_ bad.
If you want to send lots of small packets, then a dedicated
line with idle bytes to retain sync is best because you can
just send the data immediately without the training bytes.
But large packets on shared lines still seem have some life in them.
Eric |
|
Rob Warnock
Guest
|
| Posted:
Sun Feb 20, 2005 5:04 pm Post subject:
Re: Self restarting property of RTOS-How it works? |
|
|
Eric P. <eric_pattison@sympaticoREMOVE.ca> wrote:
+---------------
| del cecchi wrote:
| > dividing down a clock to sample a 2Gbit line (pci express, fibre
| > channel, InfiniBand) or a 3.125 Gbit line (xaui) is typically not done.
| > Rather the transitions in the data drive a phase detector in a classic
| > pll. And after a few seconds with no transitions, who knows were the
| > filter voltage has drifted off to.
+---------------
In a well-designed PLL, there's a local reference clock (possibly
a bit imprecise) that the PLL switches to when it loses lock on
the incoming external signal, so that it stays pretty close to the
correct "coarse" frequency. When incoming data transitions resume,
the PLL only has to reacquire "fine" frequency and then phase.
+---------------
| I was curious how long the PLL has to lock on so I poked about a bit.
|
| 10BaseT ethernet uses a 64 bit '01' Manchester encoded preamble
| at 20 MHz to train the clock, so 64 * 50 ns = 3200 ns.
+---------------
Uh... Sorry, the transmitter is required to *send* 64 bits of
preamble [well, actually, 56 bits of preamble and a magic 8-bit
"start code" pattern, but given the pattern it's really 63 bit
of preamble and one bit of "start"], but the receiver is required
to be able to acquire valid data with *much* less preamble!
In fact, the DEC/Intel/Xerox Ethernet 2.0 spec requires [in section
7.5.1.2, "Decoder"] that the decoder [PLL + slicer]:
...must provide usable output (clock and data) after no more
than 16 bit cell times following reception of an encoded signal
(the assertion of Carrier Sense)
And that *includes* that the first bit being received may possibly
"contain encoding phase violations or invalid data" [section 7.4.2.2
"Receive Pair"]. Also, the receiver is permitted to *drop* up to five
initial bits before that first possibly-invalid bit. [Ibid.]
When you consider that Ethernet v1.0 allowed two repeaters in the
path -- three transmitters & three receivers total -- and that, in
addition to the above allowances for receivers, transmitters were
permitted to drop the first two bits and garbage the third, and that
a repeater was permitted to drop a few bits (2?), as much as *half*
the 64-bit preamble could be lost! [Which is why the Ethernet 2.0 and
IEEE 802.3 specs changed the definition of a repeater to require it to
regenerate a full 64-bit preamble on output, but that's another story...]
But 16 bits isn't very hard to do at 10 Mb/s [20 Mbaud, given the
Manchester encoding]; it's harder [that is, the PLL needs more symbol
times to lock] at higher speeds. Still, a high-quality PLL should
be able to re-lock in ~30 or so symbol times. [At least, that was
a typical requirement for satellite TDMA receivers circa 1980.
PLLs may have gotten better since. Or worse, since speeds have
gone up, too.]
+---------------
| I found a 1998 datasheet on a 2.5 Gb/s 8b/10b transceiver designed for
| switched serial links and Fiber Channel applications. At power up it
| is given a 125 MHz reference clock signal and can take up to 1 ms for
| the PLL to lock on.
+---------------
Not unusual.
+---------------
| But after that it takes a max of only 80 clocks to lock onto a
| data stream provided it is within 100 ppm of 20 times the 125 MHz
| reference signal...
+---------------
Hmmm. That's rather slow.
+---------------
| If you want to send lots of small packets, then a dedicated
| line with idle bytes to retain sync is best because you can
| just send the data immediately without the training bytes.
+---------------
Yup!
-Rob
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607 |
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in