Block RAM read data have random error but it pass timing !!!

[zhongfanyang]

Hi, I have a project over the Nexys4 development board which is based on Artix100T. I have this wierd intermittent error : Block RAM randorm data corruption. BRAM clock runs at only 50MHz, timing analysis is fine. But data readback is not correct at times not even the data at the same address is read consecutively (it always gives the same error pattern as if data been tampered).I've check the VCCInt, VCCBRAM all is within normal range. I'm really struggling to find the root cause of this problem, and it has been driving me crazy for days!! Can anyone give me any suggestion,Thanks?


Following is the snippet of the code for the BRAM. It is as simple as it is.

entity BlockRAM_SDP is 

	generic(MemDepth : integer := 2048; 
			AddrBusWidth:integer:= 11;
			DataBusWidth: integer := 16);
    	Port (	
    		Clk : in  STD_LOGIC;
    		CE: in STD_LOGIC;

  		Read_Addr : in  STD_LOGIC_VECTOR ((AddrBusWidth - 1) downto 0);
		Read_Data : out  STD_LOGIC_VECTOR ((DataBusWidth - 1) downto 0);
		
		Write_Addr : in  STD_LOGIC_VECTOR ((AddrBusWidth - 1) downto 0);
		Write_Data : in  STD_LOGIC_VECTOR ((DataBusWidth - 1) downto 0);
		Write_En : in  STD_LOGIC
		
             	);


end BlockRAM_SDP;             	

--read first model

architecture Behavioral of BlockRAM_SDP is

TYPE BRAMDataVector is array (natural range <>) of STD_LOGIC_VECTOR ((DataBusWidth - 1) downto 0);

signal Memory : BRAMDataVector(0 to (MemDepth - 1)) := (others => (others=>'0'));

begin

	Process(Clk)

	begin

		if(Clk'event and Clk = '1') then
			if(CE = '1') then
			
				
				Read_Data <= Memory(conv_integer(Read_Addr));
				

				if(Write_En = '1') then
					Memory(conv_integer(Write_Addr)) <= Write_Data;
				end if;				
					
			end if;
		end if;
		
	end process;

end Behavioral;

For the timing report: setup/hold time slack for all the paths leading in/out of BRAM exceeds 10ns /0.38ns. I've exhausted every possibilities, but the problem persists. What could I'v missed! :sad:

ZFyoung

 

[aruipksni]

try to generate the bram with core generator instead....

 

[FvM]

How do you know that the error is happening inside the block RAM? How's the RAM connected, where do you detect data corruption?

You didn't show yet relevant design parts except for the basic RAM definition.

 

[zhongfanyang]

How do you know that the error is happening inside the block RAM? How's the RAM connected, where do you detect data corruption?

Actually, I inserted ChipScope probe points over the interface signals as the entity declared.And most importantly, I inspected the circuit topology as desired that this signal taps are indeed placed right over the in/output pin of RAMB36E1 via FPGA Editor.What I need to do is to watch the captured read record against the write record.

What is more disturbing is that even when I forced disable the Write enable pin (ie. no write, but initialize BRAM with known data), read data corruption still persists.

Regards
ZFYoung

 

[zhongfanyang]

After another round of thorough investigation, I finally nail down the root cause of this persitent error: Read Address bus setup/hold timing violation. One logic input driving this address bus is sourced from tri-state data bus external to the FPGA. Due to logic optimation, there is possible unknown logic state 'X' driving the address line, hence causing timing problem. And in the VHD, I did assign the address bus with 'X' state when I don't care about the read data.


Regards

ZFYoung

 

[ads-ee]

After another round of thorough investigation, I finally nail down the root cause of this persitent error: Read Address bus setup/hold timing violation. One logic input driving this address bus is sourced from tri-state data bus external to the FPGA. Due to logic optimation, there is possible unknown logic state 'X' driving the address line, hence causing timing problem. And in the VHD, I did assign the address bus with 'X' state when I don't care about the read data.


Regards

ZFYoung

Whether or not you drive signal to X in your code or testbench has nothing to do with an actual design implemented and downloaded to an FPGA development board.

What you have here is a timing constraint problem for your I/O, fix that and the design will pass timing AND work correctly.