66AK2H14: eye diagram

Bruno,

Can you give a little background on your questions?  Are the questions 100% just trying to read/understand the appnote and tool?  Or are you using the tool in a real system and seeing issues?

Thanks,

Kyle

Hi Kyle,

The picture you can se in my post is a real waveform taken from a real system where the SOC is connected to a 10G switch.running PRBS31 through lane1

I used the "serdes_diag_eye_K2HC66ExampleProject" to collect eye data, and then the EyeDiagramViewer tool to view the result.

The problem  is that I don't understand the horizontal timing axis, and I am not even sure if the vertical axis is correct because all depends upon the parameters input to the viewer tool.

If you could give some explanations it would be nice.

With best regards,

Bruno

Bruno,

I havent used the eye tool, however, I would say that what you have doesn't seem right.

As you rightly pointed out, the 10.3125G Baud rate corresponds to ~97ps and what you have shows it is close to 38ps.

Would it be possible to capture the device output on the scope and see if you still see the same eye diagram? 

The eye diagram below is from another device (DRA821) for 10GBase-KR (USXGMII) running at the same 10.3125G Baud captured on a scope and I have 2UI captured and the eye is about 97ps as expected.

Hi Shreyas,

In our case the link we receive comes from a distant equipment through backplane.and connectors Surely we won't get a nice wide opened eye as you are showing.

IT would be nice to use  a scope but we exactly want to avoid this because of some major drawbacks.

- Need to get an expensive high bandwidth scope

- Need to  implement CTLE and FFE inside the scope in order to re-open the eye. But by doing so we can be very far away from what does the SOC internal CTLE, FFE and other ATT/BOOST features. 

- risk to degrade the signal due to scope interconnexions

Therefore we believe the better way is to use the internal ON-DIE scope capabilities! WE normally get a signal picture close to reality.

It would be a pity to not use it.

Do you agree ? or not ?

With best regards,

Bruno

Bruno,

I agree that at least 16G or higher BW scope would be required to capture the signals. You would need to do some de-embedding for removing the channel/trace losses such as to take the measurement at the DUT ball.

The USXGMII picture I had didnt have de-embedding on it, and since there is no defined eye mask for the 10GBase-KR, I defined a small eye mask that fits the eye.

I agree that the On-die scope would be beneficial. Would changing to PRBS7 make any difference? Is there a way to see raw signals on the tool?

I don't want to suspect signal integrity but with the eye width at 38ps compared to the 97ps UI, I am not sure if that could be the reason.

Hi Shreyas,

OK we could debate  about scope usage but my questions are related to the Eyediagram analyzer tool that comes from Texas Instrument. May I put them again

• obviously the horizontal axis graduation from 0 to 125 do not relate to ps. ==> How should we adjust tool parameters to get a correct view ?

• Can we trust the vertical axis ?

• 4 eyes can be seen in the picture while the horizontal domain extension seems to be limited to 2UI according to SPRUHO3a. DId I missunderstood that document ?

• I guess that the EyeDiagramViewer" tool parameters should match the physical characteristics of the 66AK2H14. 
  • Is the 2mV/tap an adequat setup for 66AK2H14 ?
  • Is the 2ps/tap an adequat setup for 66AK2H14 ? note that only integer values are permitted.

i will try PBRS7 as soon as possible

Best regards,

Bruno

Bruno,

Can you see if the  following appnote helps:https://www.ti.com/lit/an/sprac37/sprac37.pdf

(Note, we have limited expertise on this tool, so are limited in our abilities to directly answer your questions...apologies)

Thanks,

Kyle

Kyle,

Thank you for your reply.

Unfortunately I already read this document which did not help answer my questions.

Okay I understand that you are not familiar with the tool.

• Is it possible to get the source code  ?

At least can you answer to my previous questions about the  SPRUHO3a document.

• in the SPRUHO3a document we can see (lane register @2C)  that the Eye fine offset control x-direction is a 7 bit word coding 1/2 UI therefore leading to 1/256 UI per horizontal tap, that is 0.37 ps/tap. Is this correct ?

• The same register includes a 2 bits word in steps of 1/2 UI . therefore i understand a maximum deviation of 3*1/2 UI. Correct ?

• Therefore do you confirm that all-in-all the eye diagramm horizontal deviation is limited to a total of 3/2UI (from PMA_LN_EYE_DLY_O_7_0(8..7)) +  1/2 UI (from PMA_LN_EYE_DLY_O_7_0(6..0))  = 2 UI ? 
  • or are there other consideration to take into account ?

With best regards,

Bruno

Bruno,

As Kyle mentioned, we have limited familiarity with the tool. We are checking internally to see if we can provide the source code to you.

1), 2), 3) Yes, your understanding and the calculation seem right to me.