cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
377 Views
Registered: ‎09-12-2007

IDELAYE3 load not taking effect

Jump to solution

I am using the IDELAYE3 in an UltraScale+ device. The IDELAYE3 is set in VAR_LOAD delay_type and TIME delay_format. The UPDATE_MODE is set to MANUAL, so that I can change the CNTVALUE every 2uS.

When I write a new CNTVALUEIN input value, the CNTVALUEOUT updates to the new value, so I know that the write cycle worked. The problem is that the new delay value does not seem to take effect (signal on IDATAIN is not delayed per the new CNTVALUEIN value).

According to UG571 (v1.10) pg 176: "If set to MANUAL, it takes two assertions of LOAD for the new value to take effect. The first LOAD loads the value defined by CNTVALUEIN into the delay line selection register, the second LOAD must be asserted together with an assertion of the CE to make the new value take effect."

In my design, I asserted the LOAD for 1 clock and then asserted CE and LOAD together for 1 clock (back-to-back clock cycles). This timing worked fine for loading the CNTVALUEIN input value but did not work for making the new delay value take effect.

Q1: Do I need to wait longer than the next clock between when I assert LOAD to when I assert CE and LOAD together in order to make the new delay value take effect?

Q2: Is there any issue with updating the CNTVALUE so often at a rate of every 2uS?

Thanks for any help!
John

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
259 Views
Registered: ‎09-12-2007

@pthakare I was already following all of those exact steps. It turns out that the IDELAYE3 load was taking effect after all. There was a misunderstanding of the correct delay value CNTVALUEIN to use that resulted in the appearance that the IDELAYE3 load was not taking effect when it actually was.

The misunderstanding I had was about when to account for the "align delay" when IDELAYCTRL is used (per AR# 66013). I was accounting for this align delay in both IDELAY and ODELAY. But if I read the AR more carefully, the AR specifies that the align delay is "included on the RX side" so this only applies to IDELAYE3 and not ODELAYE3. When I applied this clarification to my design, the issue was resolved and I could tell the correct CNTVALUEIN delay value was always taking effect.

View solution in original post

2 Replies
Highlighted
Moderator
Moderator
349 Views
Registered: ‎08-08-2017

Hi @jlevieux 

Apart from the steps you followed , Please make sure if you are following the below as well.

1. Wait for IDELAYCTRL.RDY to go High

2. Make EN_VTC Low to modify the delay line

3.  Wait for at least 10 clock cycles.

4. Put the new delay line value on the CNTVALUEIN[8:0] bus

5. Wait for one clock cycle and pulse LOAD High for a clock cycle. for manual update_mode the second LOAD must be asserted together with an assertion of the CE.

6. Wait for at least 10 clock cycles.

7.  Pull EN_VTC back High

 

 

 

-------------------------------------------------------------------------------------------------------------------------------
Reply if you have any queries, give kudos and accept as solution
-------------------------------------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
260 Views
Registered: ‎09-12-2007

@pthakare I was already following all of those exact steps. It turns out that the IDELAYE3 load was taking effect after all. There was a misunderstanding of the correct delay value CNTVALUEIN to use that resulted in the appearance that the IDELAYE3 load was not taking effect when it actually was.

The misunderstanding I had was about when to account for the "align delay" when IDELAYCTRL is used (per AR# 66013). I was accounting for this align delay in both IDELAY and ODELAY. But if I read the AR more carefully, the AR specifies that the align delay is "included on the RX side" so this only applies to IDELAYE3 and not ODELAYE3. When I applied this clarification to my design, the issue was resolved and I could tell the correct CNTVALUEIN delay value was always taking effect.

View solution in original post