Forum Discussion

KeeganJ's avatar
KeeganJ
Icon for New Contributor rankNew Contributor
4 years ago

Cyclone 10 GX Transceiver Reset Controller "LockedToData" Signal

I'm instantiating the reset controller IP in order to safely use the the Cyclone 10 GX transceivers, as described in the user manual.

My question is why does the reset controller require "rx_is_lockedtodata"? What is its use for this signal?

The concern I have is that my application will never have rx_is_lockedtodata asserted, because I am using the receiver to oversample an asynchronous signal with no recoverable clock. Therefore I intend to always operate the receiver in lockedtoref mode.

Could I possibly wire rx_is_lockedtoref to the reset controller instead and have it function okay?

7 Replies

  • Deshi_Intel's avatar
    Deshi_Intel
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    Just to clarify are you referring to Cyclone FPGA or Cyclone 10 GX FPGA here ?


    Thanks.


    Regards,

    dlim


    • KeeganJ's avatar
      KeeganJ
      Icon for New Contributor rankNew Contributor
      4 years ago

      Yes Cyclone 10 GX.

      I'm currently using the development kit with 4 of the transceiver inputs & refclk routed from FMC connector.

  • Deshi_Intel's avatar
    Deshi_Intel
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    Hi,


    rx_is_lockedtodata is status signal that's meant to be used in CDR lockedtodata mode


    Since you are using lockedtoref mode, then you can safely ignore rx_is_lockedtodata from transceiver channel operation perspective


    However, the tricky question is how to deal with "rx_is_lockedtodata" signal connection to reset controller IP and whether reset operation will be gated by "rx_is_lockedtodata" signal or not. I believe this is your concern.


    Sorry I don't have good answer for you. Perhaps you can try and error to see which work out the best for you


    Option 1 - Let rx_is_lockedtodata signal connection to reset controller IP float and don't connect to anything

    • Hopefully it won't gate transceiver channel Rx analog reset or RX digital reset
    • If transceiver channel reset is somehow gated by rx_is_lockedtodata then maybe you can explore option 2


    Option 2

    • disconnect rx_is_lockedtodata connection between NativePHY and reset controller IP
    • Then create custom state machine design
      • if locktoref = 1, drive rx_is_lockedtodata = 1 to reset controller IP
      • else if locktoref = 0, drive rx_is_lockedtodata = 0 to reset controller IP


    Thanks.


    Regards,

    dlim






    • KeeganJ's avatar
      KeeganJ
      Icon for New Contributor rankNew Contributor
      4 years ago

      Thanks, this is approximately what I was thinking to try also. The reason for using this signal in the reset controller is a bit opaque, but my assumption is that it's just validating the receiver is operational so it can assert rx_ready.

      It looks fine in simulation, I will try to validate in hardware over the next few days and report back if there are any issues.

  • Deshi_Intel's avatar
    Deshi_Intel
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    HI,


    Just want to follow up with you.


    How does it go with your hardware testing ?


    Regards,

    dlim


    • KeeganJ's avatar
      KeeganJ
      Icon for New Contributor rankNew Contributor
      4 years ago

      Well I wired "rx_is_lockedtoref" into the reset controller, as mentioned. As best as I can tell it is working... I'm getting 10Gbps of data from the transceiver into the fabric, and the data looks right (again we are oversampling a slower signal, no serial clock to recover).

      So I guess either it's working or it's not failing in a way that I have been able to observe so far.

  • Deshi_Intel's avatar
    Deshi_Intel
    Icon for Regular Contributor rankRegular Contributor
    4 years ago

    HI,


    Thanks for the update and good to know it's working on hardware.


    Alright, I am setting this case to closure.


    Feel free to post new forum thread if you still have any enquiry in future.


    Thanks.


    Regards,

    dlim