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?
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
- 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, 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.
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.
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.