cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
3,425 Views
Registered: ‎05-30-2012

Why are FSM states given values?

Hi, this must be a painfully stupid question, but I was going through the FSM chapter and in all examples the localparameters are given values and names.. such as

 

localparam  [2:O] 
zero  =  3'b000, 
waitl_1  =  3'b001, 
waitl_2  =  3'b010, 
waitl_3  =  3'b011, 
one  =  3'b100, 
waito_1  =  3'b101, 
wait0_2  =  3'b110, 
wait0_3  =  3'b111;

 

now why are these states given values, as later in code we are going to use the names anyway?.

 

these values are not used anywhere in any code or in any example I see, but everywhere these states must have some binary value.

 

Thank you

0 Kudos
4 Replies
Highlighted
Visitor
Visitor
3,421 Views
Registered: ‎05-30-2012

Re: Why are FSM states given values?

update:

ok I found out that if I dont give it a value it will come up as an error. still doesnt help explain why I should give it values.
0 Kudos
Highlighted
Teacher
Teacher
3,416 Views
Registered: ‎08-14-2007

Re: Why are FSM states given values?

Hi,

this may be an issue of  verilog.

Even when you look at the examples in the ISE Language Templates you willl find this.

 

You don't need to define the state encoding of your FSM if written in VHDL. There enumeration types are used and the synthesis tool will do the state encoding automatically. This should ensure the most optimal state encoding depending on the synthesis goals.

Of course you can constrain this, e.g. by choosing a specific state encoding scheme in the synthesis properties.

 

There are rare cases where the designer wants to define a very specific state encoding

e.g.  to make sure that every implementation has the same state encoding indepentent of the tool and target technology.

 

Have a nice synthesis

  Eilert

 

 

0 Kudos
Highlighted
Historian
Historian
3,402 Views
Registered: ‎02-25-2008

Re: Why are FSM states given values?


@farazk86 wrote:
update:

ok I found out that if I dont give it a value it will come up as an error. still doesnt help explain why I should give it values.

Because Verilog, being an untyped language, does not support enumerations (unlike smarter languages, such as VHDL). This is a significant limitation in the language, IMNSHFO.

 

So you need to define a constant for each state if you wish to use a meaningful value in the case statement.

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Professor
Professor
3,393 Views
Registered: ‎08-14-2007

Re: Why are FSM states given values?

Yes, enumerated types would be nice.  Maybe System Verilog will solve this issue.  In the meantime

I tend to write state machines with numbers in the case statements followed by a comment indicating

the "name" of the state.  Using a parameter or macro to define a state name doesn't make

the state name show up in simulation, anyway.  Having the state number close to the code makes

it easier for me to debug.  So in your case I might have coded:

 

always @ (posedge clk or posedge rst)

 . . .

  case (state)

    0:  // Zero - Machine is idling

      begin

        do something

        state <= 1;  // Go wait for event 1

      end

    1:  // Wait1_1 - wait for first event

      begin

        do something else

      end

  . . .

    endcase

 

Note that I did not size the states to the size of the state variable.  In Verilog, there's

no need to, and it makes it easier to read as well as easier to add more states when

your state variable needs to grow from 3 to 4 bits.  I also don't generally count in binary

so I use decimal numbers for state declarations as well.  Your state assignments

use a syntax that looks like it was directly translated from VHDL.  There is no need

to use binary just because you're assigning a value to a 3 bit number in Verilog.

 

3'b010 is the same as 3'b10 is the same as 3'h2 is the same as 3'd2 is almost

the same as 2 (2 is implicitly sized to 32 bits, but you will get the 3 LSB's in your

3 bit vector as required by the Verilog LRM).

 

Note that XST wil almost always change your state encoding to something other than

the numbers you entered.  The exception is if you specificlly set the FSM encoding to

"USER" in the XST properties, or in your source code for a particular FSM.  Because of

this, unless you require user encoding, the numbers you pick have no effect on the

ability of XST to optimize the state machine.

 

-- Gabor

 

 

-- Gabor
0 Kudos