I have a following state machine. enable is an input comiing from a accumulate core. Now the total number of inputs to be accumulated varies but is always greater than 5.so the maximum frequency of enable becoming high is every 5th cycle or more. I just want to find out if I have to provide a constraint on enable so that the synthesis tool understands that the enable1 doesnt become high every clock cycle and that the state machine wont miss any enable='1' input coming in and the desing would funtion properly ? or is it that synthesis and post sysnthesis tools dont care about this at all?
process(clock,reset) begin if reset = '1' then state1
You don't need to provide a special constraint on 'enable'. It's a synchronous signal like any other, and the general clock-period constraint is probably all you need.
However, if you're going for a very fast clock you may wish to take advantage of the fact that 'enable' is infrequent. The logic associated with the 'enable' signal itself looks pretty simple, and should be left with the standard clock constraint. But what about "numout"? If that result signal is at the end of a long combinational path, you may wish to apply a multi-cycle path constraint to it - probably not 5 clocks, but perhaps 2 or 3 depending on the logic that creates it. The question you must ask is: How many clock cycles do I have between the clock that causes a source register taking up its final settled value, and the clock that causes the result to be captured in another register? That's not obvious from your state machine, because it depends on the nature of the pipelining in the logic that creates "numout".
Personally I very much dislike using multi-cycle constraints because they're hard to get right, and even harder to maintain correctly as the design changes. If you can avoid it, so much the better. But if you must, take a really close look at your synthesis tool's documentation on multi-cycle constraints. Some of the FPGA tools can automatically infer multi-cycle constraints in some simple cases, but I'd guess that your logic is too involved for that to work. There are (high-cost) tools based on formal technology that can automatically generate multi-cycle constraints in a very sophisticated way; FishTail and BluePearl are worth a look.
If you're going to use multi-cycle constraints, be sure to apply them *before* synthesis so that they affect both synthesis and P&R. If you leave it until after synthesis, not only will it be unreasonably hard to locate all the paths that need constraining, but also the synth tool will have made inappropriate decisions about optimization.
Synthesis is pretty clever with this and I wouldn't expect that any constraint other than Fmax is needed. If I can't make Fmax, I much prefer pipelining or ready/ack strobes to oddball timing constraints.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.