FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > Verilog

Verilog comp.lang.verilog newsgroup / usenet

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 05-04-2005, 03:22 AM
Chloe
Guest
 
Posts: n/a
Default Stating Timing Analysis - Timing-Critical Paths & False Paths

Hello everyone,

This was written by Mark Johnson on Oct 17 1992, and for some reason, I
could not reply to the post (perhaps it's too old). Anyway, here is
what he wrote regarding false paths in static timing analysis:

-------------------------------------

IN THE DOMAIN OF STATIC TIMING ANALYSIS (if you don't know
what static timing analysis is, ignore the remainder of
this paragraph), "false path" means a path through the
logic/circuit that does exist, but which is known by
the human designer to NOT be a timing-critical path.
For example, asynchronous clear/reset paths. The static
timing analyzer reports them to the human, and the human
judges them to be "false", i.e. these paths are not
speed critical. Usually the human then puts them into
a list of "dont-annoy-me-any-more" paths, the
"known-false-paths" list, and thereafter the timing
analyzer refrains from reporting them.

--------------------------------------

My question is: what do you define as TIMING-CRITICAL paths? Any useful
examples given would be appreciated.

The idea of defining false paths is to avoid the synthesis tool from
deriving unnecessary logic, I/O replication, and/or false timing
constraint failure report. Are these false paths derived using the STA
tool first, isolated in the false paths list, and then the tool rerun
for further STA? How does the designer determine what the false paths
are before STA?

Please forgive the triviality of the questions as I am very new at
this.

Thanks very much in advance.

Kind regards,
Chloe

Reply With Quote
  #2 (permalink)  
Old 05-04-2005, 07:35 AM
Neo
Guest
 
Posts: n/a
Default Re: Stating Timing Analysis - Timing-Critical Paths & False Paths

every clock domain crossing is a false path, hence it is determined by
the designers prior to synthesis to avoid the synthesis tool from
taking those regions into consideration for optimization. STA might
also reveal some false paths missed upfront during synthesis.

Reply With Quote
  #3 (permalink)  
Old 05-04-2005, 01:43 PM
Hans
Guest
 
Posts: n/a
Default Re: Stating Timing Analysis - Timing-Critical Paths & False Paths

"Chloe" <[email protected]> wrote in message
news:[email protected] oups.com...
> Hello everyone,

snip
>
> My question is: what do you define as TIMING-CRITICAL paths? Any useful
> examples given would be appreciated.
>
> The idea of defining false paths is to avoid the synthesis tool from
> deriving unnecessary logic, I/O replication, and/or false timing
> constraint failure report. Are these false paths derived using the STA
> tool first, isolated in the false paths list, and then the tool rerun
> for further STA? How does the designer determine what the false paths
> are before STA?


Hi Chloe,

Timing critical path are those path that do not meet your timing. What
normally happens is that after synthesis the tool will give you a number of
path which have a negative slag. The first thing you would do is to make
sure those path are not false or multicycle since it that case you can just
ignore them. This can be quite a lengthy and difficult task but there are
now tools coming to market which can detect these path automatically,
Fishtail automation and BluePearl are 2 companies that springs to mind.

Hans.
www.ht-lab.com

> Please forgive the triviality of the questions as I am very new at
> this.
>
> Thanks very much in advance.
>
> Kind regards,
> Chloe
>



Reply With Quote
  #4 (permalink)  
Old 05-04-2005, 06:41 PM
Avrum
Guest
 
Posts: n/a
Default Re: Static Timing Analysis - Timing-Critical Paths & False Paths

First, let me say that you must be VERY careful when declaring a path false.
Also, the description below is somewhat dangerous...

The statement below talks about a path being "timing critical". It is very
important to be clear (and I would stay away from this term, since it is too
close to sounding like a "critical path").

Static timing analysis (as the name implies) analyzes the circuit from a
"static" point of view; it is not a simulator, and it does not know (or
care) how circuits operate. Static timing analysis (or STA) analyzes every
timing path in a circuit, and compares it against a set of timing
constraints. By definition a static timing path starts at a timing
startpoint, and ends at a timing endpoint. A startpoint can be
- a primary input to the circuit
- the "CLK" input of a flip flop (propagating out through the Q/Q_ output)
- the gate input of a latch
- an artificially created startpoint using a synthesis constraint

an endpoint can be
- the input to a flip-flop or latch other than the CLK or gate
- a primary output of a circuit
- an artificially created endpoint

The STA tool analyzes ALL paths from each and every startpoint to each and
every endpoint and compares it against the constraint that (should) exist
for that path. All paths should be constrained, and are usually given
constraints by a number of basic constraints for the circuit; most paths are
constrained by the definition of the period of the clock, and the timing
characteristics of the primary inputs and outputs of the circuit.

Taking a typical example, the STA tool will add the delay contributed from
all the logic connecting the Q output of one flop to the D input of the next
(including the CLK->Q of the first flop), and then compare it against the
defined clock period of the CLK pins (assuming both flops are on the same
clock, and taking into account the setup time of the second flop and the
clock skew). This should be strictly less than the clock period defined for
that clock. If the delay is less than the clock period, then the "path meets
timing". If it is greater, than the "path fails timing". The "critical path"
is the path out of all the possible paths that either exceeds its constraint
by the largest amount, or, if all paths pass, then the one that comes
closest to failing.

Again, STA looks at all paths, regardless of the functionality of the
circuit. It also may have multiple constraints on a path; for example it may
have a "setup" constraint (as described above, the propagation path is less
than one clock), and also have a "hold" constraint (the path must be longer
than the hold requirement of the second flop, taking into account all clock
skew).

However, not all paths that exist in a circuit are "real" timing paths. For
example, let us assume that one of the primary inputs to the chip is a
configuration input; on the board it must be tied either to VCC or to GND.
Since this pin can never change, there are never any timing events on that
signal. As a result, all STA paths that start at this particular startpoint
are false. The STA tool (and the synthesis tool) cannot know that this pin
is going to be tied off, so it needs to be told that these STA paths are
false, which the designer can do by telling the tool using a "false_path"
directive. When told that the paths are false, the STA tool will not analyze
it (and hence will not compare it to a constraint, so this path can not
fail), nor will a synthesis tool do any optimizations on that particular
path to make it faster; synthesis tools try and improve paths until they
"meet timing" - since the path is false, the synthesis tool has no work to
do on this path.

Thus, a path should be declared false if the designer KNOWS that the path in
question is not a real timing path, even though it looks like one to the STA
tool. One must be very careful with declaring a path false. If you declare a
path false, and there is ANY situation where it is actually a real path,
then you have created the potential for a circuit to fail, and for the most
part, you will not catch the error until the chip is on a board, and (not)
working. Typically, false paths exists
- from configuration inputs like the one described above
- from "test" inputs; inputs that are only used in the testing of the chip,
and are tied off in normal mode (however, there may still be some static
timing constraints for the test mode of the chip)
- from asynchronous inputs to the chip (and you must have some form of
synchronizing circuit on this input)
(this is not an exhuastive list, but covers the majority of legitimate false
paths).

In answer to the original question, false paths should NOT be derived from
running the STA tool (or synthesis tool); they should be known by the
desinger as part of the definition of the circuit, and constrained
accordingly at the time of initial synthesis.

Also, just as a clarification, "asynchronous clear/reset paths" are NOT
normally false (as the initial statement says). While the ASSERTION of the
preset/clear input of a flip flop can occur at any time, the deasserting
edge of the preset/clear must (normally) be treated as a normal (i.e. not
"false") timing path. Most flops have what is called a "recovery" timing
constraint from the preset/clear input to the clock; the deasserting edge of
the preset/clear must not come too close to the active edge of the clock. If
it does, the flop does not know if it is supposed to continue to behave as a
flop in preset/clear (i.e. take the reset value), or operate as a normal
flop (i.e. take the value on the "D" input), and may do either (or neither,
or become meta-stable). Furthermore, when you have a state machine that has
multiple flops in it, it is important that all flops "emerge" from reset,
cleanly, and on the same clock cycle. Failing to do this can lead to nasty
surprises (i.e. chips that are not guaranteed to function correctly when you
deassert reset).

Avrum


"Chloe" <[email protected]> wrote in message
news:[email protected] oups.com...
> Hello everyone,
>
> This was written by Mark Johnson on Oct 17 1992, and for some reason, I
> could not reply to the post (perhaps it's too old). Anyway, here is
> what he wrote regarding false paths in static timing analysis:
>
> -------------------------------------
>
> IN THE DOMAIN OF STATIC TIMING ANALYSIS (if you don't know
> what static timing analysis is, ignore the remainder of
> this paragraph), "false path" means a path through the
> logic/circuit that does exist, but which is known by
> the human designer to NOT be a timing-critical path.
> For example, asynchronous clear/reset paths. The static
> timing analyzer reports them to the human, and the human
> judges them to be "false", i.e. these paths are not
> speed critical. Usually the human then puts them into
> a list of "dont-annoy-me-any-more" paths, the
> "known-false-paths" list, and thereafter the timing
> analyzer refrains from reporting them.
>
> --------------------------------------
>
> My question is: what do you define as TIMING-CRITICAL paths? Any useful
> examples given would be appreciated.
>
> The idea of defining false paths is to avoid the synthesis tool from
> deriving unnecessary logic, I/O replication, and/or false timing
> constraint failure report. Are these false paths derived using the STA
> tool first, isolated in the false paths list, and then the tool rerun
> for further STA? How does the designer determine what the false paths
> are before STA?
>
> Please forgive the triviality of the questions as I am very new at
> this.
>
> Thanks very much in advance.
>
> Kind regards,
> Chloe
>



Reply With Quote
  #5 (permalink)  
Old 05-06-2005, 01:56 AM
Chloe
Guest
 
Posts: n/a
Default Re: Static Timing Analysis - Timing-Critical Paths & False Paths

To everyone who replied my post:

Thanks very much for all the much-needed information, especially to
Avrum, who explained false path to me very well.

What about multiple cycle paths? What are the "conventional" examples
of these paths?

Thanks very much in advance.

Regards,
Chloe

Reply With Quote
  #6 (permalink)  
Old 05-09-2005, 07:13 PM
Avrum
Guest
 
Posts: n/a
Default Re: Static Timing Analysis - Timing-Critical Paths & False Paths

A multi-cycle path is a path that is allowed multiple clock cycles for
propagation. Again, it is a path that starts at a timing startpoint and ends
at a timing endpoint. However, for a multi-cycle path, the normal constraint
on this path is overridden to allow for the propagation to take multiple
clocks.

In the simplest example, the startpoint and endpoint are flops clocked by
the same clock. The normal constraint is therefore applied by the definition
of the clock; the sum of all delays from the CLK arrival at the first flop
to the arrival at the D of the second clock should take no more than 1 clock
period minus the setup time of the second flop and adjusted for clock skew.
By defining the path as a multicycle path you can tell the synthesis or STA
tool that the path has N clock cycles to propagate; so the timing check
becomes "the propagation must be less than N x clock_period, minus the setup
time and clock skew". N can be any number greater than 1.

One place where you might see a multi-cycle path (MCP) is when you have a
"complex" combinational path, but it is only needed to create an output
every second clock (often an arithmatic operation). If coded correctly...

always @(posedge clk)
begin
if (every_other_clock)
begin
in <= new_inputs;
out <= complex_function(inputs);
end
end

where the signal every_other_clock is high every second clock, then the
paths from in -> out can be defined as a multicycle paths. Again, the
synthesis/STA cannot infer the MCP property, it is up to the user to define
the constraint using a multi_cycle_path directive during synthesis/STA.

Another place where you might see it is when you are doing clock crossing
from two closely related clocks; i.e. from a 30MHz clock to a 60MHz clock,
assuming the two clocks are from the same clock source (i.e. one is the
divided clock of the other), and the two clocks are in phase. The normal
constraint in this case is from the rising edge of the 30MHz clock to the
nearest edge of the 60MHz clock, which is 16ns later. However, if you have a
signal in the 60MHz domain that indicates the phase of the 30MHz clock, you
can design a circuit that allows for the full 33ns for the clock crossing

always @(posedge clk)
begin
if (30MHZ_is_low)
flop60 <= flop30;
end

then the path from flop30 -> to flop60 is a MCP (again with N=2). The
generation of the signal 30MHZ_is_low is not trivial, since it must come
from a flop which is clocked by the 60MHz clock, but show the phase of the
30MHz clock...

Another place would be when you have different parts of the design that run
at different, but related frequencies. Again, consider a circuit that has
some stuff running at 60MHz and some running on a divided clock at 30MHz.
Instead of actually defining 2 clocks, you can use only the faster clock,
and have a clock enable that prevents the clocks in the slower domain from
updating every other clock

always @(posedge clk60)
begin
if (enable_30)
begin
[operations on the flops in the "30MHz domain"]
end
end

then all the paths from the "30MHz" flops to the "30MHz" flops can be MCP.
This is often done since it is usually a good idea to keep the number of
different clock domains to a minimum.

Another place would be when dealing with a bus protocol that has an inherent
MCP in it. For example, if you have a bus protocol where (say) the address
shows up on the clock before the write data and stays valid for both clock
cycles, then you could declare the address an MCP to the destination flops.
Assuming write_strobe is only asserted during the second of the two phases
and the code reads

always @(posedge clk)
begin
if (write_strobe && (address == MY_ADDRESS))
my_data <= data_in;
end

where MY_ADDRESS is the address (a constant) for the register that is stored
in the flops my_data, then there is a MCP from address -> my_data. Note: in
all these cases, there are also paths that are NOT MCPs; in this example,
the paths from write_strobe->my_data, and the paths from data_in to my_data
are NOT muti-cycle - they are regular single cycle paths.

Again, this is not exhaustive, but gives some examples of MCPs.

Also, it should be pointed out that MCPs should be avoided where possible,
since they are easy to get wrong, and can often be coded around... In the
first case, one would normally attempt to pipeline the long arithmatic
operation rather than use MCPs. In the second case, the clock crossing
should probably be attempted in the 16ns, rather than allow the full 33MHz -
just because you CAN take 33ns, doesn't mean that you NEED 33ns. In the
third case, the same argument applies; if the technology is fast enough and
the logic simple enough, don't declare the paths as MCP - this will
overconstrain the paths, but if that doesn't cause too much area growth (or
difficulty during synthesis), then let it be. The same is true of the last
case - if you can easily meet timing without defining the MCP, then it is
probably safer not to do so...

Avrum

"Chloe" <[email protected]> wrote in message
news:[email protected] oups.com...
> To everyone who replied my post:
>
> Thanks very much for all the much-needed information, especially to
> Avrum, who explained false path to me very well.
>
> What about multiple cycle paths? What are the "conventional" examples
> of these paths?
>
> Thanks very much in advance.
>
> Regards,
> Chloe
>



Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Timing doubt... Element Blue Verilog 2 11-25-2004 10:26 AM
All Paths in RTL Module HDLDesigner Verilog 6 02-25-2004 11:02 AM
How to include paths to Header Files in NC-Sim/NC-Verilog Rajat Mitra Verilog 1 02-09-2004 11:52 AM
Backslashes in signal paths John Kolb Verilog 1 09-16-2003 10:42 PM
Re: Multi Cycle path and False paths Subroto Datta Verilog 9 08-02-2003 06:44 PM


All times are GMT +1. The time now is 07:55 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved