Forum Discussion
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
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.