View Single Post
  #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