Forum Discussion

mmeyers's avatar
mmeyers
Icon for New Contributor rankNew Contributor
5 years ago

slvs-ec interface to Sony sensor

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.

12 Replies

  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    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's avatar
      mmeyers
      Icon for New Contributor rankNew Contributor
      5 years ago

      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.

  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    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's avatar
      mmeyers
      Icon for New Contributor rankNew Contributor
      5 years ago

      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's avatar
        mmeyers
        Icon for New Contributor rankNew Contributor
        5 years ago

        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.

  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    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.


  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    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's avatar
      mmeyers
      Icon for New Contributor rankNew Contributor
      5 years ago

      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?

  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    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.


  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    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.



  • Jens's avatar
    Jens
    Icon for Occasional Contributor rankOccasional Contributor
    2 years ago

    Dear mmeyers,

    did you have any experiences with the PRBS test pattern from sensor described in SLVS-EC Spec., Annex H?

    I'm using Arria 10, Native Phy and similar settings like you. The rx_is_lockedtodata and rx_syncstatus signals are high but the SLVS-EC Phy codes are not correct or not comlete. So I will check the connection using the sensors test pattern. Therefore I need the 511 bytes between the K.28.5 symbols.

    Jens