Re: Multi Cycle path and False paths

There is a short and good example on multi-cycle path. Thanks.

- Ray

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

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.

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.

Of course, two observations:

In the Virtex II its in the

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.

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

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