View Single Post
  #2 (permalink)  
Old 11-24-2007, 11:15 AM
Jonathan Bromley
Guest
 
Posts: n/a
Default Re: vhdl state machine

On Fri, 23 Nov 2007 23:00:52 -0800 (PST), [email protected] wrote:

>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?


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.

>process(clock,reset)
> begin
> if reset = '1' then
> state1 <= IDLE;
> .....................
> elsif clock'event and clock = '1' then
>
> case state1 is
> when IDLE1 =>
> if enable= '1' then
> state1 <= M1 ;
> end if;
>
> when M1 =>
> TD <= numout;
> state1 <= M3;

[...]
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
[email protected]
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Reply With Quote