Re: Multi Cycle path and False paths

[Subroto Datta]

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.

 

[Ray Cheung]

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

- Ray

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:

Subroto Datta
Altera Corp.

--

 

[hrwieuyriwru]

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.

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.

 

[Prasanna]

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.

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

 

[rickman]

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.

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

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Prasanna]

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

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

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.

 

[Nicholas C. Weaver]

Not always true. Anytime you add a register, you have to add setup time
and output delay to your path. Plus your path must be broken
arbitrarily and it is not simple to pick the optimal points. By not
adding registers and using an enable on the one register, you allow the
full N clock cycles for the logic to settle. This was exactly how we
designed an ATM chip. Once the cell had been received we had three
clocks to analyze it and decide what to do with it. Turns out we needed
all three as a multicycle. If we had pipelined it we would not have met
the timing budget.

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.

 

[rickman]

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.

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

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Jeff Cunningham]

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.

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

 

[Nicholas C. Weaver]

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.

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).