Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
17244 Discussions

DE1 Reading / Writing to SRAM

Altera_Forum
Honored Contributor II
2,312 Views

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...
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
1,453 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
1,453 Views

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...
0 Kudos
Altera_Forum
Honored Contributor II
1,453 Views

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...
0 Kudos
Altera_Forum
Honored Contributor II
1,453 Views

that was really helpful 

thankyou
0 Kudos
Reply