cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
8,161 Views
Registered: ‎12-29-2008

timing errors:

Hi,

After synthesis, and P&R -> generate post-place&route static timing -> then it will give timing summery in  that it will show two components --> 1. timing errors , 2.  Score.

 

Could any one explain me what is the relationship between this two components and how this score is calculated??

What is the significance of this Score??

 

And some times i observed that this score gets equal to the paths that shown in red in timing window ,  but some times not ??  where i am doing mistake ?? please guide me..

 

Thanks in advance..

 

Regards

Krishna Kishore 

0 Kudos
7 Replies
Highlighted
Visitor
Visitor
8,151 Views
Registered: ‎07-15-2009

Re: timing errors:

Krishna,

 

"Timing Errors" signifies the total number of paths that do not meet the timing constraints set.

"Score" signifies the sum of all the timing failures in your design.

 

Therefore, if you have 3 paths in your design that fail by 123ps, 321ps and 111ps respectively, you would get a report stating

 

Timing errors: 3  Score: 555

 

Hope this helps

 

Rick

 

0 Kudos
Highlighted
Professor
Professor
8,140 Views
Registered: ‎08-14-2007

Re: timing errors:

"Timing score" is used by the place & route tool to tell the relative merit of

multiple passes through your design.  It is not particularly useful to you unless

you have only 1 timing error.  Usually what you want to know is the maximum

clock frequency or best setup / hold times for each place and route pass,

not the sum of the errors.  For this you really need to look at the post place & route

static timing report.  Each timing constraint should have a "slack" listed in this

report.  A positive slack is good.  For example slack of 1 ns means you have met

the timing constraint and have 1 ns spare.  Negative slack is similar to the numbers

listed in the timing summary as timing errors.  It really makes no sense to add

these together.  What you need to know is the worst case (largest negative

slack) so you can tell how fast the design really runs.  If you absolutely have to

run the design at the constrained speed, the timing report also shows you the

path that failed the constraint so you have a chance to go back and fix the

design to run faster.

 

HTH,

Gabor

-- Gabor
0 Kudos
Highlighted
Explorer
Explorer
8,125 Views
Registered: ‎12-29-2008

Re: timing errors:

Thankyou Gabor and Rick,

Here i didnt understand one thing i.e " What you need to know is the worst case (largest negativeslack) so you can tell how fast the design really runs." Could you please explain it i am bit confused with this sentence because for a design if you keep timing constrint of 10ns then negative slack may or may not arise , in the same way if you keep 5 ns then it may occur , if you still go to 3ns ,2.5ns e.t.c .. then it will come , each and every time it will be different path , then how to know how fast my design really works.

 

** One more question: In recent synthesis what i observed is if i keep timing constraint upto some extent say up to 3ns then it is showing timing errors and all signals are completely routed , and in Post generate static timing window it is showing some failed paths in red color, upto that ok. If i reduce the timing constraint still less i.e 2.5ns then it is giving an error saying that P&R failed .  I want to know  in former case by doing some optimization in design it can achieve the target frequency in later it is not possible like that ??

 

Please correct me if i am interpretting things wrongly.

Thanks in advance,

regards

Krishna Kishore 

0 Kudos
Highlighted
Teacher
Teacher
8,119 Views
Registered: ‎08-14-2007

Re: timing errors:

Hi Krishna,

P&R is not a deterministic algorithm. The results may change from run to run with the same sources.

So with 10..5ns you are in a region where a solution without timing errors is existent, but not always reached.

Below 5ns no solution can be found with this tool on your computer. (We found out, that faster computers produce better results than slow ones for the same input with the same tool.)

 

Anyway, The P&R tool tries to reach your timing goal, and if you are working on the edge of what's possible the you end up with different (failed) solutions that have different critical paths.  

 

 

**

In any case: If you change your design to acheive timing improvements it may work. Unless you reach the physical limit of the silicon. (that is the 1 LUT - 1FF plus routing delay)

 

Have a nice synthesis

  Eilert

0 Kudos
Highlighted
Explorer
Explorer
8,122 Views
Registered: ‎12-29-2008

Re: timing errors:

Hi Eilert ,

Thankyou verymuch,

Some how i am not still satisfied with my mind and the results i am getting .. Please tell me one thing , When can i say that this is the maximum frequency of the design , after that it wont work.

 

If my thoughts are not proper please correct me..

 

Thanks in advance,

Regards

Krishna Kishore 

0 Kudos
Highlighted
Explorer
Explorer
8,109 Views
Registered: ‎07-27-2009

Re: timing errors:

 

The maximum frequency of your design would result from your design being mapped optimally in de FPGA. As a first order, optimistic estimate this would be the delay through the LUTs. As you probably know, there is a lot more to this. The wire delays have to be taken into account together with clock skew, setup and hold times, fanouts, ...

 

Your maximum clock speed also depends on what other logic you put into the FPGA. This additional logic can cause the device to fill up and suddenly you might hit a wall as multiple sub-designs try to get a hold of this one critical net or a LUT that would be required to meet timing. I have also seen the oposite happening: eliminating stuff from the FPGA caused timing errors as the placer suddenly tried to put LUTs further apart.

 

I think it is incorrect to assume that timing is some kind of continuous function as these algorithms use heuristics and at some point they are inherently discrete because you can only map 1 function in a given LUT and you can only route 1 signal over a given wire. A lot of the time you don't worry about maximum speed except for some -usually very small- part of your design.

 

TIP: if you look at timing reports with timing errors make sure you add options to include more reported paths, once the router encounters timing errors it cannot resolve you could see some paths in the report that belong to other logic that is not the root cause of the timing violations. As a designer you probably have a fairly good idea where you can expect timing violations, so look for those modules in the timing report.

 

 

If your design seems to be stuck you have a number of options:

  • try to add pipeline stages to break critical paths
  • use higher latency sequential bus multiplexers instead of combinatorial
  • check if you have the right switches enabled to get a good mapping to high speed FPGA resources such as DSP slices and multipliers
  • use a faster speed grade FPGA
  • change FPGA family
  • use placement constraints to keep critical stuff together
  • rethink your design; would it make sense to do double the number of operations at half the clock speed
  • look at synthesis reports to spot the kind of codings that prohibit some more optimal mappings
  • play with the tool options for the synthesis and the P&R

Cheers!
0 Kudos
Highlighted
Teacher
Teacher
8,052 Views
Registered: ‎08-14-2007

Re: timing errors:

Hi Krishna,

woutersj wrote some good points about how to improve the timing of your design.

The short answer is: No, you never can say for sure that you have reached the maximum possible frequency.

 

There's almost always some better approach or some helpful constraint to improve timing.

The tools (should) improve too from year to year.

And once in a while there's new silicon expanding the border of what's possible even further.

 

The only thing for you to rely on is the report of your static timing analysis.

It's a worst case calculation of the maximum possible frequency for your current implementation run.

 

The next implementation run of the same sources may already give you a different result.

 

Have a nice synthesis

  Eilert

 

 

0 Kudos