Test bench RS232 Protocol VHDL

Question

Hello I have to make an rs232 driver protocol to connect into a nexys 2, I made the code with the 3 modules, frecuency divisor, Tx, Rx, but now I have to see if my code works with a test bench, I know how to create the test bench module but don't know what I have to put there in order to make it work.

The following is the test bench I made, but I don't know what I have to add there to make my RS232 UART wok

 --  VHDL Test Bench Created by ISE for module: UART
 LIBRARY ieee;
 USE ieee.std_logic_1164.ALL;

 -- Uncomment the following library declaration if using
 -- arithmetic functions with Signed or Unsigned values
 --USE ieee.numeric_std.ALL;

 ENTITY TB_RS232 IS
 END TB_RS232;

 ARCHITECTURE behavior OF TB_RS232 IS 

-- Component Declaration for the Unit Under Test (UUT)

COMPONENT UART
PORT(
     Rx : IN  std_logic;
     clk : IN  std_logic;
     Data_in : IN  std_logic_vector(7 downto 0);
     send : IN  std_logic;
     Tx : OUT  std_logic;
     Data_out : OUT  std_logic_vector(7 downto 0);
     ready : OUT  std_logic
    );
END COMPONENT;


    --Inputs
    signal Rx : std_logic := '0';
    signal clk : std_logic := '0';
    signal Data_in : std_logic_vector(7 downto 0) := (others => '0');
    signal send : std_logic := '0';

--Outputs
    signal Tx : std_logic;
    signal Data_out : std_logic_vector(7 downto 0);
    signal ready : std_logic;

    -- Clock period definitions
    constant clk_period : time := 10 ns;

 BEGIN

     -- Instantiate the Unit Under Test (UUT)
    uut: UART PORT MAP (
      Rx => Rx,
      clk => clk,
      Data_in => Data_in,
      send => send,
      Tx => Tx,
      Data_out => Data_out,
      ready => ready
    );

    -- Clock process definitions
    clk_process :process
    begin
    clk <= '0';
    wait for clk_period/2;
    clk <= '1';
    wait for clk_period/2;
    end process;


    -- Stimulus process
    stim_proc: process
    begin       
  -- hold reset state for 100 ns.
  wait for 100 ns;  

  wait for clk_period*10;

  -- insert stimulus here 

  wait;
    end process;

 END;

Here is the Frecuency divisor:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_unsigned.all;

entity DivFrec is
Port ( clk : in  STD_LOGIC;
       clk_div : out  STD_LOGIC);
end DivFrec;

architecture Behavioral of DivFrec is

signal contador : std_logic_vector(8 downto 0):=(others=>'0');

begin
process(clk)
begin
if(rising_edge(clk))then
    clk_div<='0';
    if(contador<433)then  microsegundos
        contador<=contador+1;
    else
        clk_div<='1';
        contador<=(others=>'0');
    end if;
end if;
end process;

end Behavioral;

In the stimulus section you need to modify the input signals of the UUT with some test values at the expected timing delays then verify that the outputs contain the expected values (assert...report is good for that) — Andy Brown

Jim Lewis Jim Lewis · Accepted Answer · 2015-09-02T16:51:33

Generally I code a "stimulus process" for every separate/independent interface for my design. I see a process needed to drive the RX signal. A separate process to handle data_out and ready. This process may also handle data_in and send if they are driven by the same source (such as an internal CPU or statemachine), otherwise, a separate process for data_in and send. Then perhaps an additional process to check the value on TX - or alternately below I have proposed a short-cut for this one.

Test1: Basic UART Receive Test: Drive numerous words on the Rx port to the UUT. Use a subprogram to convert 8 bits of data to UART format to be driven on the signal RX. Your subprogram interface could be as follows:

  procedure UartSend ( 
     constant Data : in unsigned(7 downto 0) ; 
     signal   RX   : out std_logic 
  ) is 
  begin 
   ...
  end procedure UartSend ;

Then your test is constructed by calling UartSend:

  UartSend(X"4A", RX) ;   
  UartSend(X"4B", RX) ;

or

 for in in 1 to 26 loop 
   UartSend(X"4A"+i, RX) ;
 end loop ;

In a separate process, check that the words are received correctly on the internal parallel interface.

Test2: Check UART Error Recovery If your UART handles parity and stop bit errors, generate those in your testbench. This could mean adding extra initialized parameters to your procedure that indicates whether to inject these errors or not.

On the internal interface, validate that your design signals errors correctly. I note that the internal interface looks like it does not have the capability to handle these.

Test3: Basic UART Transmit Test On the internal interface, generate values to be transmitted out the UART interface.

If I were to proceed with one process per independent interface, I would create a UART receive subprogram that would handle center sampling UART bit values from the TX line and use it to receive values, and then check that they are the same as transmitted by the process that handles the internal interface.

OTOH, since you have already tested your UART receiver, in this testbench, I might be inclined to take a short-cut and connect the UART TX to the RX line (loop back mode) and then validate that the correct values were received on the internal interface. In this case, I would use an if generate statement controlled by a generic to assign TX to RX.

That ought to at least get you started.

BTW, if you take the time to learn how to use a procedure to transmit UART data, you will save time in the long run - it is well worth the effort.

Test bench RS232 Protocol VHDL

1 Answers