State machine outputs and tri-state

[Grumps]

Hi
I'm not a VHDL expert, just learning, so please don't shout.

I'm using Xilinx ISE9.2sp4 and have the following code as part of a state
machine:
CP_IN_OUTPUT_DECODE: process (state_cp_in)
begin
if state_cp_in = sta_idle then
RDY <= 'Z';
BUSY <= '0';
end if;

if state_cp_in = sta_1 then
RDY <= '0';
BUSY <= '0';
end if;

if state_cp_in = sta_2 then
RDY <= '1';
BUSY <= '1';
end if;
....
....etc

The state machine goes from sta_idle, then to sta_1, then to sta_2, etc.
RDY is a pin on the device.
During operation, I can see RDY go low in sta_1, but not high in sta_2. I
know it gets to sta_2 as I can observe BUSY. I don't think RDY is tri-stated
in sta_2 as there is an external pull-up; it just stays low. Gray encoding
is used.

If I change the RDY to rdyi (signal) and then have:
RDY <= 'Z' when state_cp_in = sta_idle else rdyi;
outside of the decode process then it all behaves itself.

Apart from lack of experience, what mistake(s) have I made?
Thanks.

 

[Andy]

Hi
I'm not a VHDL expert, just learning, so please don't shout.

I'm using Xilinx ISE9.2sp4 and have the following code as part of a state
machine:
CP_IN_OUTPUT_DECODE: process (state_cp_in)
begin
if state_cp_in = sta_idle then
RDY <= 'Z';
BUSY <= '0';
end if;

if state_cp_in = sta_1 then
RDY <= '0';
BUSY <= '0';
end if;

if state_cp_in = sta_2 then
RDY <= '1';
BUSY <= '1';
end if;
...
...etc

The state machine goes from sta_idle, then to sta_1, then to sta_2, etc.
RDY is a pin on the device.
During operation, I can see RDY go low in sta_1, but not high in sta_2. I
know it gets to sta_2 as I can observe BUSY. I don't think RDY is tri-stated
in sta_2 as there is an external pull-up; it just stays low. Gray encoding
is used.

If I change the RDY to rdyi (signal) and then have:
RDY <= 'Z' when state_cp_in = sta_idle else rdyi;
outside of the decode process then it all behaves itself.

Apart from lack of experience, what mistake(s) have I made?
Thanks.

For combinatorial processes, the number one mistake I see is that not
all potential execution paths through the process are considered, and
there is some path that results in no assignment to an output. This
results in a latch, which can fool you especially if you are trying to
figure out which state you're in by observing other outputs, which may
be latches themselves.

Try putting a set of default assignments to all of the outputs that
are driven by the process, at the top of the process (right after the
begin), with no conditionals, etc. around them. That way, you know
there will be no latches.

Better yet, try learning to use clocked processes exclusively, and
expressing any combinatorial logic within those clocked processes;
then it is impossible to get a latch. Since your outputs will be
registered in almost all cases* you have to take that clock cycle
delay into account.

*Some synthesis tools allow you to create a combinatorial output from
a clocked process using an expression of variables assigned to a
signal after the clocked if-then clause. The resulting hardware
behavior is cycle-accurate compared to the RTL simulation.

Andy

 

[Grumps]

For combinatorial processes, the number one mistake I see is that not
all potential execution paths through the process are considered, and
there is some path that results in no assignment to an output. This
results in a latch, which can fool you especially if you are trying to
figure out which state you're in by observing other outputs, which may
be latches themselves.

Try putting a set of default assignments to all of the outputs that
are driven by the process, at the top of the process (right after the
begin), with no conditionals, etc. around them. That way, you know
there will be no latches.

Better yet, try learning to use clocked processes exclusively, and
expressing any combinatorial logic within those clocked processes;
then it is impossible to get a latch. Since your outputs will be
registered in almost all cases* you have to take that clock cycle
delay into account.

*Some synthesis tools allow you to create a combinatorial output from
a clocked process using an expression of variables assigned to a
signal after the clocked if-then clause. The resulting hardware
behavior is cycle-accurate compared to the RTL simulation.

Thanks for the comments.
I may go and revisit the design with this knowledge. But, it is now working
simply be taking the tri-states out of the process.