Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

DE1 Reading / Writing to SRAM

Hi, I'm trying to design a SRAM controller that can be used to read or write to or from the DE1's SRAM for a project and I have absolutely no clue where to begin. I've got the basic entity skeleton as follows...

ENTITY SRAM_16bit_512k IS

PORT(

iCLK : IN STD_LOGIC;

iREAD : IN STD_LOGIC;

iWRITE : IN STD_LOGIC:

iADDR : IN STD_LOGIC (17 donwto 0);

iDATA : IN STD_LOGIC_VECTOR (15 downto 0):

oCLK : OUT STD_LOGIC;

oDATA : OUT STD_LOGIC_VECTOR (7 downto 0);

SRAM_DQ : INOUT STD_LOGIC_VECTOR (15 downto 0);

SRAM_ADDR : OUT STD_LOGIC_VECTOR (17 downto 0);

SRAM_OE_N : OUT_STD_LOGIC;

SRAM_WE_N : OUT_STD_LOGIC;

SRAM_CE_N : OUT_STD_LOGIC;

SRAM_UB_N : OUT_STD_LOGIC;

SRAM_LB_N : OUT_STD_LOGIC);

END SRAM_16bit_512k;

Obviously to read or write one must assert iREAD or iWRITE while iDATA and oDATA are the input and output data respectively. iADDR will provide the SRAM memory address. iCLK will be the clock input to the controller and we are told that oCLK must determine the read / write cycle time.

I really just need someone to point me in the right direction and get me started with this. I've never done anything with SRAM on the DE1 board (Or SRAM at all for that matter) and could really just use some guidance on designing this controller...

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Hello,

    --- Quote Start ---

    ...we are told that oCLK must determine the read / write cycle time.

    --- Quote End ---

    There is no CLK for the SRAM in the datasheet. So, your SRAM is asynchronous. This actually makes the design easier than say SDRAM controller.

    --- Quote Start ---

    I really just need someone to point me in the right direction and get me started with this. I've never done anything with SRAM on the DE1 board (Or SRAM at all for that matter) and could really just use some guidance on designing this controller...

    --- Quote End ---

    Start by going through the datasheet for the SRAM on the DE1 system CD. Specifically pay attention to the timing diagrams for read and write cycle (p. 6 and p. 8 in the datasheet on v0.8 of the CD).

    Next go through the reference designs. The file SRAM_16Bit_512K.v from the DE1_SD_Card_Audio project on the DE1 system CD should be useful. That file should hopefully show you how simple the SRAM interface is (again, because it is asynchronous).

    Here is a link to a previous post which has a DE1 SRAM interface in VHDL from my colleague:

    http://www.alteraforum.com/forum/showthread.php?p=104287#post104287

    The VHDL design above is a little complex because it loads image data stored onto SRAM via the control panel.

    Hope this helps, good luck.

    Bart
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    So far I have the following code...

    architecture structural of SRAM_16bit_512K is

    begin

    process(iCLK)

    begin

    SRAM_OE_N <= iREAD;

    SRAM_WE_N <= iWRITE;

    if ( iCLK'event and iCLK = '1' ) then

    if ( iWRITE = '0' and iREAD = '1' ) then

    SRAM_CE_N <= '0';

    SRAM_ADDR <= iADDR;

    SRAM_DQ <= iDATA;

    elsif ( iWRITE = '1' and iREAD = '0' ) then

    SRAM_CE_N <= '0';

    SRAM_ADDR <= iADDR;

    oDATA <= SRAM_DQ;

    end if;

    end if;

    end process;

    end structural;

    is this correct? It seems to be reading and writing to and from the SRAM correctly but I'm not sure...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    A quick glance tells me your code will work, at least partially, although note that the "read" case in your code takes two clock cycles - one to set the address, and the second to read valid data, since the RAM will have a delay, and you won't end up reading the data result available on SRAM_DQ until the next cycle.

    I'm worried about the commnds at the top though. Those two lines of code are executed on rising and falling edges of the clock, and in some cases could mean you write data to the wrong address! (when write goes high, but the address isn't set yet...)

    Incase you're not sure, those two commands (the OE and WE ones) are executed on the rising AND falling edges of the clock, which probably isn't what you intended...