(Stupid/Newbie) Question on UART

Hal Murray wrote:
> >A CID (consecutive identical digits) of 50 bits will cover most
> >real-world cases of scrambled SONET traffic, but I'd personally want
a
> >CDR with noticably more staying power than that.
>
> 2**50 is 10**15  With a gigabit/sec link, that would be a glitch
> every 10**6 seconds or roughtly 10 days.  Note that we are talking
> clock-slip which is much worse than a simple bit error.
> Adjust for your link speed.
>
> I typed in 50 without much thinking.  Looks like I got in the right
> ballpark.

Yes, you did.

> Much lower than that would be a serious problem.  Much
> higher would be hard to measure.

Yep - until you start feeding PRBS test streams into the scrambler,
which can make your equipment look less reliable than it would be
against a real-world stream.

> I think I remember 70 from years ago on OC-3.  That would be
> another factor of 10**6 which would push the problem well
> beyond the lifetime of any gear I've ever worked with.
>
> What are current specs/reality for SONET links?  Are there any
> interesting alternatives to SONET for long links?

I don't think there is an absolute minimum requirement, but a commonly
accepted number is 72 digits - so your memory is quite good.  Modern
CDR's tend to be able to handle even more digits than that, but as you
said, the probability starts getting so low that it is well beyond the
lifespan of just about anything (humans, electricty, copper wire, etc).
 Somewhere I got it that the V2Pro MGT can handle over 75 CID (to try
to insert at least one FPGA related item to this post).

As for long haul links, if you want protection, SONET is still the main
choice.  I think that RPR is trying to make in-roads, but has been slow
out of the gate and from what I've heard third hand, is slow to be
adopted by the carriers.  I believe a third alternative is protected
DWDM (not as intelligent as SONET or RPR, but that means maintenance is
considerably less expensive).  There may be others I can't recall at
the moment.

Have fun,

   Marc

>Yep - until you start feeding PRBS test streams into the scrambler,
>which can make your equipment look less reliable than it would be
>against a real-world stream.

I'm missing something.  Why is a PRBS test stream going to make errors?

To make a long string of 0s, you have to send something that
matches the pattern in the scrambler register.  That pattern
is supposed to be random - hard to guess and hard to hit by
sending malicious data.

Is there a trick or quirk I don't know about?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:
> >> Much lower than that would be a serious problem.  Much
> >> higher would be hard to measure.
> >Yep - until you start feeding PRBS test streams into the scrambler,
> >which can make your equipment look less reliable than it would be
> >against a real-world stream.
>
> I'm missing something.  Why is a PRBS test stream going to make
errors?
>
> To make a long string of 0s, you have to send something that
> matches the pattern in the scrambler register.  That pattern
> is supposed to be random - hard to guess and hard to hit by
> sending malicious data.
>
> Is there a trick or quirk I don't know about?

Howdy Hal,

   I did a poor job of editing your original response, and an even
poorer job of explaining mine - sorry!  I was actually trying to
provide an example in response to your "much lower would be a serious
problem" statement.  We've chased phantom bugs in our equipment before
where a weekend long test would take a data hit.  It was eventually
tracked down to a device that effectively had a very short run-length
tolerance.  It wasn't a CDR, but the result was the same.  We've also
had a (different) vendor tell us that we had to order the STS's within
our scrambled data stream in a certain way, or downstream devices may
lose CDR lock.

BTW, the 75 bit CID number for the V2Pro CDR can be found here:

http://xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=15035
http://xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=15049
http://xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=15055

   Marc

On Fri, 09 Jun 2006 04:54:30 GMT, "Maxim S. Shatskih"
<maxim@storagecraft.com> wrote:

>> Actually with 10mb/s Ethernet and USB (all speeds) there is no carrier
>> on the wire when actual data is not begin transmitted.
>
>Same as with serial UART.
>
>>Clock recovery
>> starts at an arbitraty point with every packet.
>
>USB packets have a preamble to synchronize the PLLs. IIRC Ethernet too.

There are no clock-recovery PLLs in USB. FS/LS is specifically
designed to be implemented by a 4x DLL. One can implement 10BT without
a PLL too.