Strange Large IC delay in CycloneV

--- Quote Start ---

After Fittting, TQ reported timing violation.

I checked the data arrival path and found that there was a large IC delay(3.452ns) caused by signal routing from IOE to LAB.

I made serial-to-parralel conversion in LAB unit.

i think 3.4ns is a large delay in nowadays design, especailly in a 28-nm FPGA.

I basically think that Quartus should prevent that large IC delay, even after TQ has reported that violation(i think it is what timing-driven synthesis should do).

Please help, how can i decrease such a large IC delay in CycloneV?

Even put them physically together won't help? I am puzzled, or did i miss something obvious?

Best Wishes,

ingdxdy

--- Quote End ---

2 or 3 ns is commonly encountered in many devices for clock or data delay (io or internal) so I think you should tackle your timing problem away from this assumption that you must reduce delay. as long as both clock and data are delayed then it doesn't matter what delay is within practical latency range.

Thanks much for your reply.

--- Quote Start ---

2 or 3 ns is commonly encountered in many devices for clock or data delay (io or internal) so I think you should tackle your timing problem away from this assumption that you must reduce delay. as long as both clock and data are delayed then it doesn't matter what delay is within practical latency range.

--- Quote End ---

I do agree with you that "as long as both clock and data are delayed then it doesn't matter", after all, routing resources are limited, clock and data may need both to route through a long way.

I designed IC long before, i do not remember how fast signal transfers through metal or polysilicon etc, but i do know how fast signal transfers on a FR4 board, that is around 170ps/in, 3ns indicates 17 inch!

17 inch is a very long routing in PCB design! Of course, that is not the key of my problem.

My problem is that clock and data are not delayed identically, that is the reason why TQ reporting timing violation and my posting this thread.

data arrival path has a large IC delay compared to clock path and clock skew at the source and destination node is either not same.

And my another concern is that when i physically put source and destination node together, the IC delay does not decrease at all! and this looks unreasonable to me.

according to CV datasheet, there should be lot of local interconnect resource to connect adjacent node.

In my problem, DDIO input register in IOE and LAB are driven both by the same 240MHz, TQ reports setup time is violated.

Please refer to the attachment to see the waveform.

Best Wishes,

ingdxdy

your waveform shows launch clock delay of 5.589 ns while latch clock delay is 3.391 + 1.339 (ns).

This may give a clue to the negative setup slack. Why launch clock is so delayed?

--- Quote Start ---

your waveform shows launch clock delay of 5.589 ns while latch clock delay is 3.391 + 1.339 (ns).

This may give a clue to the negative setup slack. Why launch clock is so delayed?

--- Quote End ---

Yes, clock skew is around 0.86ns, this may be a source of the negative setup slack beside large data IC delay.

I do not know why there is such a large skew between launch and latch clock, because it is out of my control.

Both launch and latch clock come from the same 240MHz clock which is generated by a PLL.

I checked the fitter result, this 240MHz clock is routed through global clock network, so there should not be such a large skew.

The launch clock is fed into IOE to clock the two ddio input registers, while the latch clock is fed into LAB register, does that matter?

does routing to IOE be a difficult task? i have no idea.

Best Wishes,

ingdxdy

--- Quote Start ---

Yes, clock skew is around 0.86ns, this may be a source of the negative setup slack beside large data IC delay.

I do not know why there is such a large skew between launch and latch clock, because it is out of my control.

Both launch and latch clock come from the same 240MHz clock which is generated by a PLL.

I checked the fitter result, this 240MHz clock is routed through global clock network, so there should not be such a large skew.

The launch clock is fed into IOE to clock the two ddio input registers, while the latch clock is fed into LAB register, does that matter?

does routing to IOE be a difficult task? i have no idea.

Best Wishes,

ingdxdy

--- Quote End ---

Try remove PLL from design to reduce complexity for now and only use it if then timing fails.

Also you need to identify which path gave above failed waveforms; is it io path between adc and DDIO or internal path after it and have you written sdc with set_input_delay constraints?

--- Quote Start ---

Try remove PLL from design to reduce complexity for now and only use it if then timing fails.

Also you need to identify which path gave above failed waveforms; is it io path between adc and DDIO or internal path after it and have you written sdc with set_input_delay constraints?

--- Quote End ---

I need PLL to lock input synchronous clock from ADC, also with 90 degree phase shift to latch input data.

So Removing PLL is unpractical.

path between DDIO and internal fabric is failed in timing analysis.

I used set_input_delay to constrain the sync input, however, it had no influence on my problem.

as i just said, it is the path between DDIO and internal fabric that has negative setup slack, not the path between adc and DDIO.

Best Wishes,

ingdxdy

--- Quote Start ---

I need PLL to lock input synchronous clock from ADC, also with 90 degree phase shift to latch input data.

So Removing PLL is unpractical.

path between DDIO and internal fabric is failed in timing analysis.

I used set_input_delay to constrain the sync input, however, it had no influence on my problem.

as i just said, it is the path between DDIO and internal fabric that has negative setup slack, not the path between adc and DDIO.

Best Wishes,

ingdxdy

--- Quote End ---

Well you don't actually need PLL or 90 degree phase shift but it can help timing failure. Anyway there is no clear picture of your io constraints. You need sdc commands for all adc inputs and based on DDR examples cutting off unrelated edges. I have feeling that your sdc commands for inputs are misleading the reporting, just a guess. I am also not sure why clock pessimism is added to latch clock delay, is clock pessimism removal enabled, though its removal will make slack worse based on your waveforms.

--- Quote Start ---

Well you don't actually need PLL or 90 degree phase shift but it can help timing failure. Anyway there is no clear picture of your io constraints. You need sdc commands for all adc inputs and based on DDR examples cutting off unrelated edges. I have feeling that your sdc commands for inputs are misleading the reporting, just a guess. I am also not sure why clock pessimism is added to latch clock delay, is clock pessimism removal enabled, though its removal will make slack worse based on your waveforms.

--- Quote End ---

yes, set_input_delay and set_false_path are used for adc inputs and cutting off edges.

Maybe my sync constraint in the sdc file misleads the Quartus to make a long delay for the DDIO register clock, and this results in the negative setup slack between DDIO register and internal register, i will look into the sdc file carefully.

And you said "is clock pessimism removal enabled", what does this mean? can clock pessimism removal be disabled?from where in Quartus?

Thanks a lot.

ingdxdy

--- Quote Start ---

And you said "is clock pessimism removal enabled", what does this mean? can clock pessimism removal be disabled?from where in Quartus?

Thanks a lot.

ingdxdy

--- Quote End ---

clock pessimism removal should be enabled by default, go to quartus/settings/timing analysis settings and see clock pessimism removal box is checked.

It means for common clock path (that initial part shared between launch and latch clocks) the max/min difference effect should be ignored as physically you should either have max or min but not both on same physical line at anytime. If allowed it adds false unrealistic figure to setup slack and subtracts from hold slack.

Your clock pessimism of 1.3 ns is also too high!

--- Quote Start ---

clock pessimism removal should be enabled by default, go to quartus/settings/timing analysis settings and see clock pessimism removal box is checked.

It means for common clock path (that initial part shared between launch and latch clocks) the max/min difference effect should be ignored as physically you should either have max or min but not both on same physical line at anytime. If allowed it adds false unrealistic figure to setup slack and subtracts from hold slack.

Your clock pessimism of 1.3 ns is also too high!

--- Quote End ---

Yes, i see.

Thanks much for your patient reply.

Best Wishes,

ingdxdy