Hi all, I am synthesising my project and i am having timing violations wrt to IC delays. My cell delays are under control but dont know why even after adding a proper sdc the tool is not able to meet setup. I know the tool does add additional delays to meet the hold requirements but my priority is setup and i also have switched off the "optimize all hold paths" constraint. The cell delays in a path is around 2ns while the IC delays shoots upto 5ns. I dont want to use a logic lock constraint is there any othe way to meet 200Mhz for this path even if i take a 60-40 ratio of IC- CELL delays in each path. The sdc is cross checked and i have entered my requirements properly. THANKS

The fanout is also in control and the paths i am talking about is REG to REG.

Do a "report_timing -setup -npaths 2 -detail full_path -file "TQ_2worstpaths.txt" and post the output file. IC delays dominate nowadays, so the ratio you're seeing doesn't seem overly egregious, but hard to say without seeing the placement. More often than not, the values are correct and the fitter is doing a good job. You need to take off ~2ns of IC delay, which is unlikely. Also note that just adding a LogicLock constraint usually doesn't work. The fitter already knows what is critical and is working on it, so just putting the critical hierarchy into a smaller box more often than not breaks things instead of fixes them, as it just makes things more difficult.

Hi RYSC..i did what you said but this was not the path i was talking about. Here as you can see the datadelays is good but because of the clock skew my timings are failing. Because of this clock skew i had to shift my analysis to data delays and not the report timing. I use report_path option and check whether the data delays are within my clock periods. I dont know whether my analysis is correct but still would like you to guide me. I am attaching the reports you wanted and yes the path is reg to out and the output port is made virtual.

The clock skew is just as important as the data delay, so you want to work with report_timing. That's what drives the fitter and really determines if your design works. (If report_path showed the data path was 3.5ns, which would meet the 4ns clockperiod, but there were -1ns of skew, the design would fail report_timing and would not work). That being said, there's some strange stuff going on in the analysis that needs to be resolved. 1) The Data Required Path does not show the clock tree to this point. Normally it would look similar to the clock path on the Data Arrival Time, i.e. start with the clock coming in on pin AK22, through a global buffer, etc. This would balance out the clock skew. Instead the clock just appears at the memory. 2) The Data Required Path has an oExt delay, which always comes directly from a set_output_delay. Is this maybe a virtual pin or something like that? For internal paths you normally don't see that. I think there is something wrong with the .sdc causing this, but to be honest don't know what it is, but I would definitely figure out why those two issues are occuring and try to fix them first. After that, the datapath is actually Memory -> Logic, so it should be able to meet timing.

okkk i am sharing my sdc..but your first point was not clear to me..one thing that i can say wrt 2nd point is that the inputs and outputs are not registered so by virtual pin assignment the tool jus removes the last IC and buffer of the path. The rest of the path remains and yes the oExt is the set_output_delay and one more question you told me earlier that a skew of 3 to 4 ns is normal...but in the paths i have sent you even if my data delay was 0.1ns i cant meet timing because of the skew. I know you can help me out and i really do need some help.

Constraining ic delays | Altera Community

12 Replies

