cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
michielm
Contributor
Contributor
1,404 Views
Registered: ‎10-10-2018

XAPP1315 IDELAYE3 delay update procedure

Hi all,

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?

Gr,

Michiel

 

0 Kudos
6 Replies
sandrao
Community Manager
Community Manager
1,351 Views
Registered: ‎08-08-2007

Hi @michielm 

 

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. 

Xapp1315.PNG 

 

Regards,

Sandy

Thanks,

Sandy


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub , Versal Blogs and the Versal Useful Resources .

------------------------------------------------------------------------------------------------
michielm
Contributor
Contributor
1,341 Views
Registered: ‎10-10-2018

Thanx Sandy,

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)

 

Gr Michiel

0 Kudos
sandrao
Community Manager
Community Manager
1,334 Views
Registered: ‎08-08-2007

Hi @michielm 

 

When I simulate and look at the clocks at the ISERDES they look ok xapp1315_bk.PNG

Can you share when  in the simulation you are seeing the issue?

 

Sandy

Thanks,

Sandy


------------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub , Versal Blogs and the Versal Useful Resources .

------------------------------------------------------------------------------------------------
michielm
Contributor
Contributor
1,317 Views
Registered: ‎10-10-2018

@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!

0 Kudos
michielm
Contributor
Contributor
1,194 Views
Registered: ‎10-10-2018

Hi@sandrao ,

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.

Screenshot_20190904_141514.png

 

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).

if (( Update_Seq == 8'hAA) |
(VCO_MULTIPLIER == 2 && Update_Seq == 8'h7F) |
(VCO_MULTIPLIER == 2 && Update_Seq == 8'h80)) begin
rx_state <= 5'h15; // 0x15 - Stop training
 

However I'm a little worried about the other coditions in that same if statement. What's the idea behind those lines?

 

Thanx,

Michiel

 

0 Kudos
dlr
Newbie
Newbie
322 Views
Registered: ‎06-11-2021

As far as I can tell michielm's last question was never answered.

if (( Update_Seq == 8'hAA|
(VCO_MULTIPLIER == 2 && Update_Seq == 8'h7F|
(VCO_MULTIPLIER == 2 && Update_Seq == 8'h80)) begin
rx_state <= 5'h15// 0x15 - Stop training
 

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 ?

0 Kudos