doubt about static timing analysis

[kommu4946]

Hi all,
Why static timing analysis is not efficient for asynchronous designs..please explain .

Thanks

 

[TrickyDicky]

because asynchronous designs are much more suseptable to voltage, temperature and track length variation. Hence it is near impossible to time them.

 

[kommu4946]

Thanks for your replay..Here i have one more doubt,sta tool analyse four timing paths.
1.input port to output port(combinational path)
2.input port to reg
3.reg to reg path
4.reg to output port.
for above all paths does sta tool compare all path delays to clock period or only for reg to reg path?

 

[TrickyDicky]

it can only analyse reg to reg paths, unless you set max delay on specified paths.

 

[kommu4946]

it can only analyse reg to reg paths, unless you set max delay on specified paths.

If more number of such paths are there,how to set max delay for all paths and what happens if two or three clocks present in a design..

 

[TrickyDicky]

I think you need to get more specific. You are a bit vague at the moment.

When creating a design, you should try and avoid asynchronous logic at all costs.
Clock domain crossings should be done safely (with double registers or FIFOs).

 

[kommu4946]

My doubt is that set max delay is defined for all the input and output ports?

 

[TrickyDicky]

I still dont understand - are you trying to set timings for external devices?
set_max_delay is only for internal routes.

 

[kommu4946]

I still dont understand - are you trying to set timings for external devices?
set_max_delay is only for internal routes.

For reg to reg path STA tool calculates clk to q delay and combinational delay (and clock skew) along that path and compare with the clock period if it is less than the clock period,that path meets timing constraints.So in similar way how STA tool analyse remaining 3 paths.You said that it only analyse reg to reg path,unless one set max delay on specified paths that too for only internal routes. I think set_max_delay is for only combinational path.In order to analyse remaining paths which constraints should i use in a design? can i use input delay and output delay?

 

[TrickyDicky]

you can also use set max delay for reg-> reg paths, to force the fitter to put them closer together if those reg have had problems meeting timing in the past.

I dont have a lot of experience with async paths - they are usually avoided. and afaik, STA needs registers as the source and destination, but I may be wrong. Set input delay and output delay are for physical IO pins.

The main question is - why do you have async logic?

 

[ads-ee]

kommun4946,

If you are referring to the asynchronous path being the paths between different clock domains then you would want to false path the routes between unrelated asynchronous clock domains (preferred method in SDC is to declare the clock as asynchronous using set_clock_groups) and you can then also define a maximum path delay between the two clock domains which is something like 2x the period.

If you are referring to asynchronous logic, where you don't use a global clock and are doing the design as a big blob of "stuff" like asynchronous latches and edge triggered logic, then there isn't any reliable method to perform STA.

e.g. The following code would be hard to perform STA on.

always @ (posedge clk) begin
  cnt <= cnt +1;
end
always @ (posedge cnt[3]) begin
  q1 <= ~q1;
end
always @ (posedge q1) begin
  q2 <= ~q2;
end
always @ (posedge q2) begin
  out <= ~out;
end

 

[kommu4946]

The main question is - why do you have async logic?

I am not using async logic in design,but i read many blogs and articles about STA every one says that it is inefficient for async but no reason .

 

[K-J]

I am not using async logic in design,but i read many blogs and articles about STA every one says that it is inefficient for async but no reason .

Timing analysis still needs to be performed for an asynchronous design. At it's core, static timing analysis computes the early/late arrival time of signals and insures that any signal that gets sampled by some other signal arrives at a time that meets setup and hold time requirements. Two ways to perform timing analysis are:
- Static timing analysis
- Monte Carlo analysis

Depending on what your definition of 'efficiency' may be one method might be more efficient than the other. Monte Carlo might be done for ASICs, but as far as I know, it is never done for FPGA designs. Depending on the context of the blogs and articles you're reading (i.e. is it talking about timing in ASICs or something else) you can get different answers.