Altera_Forum
Honored Contributor
13 years ago
The fanout is also in control and the paths i am talking about is REG to REG.
Altera_Forum
Honored Contributor
13 years ago
Do a "report_timing -setup -npaths 2 -detail full_path -file "TQ_2worstpaths.txt" and post the output file. IC delays dominate nowadays, so the ratio you're seeing doesn't seem overly egregious, but hard to say without seeing the placement. More often than not, the values are correct and the fitter is doing a good job. You need to take off ~2ns of IC delay, which is unlikely.
Also note that just adding a LogicLock constraint usually doesn't work. The fitter already knows what is critical and is working on it, so just putting the critical hierarchy into a smaller box more often than not breaks things instead of fixes them, as it just makes things more difficult.
Altera_Forum
Honored Contributor
13 years ago
Hi RYSC..i did what you said but this was not the path i was talking about.
Here as you can see the datadelays is good but because of the clock skew my timings are failing.
Because of this clock skew i had to shift my analysis to data delays and not the report timing.
I use report_path option and check whether the data delays are within my clock periods. I dont know whether my analysis is correct but still would like you to guide me.
I am attaching the reports you wanted and yes the path is reg to out and the output port is made virtual.
TQ_2worstpaths.zip2 KB
Altera_Forum
Honored Contributor
13 years ago
The clock skew is just as important as the data delay, so you want to work with report_timing. That's what drives the fitter and really determines if your design works. (If report_path showed the data path was 3.5ns, which would meet the 4ns clockperiod, but there were -1ns of skew, the design would fail report_timing and would not work).
That being said, there's some strange stuff going on in the analysis that needs to be resolved.
1) The Data Required Path does not show the clock tree to this point. Normally it would look similar to the clock path on the Data Arrival Time, i.e. start with the clock coming in on pin AK22, through a global buffer, etc. This would balance out the clock skew. Instead the clock just appears at the memory.
2) The Data Required Path has an oExt delay, which always comes directly from a set_output_delay. Is this maybe a virtual pin or something like that? For internal paths you normally don't see that.
I think there is something wrong with the .sdc causing this, but to be honest don't know what it is, but I would definitely figure out why those two issues are occuring and try to fix them first. After that, the datapath is actually Memory -> Logic, so it should be able to meet timing.
Altera_Forum
Honored Contributor
13 years ago
okkk i am sharing my sdc..but your first point was not clear to me..one thing that i can say wrt 2nd point is that the inputs and outputs are not registered so by virtual pin assignment the tool jus removes the last IC and buffer of the path. The rest of the path remains and yes the oExt is the set_output_delay and one more question you told me earlier that a skew of 3 to 4 ns is normal...but in the paths i have sent you even if my data delay was 0.1ns i cant meet timing because of the skew.
I know you can help me out and i really do need some help.
project.zip1 KB
Altera_Forum
Honored Contributor
13 years ago
okk i got the 1st point but the tool has generated the report any problem with any other constrain..I mean i need the clock skew in the required path but yes its not there so what should i do about that.
Altera_Forum
Honored Contributor
13 years ago
A skew of 3-4ns is not normal at all. It should be ~200ps or less(depending on many factors).
SDC looks good. I noticed you're not using a virtual clock for the I/O interfaces. Not too big a deal, but I would recommend it.
Do you have virtual pin assignments in the design? I'm guessing that's what is happening. What about virtual clock assignments? I'm guessing that's what's causing it.
Can you change your SDC so the set_input_delay and set_output_delay are applied to specific ports(ones you know that really drive I/O), rather than [all_inputs],[all_outputs], which I'm guessing is catching the virtual I/O.
Finally, the I/O won't meet timing. Just looking at the outputs, the setup relationiship is 4ns, and the external delay is 2.664ns, which leaves 1.336ns for the FPGA to get data off chip. Right now your clock doesn't drive a PLL, so your going to have the entire global clock tree delay + the output buffer for your delay, which will be significantly larger than 1.336ns. You're minimally going to need a PLL to run I/O at 4ns period, and may need some other tricks. (That's where users often start doing source-synchronous interfaces).
Altera_Forum
Honored Contributor
13 years ago
Ok i get you...i know you strongly recommend virtual clock and i also tried using it but failed badly...I have two problems in understanding virtual clock that you have often suggested to many.
1. The advantage
2. If i am not feeding the clock to any port how will it constraint my design. How will the tool know the frequency it has to meet. I know that the problem lies with my understanding and thats why i couldnt use it although i really want to know the advantage of it.

I will also try your suggestion using input and output delays only to driving ports and can you also tell me the correct way of using pll I also tried using pll but maybe the correct syntax is wat i am failing in and yes one thing would like to mention that the reports are generated in ARRIA V.
Altera_Forum
Honored Contributor
13 years ago
And yes all my inputs and all my outputs except clocks and reset are virtual so in any case i am catching virtual I/O.
Altera_Forum
Honored Contributor
13 years ago
Yeah, you usually don't want virtual.
Most of the advantages of a virtual clock are secondary. Examples include:
- You can do stuff to the clock, like give it an offset, give it clock latency, etc. That being said, most people don't do this.
- You have a name for the external clock. This makes timing analysis easier. It's easier to identify it's related to I/O when you see one of the clocks called clk_sys_ext(or whatever name you give it). You can also do things like "report_timing -to_clock sys_clk_ext..." and get all outputs in that domain.
These are secondary since you may not use them. The only truly major one is that derive_clock_uncertainty should give a slightly different uncertainty to an external clock, so the timing is more accurate, but we're probably talking 20ps or less here.
As mentiond, your I/O is probably going to fail, and to be honest, might fail with a PLL, but should be closer.
Good luck. (I'm busy for the rest of the day so most likely won't be able to respond...)

Forum Discussion

Constraining ic delays

12 Replies

Recent Discussions

Cyclone-V SCFIFO - adding ECC to M10K/MLAB/Auto memory

Will serialization factor of 6 in LVDS serdes IP be supported in the future on Agilex5?

System PLL of Agliex5 PCIE example design cannot be locked after configuration

JTAG Chain Broken on Agilex 7-I Dev Kit

Request for Cyclone V Pinout File Information