DS110DF111: Eye Capture using SigCon Architect Tool for DS110DF111

While I was trying to check the eye using sigcon tool, the eye pattern is always blank even though the opening values is getting updated ( Example HEO – 0.78125 UI and VEO – 325mv). Is there any sequence of registers we need to write to display eye . I tried below sequence as per the datasheet, but didn’t help.

• Clicking on “Single Capture” on the GUI EOM tab should be sufficient; no additional register writes are required from the user
• Question: Please confirm the GUI revision number they are using? Also what PC operating system is being used?

In one of the document (snlu126c), I could see that there was tab in the same eye opening window that shows the data rate. I don’t see that in my tool. This display would help me to confirm the data rate observed is 10.3125Gbps. If we don’t have this option for ds100df111 profile , how else can I confirm the data rate ?

• The grayed out data rate number in question on the SigCon Architect EOM tab does not correspond to the data rate detected by retimer. That field is simply for the user to enter their data rate to enable the GUI to compute the HEO in ps
• The CDR rate should be configured by the user via the CDR tab. For Ethernet there is a Standard mode option available. These Standard Mode settings implemented by the GUI are consistent with the product datasheet

Rate and Subrate Setting (from DS110DF111 datasheet)

Each channel of the DS110DF111 will, by default operate at 10.3125 Gbps and 1.25 Gbps. The device can be configured to operate at other VCO frequencies between 8.5 GHz and 11.3 GHz using the RATE (Reg: 0x2F bits [7:6]) and SUBRATE (Reg: 0x2F bits [5:4]) registers.

The DS110DF111 is designed to lock to signals conforming to several different data transmission standards. These standards may define a single data rate or multiple data rates. The rate and subrate settings of the DS110DF111 may be used to select a data transmission standard to which the input signal is expected to conform. The DS110DF111 searches each data rate applicable to the selected standard to find a valid signal to which it then phase locks.

Table. Rate/Subrate VCO and Data-rate Information

  After configuring the retimer channel in question to Ethernet standard mode via channel register 0x2F[7:4], Lock status is checked via channel register 0x02

I am using SigCon architect V2.0.0.8. Windows version is Win7.

My configuration is 1.25G,10.3125G mode, so default setting is good enough. On the SFI side, i am using SFP+ electrical loopback.I am able to see the link up ( LED green)

On the EOM tab ( Eye monitor) tab, I am able to see the signal detection status and CDR status updated as locked on both the channels.

EOM select  vrange is 200mV. Eye opening values : HEO - 0.8125UI, VEO - 337.5mV. ( does change whenever we recompute, so it seem to be working fine)

But the eye capture is blank.  I did try single capture and continuous capture, both cases i don't see any eye. While i verify the export raw tab , all the values are zero, sometimes i see one row being updated with some

values.

On the CDR status both channel A and channel B 0x02 value is 0x9C.

0x2F - 0x06 for both the channel. This confirms that rate and subrate value of 1.25Gbps and 10.3125Gbps.

On High level page,CDR tab, mode selection is Standard. So i believe rest everything is taken care for ethernet mode with this selection.

I feel with above settings and update seem to be correct. Not sure why aren't seeing the eye ?

While i try in demo mode to cross verify if tool is working fine or not, was able to see the eye  and also the raw data is updating fine

I feel with above settings and update seem to be correct. Not sure why aren't seeing the eye ?

• I agree that you have proceeded correctly related to retimer CDR configuration and assessment of status. based on the HEO and VEO values you are observing the retimer link performance should be good
• In the past we have run into issue with SigCon Architect full EOM plotting functions and some Operating System version. Can you confirm what operating system and version you are using?
  

Regards,

Rodrigo Natal]

HSSC Applications Engineer

Rodrigo,

Sorry i was off to work due to cold. So couldn't respond back. The OS i am using is Windows 7 Professional, SP1.

Version of SW is 2.0.0.8, build 05/12/2016.

How do we fix this ?

--

Krish

Update on this would be helpful. I am stuck at this stage. Please do help.

--

Krish

Hi Srinivas,

Sorry that this issue is still lingering. I have a few ideas for you to try based on past experience with SigCon Architect.

1. There are sometimes occasions where I have seen the retimer profile get in a state where the software hangs during EOM plotting and is unable to recover, i.e. a blank screen occurs in the eye monitor window. I have seen that simply closing and reopening the application makes the EOM work again.

2. Another idea is to try running the EOM on another retimer profile such as the DS125DF111. Though the profiles are different, the software mechanism that plots the eye diagram is the same, so this will help us determine if there is a profile-specific issue rather than an OS issue.

For these captures, please use 400 mV EOM_SEL_VRANGE as a start, and for additional debug, a screenshot of what you see would be helpful.

Thanks,

Michael

Michael,

Thanks for the response. It didn't help. I tried both the options you mentioned. I am still facing the same issue.

