is this multicycle?

reposting sorry

Hi all,

A counter runs on system clock, counting from 0~95 in steps of 1. every 3 counts, registers for two signals are updated (data signal andwrite

signal to ram).

I first assumed both data and write target registers are multicycle but now

have doubts since that implies that fitter may delay data signaldifferently

from write signal though each is multicycle leading to wrongdata being written

into ram.

Any thoughts please?

Thanks

Kaz

--------------------------------------- Posted through

every 3 counts, registers for two signals are updated (data signal and wri te signal to ram). I first assumed both data and write target registers are multicycle but now have doubts since that implies that fitter may delay da ta signal differently from write signal though each is multicycle leading t o wrong data being written into ram. Any thoughts please? Thanks Kaz ------

--------------------------------- Posted through

First, registers are not multi-cylce paths. Paths are multicycle.

We cannot tell from your description whether you intend the paths into the registers might be MC, or whether the path from the registers to the RAM mi ght be MC.

Depending on how the RAM is enabled, the path from the registers to the RAM might be multi-cycle.

It is impossible to know about the paths into the registers. Do ALL the sig nals that drive ANY combinatorial logic that drives the registers (apart fr om the implied clock enable) also only change on the same clock edge, every 3rd clock?

Finally, multi-cycle (and false) path constraints are the most difficult to verify that you specified them correctly, and did not unintentionally rela x the timing constraint on a specific path that is actually NOT MC/F. Verif ying this takes either very expensive analysis tools, or carefully construc ted, extensive simulations (with full timing) at the gate level. STA just a ssumes you specified the constraint correctly.

Andy

wri=

are=

da=

t=

------=

mi=

RAM=

sig=

fr=

every=

to=

rela=

Verif=

construc=

a=

Thanks Andy

The count value itself is used as enable(rather than using explicit clkenable)

My intention was that the path to above two registers is to be multicycled

and I didn't include the paths to ram (though they might be as well). There are no other comb signals entering the scene. The data itself come from its registers that change every 3 clocks. The write is meant to be one clock pulse and is assigned from a wire set to '1'

always.

My concern is that the write signal(one high pulse every three clocks) may

misalign with its data at ram leading to one extra wrong data or duplicate.

Kaz

--------------------------------------- Posted through

On Monday, January 14, 2013 10:19:09 AM UTC-6, kaz wrote:

unter runs on system clock, counting from 0~95 in steps of 1.= > every 3 counts, registers for two signals are updated (data signal and wri= >te s ignal to ram). I first assumed both data and write target registers are=

a= >ta signal differently from write signal though each is multicycle lea ding t= >o wrong data being written into ram. Any thoughts please? Thanks Kaz ------= >--------------------------------- Posted through http://www .FPGARelated.com > >First, registers are not multi-cylce paths. Paths are m ulticycle.=20 > >We cannot tell from your description whether you intend the paths into the = >registers might be MC, or whether the path from the registers to the RAM mi= >ght be MC.=20 > >Depending on how the RAM is enabled, the path from the registers to the RAM= > might be multi-cycle. =20 > >It is impossible to know about the paths into the registers. Do AL L the sig= >nals that drive ANY combinatorial logic that drives the regis ters (apart fr= >om the implied clock enable) also only change on the sam e clock edge, every= > 3rd clock? > >Finally, multi-cycle (and false) pat h constraints are the most difficult to= > verify that you specified them correctly, and did not unintentionally rela= >x the timing constraint on a specific path that is actually NOT MC/F. Verif= >ying this takes eithe r very expensive analysis tools, or carefully construc= >ted, extensive s imulations (with full timing) at the gate level. STA just a= >ssumes you specified the constraint correctly.=20 > >Andy > Thanks Andy The count va lue itself is used as enable(rather than using explicit clkenable) My inten tion was that the path to above two registers is to be multicycled and I di dn't include the paths to ram (though they might be as well). There are no other comb signals entering the scene. The data itself come from its regist ers that change every 3 clocks. The write is meant to be one clock pulse an d is assigned from a wire set to '1' always. My concern is that the write s ignal(one high pulse every three clocks) may misalign with its data at ram leading to one extra wrong data or duplicate. Kaz -------------------------

-------------- Posted through

