how to measure eye diagram on a data signal triggered on a self-triggered clk signal

You can have it self-triggered. I did that here (click in the Signal field and then click on the source waveform):

Hi, Andrew.

Thanks for replying! Not sure if I described the question clearly... What I was trying to do is to use the self-triggered clk signal (eye_delclk in your case) to again trigger another data signal, such that all the pos edge zero-crossings that another data signal is triggered on are completely aligned at the same point (at around 20.2ns in your case). That way the eye diagram generated on the data signal (triggered by eye_delclk pos edge zero-crossings) would be much cleaner than directly using delclk to trigger that data signal. Seems like the tool doesn't let me enter an eye diagram into the Signal field as a triggering source. But I'm trying to get all the clk pos edge zero-crossings lined up before I can use it to trigger the other data signal.

Does this mean a customized skill function have to be written to achieve this purpose?

Can you please help take another look at this?

Thanks!

I don't understand what it would mean to use the eye diagram as the trigger. All the eye diagram is a reformatted version of the original waveform, with the x-axis folded at the threshold point (in my case where delclk crosses 0.5). If you were able to use the eye diagram (not sure why you would want to), it's going to trigger in the same place - so I can't see how this would help? Of course, you can have your data signal triggered by the transition on a different signal too. So I simply do not understand what you mean by "That way the eye diagram generated on the data signal (triggered by eye_delclk pos edge zero-crossings) would be much cleaner than directly using delclk to trigger that data signal" - it wouldn't be "cleaner" - it would be the same.

If you want all the positive edge zero-crossings on the data signal to align, you'd trigger on the data signal.

Andrew

Hi, Andrew.

Thanks for looking into this. Attached below is an eye diagram required from the spec manual which I'm trying to comply with. As you can see, the colorful data signals are triggered on pos edges of rclk signal, where all the pos edges are lined up at the same point, which is the same as section 4 in my first screenshot (an eye diagram of rclk triggered on rclk itself). If I were to directly use rclk to trigger data, the pos edges (as the triggering points) would probably be all jittery, the same as section 3, the non-self-triggered eye diagram of rclk in my first screenshot. Since in one case all pos edges as the triggering points are lined up, and in the other case they are all jittery, the eye diagram generated on the data signal triggered on these non-jittery/jittery triggering points will be different, I think.

What I was trying to do is to either trigger the rclk on itself first, and use those aligned pos edges (in this self-triggered eye diagram of rclk) to trigger the data signal, or directly use rclk pos edges to trigger the data signal first, and then fold the data at the rclk pos edges threshold in a way that all the thresholds are lined up at the same point.

Can you please help take a look if this purpose can only be achieved by writing a new skill function?

Thanks

Dear a048,

a048 said:

Attached below is an eye diagram required from the spec manual which I'm trying to comply with. As you can see, the colorful data signals are triggered on pos edges of rclk signal, where all the pos edges are lined up at the same point, which is the same as section 4 in my first screenshot (an eye diagram of rclk triggered on rclk itself).

I studied your initial Forum question and your latest Forum post to try to understand your objective. From my understanding of your objective, which my not be correct, I think you may have some confusion concerning what the specification is actually displaying. In summary, I believe you do want to create an eye diagram of your signal "vod_a2b2" using "rclk_2" as the trigger for "vod_a2b2". I have placed a few notes as to why this is my suggestion where I annotate your specification and add a  few comments to statements in your last Forum post. I apologize if you think I am still not understanding your objective, but in my experience with data recovery, your description is does not represent a metric used to evaluate the quality of a data recovery system.

The 3 page note is at URL:

www.dropbox.com/s/3mzemv7la2jq1w3/a0480_eye_diagram_comments_sml_032923v1p0.pdf?dl=0

Shawn

Hi, Shawn.

Thanks for looking into this in details. Previously I have intentionally omitted some circuit/protocol details and tried to confine the question within the context of cadence tool. One thing I can provide, to my best knowledge, as some feedback to your attached note is, rclk is extracted/recovered from the data, and when each UI is overlay to generate the eye diagram as shown in the spec figure above, each UI of rclk is also overlay to generate an eye, which is required by the spec to be self-triggered (all pos edges on one (left or right) side aligned, same as in my and Andrew's cadence plot).

My issue is I'm not able to align all the zero-crossings of rclk first before I can use it to trigger another data signal.

Regards

Dear a048,

a048 said:

My issue is I'm not able to align all the zero-crossings of rclk first before I can use it to trigger another data signal.

I don't think you need or want to do this. If you trigger your eye-diagram (using external trigger option as shown and highlighted below in Figure 1) with your RCLK signal, it will have the exact effect you want. It effectively "aligns" the RCLK edges so that each specified edge (rising or falling) is at the left side of the resulting eye diagram.

Shawn 

Figure 1

From: support.cadence.com/.../techpubDocViewerPage

Hi, Shawn. 

Thanks for the info! This is good to know! I just read through the Eye Diagram Assistant section of the viva document and realized my previous confusion was that I've specified some period Trclk_average in the Eye Period field ("specify the time period for the eye diagram") while enabling external triggering Threshold field ("when crosses, the eye diagram starts a new period") at the same time. These two fields seem to be contradicting each other. So I tried two cases, both with external triggering threshold enabled, but with Trclk_average in the Eye Period field for the 1st, and with nothing in the Eye Period field for the 2nd. And I saw in the 2nd case the max x-axis boundary of the eye generated goes beyond Trclk_average by about the same amount of UIjitter_peak that I measured on rclk, indicating the x-axis boundary is tracking the max jitter on rclk pos edge and the data signal is getting triggered on all the aligned rclk pos edges. Whereas in the 1st case, it's the exact same eye in case 2 but with x-axis boundary truncated down to Trclk_average specified in the Eye Period field.

Thanks for the help!

Regards

Hi, Andrew. If possible can you please help take a quick at the discussion below and confirm when a jittery rclk is used to trigger another data signal, all the rclk pos edge zero-crossings (used as the triggering threshold) are automatically aligned together at the same point?

Thanks

I've been trying (and failing) to explain this all the way through because you seem to keep insisting that it needs to "align all the edges together" first before it triggers. As Shawn has said (and I did too), the trigger is used to determine the start of each period for the eye diagram. It's as simple as that. If the rclk and data signals are related in time, then the zero-crossing of the rclk causing each period of the eye to start should do exactly what you want - which is why I couldn't understand why you thought it was a problem! 

Put simply, an eye diagram is just a set of intervals of the data waveform snipped out and shifted to zero-time. The point that each of these intervals start is determined by how that's triggered - either a self-triggered (via a fixed period), or triggered from a signal with a given threshold. If the external trigger has a good timing relationship with the data (which it should, if the clock has been recovered from the data), then the alignment should be good too.

Regards,

Andrew