Below is the screen shot of eye capture. Hope this might help you to guide me further. Below is the screenshot for both continous capture and single capture.

Michael Lu (Santa Clara) said:

Hi Srinivas,

Sorry that this issue is still lingering. I have a few ideas for you to try based on past experience with SigCon Architect.

1. There are sometimes occasions where I have seen the retimer profile get in a state where the software hangs during EOM plotting and is unable to recover, i.e. a blank screen occurs in the eye monitor window. I have seen that simply closing and reopening the application makes the EOM work again.

2. Another idea is to try running the EOM on another retimer profile such as the DS125DF111. Though the profiles are different, the software mechanism that plots the eye diagram is the same, so this will help us determine if there is a profile-specific issue rather than an OS issue.

For these captures, please use 400 mV EOM_SEL_VRANGE as a start, and for additional debug, a screenshot of what you see would be helpful.

Thanks,

Michael

Michael Lu (Santa Clara) said:

Hi Srinivas,

Sorry that this issue is still lingering. I have a few ideas for you to try based on past experience with SigCon Architect.

1. There are sometimes occasions where I have seen the retimer profile get in a state where the software hangs during EOM plotting and is unable to recover, i.e. a blank screen occurs in the eye monitor window. I have seen that simply closing and reopening the application makes the EOM work again.

2. Another idea is to try running the EOM on another retimer profile such as the DS125DF111. Though the profiles are different, the software mechanism that plots the eye diagram is the same, so this will help us determine if there is a profile-specific issue rather than an OS issue.

For these captures, please use 400 mV EOM_SEL_VRANGE as a start, and for additional debug, a screenshot of what you see would be helpful.

Thanks,

Michael

--

Krish

Hi Krish,

Thanks for the plots. The HEO/VEO measurements you are reading back seem very large (0.96875 UI / 412.5 mV), meaning the eye is completely open. Since this is nearly the size of the entire EOM  64x64 array, there may not be eye hits that the EOM is able to plot. I have some ideas to ensure that we eliminate this as a root cause.

1. Can you reduce the source Tx VOD prior to the channel in which you are measuring the eye? In other words, I'd like to see how the eye looks when the VEO is closer to 200-300 mV.

2. What test pattern are you using? A HEO/VEO measurement this large at 10.3125 Gbps seems to indicate a 1010 pattern, which I have seen issues during EOM capture because of lack of varied bit transitions. Can you try running something like a PRBS-7 or PRBS-9 pattern at 10.3125 Gbps and seeing whether this makes a difference?

Thanks,

Michael

Michael,

Sorry i was off on friday and couldn't work on this.

I tried to reduce the source TX VOD < 200mV and also tried with both PRBS 7/9 pattern from source. I don't see any improvement in eye plot.

I am attaching the snapshots for your reference. I am attaching the default setting which had >300mV VOD and reduced amplitude.

Should we have webex session or something to work on this ? With CDR lock is happening at ethernet standard mode i believe TX is at 10.3125Gbps.

--

Krish

retimer_data.zip

Hi Krish,

Thanks for the screenshots. I did some evaluation with a DS110DF111EVM on my side, and I am always able to obtain at least an eye crossing for my use cases. I do see after several repeated eye captures that the eye may get off-center vertically as a software bug, but there is still an eye crossing unlike the plots you provided me.

I am happy to have a 30 minute WebEx session to do a live debug of what is happening. We can organize this offline (I believe we can coordinate through the FAE you are currently communicating with).

Beforehand, is there a possibility of you using another laptop, preferably with Windows 10, to see if the issue is specific to your computer or not? I do not recall if you have tried this already?

Thanks,

Michael

Hi Michael,

I had verified in other PC with windows 10 and i see same issue related EOM. I guess conference call should nail out the reason for this. I will check with Kris (FAE) reg this.

In the same laptop i had seen one time eye opening plot while trying the Tx pattern from source. But while i try to repeat the same it didn't work. From there nothing is working. I want to make sure my setup is correct. I am providing the details that i tried

The processor that i have connected to retimer on the board has debug tool ( similar to Sigcon) which can generate different PRBS pattern and also other pattern.

Connection is  as follows

From Proc TX, if i enable either of PRBS 7/9 pattern i can see that signal detection happening and cdr lock also happens after a second or two. Other change i do is the standard ethernet mode selection and i could see CDR gets relocked. So i consider we are running at 10.3125Gbps and TX source pattern is correct.

As you had mentioned earlier the VEO was more than 400mV. So i did reduce the amplitude from the TX by factor and was able to see the CDR relock and VEO did reduce , which i had shared yesterday. With this setup we should get proper eye eventhough there are some hits.

On the SFP side, i did try with electrical loopback SFP+ and also SFP+ with optical loopback. I could see both CHA and CHB signal detection and CDR lock happening.

My question on EOM.

As per the block diagram, EOM is captured at input of CHA/CHB , signal post CTLE and DFE settings (please confirm). To isolate if it is bit pattern issue from the processor or EOM issue, is there any other experiment i can try ?

