Hi all, 5CGXFC7D6F31C7N is used to implement a TDC in my design with QII14.0. according to timequest analysis results, the average carry delays of adder in a ALM are 52ps, 46ps, 27ps, 26ps respectively for timing corner slow_1100mV_0c, slow_1100mV_85C, fast_1100mV_0c and fast_1100mV_85C. however, real test shows that the average carry delay is only 11ps under room temperature (core voltage is 1118mV under test), and 11ps is not in the range of delay of four timing corners. it seems timequest gives incorrect results. could anyone explain this delay difference between real test and timequest? why the delay value differs so much between real test and timequest result? Regards, ingdxdy

How are you measuring this delay on an internal FPGA path?

--- Quote Start --- How are you measuring this delay on an internal FPGA path? --- Quote End --- Well, i chained 420 ALMs vertically, a carry signal is generated by an input (active high). then the carry signal is propagated along the (adder) chain. A 250MHz system clock is used to sample the carry signal position, then i could get to know how many ALMs the carry signal is passed within a 250MHz period(positions at two adjacent clock edges can be obtained and then subtracted). according to test result, the carry signal propagates about 360 ALMs in a 250MHz period, so i get average carry delay per ALM is 4000ps/360=11ps. you could look at the basic idea of FPGA based TDC implementation to get a deep understanding. Best Regards, ingdxdy

--- Quote Start --- Well, i chained 420 ALMs vertically, a carry signal is generated by an input (active high). then the carry signal is propagated along the (adder) chain. A 250MHz system clock is used to sample the carry signal position, then i could get to know how many ALMs the carry signal is passed within a 250MHz period(positions at two adjacent clock edges can be obtained and then subtracted). according to test result, the carry signal propagates about 360 ALMs in a 250MHz period, so i get average carry delay per ALM is 4000ps/360=11ps. you could look at the basic idea of FPGA based TDC implementation to get a deep understanding. Best Regards, ingdxdy --- Quote End --- I have heard about TDC on FPGAs but I have doubts about its precision as it should take into account clock tree delays, timing violations, fitting variation, optimisation and needs some sort of averaging

--- Quote Start --- I have heard about TDC on FPGAs but I have doubts about its precision as it should take into account clock tree delays, timing violations, fitting variation, optimisation and needs some sort of averaging --- Quote End --- Thanks for your reply. Well, as you look into FPGA based TDC implementation, you will see that these problems you said all will be handled commendably. Here my problem is not how to implement TDC in FPGA, my problem is why TimeQuest analysis result is different from real test. Since TimeQuest plays a critical role in regular FPGA designs, i need to figure out what is wrong? is my test result wrong? or something else. I have used the same method to acquire the carry delay of Cyclone-IV, the real test result is well fitted into Timequest analysis result, while for Cyclone-V, this is not the case. I think the problem could be replicated easily, i need a confirmation from someone else. Best Regards, ingdxdy

I strongly suspect your measurement is wrong. The main concern in the design of TDC on fpga is that your signal input will be asynchronous and can't be sampled on registers without timing violation. It also can't be synchronised through two stage registers as this will defeat the purpose. So I don't see how TDC can sort out this issue.

carry chain delay difference between real test and Timequest analysis result

14 Replies

Altera_Forum
Honored Contributor
8 years ago
--- Quote Start ---
Thanks much for your reply, Jerry, and sorry for my delayed response.

As you said, there are two dedicated adders in a ALM, and according to TQ result, the second adder delay is 0ps, while the first adder contributes the main component of TDL.
the granularity of delay element is not as uniform as in CIV, but this is not problem. i have seen other peoples works where they implement TDCs in 28nm(or 20nm?) Xilinx FPGAs, the delay elements there are either non-uniform and there exist many zero-wide bins.
Generally, TDCs implemented in more advanced process FPGAs (28nm and below) need bin realignment, for IC delays including clock skews play a more important role than before to decide bins positions. the tuition of bins are arranged according to their physical locations should be adjusted.

However, the purpose of my posting this thread is not to discuss how to implement TDCs in CycloneV, but the real test delay value is different from TQ result which makes me puzzled.

B&W,
ingdxdy
--- Quote End ---

Did you mean re-asign delay time to those 0ps cell?

BTW, what's you test input hit? I can implement PLL generated HIT as calibration input, however, this can't be realized in CV or SIVGX devices.
Altera_Forum
Honored Contributor
8 years ago
--- Quote Start ---
Thanks much for your reply, Jerry, and sorry for my delayed response.

As you said, there are two dedicated adders in a ALM, and according to TQ result, the second adder delay is 0ps, while the first adder contributes the main component of TDL.
the granularity of delay element is not as uniform as in CIV, but this is not problem. i have seen other peoples works where they implement TDCs in 28nm(or 20nm?) Xilinx FPGAs, the delay elements there are either non-uniform and there exist many zero-wide bins.
Generally, TDCs implemented in more advanced process FPGAs (28nm and below) need bin realignment, for IC delays including clock skews play a more important role than before to decide bins positions. the tuition of bins are arranged according to their physical locations should be adjusted.

However, the purpose of my posting this thread is not to discuss how to implement TDCs in CycloneV, but the real test delay value is different from TQ result which makes me puzzled.

B&W,
ingdxdy
--- Quote End ---

Hi ingdxdy,

Recently, i implemented TDC in my CycloneIVGX devices. I found there were several (9 to 12) zero width bins. Did you meet this situation in your case? Also, i tried to do bin re-alignment, however, there was no effection. I attached my test result. The average bin width should be about 40 ps, but the biggest bin width is about 100ps.

https://alteraforum.com/forum/attachment.php?attachmentid=14704&stc=1

Thanks

Jerry
BazingaWei
New Contributor
5 years ago
hi there，

i noticed the same phenomenon and got the same question, did you get the answer for it?

Forum Discussion

carry chain delay difference between real test and Timequest analysis result

14 Replies

Recent Discussions

MAX10 DDR3 Timing

Help with BTS and .sof example files for Agilex 7 AGM039EA

Quartus Prime Pro 25.1 fatal error during fitter: Windows "Efficiency mode" required

Quartus Pro simulation libraries for Riviera Pro

RoHS declaration of 10M50DDF256C8G