06-17-2012 03:42 PM
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.
06-17-2012 08:16 PM
06-17-2012 11:30 PM
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
06-18-2012 09:49 AM
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.
06-18-2012 02:13 PM
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)
. . .
0: // Zero - Machine is idling
state <= 1; // Go wait for event 1
1: // Wait1_1 - wait for first event
do something else
. . .
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.