There is PRBS generator available in retimer , can we try that ? I tried my luck but didn't help. Not sure if i was doing it right. There is an option in GUI as loopback input A/B with output signal states -- mute,rawdata,retimed data,prbs. 

In datasheet there are couple of options which includes with valid locked input and without input. I would like to try without input data pattern and only PRBS pattern from retimer and reduced amplitude. This would help us to know the EOM state.

Do we need any external sequence as mentioned in datasheet or just trying the proper loopback and output signal in this tool should get the pattern seen on either of input channels?

As an example, If i go for loopback A set and output signal select as PRBS generator , as per the block diagram i understand it would be chan A with PRBS pattern and looping back to ch B out. Would it consider DFE /CTL setting or not ? Also Question here is where does the EOM measures from for this test case ? How do we reduce amplitude if needed to see eye on EOM

--

Krish

Hi Krish,

Let's work with Kris to find a time that works to have a WebEx so we can do a live debug. Since you are seeing this issue with other windows PCs, it is possible that there is something happening with your setup that is different than when we use the EVM in our lab.

I am unable to see the connection you have posted in the earlier thread. It appears that the link is broken.

I will do my best to cover all the questions you asked:

1. The exact PRBS pattern does not affect the ability for the EOM tool to plot. The key thing is that there is a variety of transitions to form the eye. I believe, since you are able to see the HEO/VEO change when you modify the processor Tx settings and the CDR lock status changes, that you are indeed locked to the incoming signal. 

2. Regarding the EOM, it is after the CTLE/DFE and before the CDR input. This way, the EOM offers a view of the incoming eye that the CDR uses to slice the data and distinguish between a logic "1" or "0." I do not believe that changing the bit pattern here will isolate whether the EOM or the processor Tx is the problem, as they are interconnected.

3. The PRBS generator is a debug tool. In order to generate an output, you must provide a pattern at the input for the DS110DF111 to lock to, such as some other 10.3125 Gbps pattern (does not necessarily need to be a PRBS input) so that the CDR knows to output PRBS at 10.3125 Gbps. If there is no input, the DS110DF111 will not be able to generate an output since there is no signal for the internal clock to recover. So, I am afraid you will not be able to run a test with the retimer where there is no input data pattern.

4. I am not sure how using internal loopback will improve the EOM debug. I suggest that we focus on debugging the channel receiving from the processor Tx.

I have some requests while we work on setting up a WebEx to do a live debug session:

1. Is there a way for you to connect the DS110DF111 output to a scope? This way, we can verify as a sanity check that the locked and retimed signal coming out of the retimer is indeed a 10.3125 Gbps PRBS pattern.

2. I presume that you are not using our DS110DF111EVM.  Since the EOM measurement is a pretty significant burst read, I want to ensure that there aren't any other devices interfering with the communication. Are there any other devices connected to the same SDA/SCL/GND bus?

Thanks,

Michael

Hi Krish,

One more request to add  to my previous questions -- can you take a register dump of your DS110DF111 settings so that I can load them into the DS110DF111EVM setup on my side? You can do this by clicking "Save to File" and then attaching the .cfg to the next post.

Thanks,

Michael

Micheal,

I am out of office for compliance tests. Would get back to you regarding this. Will also coordinate with Kris to arrange webex session.

--

Krish

Hi Krish,

Sounds good. We'll be in touch when you get back!

Michael

Michael,

Below are my repsonses

1. Is there a way for you to connect the DS110DF111 output to a scope? This way, we can verify as a sanity check that the locked and retimed signal coming out of the retimer is indeed a 10.3125 Gbps PRBS pattern.

Krish : We have 13G scope. I can try capturing time domain signal. Capturing eye isn't possible.I will try this today and share some scopeshots

2. I presume that you are not using our DS110DF111EVM.  Since the EOM measurement is a pretty significant burst read, I want to ensure that there aren't any other devices interfering with the communication. Are there any other devices connected to the same SDA/SCL/GND bus?

Krish:  I am not using eval board , using my board . I2C bus has multiple slave devices connected.

Hi Krish,

1. Thanks. I'm interested in seeing whether the link is truly operating without issue at 10.3125 Gbps. If it is a matter of just the eye-monitoring not working in SigCon Architect, then perhaps we can find another method for reading back the eye.

2. Is it possible that any of the other slave devices connected to the same I2C bus are influencing eye monitor readback in SigCon Architect? One of the main differences between what you are seeing and what we see on our side is that the EVMs we test with have the DF111 as the only device connected to I2C on the board. If another slave device causes an intermittent interruption on the bus, it is possible that we may only observe it during eye monitor readback (large I2C burst read) and not during any of the other operations in SigCon Architect.

Would there be a way, for debug purposes, to isolate the DS110DF111 so that it's I2C is the only device connected to the USB2ANY, after which you try reading the eye back?

Michael