Forum Discussion
New ContributorHow long should rx_is_lockedtodata be asserted before a valid connection can ACTUALLY be assumed?
Hi,
If during the toggling, the rx_is_lockedtodata assertion duration is longer than 4us, you can try to workaround by monitoring the RX signal detect to ensure valid signal presence before you check on the CDR status. Note that you would need to enable 8b10b block to use RX signal detect. You will need to set the signal detect thresholds according to your specific setup. You may refer to the SATA/SAS recommended QSF assignments in the V series XCVR PHY IP user guide -> Cyclone V Transceiver Native PHY IP Core -> "Enable rx_std_signaldetect port" section for further details.
Please let me know if there is any concern. Thank you.
Best regards,
Chee Pin
Regular ContributorHi,
Sorry for the delay. As I understand it, it seems like you are observing bit errors when you are sending some fixed data pattern from TX to RX. I believe the TX and RX are different FPGA. Based on this observation, it seems to be trending towards signal integrity issue or probably clocking issue instead of CDR lose lock. Generally when CDR lose lock, you will see all corrupted data instead of a few bit toggling with correct word boundary.
Would you mind to try the following:
1. Connect the rx_clkout to rx_coreclkin which is the recommendation connection.
2. Perform a serial loopback from TX to RX within the same FPGA with the same data pattern to see if RX still exhibit similar error. This would be helpful to narrow down potential signal integrity issue.
3. Please share with me you Native PHY .ip file so that I could have better understanding on your configuration as well as to see if can spot any anomaly.
Please let me know if there is any concern. Thank you.
Best regards,
Chee Pin
- ABoge
I'll try your points 1 and 2. In the meantime I've also included what I hope are the files that you are asking for.
As a side point:
You mention that connecting rx_clkout to rx_coreclkin is the recommended connection. I don't see this recommendation in any documentation.
On page 11-8 (pdf page 293) of this document https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/xcvr_user_guide.pdf
It says that it can be connected to any clock that the user wants. Specifically: "FPGA fabric clock, the FPGA fabric RX interface clock, or the input reference clock"
Obviously the clock used cannot drift relative to the transmitter or the fifo will overflow or underflow as the case may be, but that is guaranteed since I'm using the same reference for both FPGAs.
Admittedly that page is detailing information for the Low Latency PHY IP core not the Native PHY IP core. But that is not the only bit of information that is only mentioned for one variant of the IP core that is reasonably applicable to all the variants. For example, the fifo overflow possibility is only mentioned in the Interlaken section.
Is there better documentation somewhere else?