Perhaps you should read those blogs a bit closer, dig out the context of the article and if you still have questions post them along with the links to the articles. What you've stated so far is too general to answer properly. You've not posted any links to these articles or blogs that you have been basing your opinions on which just leads to the thrashing around that is going on with this thread.

Kevin Jennings

 

[kommu4946]

Hello kevin jennings,
here is the link

http://www.vlsi-expert.com/2011/03/static-timing-analysis-sta-basic-timing.html#.U37BedKSxc0

Under static timing analysis section ,last paragraph..

 

[jason_bill]

hi,i think "static timing analysis is not efficient for asynchronous designs" refer to asynch clock domain no asynch logic. and means that the analyzer don't account the setup and hold time analysis ,Phase relationship,... in its analysis because clocks are not related. it can just extract the delay of combination logic between to reg that work with to asych clock. spatialy as mentiond in ug612 in Period Constraints:
The Period constraint covers paths only between synchronous elements.
The following are not included in this analysis.
• Pads
NGDBuild issues a warning if pad elements are included in the Period time group.
• Analysis between unrelated or asynchronous clock domains

 

[K-J]

Hello kevin jennings,
here is the link

http://www.vlsi-expert.com/2011/03/static-timing-analysis-sta-basic-timing.html#.U37BedKSxc0

Under static timing analysis section ,last paragraph..

Perhaps you should contact the author or post something on that website, the author seems to respond. A couple of points:
- The author's comment regarding efficiency is not substantiated by anything that he wrote.
- The author's description of dynamic timing analysis is not timing analysis at all, it is functional simulation and verification.[1]
- As I had guessed in my earlier post, the author is clearly discussing VLSI design, not FPGA design which would likely exclude most readers in this forum from any direct experience.

Kevin Jennings

[1] On his link about 'Timing Analysis', (http://www.vlsi-expert.com/2011/02/timing-analysis-basis-what-and-why.html) the author states
There are 2 type of Timing Analysis-
Static Timing Analysis: Checks static delay requirements of the circuit without any input or output vectors.
Dynamic Timing Analysis. verifies functionality of the design by applying input vectors and checking for correct output vectors

 

[kommu4946]

- The author's description of dynamic timing analysis is not timing analysis at all, it is functional simulation and verification.[1]
- As I had guessed in my earlier post, the author is clearly discussing VLSI design, not FPGA design which would likely exclude most readers in this forum from any direct experience.

Thanks for your reply.How dynamic timing analysis is different from functional simulation and verification. Can you please suggest a book or material which will explain things clearly STA for fpga design.

Regards

 

[K-J]

Thanks for your reply.How dynamic timing analysis is different from functional simulation and verification. Can you please suggest a book or material which will explain things clearly STA for fpga design.

Regards

Googling for 'dynamic timing analysis' should get you off to a start. Most seem to refer to this as functional simulation using a post fit/route model for the design. One would expect the simulation results using the original design source code and the results using the post route model to be the same. Any differences indicates a problem either with the design or the testbench. Simulation is not really any form of 'analysis' so calling it 'dynamic timing analysis' is misleading. Analysis wouldn't start until one starts to compare the two sim results to try to discover why the post-route failed.

Typical reason why the post-route sim would fail is because either the testbench has problems (like not setting up inputs to occur at a time that violates setup or hold time constraints) or long logic paths that violate clock frequency constraints. There are other error sources, but both of these particular problems (and others) can be found only by performing static timing analysis. In FPGA designs, there is little call for such types of simulation. When designing silicon, the needs would be different because of the much higher cost of having any design issue uncovered after fabrication.

Kevin Jennings

 

[nitin4u7865]

Anyone can let me know,what type of suggestion is provided to PD team by STA engineer after analysis?

 

[mrflibble]

Anyone can let me know,what type of suggestion is provided to PD team by STA engineer after analysis?

I'll have a double espresso with sugar, thanks?

You really have to be more specific with that question...