Hmm...maybe I should have posted some code. Basically I want to know when I
synthesize this code:
process(command, currentState)
begin
case currentState is
when IDLE =>
-- Do nothing
if(command = DONOTHING) then
nextState <= IDLE;
-- the command is a read
elsif(command(4) = '1') then
nextState <= R_INITREAD1;
-- the command is a set pixel
elsif(command = SETPIXEL) then
nextState <= W_INITREAD;
-- the command is a write that doesn't need a read
elsif(command(4) = '0') then
nextState <= W_SETUP1;
else
nextState <= IDLE;
end if;
.........
where command is an input port to the entity defined as UNSIGNED(4 downto
0). If all the drivers are writing ZZZZZ to the command line and the
current state is IDLE, what will the nextState signal be?
In simulation, it will fall out the bottom of your if - else chain to
the last else, and nextstate will get the value IDLE.
In synthesis, it will vary depending on how tristates are modelled in
the hardware.
- If the hardware has true tristates, then ZZZZ may be decoded as
garbage, and your state machine could do anything (including entering
illegal states or locking up if you haven't been careful enough to
avoid lock up states).
- If your hardware has "keepers" on the tristate lines, it may retain
the last non-Z value of the command signal.
- If your hardware has weak "pullups" (or pulldowns) on the tristate
lines, it may slowly float through some illegal values (crashing your
state machine) before it settles at all ones or all zeros.
- If your hardware has tristate emulation (e.g. some FPGAs) then the
tristate value may turn into a command of all zeros or all ones.
Note: in none of these cases does the hardware match the simulation
behaviour.
Summary: you really want to avoid testing a value for Z in your code.
I recommend adding an extra bit to indicate when command is valid.
Use this valid bit in your state machine to force the state to IDLE.
(The valid bit will be the logical or of all the enable signals for
the various drivers of the command signal.)
This will ensure that (1) the hardware works, (2) the hardware and
simulation will behave the same way.
Regards,
Allan.