Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Announcements
Need Forum Guidance? Click here

Search our FPGA Knowledge Articles here.
18955 Discussions

slvs-ec interface to Sony sensor

mmeyers
Beginner
602 Views

I have implemented an 8 lane slvs-ec interface to the IMX420 sensor. I have it functioning but I randomly run into an issue on startup (bringing the sensor out of Standby where it starts sending the sync codes). The 8B/10B decoder in the Arria5 device flags a rx_errdetect and rx_disperr which I interpret as a disparity error in the received 8B/10B word.  I have to repeat the startup sequence (sometimes multiple times) to achieve proper reception. Once the interface is running properly, it appears to be solid.

Does anybody have experience with this? Is it just the nature of the beast and people have to deal with this at link startup?  I can't find any mention of initial disparity setting (+ or -) in the sensor spec or the Arria5 transceiver docs.

0 Kudos
11 Replies
CheePin_C_Intel
Employee
579 Views

Hi,


One of the possible cause to the 8b10b error at AV RX is related to the signal integrity. Just wonder if you have had a chance to measure the eye diagram at the AV RX with oscilloscope and check against the datasheet to see if there is any anomaly or violation of the specs.


Please let me know if there is any concern. Thank you.



mmeyers
Beginner
574 Views

Measuring eye diagrams is pretty difficult for us. The data rate is 2376 Mb and the board is very dense. What I can say is that when the link does come up, we can run a test pattern from the sensor into the fpga and do a pixel - pixel comparison to a known good reference. Test runs overnight with zero errors so we're pretty confident signal integrity is not the issue.

I had left out one piece of info in original post.  Due to the Arria5's maximum fabric rate, I couldn't run the recovered byte info into logic to perform the final byte unpacking as defined by SLVS-EC spec. I had to use the transceiver's ability to go double wide on output (at half the input rate). Using SignalTap, on good startups, I see the 8B10B error signals bouncing around until I bitslip the incoming bytes to get byte alignment. At that point the 8B10B errors stop and system is happy which I would expect. On bad startups, I see the 8B10B errors continue on. I'm convinced the issue lies in the single to double wide conversion somehow.

CheePin_C_Intel, if you have any thoughts on this, would appreciate hearing them.

CheePin_C_Intel
Employee
567 Views

Hi,


Thanks for your update. I understand that you are using bitslip to get to the correct word alignment. You are using double width. In double width, you would need to take care of the byte ordering as well. Would you mind to share with me your Native PHY .v file so that I can have a better understanding of your configuration. 


Please let me know if there is any concern. Thank you. 



Best regards,

Chee Pin



mmeyers
Beginner
561 Views

CheePin

I do handle the byte ordering.

I believe my issue lies in the interaction between the Native PHY and the Reset Controller IP that I used. 

I am watching that with SignalTap now. 

Will get back to you with what I see.

mmeyers
Beginner
545 Views

Chee Pin

I have been looking at the Reset signals from the Reset Controller and it looks like there is some difficulty with the lanes locking to data (rx_is_lockedtodata signal goes false).

Digging into this now.

I have included my nativephy.v per your request.

mmeyers
Beginner
542 Views

Chee Pin

Could you comment on the clocks I am using in my interface?

The Native PHY is clocked at 74.25 MHz (cdr_refclk) which is one of the choices given in the Megawizard when building the core. My input data rate per lane is 2376 Mb.     2376M/32 = 74.25M.

I have been clocking the Reset Controller at that same rate (74.25 MHz).

I have been clocking the Reconfig Controller at 100 MHz.

Should the Reset Controller and Reconfig Controller run on same clock?

CheePin_C_Intel
Employee
509 Views

Hi,


Sorry for the delay. Regarding your inquiry on the clocks, please see my comment as following:


1. There is not specific requirement that the XCVR reconfig IP refclk need to be at the same frequency or clock with the reset controller. 


2. Note that normally to ease the connection, I will tied the clocks for reset controller and reconfig controller. You can give it a try as well.


3. For the XCVR reconfig clock, it is mandatory to have it sourced directly from a free-running and stable clock source. This is to ensure successful power up offset cancellation. It is also recommneded for the Native PHY refclk to be free-running as well.


Please let me know if there is any concern. Thank you.


CheePin_C_Intel
Employee
509 Views

Hi,


As I understand it, in your latest observation, you found that the rx_is_lockedtodata signal = low. I believe you are seeing it toggling periodically. If this is the case, it indicates that the CDR is unable to achieve lock to the data. 


You can also check if the rx_is_lockedtoref = high to check if the CDR has successfully locked to the refclk. Note that when rx_is_lockedtodata = 1, the state of the rx_is_lockedtoref can be ignored.


Common causes for the CDR to unable to lock to data are signal integry issue, incorrect data rate, local refclk signal integrity issue, incoming data's ppm exceed CDR threshold and offset cancellation issue. You can try to debug into these to see if can spot any anomaly.


Please let me know if there is any concern. Thank you.


mmeyers
Beginner
476 Views

Chee Pin

One last question.

What IO_STANDARD should the SLVS-EC inputs use? I have specified LVDS in my .qsf but is there something more appropriate in terms of input voltage swing?

CheePin_C_Intel
Employee
471 Views

Hi,


Thanks for your update. Regarding your latest inquiry on the IO standard to use, sorry as I am not familiar with SLVS-EC and could not comment what is the required IO standard for this protocol.


However, if you are using the AV GX transceiver receiver, the supported IO standards are 1 .5 V PCML, 2.5 V PCML, LVPECL, and LVDS. When configured in either of these IO standard, the receiver support the same set of specifications as in AV device datasheet -> "Receiver Specifications for Arria V GX and SX Devices" table.


You may refer to the table and cross check with the interface requirement or specs of SLVS-EC to ensure compatibility.


Please let me know if there is any concern. Thank you.


CheePin_C_Intel
Employee
459 Views

Hi,


As I understand it, it has been some time since I last heard from you. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.



Reply