07-30-2009 02:26 AM
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..
07-30-2009 09:40 AM
"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
07-30-2009 02:25 PM
"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.
07-30-2009 11:11 PM
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,
07-31-2009 12:24 AM
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
07-31-2009 12:46 AM
Hi Eilert ,
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,
07-31-2009 03:11 AM
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:
08-03-2009 12:37 AM
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