I have reference lock issue on high speed interface mode. Then, I would need CDR-PLL related values, actually I have found some improvement with modification. However the following parameters are not explained in Transceiver user guide. Does anyone tell me that
1) What are those values?
2) Which characters are changed by those parameters, with larger value or smaller value?
3) How wide are available ranges?
The target parameters are "cdr_pll_set_cdr_vco_speed" and "cdr_pll_set_cdr_vco_speed_fix" in ALTERA_SERDES_SINGLE.v
Thank you for your rapid response.
I have an issue on my board as reference lock issue as you would know, and those parameters are related to that.
We build production boards with using Transceiver PHY and some of boards failed (around 15%) as non-lock at reference lock, occurs at early stage after configuration. Then when I modified those parameters, the reference lock failure has been fixed. But I don't have any information about those parameters, then I did it with cut and try. So I would know about details.
And there is another strange symptom on this matter. This is trigger why I have started modification.
I was delivered design files as vendor's IP using Transceiver PHY, and verilog HDL was generated by vendor's system. And I also generated HDL from an exact same Transceiver PHY Qsys file, but those parameter's values of mine were different from vendor's one. Not only vco_speed values but, some of L/M/N counters' values are different. Vendor told me that they didn't modify any parameters.
My generated HDL caused 100% failures on our products. And vendor's HDL caused 15% failures as above. So I have tried to modify those values. Those vco_speed values would be automatically generated by QUARTUS system, but how are optimized to each hardware board?
I attach a file including two screen shots of Signal Tap. The rx_is_lockedtoref is rise up immediately after releasing rx_analogreset in Pass board. However the rx_is _lockedtoref always stays Low after rx_analogreset. I have done a plenty of analysis, reset timing, clock waveform check etc. , but there was no solution without those value's modification so far.
Additionally, I think those parameters are PLL-VCO analog character settings judging from parameter names, so I think any modification for them would not affect any logical process for Transceiver communication process. And this issue would be issue on analog area. Anarolg-reset will not affect, as Fine board is always fine and Fail board is always fail even on any timing or no analog reset. I think, rx_analogreset affects to PMA process only.
Thanks for your update. I have looked through your signaltap screenshot, seems like after analogreset is released, the rx_is_lockedtoref for failing board will not go high. Generally if the CDR is unable to achieve lock to ref, it may be related to the input refclk as following. You may try to further look into them as well.
1. The input refclk would need to be sourced directly from a free-running on-board oscillator with the right frequency. This is the ensure successful power up calibration.
2. Similarly, the CLKUSR would need to be sourced directly from a free-running oscillator as well for calibration.
3. Related to potential signal integrity issue, you might need to use scope to check on the eye diagram of at the input refclk pin to ensure it is meeting the specs in the device datasheet.
4. Just wonder if you wait for some more duration, will the rx_is_lockedtoref gets asserted? Or it stucks at 0.
Regarding your understanding of the rx_analogreset, yes, you are right, it affects the PMA only. Regarding the modification of analog parameters, you are also correct, it would only affect the behavior of PMA instead of logical or digital processes.
Please let me know if there is any concern. Thank you.
Thank you for your reply.
I reply to your question.
1 and 2.
The refclk and CLKUSR are connected to input directly with close distance.
Once I checked waveform and jitter of refclk. It would be clear. Is there specification of eye-diagram of refclk? Icouldn't fine in the usergides. Anyway it was fine clock, then I think eye-diagram should be fine.
When I wait for a long duration more than several minutes, rx_is_lockedtoref always stay as Low.
Signal integrity is one of possibilities, but it might be difficult revising our board.
And this is an additional information.
I checked the fine range of cdr_pll_set_cdr_vco_speed for my boards, and found a bit strange matter. Fine range are intermittent. 1-3, 7-10 and 16-20 are the fine range for Fine board. Regarding Fail board, those range more narrow. Then some boards failed by slight deviation . But by optimizing this value, all boards became to fine. Do you have any idea about such intermittent range? At first, I thought this value was for loop-filter on loop-gain setting, but it might be correct.
And regarding cdr_pll_set_cdr_vco_speed_fix, it didn't affect to at least PLL-lock performance.
Thanks for your update. Regarding the refclk input specs, you may refer to the device datasheet -> "Reference Clock Specifications" section for further details on the requirement.
Regarding the intermittent range of the cdr_pll_set_cdr_vco_speed, sorry as I do not have insight on it because there is no detail on this internal parameter in the existing documentation nor database that I can access. Sorry for the inconvenience.
By the way, if you would like to proceed using the workaround of customizing this parameter, it is recommended for you to perform thorough verification to ensure your system are working per your expectation.
Please let me know if there is any concern. Thank you.
I have replaced oscillator with fast edge one, rising/falling 200ps (typ), and checked performance. However result was almost same with before. So some FPGA internal analog process or QUARTUS setup might be root cause. Anyway I set optimal value for our boards, and will do qualification test. Indeed, there is a risk without technical background though.
Thank you for your rapid response information. Regarding rise/fall specification, the waveform might be slow for 420ps. The specification of the component are 300ps(typ) and 500ps(max), so I would reconsider it. It is very useful information.