To build a FIFO using SRAM

[Altera_Forum]

Hi, 

 I would like to build a DCFIFO using a SRAM chip on DE2-115. Any idea on where i should start?  I know SRAM reads and writes on a different clock cycle as the dataIn and dataOut share the same bidirectional databus, but do you think i can increase the frequency by 2 times (based on spec sheet, max performance of my SRAM is 125MHz), meaning if my ADC data coming in at 60MHz, i am inputting data and outputting data to/from my SRAM on an alternate cycle at 120MHz. is it possible? if yes, what are the things i need to be concerned about?    regards, Michael

[Altera_Forum]

--- Quote Start ---   I would like to build a DCFIFO using a SRAM chip on DE2-115. Any idea on where i should start?   --- Quote End ---  You'd be designing a FIFO, not a (dual-clock) DCFIFO.    --- Quote Start ---   I know SRAM reads and writes on a different clock cycle as the dataIn and dataOut share the same bidirectional databus, but do you think i can increase the frequency by 2 times (based on spec sheet, max performance of my SRAM is 125MHz), meaning if my ADC data coming in at 60MHz, i am inputting data and outputting data to/from my SRAM on an alternate cycle at 120MHz. is it possible? if yes, what are the things i need to be concerned about?   --- Quote End ---  You'd likely want to perform burst writes and reads to the SRAM (its likely a clock or two faster, since there is no need for the SRAM controller FSM to conservatively insert bus turn-around cycles).  So you'd have your ADC write to a DCFIFO or dual-ported RAM internal to the FPGA at 60MHz, and then once the FIFO was filled above a threshold, start a DMA to the SRAM at its maximum speed. Then when that DMA is done, perform another DMA to read older data back.  However, what's the point? You're just adding delay. Of course, if you are aligning multiple different data streams, this might be what you want.  Cheers, Dave

[Altera_Forum]

Dave, 

 Is there any DMA IP core in Quartus 2 i could use? or do i need DMA if i am writing to a SRAM? what does DMA do? can i just use a controller(with a up counter for address bus, etc..) ?   regards, Michael

[Altera_Forum]

Why dont you make a system with NIOS2, DMA and a SRAM controller to do this? It would be easier

[Altera_Forum]

Hi Michael, 

  --- Quote Start ---   Is there any DMA IP core in Quartus 2 i could use? or do i need DMA if i am writing to a SRAM? what does DMA do? can i just use a controller(with a up counter for address bus, etc..) ?   --- Quote End ---    Read the Altera documentation on SOPC Builder (old tool) and Qsys (newer tool), and the Avalon bus specification.  What you want is an SOPC/Qsys system with an Avalon-ST ADC source, an SGDMA controller, an SRAM controller, and an Avalon-MM master (eg. the JTAG-to-Avalon-MM bridge or a NIOS II processor).  You will need to design the ADC to Avalon-ST streaming component (its pretty simple though). You can then use the SGDMA controller for Avalon-ST (ADC) to Avalon-MM (SRAM) data movement.  What are you trying to do with the data? Capture snapshots of data, or continuously stream it somewhere (other than the SRAM)?   Cheers, Dave

[Altera_Forum]

My ADC is sampling at 65MHz. i am trying to capture 2MB(1024000 samples) of ADC data and send to through QuickUSB at 30MB/s, and graph it on my laptop continuously . 

 Do you think NIOS 2 is capable of handling 65MHz data? or the SRAM controller is running at slower speed than 65MHz?  regards, Michael

[Altera_Forum]

Hi Michael, 

  --- Quote Start ---  My ADC is sampling at 65MHz. i am trying to capture 2MB(1024000 samples) of ADC data and send to through QuickUSB at 30MB/s, and graph it on my laptop using Matlab.   --- Quote End ---    What is the bit-width of the ADC?    --- Quote Start ---   Do you think NIOS 2 is capable of handling 65MHz data? or the SRAM controller is running at slower speed than 65MHz?   --- Quote End ---    The NIOS II never actually touches the ADC data, its just there to coordinate movement of the data.  The key design parameter is whether you can find a memory target that can maintain a sustained data transfer rate of 65MHz x ADC bit-width.  You'll need to see whether the SRAM or SDRAM on the DE-115 can handle that data rate.  Cheers, Dave

[Altera_Forum]

Dave, 

 The width of ADC is 14 bits, but i am sending 16 bits across every transfer. 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? 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.    Regards, Michael

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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