Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
9 years ago

DE2-70 SRAM timing question

Hi

First off, I'm fairly new to FPGA programming, so I apologise in advance for any obvious questions, and thank you for your patience.

So I'm currently trying to design a processor that makes extensive use of a cache that interfaces with some form of main memory, my choice for this memory is the SSRAM on the perscribed DE2-70 board via their pins.

I'm aware that interfacing with main memory can result in significant delay, and I was wondering if there's anyway to generate a flag that gets set when the write/read operation finishes?

Or is there a set read delay and write delay associated with the chip, in which case I can just stall until that specific number of cycles have passed?

I've been looking for a while, but I couldn't find any information pertaining to this problem.

Thanks

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    What entity is going to look at the flag you're intending to raise? A Nios processor? Or some other internal logic?

    Accessing external SSRAM won't incur any 'significant' delay. Unless you're hoping to operate your logic/Nios at a very high clock frequency (which will be tricky with Cyclone II), the SSRAM on that board will operate at the same frequency as your logic. SSRAMs offer single (or double) clock cycle accesses. So any flag you raise is only going to be high for 1 or 2 clock cycles. I accept burst accesses are slightly longer, but arguably still not significant.

    However, if you're using Nios, it will handle these accesses without the need for a flag. If you're writing your own logic then you will design your SSRAM controller in such a way that the logic always knows where in the SSRAM access cycle it is, and when it's finished.

    Cheers,

    Alex
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    --- Quote Start ---

    What entity is going to look at the flag you're intending to raise? A Nios processor? Or some other internal logic?

    Accessing external SSRAM won't incur any 'significant' delay. Unless you're hoping to operate your logic/Nios at a very high clock frequency (which will be tricky with Cyclone II), the SSRAM on that board will operate at the same frequency as your logic. SSRAMs offer single (or double) clock cycle accesses. So any flag you raise is only going to be high for 1 or 2 clock cycles. I accept burst accesses are slightly longer, but arguably still not significant.

    However, if you're using Nios, it will handle these accesses without the need for a flag. If you're writing your own logic then you will design your SSRAM controller in such a way that the logic always knows where in the SSRAM access cycle it is, and when it's finished.

    Cheers,

    Alex

    --- Quote End ---

    Given that this is for a processor design course, I'll probably have to handle this with my own controller, using the SRAM input/output pins.

    Is there a specific document that identifies how many clock cycles it takes to read and write (specifically using the 50MHz clock), or will I need to develop a cycle by cycle verification of the process?

    Additionally, do you know if there's an SRAM content viewer/editor built into Quartus II to make verification of data input/output easier?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Quartus has an "in-system memory content editor (http://quartushelp.altera.com/16.1/index.htm#program/red/red_com_editor.htm)" built in - see the Tools menu in Quartus. However, it'll only let you monitor/change memory internal to the FPGA, via JTAG.

    It is worth playing around with. You should be able to setup an internal RAM to mirror a portion of external SSRAM. It requires more code and, rather fundamentally, a working interface to your external memory. However, it can be a useful debugging tool.

    Cheers,

    Alex