- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page