Re: Multi Cycle path and False paths

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.




"LIJO" <> wrote in message
news:bftlvd$iao78$...
> Hi,
> Can anyone tell me what is Multi Cycle path and False path?
>
> thanks
> Lijo
>
>
>
>

Subroto Datta

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

- Ray

In comp.arch.fpga Subroto Datta <> wrote:
> 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.




> "LIJO" <> wrote in message
> news:bftlvd$iao78$...
>> Hi,
>> Can anyone tell me what is Multi Cycle path and False path?
>>
>> thanks
>> Lijo
>>
>>
>>
>>



--

Ray Cheung

"Subroto Datta" <> wrote in message
news:qXuUa.3036$ m...
> 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.

>
>
>
> "LIJO" <> wrote in message
> news:bftlvd$iao78$...
> > Hi,
> > Can anyone tell me what is Multi Cycle path and False path?
> >
> > thanks
> > Lijo
> >
> >
> >
> >
>
>
>

hrwieuyriwru

"hrwieuyriwru" <> wrote in message news:<WyHVa.696$ y.com>...
> "Subroto Datta" <> wrote in message
> news:qXuUa.3036$ m...
> > 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.
>
> >
> >
> >
> > "LIJO" <> wrote in message
> > news:bftlvd$iao78$...
> > > Hi,
> > > Can anyone tell me what is Multi Cycle path and False path?
> > >
> > > thanks
> > > Lijo
> > >
> > >
> > >
> > >
> >
> >
> >

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

Prasanna

Prasanna wrote:
>
> 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


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

rickman

rickman <> wrote in message news:<>...
> Prasanna wrote:
> >
> > 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
>
>
> 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.

Prasanna

In article <>,
rickman <> wrote:

>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.
--
Nicholas C. Weaver

Nicholas C. Weaver

"Nicholas C. Weaver" wrote:
>
> In article <>,
> rickman <> wrote:
>
> >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.

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


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

rickman

rickman wrote:

> 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

Jeff Cunningham

In article <JIPWa.2842$>,
Jeff Cunningham <> wrote:

>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).
--
Nicholas C. Weaver

Nicholas C. Weaver