The Designer's Guide Community Forum

The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl
Design >> High-Speed I/O Design >> Regarding eye diagram
https://designers-guide.org/forum/YaBB.pl?num=1325780184

Message started by raja.cedt on Jan 5^th, 2012, 8:16am

Title: Regarding eye diagram
Post by raja.cedt on Jan 5^th, 2012, 8:16am

hello,
i am doing an optical modulator driver @ 40G data rate, so i want to simulate this ckt at 2^31-1 data pattern. When i simulating with this data pattern i would see how it is responding for high frequency like 1010101 pattern and how it is behaving for low frequency mean 31 consecutive 1 or 0. is it okay to simulate directly this conditions rather than simulating all kind of patterns?

Thanks,
Raj.

Title: Re: Regarding eye diagram
Post by loose-electron on Jan 6^th, 2012, 1:45pm

Highest BW patterns are where people
usually start, and then things like lowest
frequency situations need to be examined as well.

If its RLL coding (limited consequtive zeros, Run length limited)
you can usually come up with a few test cases to cover the extremes.

Title: Re: Regarding eye diagram
Post by raja.cedt on Jan 7^th, 2012, 2:25am

hello,
ya what you are saying is correct, but what i feel these two test cases will cover for an serial link transmitter, correct me if am wrong., but you said several cases.
Thanks,
Raj.

Title: Re: Regarding eye diagram
Post by ywguo on Jan 7^th, 2012, 6:10am

Hi Raj,

Quote:

but what i feel these two test cases will cover for an serial link transmitter

Do you mean 101010 pattern and low frequency, saying 31 consecutive 1's or 0's? Usually they are not enough for Serdes. I think the same principle applied for your optical driver. The 101010 data pattern is used to uncover duty cycle distortion. As you know, inter-symbol interference (ISI), also named data dependent jitter is one of the major source for deterministic jitter. So you need to run simulation like 1000010111. I recalled that is the worst case for ISI if 8B/10B code is used for Serdes/driver. If you have other coding scheme, please select a similar code for ISI, which has a single 1 succeeding the longest run of 0's, and vice versa. The height of single 1 is reduced, even killed if the driver has not enough bandwidth. Hope this is helpful.

Yawei

Title: Re: Regarding eye diagram
Post by raja.cedt on Jan 7^th, 2012, 6:44am

hello Yawei,
could you please explain bit more, i am new to this field.

Thanks,
raj.

Title: Re: Regarding eye diagram
Post by ywguo on Jan 7^th, 2012, 6:46am

It is too late in Shanghai. I will try to explain it in more detail tomorrow.

Title: Re: Regarding eye diagram
Post by ywguo on Jan 8^th, 2012, 4:30am

Hi Raj,

The jitter in serial data communication are put into two categories, random jitter (RJ) and deterministic jitter (DJ).

DJ has several sub-types, duty cycle distortion (DCD), data dependent jitter (DDJ), periodic jitter.

DCD is usually caused by the unsymmetrical rise and fall edge of the driver. In your case, a 40Gbps optical driver. You need to run 010101... pattern to measure it. A data pattern, saying 0000101111 is not suitable because DDJ also affects on the rise/fall times.

DDJ is also called ISI. It is inter-symbol interference in fact because the channel is band-limited. So a rise/fall edge succeeding a long 0/1 bit stream is more slow. For pseudo-random binary stream (PRBS), run transient simulation and plot its eye diagram, the rise edges are not coincident. And the same for all falling edges.

Periodic jitter is usually caused by low frequency sinusoidal interference on supply voltage. It caused the jitter varies periodically.

Yawei

Title: Re: Regarding eye diagram
Post by ywguo on Jan 8^th, 2012, 4:37am

Here is the transient waveform corresponding to the above eye diagram. Obviously some pulses is not as high as others. This is caused by ISI.

Title: Re: Regarding eye diagram
Post by raja.cedt on Jan 8^th, 2012, 5:26am

hello ywguo,
thanks for the reply. So i understood the following.

DDJ: To simulate ddj i have to use long 1/0 followed by single bit 0/1. With this we can find peak jitter from the EYE-diagram

