06-14-2019 03:11 AM - edited 06-17-2019 12:48 AM
To me it looks like the "dynamic alignment state machine" in rx_clkgen_1to7.v of XAPP1315 isn't following the IDELAYE3 delay update procedure as documented on page 178 of UG571. the EN_VTC inputs of the IDELAYE3 are not lowered while manipulating the delays and also the CNTVALUEIN of the master (Mstr_CntVal_In) is set to 0 in state 5'h08. On page 180 it is mentioned you should never set it lower as the align_delay tap value (54 typically) Also the first two states of this statemachine are setting Mstr_IdlyRst that's never used further on...
Is my understanding right?
06-20-2019 07:33 AM
In Xapp1315 there is a mixure of COUNT and TIME mode. In COUNT mode the BISC is not used and the align delay is not accounted for and this recommendation does not apply. It is not not a requirement to pull EN_VTC low when the IDELAY is in COUNT mode.
The reason to pull EN_VTC low when making changes to the IDELAY is so that BISC and the new value are not competeting. When you are in COUNT mode BISC is not running so this is not an issue.
The IDELAYs that are in TIME mode have the BISC runs at the start and then their EN_VTC is pulled low so that the updates are all from the CNTVALUEIN / state machine.
Here is a snippet from the simulation the RXC_GEN IDELAYs are in TIME mode and their EN_VTC starts high and then pulled low by the design.
06-20-2019 08:16 AM
That part I do understand and doesn't impact the search for the optiumum ISERDES sample point. However to put the ISERDES samplepoint halfway the bittime we need to include the align_delay (54 typically as I undestand) From this AR https://www.xilinx.com/support/answers/64743.html I understand (note at the bottom of that page) this value is not reported in simulation (it will be 0). But if I dig through the statemachine I'm under the impression also in physical hardware this align delay is not accounted for and CNTVALUEIN will be set to 0 at state 5'h08 of the state machine. According the SelectIO manual page 180 this is not ok?!
My simulation also doesn't look nice. Optimum sampling point is found but rx_clkdiv2 (sample clock ISERDES) is not halfway the received data/clock bits (clkin_p_d/clkin_n_d)
06-20-2019 02:12 PM
When I simulate and look at the clocks at the ISERDES they look ok
Can you share when in the simulation you are seeing the issue?
06-21-2019 02:16 AM
@sandraoWhat is the bittime (CLKIN_PERIOD) you use? And the REF_FREQ? I added .SIM_DEVICE ("ULTRASCALE_PLUS") to the IDELAYEs ISERDES primitives... But I will try it with all default settings. Thanx again!
09-04-2019 05:39 AM
I finally managed to do the same simulation you did. Indeed when I simulate xapp1315 test_txrx_1050m.v I get the correct results you also showed. But when I simulate the other (test_txrx_0525m.v) I get this.
The sample is not in the middle. The design uses an alexander bang bang phase detector that ends the search for the middle of the UI if the algorithm is alternating increasing and decresing the delay. In rx_clkgen_1to7.v line 664 you see this condition (Update_Seq= 8'hAA).
However I'm a little worried about the other coditions in that same if statement. What's the idea behind those lines?
06-11-2021 09:43 AM
As far as I can tell michielm's last question was never answered.
However I'm a little worried about the other conditions in that same if statement. What's the idea behind those lines?
To which I add my question: What about lower input clock frequencies that require higher VCO_MULTIPLIER to satisfy MMCM_FVCOMIN ?