Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
17049 Discussions

vhdl testbench issue in modelsim

Altera_Forum
Honored Contributor II
3,856 Views

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.
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
2,997 Views

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;
0 Kudos
Altera_Forum
Honored Contributor II
2,997 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
2,997 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
2,997 Views

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.
0 Kudos
Reply