[SOLVED] Simulation Problems - Output signal displays false values in the beginning.

Status
Not open for further replies.
S

sreevenkjan

Full Member level 5
Joined
Nov 4, 2013
Messages
268
Helped
27
Reputation
54
Reaction score
26
Trophy points
1,308
Location
Germany
Visit site
Activity points
3,115
Hi all,

I have written a VHDL program to use ROM as look up table. The program compilation is done without any errors. However during simulation (screenshot is attached below) I get initialization problems where data_out values are read as 000 ans 3FF (hexadecimal values).

Since I have given data_in as random values and data_out values are correct after 2 clock cycles. Could you tell me why is it happening and where am I going wrong??



Thanks,
Sreeni
 

if u see the picture attached, data_out and data_in are not in snyc with each other. Data_out is reading in the first 2 clock cycles wrong values. My question is why am I getting wrong values and why are the two signals not in sync with each other??
 

Don't read the data as soon as you write. Keep a gap of a few clock cycles. This is to account for write settling time.
But why is the read data different from the write data?
 

what do u mean by the first sentence??
data_in is a random value which changes every 40ns. I have used waveform editor of quartus. As this value changes the data_out changes. like I said i have designed a LUT. the values are correct. but I do not know why I get wrong values (i.e 000 and 3FF) on data_out signal for first 2 clock cycles ??
 

Can you please post the testbench code and the ROM code?
Is this a synchronous or asynchronous rom?
 

the vhdl code for lut is

Code: 
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_unsigned.all;
use IEEE.STD_LOGIC_arith.all;

-- Entity Declaration

ENTITY MC1362LUT IS
	GENERIC
	(
		n	: INTEGER := 1
	);

	PORT
	(
		data_in	: IN STD_LOGIC_VECTOR(n*(10-1) downto 0);	
		clk		: IN STD_LOGIC;
		rst		: IN STD_LOGIC;
		f_val_in	: IN STD_LOGIC;
		l_val_in	: IN STD_LOGIC;
		d_val_in	: IN STD_LOGIC;
		f_val_out: OUT STD_LOGIC;
		l_val_out: OUT STD_LOGIC;
		d_val_out: OUT STD_LOGIC;
		data_out	: OUT STD_LOGIC_VECTOR(n*(10-1) downto 0)	
	);
	
END MC1362LUT;

-- Architecture of LUT

ARCHITECTURE behav of MC1362LUT IS

COMPONENT rom
PORT (
			address	: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
			clock		: IN STD_LOGIC ;
			q			: OUT STD_LOGIC_VECTOR (9 DOWNTO 0)
	);
END COMPONENT;

	signal address : STD_LOGIC_VECTOR(9 downto 0);			-- address depth = 1024
		
	BEGIN

	-- instantiating rom

	rom_lut : rom
		port map(
			address	=> address,
			clock		=> clk,
			q			=> data_out
		);
	
	lut : process(clk,rst)
	
	BEGIN
		
		if rst = '1' then
			address  <= "0000000000";
		elsif rising_edge(clk) then
			--address  <= address + "1";
			address  <= data_in;
		end if;
		
	end process;
	
	f_val_out <= f_val_in;
	l_val_out <= l_val_in;
	d_val_out <= d_val_in;
	
END behav;

for behavioral simulation I am using quartus 2 waveform editor.
 

and the code for the rom_lut?

Basically the output is because the values for the ROM at time 0 have to be something. Im guessing the default output is 00 or FF
 

The component ROM is generating Q after a couple of cycles after getting the address. We don't the know value of address/data_in in the cycles prior to the waveform you posted. So assuming data_in is junk in that period it gives out junk data.
 

i have used .mif file to load values into rom. depth is about 1024 and width 10bits. when the data_in is 0 output is 3FF. its just inverted in the rom. but why are my data_in and data_out signals not synchoronised??..do i get such timing issues when i load it into the fpga??
 

@sharath666 - yes the data_out is showing the value when data_in is not initialised i.e when data_in is 000 data_out is 3FF. which is a correct value.

now hw should I overcome this? or can I load this program into fpga ??..apart from first two clk cycles the remaining values are perfect.

- - - Updated - - -

yes simulataneous.
 

The problem is we don't know how much time the ROM component is taking.So the solution would be to ignore the first 2 cycles of output_data. Consider the output data only from the 3rd or 4th cycle onwards.
 

maybe data_out does not know what is the value of data_in in the previous clock cycle so it takes data_in as 000 and gives output as 3FF (which is the correct output).
 

If it does not know, then it should give out junk which anyway should not be considered. You should ignore the first 2 values.
 

With any synchronous design, you will get at least 1 clock of latency. THis looks like your waveform (and the fact the ROM is clocked).
This is normal. An asynchronous ROM (ie. zero latency) is not really a good thing to have in an FPGA.
 

what do u mean by like my waveform??...i also had similar issues while trying to read from bram memory.
 

i did the test bench simulation in modelsim and I have added the screenshot of the waveform.i have got the same response.

 

I dont quite know what you're expecting. This is a synchronous ram, so has a latency. At time 0, the address is unknown, so the output wont be valid for several clock cycles.
 

Nobody seems to have pointed out clearly why the output of the simulation shows the delay.

Code: 
lut : process(clk,rst)
BEGIN
    if rst = '1' then
        address  <= "0000000000";
    elsif rising_edge(clk) then
        address  <= data_in;
    end if;
end process;
The address is the output of a clocked synchronous element (i.e. a register), therefore data_in is delayed by 1 clock cycle to produce address.

Code: 
rom_lut : rom
port map (
    address  => address,
    clock    => clk,
    q        => data_out
);
The ROM uses a clock, therefore you will not see an output of the ROM for a given address until there is a clock and the address is stable prior to the rising clock edge.

Here is a diagram showing some data Do propagating through the code you wrote. There is a pipeline of registers that need to be filled before the corresponding DOo is generated.

You should note I've offset the transitions of data_in, address, and data_out from the clock edge to emphasize that the data is stable prior to and after the clock edge. You won't see this offset in your simulation unless you add unsynthesizable after # ns delays in your code (don't do this). You will instead see that the transitions line up with clock edges (in reality there are delta delays that actually offset the transitions from the clock edges)

Given that you think of your VHDL code as a program shows you don't have a full grasp on the fact that VHDL represents hardware and time in hardware is measured in clock cycles. You are thinking like a software programmer, where there really isn't much of a concept of pipelines that need to be filled and code executes in many clock cycles, but are interpreted as a single software "state".
 
Last edited:
Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…