Re: Multi Cycle path and False paths

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Multicycle paths are paths between registers that intentionally take more
than one clock cycle to become stable. For example a register may need to
trigger a signal every second or third rising clock edge.

A False path is any path that is not relevant to a circuit's operation.

A good description of both multicycle and false paths can be found in the
following Timing Analysis App Note:

http://www.altera.com/literature/an/an123.pdf

Subroto Datta
Altera Corp.




Quoted text here. Click to load it



Re: Multi Cycle path and False paths
There is a short and good example on multi-cycle path. Thanks.
http://www.saros.co.uk/hdlsolutions/appsnotes/leonardo/SAN001.pdf

- Ray

Quoted text here. Click to load it











--

Re: Multi Cycle path and False paths

Quoted text here. Click to load it

From a conceptual standpoint, these definitions are mostly correct.
But be aware that different CAD-tool vendors (Synopsys, Cadence,
etc.) may treat the *operational* meanings of false-path differently..

In Synopsys's case, their application manuals have clear
examples when to use 'set_disable_timing' versus 'set_false_path.'
The problem with set_false_path is that it can (unintentionally)
affect more than just timing-constraints.

Quoted text here. Click to load it



Re: Multi Cycle path and False paths
Quoted text here. Click to load it

Here are some examples I can think of.

Lets say you have a mode bit that you use in your logic and you know
some paths specifically do not exist when the core is not in that
mode, that becomes a false path.

Lets say, you do a complex logic such as a CRC and find that your
final CRC evaluation takes more than one clock cycle (based on byte
enables) and cannot meet the speed requirements. You can pipeline the
data and calculate final CRC in multiple clock cycles.

Open to learn more :-)

Re: Multi Cycle path and False paths
Quoted text here. Click to load it

This is exactly what multicycle is not.  If you allowed the CRC
calculation to have two or three clock cycles for the logic delays to
settle out and used an enable on the register at the end, that would be
a multicycle path.  This requires a separate multicycle timing spec
since otherwise the tool will try to optimize this to get it to run in
one clock cycle.  If you add pipeline registers, then each stage will
need to be done in a single clock cycle and will definitely *not* be
multicycle.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Multi Cycle path and False paths
Quoted text here. Click to load it

I guess you know what I meant on multicycle path on calculating final
CRC. I was not mainly addressing the issue how to use pipeline here. I
used the word pipeline there to address the issue of what do you do
with the incoming data when the logic is taking multiple clock cycles
to complete a job. I think designers do understand how to keep data
stable for more clocks with enables.

Guess I focussed my point this time on multicycle path.

Re: Multi Cycle path and False paths

Quoted text here. Click to load it

Of course, two observations:  

1) Flip-flop setup and clk->Q combined are pretty low compared to
interconnect costs.  EG, from the Spartan II datasheet, the additional
time if the flip-flop is the LUT output is ~2 ns.  So even if your
design is running at 100 MHz in one of these parts, only 20% of your
time is going to the flops.

In the Virtex II its in the <1 ns range on the slowest speedgrade.


2) Retiming can place those registers in the right place.  You can
either do the transformation by hand or use a tool, but I'm not sure
how well Synplify will handle retiming through preplaced blocks, and
the attempt to maintain initial conditions really hurts the power of
this transformation.

Nonetheless, it is possible, and NOT hard (given a timing model), to
move all the registers manually into the right place, given the
algorithm to solve the problem.  If a block is feed forward, and you
just want to repipeline the block, the task is easier.
--
Nicholas C. Weaver                                 snipped-for-privacy@cs.berkeley.edu

Re: Multi Cycle path and False paths
Quoted text here. Click to load it

The point is, why bother spending the effort to do something that is
going to *slow* down the design and possibly break it?  As in the
example I gave, we found it was not worth the effort in our design to
even consider adding the registers.  Besides, they are not anything
remotely like free in a design that has a high utilization.  

I guess you just don't like multi-cycle constraints.  But I find they
are quite easy to use if used correctly.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Multi Cycle path and False paths

Quoted text here. Click to load it

This mirrors my experience. In a recent FPGA design, I had to multiply
two signed 24 bit numbers. It seemed easier to implement it as a
multicycle path than to break it up by hand into pipelined stages.

Now if there is some tool that will insert the pipelining automatically
that is easy to use and doesn't cost $20K/seat I would like to hear
about it, because it is a small hassle to set up the multicycle timing
constraints.

JCC



Re: Multi Cycle path and False paths

Quoted text here. Click to load it

Altera's standard flow includes retiming, so if you turn it on and
place the registers at the start, they get moved forward into the
design.

Likewise, Synplify does this as well, and the Xilinx only version I
thought was 7K each.

The only (and moderate/significant) gotcha is that both tools
preserve initial condition/global set-reset semantics, which limits
the benefits which retiming achieves.  For a large design (eg, a uP
core) this can be a significant limitation, but it may be OK for a
single smaller module.




Also, if you do have to do this by hand for some design piece (after
all, the result IS a pipelined, higher throughput design), the
retiming algorithm itself is not that bad, and can be simplified: as
you don't have to get an exact solution to the all-pairs shortest-path
problem, but just want to insure the correctness constraints (the
number of registers on each path are unchanged).
--
Nicholas C. Weaver                                 snipped-for-privacy@cs.berkeley.edu

Site Timeline