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,
Thanks for your update. Glad to hear that you have managed to make it works.
Regarding your latest inquiry on the signaldetect, for your information, the signaldetect will look for voltage above the set threshold to assert or de-assert the status signal. It is not watching for transition.
Please let me know if there is any concern. Thank you.
Best regards,
Chee Pin
New ContributorAfter some more testing the reliability of establishing a connection is still flaky.
That is once a connection is successful it works great, but getting a connection is unreliably.
For example when in the bad state, every time the following packet is sent:
003C, 0200, 1234, 5678
The following is received:
003C, 023C, 1234, 567C, 5678
This is looking directly at rx_parallel_data with signal tap after both rx_is_lockedtodata and rx_std_signaldetect are high.
The state machine does not have any way to detect this because when empty packets are being sent they look fine:
003C, 0000, 0000, ....
Received:
003C, 0000, 0000, ....
Is it possible for rx_is_lockedtodata to have false positives (besides the 4us timeout)?
It is as if some component within the Native Phy is partially out of alignment.
Right now tx_std_clkout is connected to both tx_std_coreclkin and rx_std_coreclkin so as to keep everything in the same clock domain and simplify the design on my side. The documentation states that there is alignment logic that will take care of some discrepancy between rx_std_coreclkin and rx_std_clkout as long as they don't drift relative to each other. Since both FPGAs are running from the same reference, that requirement should be satisfied. Maybe the alignment logic is not as strong as the documentation suggests?
Maybe the state machine is going to have to do some additional handshaking by sending test data to make sure everything is aligned, then toggle rx_std_wa_patternalign again if that fails.
But that is annoying since sending a comma symbol (3C and datak=1) every packet really should be enough to get a good alignment.
Version info:
Quartus Prime Version 18.1.1 Build 646.