DCD: to simulate DCD we have to use 1010101 pattern.

last thing is we have to check bw limitation again by applying 101010 pattern and check whether output is reaching the level or not.

Bottom line is no need to simulate the driver for entire PRBS pattern . Correct me if am wrong.

Thanks,
Raj.

Title: Re: Regarding eye diagram
Post by loose-electron on Jan 8^th, 2012, 1:37pm

What is your encoding ?

Is this something like 8b-10b or something different?

You can generally come up with a set of test cases that will
deal with max-min frequency, intersymbol interference,
pulse pairing (thou that is usually magnetic media) offset to
pattern sensitivity and similar.

The RLL structures are easier to test than things that use
NRZ which has lots more problems (lonely pulse, Offset
dependency on pattern, etc)

Title: Re: Regarding eye diagram
Post by ywguo on Jan 8^th, 2012, 11:07pm

Raj,

You need not simulate the driver for the entire 2³¹-1 PRBS. It takes long long time.

Jerry,

What is RLL structure?

Yawei

Title: Re: Regarding eye diagram
Post by raja.cedt on Jan 9^th, 2012, 12:35am

hello Yawei,
thanks you i will try to follow this. are you ware some kind PRBS generators in spice, i had one source in cadence varilog A, but there is no choice of selecting run length. One more last Question is driver simulation methodology or some properties of driver is really depends on the encoding (8b/10b)? may be like it limits the same bits stream like 11111 up to some extent and may reduce the ISI and we can use in simulation as well. Any how thanks for your continues help.

RLL means Run length limited encoding, which is common term in Clock and Data Recovery (CDR), hello jerry correct me if am wrong.

Thanks,
Raj.

Title: Re: Regarding eye diagram
Post by loose-electron on Jan 9^th, 2012, 11:58am

Raj Correct.

RLL codes are used to avoid things like a million 0's in a row.
Where you lose amplitude and phase information. (NRZ data
has this problem.)

RLL coding got introduced into CDR systems associated with
disk drive read channels way back in the late 1970-1980 era
More recently has been applied to communication systems
and SerDes devices.

Wiki:

http://en.wikipedia.org/wiki/Run-length_limited

Title: Re: Regarding eye diagram
Post by raja.cedt on Jan 9^th, 2012, 1:28pm

hello jerry,
if you have coding like 8b/10b in transmitter, then data has some minimum transition so whats the purpose of RLL then?

Sorry jerry, i am new to this field so i am asking this kind of basic Questions.

Thanks,
Raj.

Title: Re: Regarding eye diagram
Post by ywguo on Jan 9^th, 2012, 6:08pm

Raj,

Even if the original data are all 0's/1's, the data has a lot of toggles if you have 8B/10B coding in your system. And the data has balanced 0/1 so that it is helpful to eliminate any DC wandering. I don't know details of other coding, but I think they have similar function.

The earliest paper I know about 8B/10B coding is from IBM Journal of Research in 1980's. At that time, IBM was the leader in disk drive. A few years ago, I found it in IBM website. Now it is available in ieeexplore.

Yawei

Title: Re: Regarding eye diagram
Post by raja.cedt on Jan 10^th, 2012, 12:43am

hello YWguo,
yes you are correct. But i guess now many standards got migrated to 66b/68b to less data rate overhead due to coding . May i know what is the main criterion behind coding selection.

Thanks,
Raj.

Title: Re: Regarding eye diagram
Post by loose-electron on Jan 10^th, 2012, 3:47pm

raja.cedt wrote on Jan 9^th, 2012, 1:28pm:

Not a problem Raj.

The 8b/10B is a RLL code.

Some form of binary data (aka NRZ data) with no restrictions (it
can have a million 0's in a row in it!) is put into an encoder,
which transforms it into an 8b/10b code structure which obeys
rules associated with min-max distance between transitions.

The RLL code is transferred in the communication medium.

Reception of the RLL code is synchronized back to a clean synchronous
set of digital transitions which is tied to the receiver's CDR system.

That data goes through a decoder, which takes the 8b/10b and
converts it bake to NRZ data.

thats the basics.... :)