carry chain delay difference between real test and Timequest analysis result

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

--- Quote Start ---

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.

--- Quote End ---

Although talking about TDC implementation in FPGA is not my purpose of this thread, i will input some more words as your concern.

Yeah, as you said, external signal input are totally asynchronous. when a hit signal arrives, a carry signal will be generated and this carry signal will propagate along the tapped delay line which is created with carry chain (cascaded carry LEs in Cyclone-IV). for example, in Cyclone-IV, average carry delay is 45ps at room temperature. so in worst case, only the most front register where carry signal reaches may run into metastability(this may need some more thinking). since TDC implemented in FPGA is somewhat of statistical meaning, and on-line calibration is also employed to revise result, so it is ok for last bit instability.

As to my test result, the same method is also used to measure carry delay in Cyclone-IV and the test result is 45ps under room temperature which is well fiitted into timequest result. I rechecked my method in Cyclone-V, and i did not find any problem with my method.

i think i need a definitive answer, or maybe i need send a service request to Altera?

Best Regards,

ingdxdy

The timing model needs to account for worst case variation from the fab in each corner + design margin, have you tried sweeping the entire FPGA to see how much variation you get? It's possible you have a faster part or used a faster region on the FPGA.

Also, did you take into account clock skew in your measurement?

--- Quote Start ---

Hello ingdxdy,

The Cyclone V serial devcies carry chain should be like this, as attached picture shows. One ALM include two LEs, however, timequest display that one of LE can't privide any delay time.

--- Quote End ---

Your testing result seems fit arria ii devices. And I run same test on StratixIV device, the delay time is about 14 ps.

I doubt Cyclone V has same die as arria II. For i know that Arria GX has same die as Stratix IIGX.

BTW, I have a question about you TDC implemented inside Cyclone V. The delay time is so tiny (not like 45 ps, as you said in CIV), it means that you have to implement longer delay chain, this would give you many problems for logic design. Speak frankly, I try to implement TDC inside Cyclone V and StratixIV, and i found the delay line was not stable. So i gave up.

--- Quote Start ---

Although talking about TDC implementation in FPGA is not my purpose of this thread, i will input some more words as your concern.

Yeah, as you said, external signal input are totally asynchronous. when a hit signal arrives, a carry signal will be generated and this carry signal will propagate along the tapped delay line which is created with carry chain (cascaded carry LEs in Cyclone-IV). for example, in Cyclone-IV, average carry delay is 45ps at room temperature. so in worst case, only the most front register where carry signal reaches may run into metastability(this may need some more thinking). since TDC implemented in FPGA is somewhat of statistical meaning, and on-line calibration is also employed to revise result, so it is ok for last bit instability.

As to my test result, the same method is also used to measure carry delay in Cyclone-IV and the test result is 45ps under room temperature which is well fiitted into timequest result. I rechecked my method in Cyclone-V, and i did not find any problem with my method.

i think i need a definitive answer, or maybe i need send a service request to Altera?

Best Regards,

ingdxdy

--- Quote End ---

I don't think you will get what you want from Altera guys. Only information you can get from SR will like kaz have given you.

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