System Logic

[kahosl]

Hello,

I made this ram block with the RSTA connection and the ENA enabled all the time. I also added a *.COE file to fill the memory with initial values.

The reading, writing all works fine, but as soon as i reset the block, at first the DOUTA goes to "000...0" and after that it yust takes the previous values again instead of the initial values in the *.COE file.

for ex initial values =>  01234567,    89ABCDEF;
i read them and
overwrite them with =>  45645645,    FFFFFFFF;

after resetting the
content is              =>  45645645,    FFFFFFFF;

instead of my
expected               =>  01234567,   89ABCDEF;

 Am i doing something wrong here? did i forget some signal that needs to be set aswell except the RSTA and ENA?

thx

[austin]

k,

The BRAM has no global reset (set every value to zero).  One may only reset the output register.

[austin]

k,

How did the ram get implemented?

If one uses DFF in the CLB's, one can reset everything...but that uses a great desal of resources and logic.

[kahosl]

this makes things different... so there is no way if i reset the memory block it sets its content back to the initial.COE file?

I adjusted my project using these gererated RAM blocks to save more space on my chip since i was working with 4 Sboxes (used for encryption) each contain 255 values of each 32bit wide.

my original design was this:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity SBox0 is
    Port (              Clk : in  STD_LOGIC;
			  Reset : in  STD_LOGIC;
			  Write_Enable : in  STD_LOGIC;
                          SAddr : in  STD_LOGIC_VECTOR (7 downto 0);
                          SOut : out  STD_LOGIC_VECTOR (31 downto 0);
                          SNewData : in  STD_LOGIC_VECTOR (63 downto 0));
end SBox0;

architecture Behavioral of SBox0 is

  type ram_t is array (0 to 255) of std_logic_vector(31 downto 0); -- Declaration of the RAM array signal Sram : ram_t;
  
begin

	process (clk, Reset, Write_enable, SNewdata, SRam, SAddr)
	begin
		if (clk'event and clk = '1') then
			if (Reset = '1') then
			  SRam <=( x"d1310ba6", x"98dfb5ac", x"2ffd72db", x"d01adfb7",
				         x"b8e1afed", x"6a267e96", x"ba7c9045", x"f12c7f99",
				         x"24a19947", x"b3916cf7", x"0801f2e2", x"858efc16",
                                          ..........................total of 255 values......................);
			else
			   if (Write_Enable = '1') then
				SRam(to_integer(unsigned(SAddr)))     <= SNewData(63 downto 32);
				SRam(to_integer(unsigned(SAddr + 1))) <= SNewData(31 downto  0);
			  else
				SRam <= SRam;
			  end if;
			end if;
		else
			SRam <= SRam;
		end if;
	end process;
	 	SOut <= SRam(to_integer(unsigned(SAddr)));		
end Behavioral;

 i was working with an array that had my initial values. after synthesis i saw that i had

                                                   used available
Number of Slice Registers 	         33916 	301440 	   11%
Number of Slice LUTs 	                 45892 	150720 	   30%
Number of fully used LUT-FF pairs 33716 	  46092 	   73%
Number of bonded IOBs                     0 	     600 	   0%
Number of BUFG/BUFGCTRLs 	       1 	       32 	   3%

With the coregenerator i only have:

                                                used available
Number of Slice Registers 	          844 	301440 	0%
Number of Slice LUTs                   3238 	150720 	2%
Number of fully used LUT-FF pairs   827 	3255 	25%
Number of bonded IOBs 	          195 	600 	        32%
Number of Block RAM/FIFO 	              2 	416 	        0%
Number of BUFG/BUFGCTRLs 	      2 	32 	        6%


for some reason this code window messus up my spacing sorry

The only upside i can think of to fix this problem is that the initial.COE file data contains the HEX values of the digits of PI

Would it be easyer if i generate these values on the fly and refill my Sboxes when needed? I only need to do this if my MasterKey changes (so thats not very often).

thank you for replying,

Sorry for my english it's not my main language and sorry for the messy VHDL code, i'm still new to this (programming in VHDL)!

[gszakacs]

I don't know how much block RAM you have left, but you could always have another RAM implemented

as ROM (never written after config) and just copy its contents to the working RAM when you need to

get back the .COE values.

-- Gabor

[kahosl]

Doest that take like double of my chip again cause I have to make 8 RAM blocks now instead of 4?

The chip usage really doesn't bother me that much, but  I guess the jury that reads my paper won't like it.

I'am yust trying to find the most cost efficient method of implementing what i need.

thx for the help so far poeple i appericiate it.

[kahosl]

oh i get what u mean u want me to make 8 RAM blocks with the coregen? And it will still take less space then when i make the RAM with array's in VHDL myself?

[joelby]

---

kahosl wrote:
oh i get what u mean u want me to make 8 RAM blocks with the coregen? And it will still take less space then when i make the RAM with array's in VHDL myself?

---

The amount of space it'll take might depend on your BRAM's geometry. For example, if you're currently only using the lower half of an 18K BRAM, or half of the 36-bit width, you could store the 'original' copy of the data in the upper half of the address or data space and you wouldn't use any more BRAMs.

If you don't mind the whole design being reset, you could also trigger an FPGA reconfiguration, which will load the design and the original BRAM contents back from your configuration PROM.

[kahosl]

That FPGA reconfiguration might be an option for me. Is there anywhere i can find data/code for this? (ill awsk my friend google too in the meanwhile).

thank you for the help!

[joelby]

You haven't said which device you're using, but you can trigger reconfiguration by pulsing the PROGRAM_B pin (you will need some external logic to do this from a spare output), or by issuing an IPROG command using ICAP. For the Spartan-6, the document to read is UG380.