01-30-2018 05:29 PM
I am having some issue understanding exactly what the RXCDRHOLD port does on the GTX Transceiver core?
First of all, this port is on the optional list on the GTX wizard GUI. So, the first question is that if this port is not selected, then what is the default value of this port? Is it 0 or is it 1?
Because I found some contradictory information about this port, as explained in ug476:
on page 183 of the above user guide, it explains that in case if no data is driven to the RX, CDR could potentially pick up noise on the RX trace. So, to prevent the CDR from picking up noise, then we have to Set RXCDRHOLD = 1'b1
So the above tells me that in order to start locking then we have to set Set RXCDRHOLD = 1'b0.
But then, on page 203 of the above user guide, it says:
To get the CDR to lock to reference, set RXCDRHOLD = 1’b1
So, now, I am confused !!!
Are we going to lock CDR when RXCDRHOLD = 1’b0 or RXCDRHOLD = 1’b1 ?
And then, if we do not include this signal from the optional signal list, then what is the default value of this signal selected by the tool? Is this port always set to 0 or set to 1? In other words, are we constantly locking or not locking, if we do not use this optional port?
Also, back to page 183, how does stopping/holding CDR, when there is no data on the RX, help with the CDR re-locking mechanism? Isn't it that every time when there is valid data driven to the RX, then CDR has to start the re-locking process over again? So, let's say if there are noise driven to the RX, and I want to hold the CDR, how will this help the CDR next time when it gets the valid data to be able to recover it better?
What will happen if CDR keeps locking, even if there is no real data and rather there is noise on the RX trace?
01-30-2018 08:24 PM
The CDR hold input has limited applications, because it essentially freezes the clock and data recovery circuits in the receiver. The phrase, "To get the CDR to lock to reference, set RXCDRHOLD = 1’b1" means that the input data is locked to the receiver clock, and the data sampling rate is determined exactly by the reference clock. During normal operation, when the RXCDRHOLD= 1'b0, the data sampling is determined by the incoming edges of the received data, not the reference clock.
To put it another way, asserting the RXCDRHOLD to a high state turns the receiver into a simple serial to parallel shift register, with no data recovery capability. This is needed for certain applications like 1 bit analog to digital converters, for example, OR when the NIDRU unit is being used in the fabric to recover data in frequency ranges outside of the GTX/GTH/GTY/GTP CDR range.
01-30-2018 11:24 PM
Thanks for part of the answer.
I am not sure if I follow 100%. Are you saying that when RXCDRHOLD= 1'b0, then the reference clock is not needed?
So, if that is the case, then we may not even connect a reference clock?!
I think in either case, the sampling happens with respect to the reference clock, regardless of whether it is locked or not..
In my original question I had few different points that I wasn't clear about (e.g. what is the default value of this port, if this port is not used). Could someone please elaborate more on the points listed in the original post?
01-31-2018 12:18 AM
The reference clock is always needed.
Starting from the REFCLK (frequency multiplied in the PLL), the CDR locks to incoming serial data frequency and phase and becomes solid or synchronous to the incoming data.
If you assert RXCDRHOLD=1, the CDR unlocks from data and goes back to REFCLK.
We use a PI (Phase Interpolator) based CDR, meaning that the initial REFCLK multiplied frequency is phase corrected in the CDR - thanks to the PI - in order to reach the incoming data frequency and phase. If RXCDRHOLD=1, the PI mechanism is frozen and the CDR output clock is no more synchronous with incoming data but goes back synchronous to local oscillator driving the REFCLK.
The default value of RXCDRHOLD is 0: CDR free to lock to incoming data.
There are rare cases where RXCDRHOLD=1 is needed: as JMCCLUSK said one typical case is when the GT is used as simple oversampler; another case is during SATA OOB operations; another possible case is when the data cable is unplugged, or data are missing ...
hope this helps to clarify
01-31-2018 05:52 AM
Okay Thanks for all the answers. I started seeing how this works.
So basically when RXCDRHOLD = 0, then CDR output clock locks to the incoming data. And when RXCDRHOLD = 1, then CDR output clock locks to be synchronous to the local oscillator that drives the REF clock...
But, I still have one question. Let's say for the special case, when data is actually missing, what is wrong if the CDR output clock is messed up and bad.... ?!
What I am trying to say is that why do we need to set RXCDRHOLD = 1, when there is no data (data missing). So, let's say what is wrong with setting RXCDRHOLD = 0, during the time that there is no data? Because, CDR will try to lock to the incoming data, but YES, there is no incoming data, so CDR will never be able to output any clock (since it won't be able to lock), but who cares ?!
There is no data to sample, why anyone has to care if CDR outputs a clock or not ! Is anyone going to get upset?
I am trying to see what is the advantage (or the necessity) of switching RXCDRHOLD to 1, when there is no data ?
Also on a separate note, is there a way for the fabric to monitor the lock signal of the CDR? In other words can CDR output some sort of an indicator to the FPGA fabric, that it is locked, and ready to go?
01-31-2018 07:32 AM
There is a reason to assert the RXCDRHOLD when there is no input data. This is because the recovered clock output (RXCLKOUT) of the transceiver can have glitches and short clock pulses. In turn, these clock glitches can corrupt the contents of BRAM that is connected to the clock. I've seen BRAM data corrupted, even when the write enable is tied low.
01-31-2018 07:59 AM
There should be a rxcdrlock_out port when you use the transceiver wizard to generate the IP that tells you it is ready to go. Depending other settings it the CDR lock may figure into a data valid indicator.
Getting that lock quickly is the reason you want to lock to reference when there is no data. You can stay in lock to data mode but you may falsely lock and it will take some to recognize that it bad a lock.
Basically the lock signal is driven by a state machine that counts if the data transitioned at the expected time and controls if the CDR circuit is doing adjustments to try to find the lock or just minor adjustments to keep the lock to data. When not locked it will try one setting for some time. If it gets enough transitions it will move the lock state state and the rest of logic can actually use the data coming out. If it does not find enough transitions it changes some settings and tries again. If it is locked it still counts the number of transitions but this time if it doesn't find enough it deasserts lock and goes back to adjusting settings.
So if there is no data the CDR state machine may falsely transition into the locked state from the noise which could let the downstream logic attempt to use that data and it will take some extra time to recognize that it shouldn't have locked yet and go back to adjusting the CDR.
02-01-2018 12:43 AM
because the channel is AC-coupled in most of the cases, if there are no transitions the p-n signal levels go quickly to the common mode value, or the RX bias value. This means that the Vdiff becomes 0 + noise. The CDR looks for information in the transitions phases. Ideally if there are no transitions the CDR will not move the PI . In reality the noise could cause same false transitions. The CDRHOLD will prevent this.
There is indeed a CDRLOCK port, but this is not supported because it cannot guarantee to detect the LOCK status in every condition. The safe way to determine if the CDR is locked is to check the recovered data. There is another method for CDR lock determination, based on eyescan. Also this method has few drawbacks.