To build a FIFO using SRAM

http://www.issi.com/pdf/61wv102416all.pdf

Please take a look at write cycle number 4 in page 16.

Note that tSA, tHA and tHD can be as low as zero. My interpretation is that even the UP and LB pulses shown are not needed, it suffices to keep them low during the write burst, along with CE, WE and OE.

And then, you only need to make sure tSD is respected relative to the next address change.

--- Quote Start ---

http://www.issi.com/pdf/61wv102416all.pdf

Please take a look at write cycle number 4 in page 16.

Note that tSA, tHA and tHD can be as low as zero. My interpretation is that even the UP and LB pulses shown are not needed, it suffices to keep them low during the write burst, along with CE, WE and OE.

And then, you only need to make sure tSD is respected relative to the next address change.

--- Quote End ---

I was talking about the FPGA side of the interface.

The SRAM requirement is that tSA = 0ns and tHA = 0ns minimum be met, and you cannot guarantee this using FPGA I/O pins and asserting both the address and write signals all at the same time. Hence you need to assert the address/byte-enables/data one clock before the write-low pulse, and then deassert the controls one clock after. Or you can play tricks with rising and falling edges of the clocks. However, you need to know the clock-to-output delays of the FPGA before you can play those tricks.

Cheers,

Dave

I think we're misunderstanding each other! :D

What I'm proposing is a back to back write sequence such as:

clk 0: WE = UB = LB = CS = OE = 0; ADDR = addr0; DATA=xxxx

clk 1: ADDR = addr0; DATA=data0; others remain the same

clk 2: ADDR = addr1; DATA=data1; others remain the same

clk 3: ADDR = addr2; DATA=data2; others remain the same

...

clk N: ADDR = addrN-1; DATA=dataN-1; others remain the same

clk N+1: WE = 1; ADDR = addrN-1; DATA=dataN-1; others remain the same

No complicated pulses on WE/CS/OE/UB/LB!

The only tricky thing is to make sure tSD is respected. Ie, DATA needs to remain stable right until after ADDR changes.

But that can be done, either with output delays or using the other clock edge.

--- Quote Start ---

I think we're misunderstanding each other! :D

--- Quote End ---

Yes, its always a possibility, lets see what you propose ...

--- Quote Start ---

What I'm proposing is a back to back write sequence such as:

clk 0: WE = UB = LB = CS = OE = 0; ADDR = addr0; DATA=xxxx

clk 1: ADDR = addr0; DATA=data0; others remain the same

clk 2: ADDR = addr1; DATA=data1; others remain the same

clk 3: ADDR = addr2; DATA=data2; others remain the same

...

clk N: ADDR = addrN-1; DATA=dataN-1; others remain the same

clk N+1: WE = 1; ADDR = addrN-1; DATA=dataN-1; others remain the same

No complicated pulses on WE/CS/OE/UB/LB!

--- Quote End ---

Yeah, but no writes either :)

The write-enable signal rising-edge is used for each and every write to the SRAM, and you need to meet the tHD = 0ns, and tHA = 0ns requirement, so you cannot change these signals for one clock.

Let me attach a figure ...

The figure was drawn for the slower SRAM on the BeMicro, however, its got much the same timing parameter names as the DE115 SRAM.

Cheers,

Dave

--- Quote Start ---

Err.. isn't the part on the DE2-115 a 10 ns access time part?

IS61WV102416BLL-10

Anyway, it supports back to back write operation, so he can write at 100 or 125 MHz.

--- Quote End ---

From the user manual of Terasic, it says the SRAM has maximum performance of up to 125MHz under condition of standard 3.3V....

so i thought 1/125MHz = 8ns ?? no?

And what do you mean by "back to back" ? how does it work?

Michael

If i am using NIOS 2 to control my SRAM, do i need to concern about all of these timing issues? isn't all these be taken care of?

Michael

--- Quote Start ---

From the user manual of Terasic, it says the SRAM has maximum performance of up to 125MHz under condition of standard 3.3V....

so i thought 1/125MHz = 8ns ?? no?

--- Quote End ---

You can't believe everything you read :)

Look at the timing diagram I posted, and compare it to the timing diagram in the SRAM data sheet. If the low time of sram_weN is adjusted to be exactly 8ns, then the actual low time of the FPGA pulse must be 8ns PLUS the clock-to-output uncertainties. Since the SRAM has setup parameters relative to the falling edge of write-enable and other timing parameters relative to the rising-edge of write-enable, you need an additional clock at either end.

The fastest you can run this SRAM is a 3 clock write cycle. If your clock is 125MHz, then your clock period is 8ns, but your write-enable low time would have to be two clocks to ensure you meet the 8ns low-time requirement of the SRAM. Hence, you have a 4 x 8ns = 32 ns write cycle, so your maximum write performance is 1/32ns = 125MHz/4 = 31.5MHz.

You could make the interface faster by using a clock higher than 125MHz, but you'd still be limited by the clock-to-output uncertainty of the FPGA outputs.

Cheers,

Dave

--- Quote Start ---

If i am using NIOS 2 to control my SRAM, do i need to concern about all of these timing issues? isn't all these be taken care of?

--- Quote End ---

The tools only do what you tell them. If you do not put in timing constraints, then the tool will happily not apply them.

You need to apply appropriate timing constraints to the SRAM interface, or check that the IP core you use includes a TimeQuest .sdc file that applies the appropriate constraints.

Cheers,

Dave

I really have 0 experience on this... i thought SRAM is suppose to be easy.. at least easier than DRAM. Does anyone have some kinda tutorial i can go through on SRAM? i never learn anything about timing analysis, timing contraints... nothing on timing stuffs, only functional, now i know how important it is.

Michael

--- Quote Start ---

I really have 0 experience on this... i thought SRAM is suppose to be easy.. at least easier than DRAM. Does anyone have some kinda tutorial i can go through on SRAM? i never learn anything about timing analysis, timing contraints... nothing on timing stuffs, only functional, now i know how important it is.

--- Quote End ---

Read the TimeQuest guide written by Rysc on the Altera wiki:

http://www.alterawiki.com/wiki/timequest_user_guide

I have some questions for Rysc related to asynchronous interface TimeQuest constraints. I'm putting those questions into a document dealing with SRAM constraints as the example. I'll post that in a day or so when I get it done (the figure above will be in it).

Cheers,

Dave