To build a FIFO using SRAM

--- 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

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 ---

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

--- 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

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 ---

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

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 ---

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 ---

If your FPGA has a clock-to-output uncertainty of 0ns, then sure you would get a 10ns pulse out of a 100MHz clock. However, realistically, you will have clock to output delays on the orders of tco(min) = 2ns, tco(max)=4ns (or perhaps larger), so each write low assertion time would need to be two clocks to guarantee you meed the SRAM 10ns write-pulse low time timing.

It depends how robust he needs the design to be.

Cheers,

Dave

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 Start ---

The width of ADC is 14 bits, but i am sending 16 bits across every transfer.

--- Quote End ---

Ok.

--- Quote Start ---

The SRAM on my DE2-115 has access time of 8ns, so its maximum performance is 125MHz, so i guess it is more than enough to hold 2MB of sample from the ADC at 65 MHz. Am i right on this?

--- Quote End ---

Have you checked the SRAM controller timing? An SRAM write needs three clock cycles; chip select asserted with write-enable high, then write-enable low, then write-enable high again. This pulse sequence is required to meet all of the timing parameters of the SRAM. To get 65MHz writes to 16-bit SRAM, your FSM will need to run at 3 x 65MHz = 195MHz, which seems do-able, but you'll have to check.

--- Quote Start ---

I only need a "window" (1024000 ADC samples), not to stream continuous raw data, as some portion of the data will be lost(which is fine).

I want to see the streaming of "window" of data.

--- Quote End ---

However, the window is consecutive samples at 65MHz, so that is the data rate you need to support while capturing the data.

Cheers,

Dave