OK, first, the functionality (whether clock cycles and data align properly is not affected/dictated by a multi-cycle path constraint. The constraint o nly relaxes the normal one-period STA-allowable propagation delay from any register to any other register on the same clock signal.

Whether the clock cycles and data align or not is a function of the RTL, an d should be observable in RTL simulation, and certainly in full-timing gate level simulations. The gate level sims will also, if the correct condition s are simulated, show you whether the RTL plus the final timing and delays will still perform correctly.

From the sounds of it, if (and only if) the data to the registers is provid ed by registers that only update themselves on the SAME clock cycle. It is not enough to say that they both are enabled (only) every three clocks. The y must be enabled (only) at the same time every three clocks. Then you can probably put a multi-cyle path constraint of 3 clock cycles on the data pat h between the registers.

My rule of thumb is to NEVER add a multi-cycle path constraint unless the s ynthesis and/or P&R tool is having problems making the timing, and there ar e no other reasonable alternatives to resolve the problem (pipelining, etc) . The reason is, as I said earlier, these constraints are very hard to veri fy that they are accurately specified.

I used to go ahead and put multi-cycle path constraints in as soon as I was aware of them (e.g. in RTL coding/simulation, before I even tried to synth esize or P&R), so that the P&R tool would not work so hard to meet timing I did not need. Then I got bit a time or two with bad assumptions about the path and data (or changed the logic, and did not update the constraints!), and learned (the hard way) why that was not a good idea.

There could be times when not having a MCP constraint could cause the place r to distort the register placement such that other, single-cycle paths can not be routed and meet timing. I'll run off that bridge when I get there... It hasn't happened yet.

Hope this helps,

Andy

Thanks Andy, it all makes sense.

I set to multicycle of 2 (rather thn 3 for reasons to do with clock cycle of

input register itself) to improve timing which we are struggling with. The design was showing malfunction pointing to that multicycle area. I removed the multicycle (only this change made to build) and it is now outputting correct expected spectrum.

So I have to assume it was wrong multicycle but my own paper analysis indicated

it could be multicycle.

I believe the issue of multicycle must be automated by tools as part of timing

analysis as it is indeed very hard to get right in many cases.

Kaz

--------------------------------------- Posted through

or reasons to do with clock cycle of input register itself) to improve timi ng which we are struggling with. The design was showing malfunction pointin g to that multicycle area. I removed the multicycle (only this change made to build) and it is now outputting correct expected spectrum. So I have to assume it was wrong multicycle but my own paper analysis indicated it could be multicycle. I believe the issue of multicycle must be automated by tool s as part of timing analysis as it is indeed very hard to get right in many cases. Kaz --------------------------------------- Posted through http://w ww.FPGARelated.com

I believe you have hit upon the main reason I avoid MCP constraints. It is too easy to overly broadly specify the paths that are covered by an MCP, wh ich lead to issues that may be difficult to identify and debug. You were lu cky that the effects showed up quickly.

STA is strictly a structural analysis of the results of placing and routing the FPGA. It does not include any knowledge about the functionality of the logic, other than what is a combinatorial primitive, and what is a sequent ial primitive. Therefore, adding identification or verification of MCP cons traints to this process would be very difficult (the necessary information is not available in this process).

There are SW tools that perform analysis or even generation of multi-cycle and false path constraints from the RTL. Blue Pearl Software has one such t ool. I do not know much at all about it. If such capability were to be inte grated into the tool suite, it would likely be into the synthesis process, not the timing analysis process.

Andy

reasons to do with clock cycle of input register itself) to improve timing which we are struggling with. The design was showing malfunction pointing to that multicycle area. I removed the multicycle (only this change made to build) and it is now outputting correct expected spectrum. So I have to assume it was wrong multicycle but my own paper analysis indicated it could be multicycle. I believe the issue of multicycle must be automated by tools as part of timing analysis as it is indeed very hard to get right in many cases. Kaz

--------------------------------------- Posted through

easy to overly broadly specify the paths that are covered by an MCP, which lead to issues that may be difficult to identify and debug. You were lucky that the effects showed up quickly.

the FPGA. It does not include any knowledge about the functionality of the logic, other than what is a combinatorial primitive, and what is a sequential primitive. Therefore, adding identification or verification of MCP constraints to this process would be very difficult (the necessary information is not available in this process).

false path constraints from the RTL. Blue Pearl Software has one such tool. I do not know much at all about it. If such capability were to be integrated into the tool suite, it would likely be into the synthesis process, not the timing analysis process.

Tools that automatically create multicycle constraints are not inexpensive!

I generally only use milticycle constraints on registers that are clearly coded to use a periodic clock enable. Even then, using the clock enable itself as a selector for the timing group can bite you if you have also used the clock enable as a feedback to itself like:

if rising_edge(clock) then clock_enable

Agreed on the cost of those tools... Tools like that have to be leveraged across larger design teams.

Clock enable signals are almost NEVER multicycle themselves, regardless of how they were generated (feedback or not). They still have to propagate (on and off) from their source register to every enabled register in only one clock.

And wildcards are just begging to include paths you did not intend to include. When done accurately, they work great. The problem is verifying they were done accurately. And just because a path is multi- cycle constrained, does not mean it WILL take multiple clocks to propagate in the final P&R results, making it impossible to know whether it could have been multi-cycle and still worked. You'll never know until some design/tool change suddenly lengthens the propagation to longer than one clock, and boom!

It is relatively easy to add assert statements in the RTL such that you can detect if the signal ever changes more recently than your assumed MCP constraint, even in RTL simulation. The problem is making sure the constrained paths are the same ones checked by the the assertion!

Andy

I find multicycle constraints to be a very simple issue. As was explained, it is the paths that are constrained, not the registers. So think in terms of the paths.

You have multicycle paths ending at some registers. These paths need to be constrained with the correct time values. The register enables (or write enables in your case) are still single clock cycle paths. So you need to make sure the enables are constrained with the single clock period. If you apply the longer, multicycle constraint to the enable paths, you may well end up with misaligned enables and data because of excessive path delays. That is all there is to "multicycle" timing constraints.

But of course the devil is in the details.

I don't know what tools you are using and I'm not familiar with every tool family, so I likely couldn't give you detailed info on just how to apply timing constraints in your case.

What was said about the tools not being too smart about verifying timing constraints is, in my opinion, a major shortcoming of the tools. We have powerful tools to verify our logic and our timing... but not the timing constraints which drive the timing analysis. Everything about engineering is verification. So I find it odd that you can't verify your timing constraints in any useful way.

If you are concerned that your timing constraints are working correctly, you can run a post-route simulation which will include timing. This can help, but likely won't catch all potential issues.

Rick