VHDL Simulation Error on Outputs
I'm trying to do a handshake protocol for 2 modules in quartus II. First I used a simple IF-ELSE architecture to do this and it works, now I'm trying to adapt this architecture of IF-ELSE to a state machine. The circuito works basically like this: the PRODUCER module sends a 4-bit signal to the CONSUMER module, the CONSUMER module waits the REQ signal that comes from the PRODUCER, when he REQ signal is '1' a "RDY" led needs to be activated, when the user tightens de RCV button de output from the CONSUMER shows the 4-bit data received from the PRODUCER on 4 leds, and sends a confirmation signal to the producer by an output call ACK. The state machine from the PRODUCER module it's working correctly, but when I simulate the CONSUMER state machine the outputs doesn't works.
Below the two codes from the PRODUCER and CONSUMER module:
PRODUCER:
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.std_logic_unsigned.ALL;
use IEEE.std_logic_arith.ALL;
ENTITY produtor IS
GENERIC(W : NATURAL := 4);
PORT (o_RDY : OUT BIT;
i_SND : IN BIT;
i_DIN : IN STD_LOGIC_VECTOR(W-1 DOWNTO 0);
o_DOUT : OUT STD_LOGIC_VECTOR(W-1 DOWNTO 0);
o_REQ : OUT BIT;
i_ACK : IN BIT);
END produtor;
ARCHITECTURE arch_1 OF produtor IS
TYPE state_type IS (s0, s1);
SIGNAL state_reg : state_type;
SIGNAL next_state: state_type;
BEGIN
p_state_reg: PROCESS(i_SND,i_DIN,i_ACK)
BEGIN
IF (i_ACK ='0') THEN
state_reg <= s0;
ELSIF (i_ACK ='1') THEN
state_reg <= next_state;
END IF;
END PROCESS;
p_next_state: PROCESS(state_reg,i_SND,i_ACK)
BEGIN
CASE (state_reg) IS
WHEN s0 => IF (i_ACK = '1') THEN
next_state <= s1;
ELSIF (i_ACK = '0') THEN
next_state <= s0;
END IF;
WHEN s1 => IF (i_SND ='1') THEN
next_state <= s1;
ELSIF (i_SND='0') THEN
next_state <= s0;
END IF;
WHEN OTHERS=> next_state <= s0;
END CASE;
END PROCESS;
o_DOUT <= i_DIN WHEN (state_reg = s1);
o_REQ <= '1' WHEN (state_reg = s1) ELSE '0';
o_RDY <= '0' WHEN (state_reg = s1) ELSE '1';
END arch_1;
CONSUMER:
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.std_logic_unsigned.ALL;
use IEEE.std_logic_arith.ALL;
ENTITY consumidor IS
GENERIC(W : NATURAL := 4);
PORT (o_RDY : OUT BIT;
i_RCV : IN BIT;
i_DIN : IN STD_LOGIC_VECTOR(W-1 DOWNTO 0);
o_DOUT : OUT STD_LOGIC_VECTOR(W-1 DOWNTO 0);
i_REQ : IN BIT;
o_ACK : OUT BIT);
END consumidor;
ARCHITECTURE arch_1 OF consumidor IS
TYPE state_type IS (s0, s1, s2);
SIGNAL state_reg : state_type;
SIGNAL next_state: state_type;
BEGIN
p_state_reg: PROCESS(i_RCV,i_REQ,i_DIN)
BEGIN
IF (i_REQ ='0') THEN
state_reg <= s0;
ELSIF (i_REQ ='1') THEN
state_reg <= next_state;
END IF;
END PROCESS;
p_next_state: PROCESS(state_reg,i_RCV,i_REQ,i_DIN)
BEGIN
CASE (state_reg) IS
WHEN s0 => IF (i_REQ = '1') THEN
next_state <= s1;
ELSIF (i_REQ = '0') THEN
next_state <= s0;
END IF;
o_RDY <= '1';
o_ACK <= '0';
WHEN s1 => IF (i_RCV ='1') THEN
next_state <= s2;
ELSIF (i_RCV='0') THEN
next_state <= s0;
END IF;
o_RDY <= '0';
o_ACK <= '1';
WHEN s2 => o_DOUT <= i_DIN;
o_ACK <= '0';
o_RDY <= '0';
next_state <= s0;
WHEN OTHERS=> next_state <= s0;
END CASE;
END PROCESS;
--o_DOUT <= i_DIN WHEN (state_reg = s2);
--o_ACK <= '1' WHEN (state_reg = s1) ELSE '0';
--o_RDY <= '1' WHEN (state_reg = s0) ELSE '0';
END arch_1;
I used three states to do the state machine of consumer:
s0 --> Ready to receive
s1 --> Waiting authorization to receive (authorization is send by the RCV input)
s2 --> Receiving
* The two modules are connected by a BDF file using wires.
The architecture IF-ELSE of the CONSUMER module below:
ARCHITECTURE arch_1 OF consumidor IS
BEGIN
PROCESS(i_RCV, i_DIN, i_REQ)
BEGIN
IF (i_REQ = '1') THEN
o_RDY <= '1';
ELSE
o_RDY <= '0';
END IF;
IF (i_RCV = '1') THEN
o_DOUT <= i_DIN;
o_ACK <= '1';
ELSE
o_ACK <= '0';
END IF;
END PROCESS;
END arch_1;
The error is shown in the images below:
1) Error with the producer-consumer state machine on the outputs
:
2) Simulation working with the PRODUCER using state machine architecture and consumer module using IF-ELSE architecture:
3) BDF file conecting the two modules:
If the architecture IF-ELSE of the PRODUCER module is necessary to solve this, It's below:
ARCHITECTURE arch_1 OF produtor IS
SIGNAL entrada : STD_LOGIC_VECTOR (W-1 DOWNTO 0);
BEGIN
PROCESS(i_SND,i_DIN,i_ACK)
BEGIN
IF (i_ACK = '1') THEN
o_RDY <= '1';
ELSE
o_RDY <= '0';
END IF;
IF (o_RDY = '1') THEN
IF (i_DIN(0) = '1') THEN
entrada(0) <= '1';
END IF;
IF (i_DIN(0) = '0') THEN
entrada(0) <= '0';
END IF;
IF (i_DIN(1) = '1') THEN
entrada(1) <= '1';
END IF;
IF (i_DIN(1) = '0') THEN
entrada(1) <= '0';
END IF;
IF (i_DIN(2) = '1') THEN
entrada(2) <= '1';
END IF;
IF (i_DIN(2) = '0') THEN
entrada(2) <= '0';
END IF;
IF (i_DIN(3) = '1') THEN
entrada(3) <= '1';
END IF;
IF (i_DIN(3) = '0') THEN
entrada(3) <= '0';
END IF;
IF (i_SND = '1') THEN
o_DOUT <= entrada;
o_REQ <= '1';
o_RDY <= '0';
ELSE
o_REQ <= '0';
o_RDY <= '1';
END IF;
END IF;
END PROCESS;
END arch_1;
I believe the error is on the state machine of consumer, after doing this state machine the simulation doesn't works anymore.
*****UPDATE*****
Changing the circuit to a Synchronous mode with Clock and Reset Entrance. Now the simulation works but the Leds and the output stay always with the same value...
The new architecture
CONSUMER:
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.std_logic_unsigned.ALL;
use IEEE.std_logic_arith.ALL;
ENTITY consumidor IS
GENERIC(W : NATURAL := 4);
PORT (o_RDY : OUT BIT;-- data input
i_RST : IN BIT;
i_CLK : IN STD_ULOGIC;
i_RCV : IN BIT;-- data input
i_DIN : IN STD_LOGIC_VECTOR(W-1 DOWNTO 0); -- clock
o_DOUT : OUT STD_LOGIC_VECTOR(W-1 DOWNTO 0); -- clear
i_REQ : IN BIT; -- enable
o_ACK : OUT BIT);-- data output
END consumidor;
ARCHITECTURE arch_1 OF consumidor IS
TYPE state_type IS (s0, s1, s2);
SIGNAL stateT : state_type;
BEGIN
PROCESS(i_CLK)
BEGIN
IF rising_edge(i_CLK) THEN
IF (i_RST = '1') THEN
CASE stateT IS
WHEN s0 => IF (i_REQ = '0') THEN
stateT <= s0;
ELSE
stateT <= s1;
END IF;
WHEN s1 => IF (i_RCV = '1') THEN
stateT <= s2;
ELSE
stateT <= s0;
END IF;
WHEN s2 => stateT <= s0;
END CASE;
END IF;
END IF;
END PROCESS;
o_DOUT <= i_DIN WHEN (stateT = s2);
o_ACK <= '1' WHEN (stateT = s1) ELSE '0';
o_RDY <= '1' WHEN (stateT = s0) ELSE '0';
END arch_1;
PRODUCER:
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.std_logic_unsigned.ALL;
use IEEE.std_logic_arith.ALL;
ENTITY produtor IS
GENERIC(W : NATURAL := 4);
PORT (
i_RST : IN BIT;
i_ACK : IN BIT;
i_CLK : IN STD_ULOGIC;
i_SND : IN BIT;-- data input
i_DIN : IN STD_LOGIC_VECTOR(W-1 DOWNTO 0); -- clock
o_DOUT : OUT STD_LOGIC_VECTOR(W-1 DOWNTO 0); -- clear
o_REQ : OUT BIT; -- enable
o_RDY : OUT BIT);-- data output
END produtor;
ARCHITECTURE arch_1 OF produtor IS
TYPE state_type IS (s0, s1, s2);
SIGNAL stateT : state_type;
BEGIN
PROCESS(i_CLK)
BEGIN
IF rising_edge(i_CLK) THEN
IF (i_RST = '1') THEN
CASE stateT IS
WHEN s0 => IF (i_ACK = '0') THEN
stateT <= s0;
ELSE
stateT <= s1;
END IF;
WHEN s1 => IF (i_SND = '1') THEN
stateT <= s2;
ELSE
stateT <= s0;
END IF;
WHEN s2 => stateT <= s0;
END CASE;
END IF;
END IF;
END PROCESS;
o_DOUT <= i_DIN WHEN (stateT = s2);
o_REQ <= '1' WHEN (stateT = s1) ELSE '0';
o_RDY <= '1' WHEN (stateT = s0) ELSE '0';
END arch_1;
The Clock and Reset signal are the same for the two modules in BDF. Now the simulation goes like this:
What's happening now to the output stay with XXXX value, the logic of the two modules seems to be correct.
On Altera FPGAs, latches are implemented using the look-up table (LUT) and a combinational feedback path within the logic element (LE). The state of such a latch is undefined after programming the FPGA. The simulation of the synthesized netlist with an Vector Waveform File (VWF) shows this as 'X'es. In your original code, the synthesizer reports warnings about latches for state and next_state (both state machines) and o_DOUT (consumidor). Thus, signals such as RDY_PRODUCER and RDY_CONSUMER which depend on the (unknown) state will be unknown too (as observed by you).
An asynchronous design using latches is possible, but only if the logic is free of timing hazards. The actual requirements for Altera FPGAs are described in the Altera Quartus-II / Quartus Prime Handbook, Volume 1, Recommended HDL Coding Styles, Register and Latch Coding Guidelines.
If your design contains latches, then the Compilation Report will denote if they are free of timing hazards. The information is found in the section Analysis & Synthesis -> Optimization Results -> Register Statistics -> User-Specified and Inferred Latches.
Altera and I recommend to use a synchronous design instead. I have already given a code template in the comments, but it was wrong. (Sorry!)) You have used it in the updated code in your question, but it must be changed another time to:
PROCESS(i_CLK)
BEGIN
IF rising_edge(i_CLK) THEN
IF (i_RST = '1') THEN
stateT <= s0;
ELSE
CASE stateT IS
-- description of state machine here
END CASE;
END IF;
END IF;
END PROCESS;
A reset i_RST needs to be asserted during the startup of the
FPGA only, if state machines may toggle states immediately. The
initial state will always be defined by the declaration of signal
stateT.
But even fixing this does not help. The producer keeps staying in
state s0 because it is awaiting an acknowledge. But, the consumer is
waiting for an request first before replying with an
acknowledge. Thus, the state machines are in a dead-lock.
A producer-consumer scheme will work as follows instead:
The producer issues a new request (
o_REQ <= '1') if sending is enabled (i_SND = '1').The consumer waits for a request and then saves the incoming data if receiving is enabled (
i_RCV = '1'). The consumer replies with an acknowledge afterwards (o_ACK <= '1')The producer waits for the acknowledge and then finished the request (
o_REQ <= '0') afterwards.The consumer finishes the acknowledge as well (
o_ACK <= '0') either after 1 clock cycle or after the request has been finished.Continue with step 1. But, your waveforms indicates that a new transaction should be issued by the producer only if
i_SNDis low in between. This is necessary to detect when new dataDINis available.
The implementation of the producer will now be:
ARCHITECTURE arch_1 OF produtor IS
TYPE state_type IS (s0, s1, s2);
SIGNAL stateT : state_type;
BEGIN
PROCESS(i_CLK)
BEGIN
IF rising_edge(i_CLK) THEN
IF (i_RST = '1') THEN
stateT <= s0;
ELSE
CASE stateT IS
when s0 => if (i_SND = '1') then -- wait until sending enabled
stateT <= s1; -- issue new request
end if;
when s1 => if (i_ACK = '1') then -- wait until acknowledge
stateT <= s2; -- finish request
end if;
when s2 => if (i_ACK = '0') and (i_SND = '0') then
-- wait until acknowledge finished and `i_SND` low
-- before starting a new transaction.
stateT <= s0;
end if;
END CASE;
END IF;
END IF;
END PROCESS;
o_DOUT <= i_DIN WHEN (stateT = s0); -- latch open when ready
o_REQ <= '1' WHEN (stateT = s1) ELSE '0';
o_RDY <= '1' WHEN (stateT = s0) ELSE '0';
END arch_1;
And the implementation of the consumer (code updated to signal ready only after request):
ARCHITECTURE arch_1 OF consumidor IS
TYPE state_type IS (s0, s1, s2);
SIGNAL stateT : state_type;
BEGIN
PROCESS(i_CLK)
BEGIN
IF rising_edge(i_CLK) THEN
IF (i_RST = '1') THEN
stateT <= s0;
ELSE
CASE stateT IS
WHEN s0 => IF (i_REQ = '1') then -- wait until request
stateT <= s1; -- signal ready
END IF;
when s1 => if (i_RCV = '1') then -- wait until receiving enabled
stateT <= s2; -- save data and acknowledge
end if;
WHEN s2 => IF (i_REQ = '0') then -- wait until request finished
stateT <= s0; -- finish acknowledge
END IF;
END CASE;
END IF;
END IF;
END PROCESS;
o_DOUT <= i_DIN WHEN (stateT = s2); -- latch open during acknowledge
o_ACK <= '1' WHEN (stateT = s2) ELSE '0';
o_RDY <= '1' WHEN (stateT = s1) ELSE '0';
END arch_1;
I have used the inputs from your waveform, but some changes are required:
RCVandSNDmust be low at the beginning otherwise a reset is needed.The clock frequency must be 2 times, so that, inputs due not change near the rising edge of the clock.
RCVis disabled at the beginning of the third transaction to demonstrate the delay of the data output and the acknowledge.
The simulation output will now be:
My waveform also includes the REQ and ACK signal between both
state-machines to demonstrate the hand-shaking (named DEBUG_REQ and
DEBUG_ACK here).
The assignments of signal o_DOUT in both state-machines still describe
latches. According to the Compilation Report, Quartus can implement
them without timing hazards. But, it would be better to implement them
as synchronous registers as well. I will leave this as an exercise.