To build a FIFO using SRAM

--- Quote Start ---

Hi Michael,

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.

Cheers,

Dave

--- Quote End ---

Dave,

From your previous post, is a NIOS 2 processor an option in the design? cause you said "(eg. the JTAG-to-Avalon-MM bridge OR a NIOS II processor).". I thought NIOS 2 is used for commanding data movement?

For me to get some reassurance, do you think that this design will work on the DE2-115's SRAM at 65MHz? i need to know this before i dig deep into this, as i have limited time to work on this project.:(

Thank you.

Michael

--- Quote Start ---

During the write burst operation, can i just keep WEN, CEN, OEN, UBN, and LBN low the whole time?

--- Quote End ---

No, you can't.

During a write-burst, you can keep chip-select asserted and the byte-enables asserted, but the write-enable signal (weN) needs to be pulsed. Writes to the SRAM occur on the rising-edge of write-enable. However, the SRAM writing timing requirements have timing parameters that are relative to both the falling-edge and the rising-edge of the write-enable pulse. Look at the SRAM data sheet, tSA = 0ns indicates that the address must be valid for no less than 0ns when write-enable asserts, and tHA = 0ns indicates that the address must be valid for no less than 0ns when write-enable deasserts. Given that the FPGA address clock-to-output timing is different than the write-enable clock-to-output timing, there is no way you can guarantee across all temperature variation that you can meet this timing by changing the address on the same clock cycle as you change the write-enable pulse, hence you must have a clock at the start, and a clock at the end, to ensure your FPGA controller meets the SRAM timing.

Cheers,

Dave

--- Quote Start ---

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

During the write burst operation, can i just keep WEN, CEN, OEN, UBN, and LBN low the whole time? do i really need to pulse LBN and UBN ?

UBN = active low upper byte access

LBN = active low lower byte access

CEN= active low chip enable

WEN = active low write enable

OEN = active low output enable

Michael

--- Quote Start ---

Answering my own question... Back to Back means the second data is write to the SRAM right after the first data is wrote to the SRAM. .. i think

--- Quote End ---

Yes, that is correct. The back-to-back writes still have to satisfy the 0ns setup and hold timing requirements, so you still need to have a clock with write enable high at either end of the write, i.e., two clocks with write enable high between back-to-back writes.

Cheers,

Dave

--- Quote Start ---

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

--- Quote End ---

Thanks DAVE!

--- Quote Start ---

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

--- Quote End ---

Answering my own question... Back to Back means the second data is write to the SRAM right after the first data is wrote to the SRAM. .. i think

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

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

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