multicycle path

--- Quote Start ---

What is a multicycle path?Can someone explain with a clear example.

--- Quote End ---

Hi,

with a multicycle path you describe a path where you have more than one clock cycle time for your signals to propagte through the logic between two registers.

Simple expample:

Assume you have two registers stages. Between the registers you have a multiplier.

The registers behind the multiplier is not only controlled by the clock, it also gets an enable signal which enables the register only every second clock. Without a multicycle constraint the timing analysis treat the path as normal register to register path. Maybe your multiplier logic needs more than one clock cycle and you will get a timing violation.

With the enable signal you have two clock cycles time for the calculation, but you have to specify the path as multicycle path for timing analysis.

Kind regards

GPK

A further note:

It is to do with timing window violation. If a register is clocked at every clk edge (without having enable) then timing has to be correct at every edge.

But if you have registers though clked at every edge but with known enable signal then it becomes possible to exclude from timing those not-enabled clk edges as timing violation there is irrelevant. This translates to treating that register as having 1/2 clk rate or 1/4 depending on multicycle settings.

The problem is how to know which register, that is the job of the tool and designer. Applying the multicycle constraint directly on a regular enable signal is easiest for the tool. Applying it elsewhere(on registers) can lead to chaos and is like playing with fire.

What mystifies me is that why tools can't just do that automatically, after all they see the enable pattern of registers? or don't they?

Kaz, good descritption, as clock enables are a good case for multicycles(I believe there's an example on the web on assigning MCs based on the clock enable). At a higher level, this scenario is when your design has a faster clock rate(say 200MHz), but some of the logic runs at only 100MHz. You can still drive that slower logic with the 200MHz clock and just enable every other clock cycle, effectively giving you 100MHz whose data can easily be transferred to/from the 200MHz since their driven by the same clock and have the same skew. The multicycles allows you to tell timing analysis to not time paths within the slower domain to 5ns but instead 10ns.

Another example is if the data rate is slower. It may even be off-chip, i.e. your data is coming in from a slow source and so you only get a new word every 4 clock cycles, or something like that. There are lots of other cases.

Tools could find most MCs, I believe. Fishtail is the one I've heard of, although I don't think it's main intention is for the clock enable scenario. That one should be pretty apparent that you've designed MC paths and you can add them in. Fishtail tends to find MC paths throughout your design that you didn't even realize were MCs.

And we're talking about a narrow set of MCs. They are ones that "expand the window" that your data transfers in. MCs really just change the edges of your clock used for setup and hold analysis. Another common case is shifting the window. For example, you have a 10ns clock feeding another 10ns clock that has a phase-shift of 500ps(let's say you did this phase-shift to help with I/O timing). The default setup relationship will be 500ps and the hold relationship will be -9.5ns. That means your data delay needs to be faster than 500ps, which is unlikely. In TimeQuest, if you add a MC -setup 2 -from clk10ns -to clk10n_phaseshifted, then you shift the window of analysis over by one cycle, so your setup relationship is 10.5ns and the hold relationship is 0.5ns. (It's not hard to visualize, but if you draw out the two waveforms it should make complete sense). In this case it's not a MC that is based on the logical behavior, but on the clocking relationship.

Those two cases cover 99% of all MCs.

Thanks Rysc for the examples, I am trying to digest them.

One other thing that confuses beginners is that while the concept of multicycle is built around the idea of enabled register, however the multicycle constraint itself applies to a path between two registers !

The aim of constraining path is to get timing of destination register under control. if the source register and destination register are both on same enable then the rule applies to the path in between.

If an enabled register sources a differently-enabled or non-enabled register then the path should not be included as multicycle.

Note that multicycles are not build around enabled registers. That is a common example, but by no means the only one. If you do use the enable, then the [get_fanouts...] is a good way to build multicycles off the enable:

http://www.altera.com/support/examples/timequest/exm-tq-clock-enable.html?gsa_pos=1&wt.oss_r=1&wt.oss=get_fanouts

And note that there are multiple ways to use this. For example:

set_multicycle_path -setup 2 -to [get_fanouts [get_pins enable_reg|q]]

set_multicycle_path -hold 1 -to [get_fanouts [get_pins enable_reg|q]]

This grabs all registers driven by that enable register and makes MCs to all of them, even if they come from full-rate registers. This is pretty common, where the transfer from the full-rate domain to the half-rate domain has data running at half-rate, so technically it's a MC.

Or you could just do it within the group. Using a variable:

set mc_group [get_fanouts [get_pins enable_reg|q]]

set_multicycle_path -setup 2 -from $mc_group -to $mc_group

set_multicycle_path -hold 1 -from $mc_group -to $mc_group

This only adds the MC if both source and destination registers are driven by the enable. There are other options, and they're all design dependent.

One thing with what I just wrote is that it also puts a MC on the enable register(the feedback path where the enable register feeds back on itself), which actually must meet the full-rate timing. Technically this will never fail timing since the fitter will always use a quick route(even when there's plenty of timing margin, the router tries to route things as quickly as possible to free up resources for other stuff). But if you wanted to, you could set this path back to the full-rate:

set_multicycle_path -setup 1 -from enable_reg -to enable_reg

set_multicycle_path -hold 0 -from enable_reg -to enable_reg

My example of the clock phase-shift would be -from [get_clocks clkA] -to [get_clocks clkB], i.e. between clock domains instead of between registers. In a case where the data is stable for multiple cycles, then the MC is between registers, as there is no control.