Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

vhdl testbench issue in modelsim

I am having a problem in modelsim-altera with a vhdl testbench I have set up to generate a serial data stream. I created a procedure to generate the serial stream as such:

-- create procedure to generate one symbol long DL rx signal

procedure dl_rx_gen (

signal clk : in std_logic;

signal encoded_symbol : in std_logic_vector(13 downto 0);

signal dl_serial_out : out std_logic ) is

begin

-- loop for each half bit of encoded symbol

for i in encoded_symbol'range loop

dl_serial_out <= encoded_symbol(i);

wait for dl_bit_period/2; -- two values per bit period for manchester encoding

end loop;

end procedure;

I call this procedure repeatedly as follows:

-- process to generate DL serial data

process

begin

-- wait until after configuration is done

wait for 525 ns;

-- good packet

dl_test_symbol <= "11111111111111"; -- idle

dl_rx_gen( clk, dl_test_symbol, RX_DL_TTL(0) );

dl_test_symbol <= "10011001100110"; -- sync

dl_rx_gen( clk, dl_test_symbol, RX_DL_TTL(0) );

dl_test_symbol <= "01010110100110"; -- start of frame

dl_rx_gen( clk, dl_test_symbol, RX_DL_TTL(0) );

dl_test_symbol <= "01010101010101"; -- 0

dl_rx_gen( clk, dl_test_symbol, RX_DL_TTL(0) );

...

What I am seeing though is that the first bit in the test symbol sometimes gets inverted. It happens with both ones and zeros, although it does seem to be more likely to happen when the first bit has the opposite polarity of the last bit of the previous symbol - but I have seen it even when the previous bit is the same value. Does anyone know why this could happen?

Thanks for the help.

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I don't know that I can answer your question, but here are a few observations about your code:

    (1) It looks like you intend for your events to happen synchronous to the rising and falling edges of your clock, but you do not actually refer to 'clk' inside the procedure.

    (2) Is dl_bit_period equal to the period of 'clk'?

    How I might tweak the procedure code to align your events to clock edges:

    -- code fragment (assumes encoded_symbol'length is an even number)

    for i in 1 to encoded_symbol'length/2 loop

    wait until rising_edge(clk);

    dl_serial_out <= encoded_symbol(i);

    wait until falling_edge(clk);

    dl_serial_out <= encoded_symbol(i);

    end loop;
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I did intend the signal to be asynchronous to the clock, as that is how it will be in the application. The input goes through a synchronizer and the design performs clock recovery.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    OK. Understood. I know that I have seen strange things in simulation before when I have messed up event timing and created a delta delay issue. In your case, you do indicate to wait for a fixed period of time before each new event, so I don't see that this could be a delta delay related issue.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I found a solution. It works when I make the following change to the procedure:

    procedure dl_rx_gen (

    signal clk : in std_logic;

    signal encoded_symbol : in std_logic_vector(13 downto 0);

    signal dl_serial_out : out std_logic ) is

    begin

    wait for 1 ps;

    -- loop for each half bit of encoded symbol

    for i in encoded_symbol'range loop

    dl_serial_out <= encoded_symbol(i);

    wait for dl_bit_period/2; -- two values per bit period for manchester encoding

    end loop;

    end procedure;

    It seems that the simulator did not like the fact that the encoded_symbol value was getting set and that value was being used to set dl_serial_out all in the same instant in time.