Forum Discussion

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

External SRAM timing

Hi

Based on comments I've seen on the software side of Niosforum, I am getting the impression that there may be timing issues when using external SRAM and the Altera supplied components. I could use some help.

I'm using a custom board with 71V416 SRAM, basically the same approach used in the Stratix Nios development Kit. Nios clock speed is 40 MHz.

When my software was smaller, I ran it out of the on-chip memory and it seemed reliable. The program has grown to the extent that it won't fit in on-chip, so I moved the code and data storage into external SRAM.

Now, it seems somewhat unreliable. When running the program with the IDE debugger, it occasionally "blows", with a bunch of "y"s on the console. My impression, supported by stuff I've seen on the software side, is that the SRAM chips may need some setup time, possibly also a wait state.

I don't want to wastefully slow down the system by adding setup and wait. And I don't want to meddle with something that's pretty far along and almost works.

Can someone shed some light on this? Can I modify the timing of the Altera supplied 71V416 code without ripping everything apart? What is the ideal timing, if not as Altera supplies?

Thanks in advance

4 Replies

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

    For the benefit of all, I have at least partially addressed the problem. The following may help others...

    Yes, as others have said here, memory speed does seem to be at least part of the problem. The issue surfaced when I moved my memory from onchip to external.

    The easy way to slow down the program is to edit the .pl file. Your structure may differ, but mine was at

    C:\altera\kits\nios2\components\altera_nios_dev_kit_stratix_edition_sram2

    Editing the class.ptf file doesn't work. Apparently SOPC looks at the mk_sram.pl file and adds wait states depending on the clock speed chosen for the design. In my case, at 40 MHz, it didn't add any.

    By editing the mk_sram.pl file to add wait states above 39 MHz, I caused this to happen.

    I still have issues to resolve, but this was a big step in the right direction.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Further....

    With timing 1 setup, 1 wait, 1 hold performance was much better, but still some odd errors.

    Changed timing to 2 setup, 2 wait, 2 hold and now perfect.

    I don't know why on earth so much slack time is needed, but that's an issue for later. At this point, it's working reliably
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    we especially had a problem with the setup time of

    SRAM (ISSI) IS61LV25616AL-10T.

    I also got the tip from altera engeneer to reduce driver

    strengh on bus signals e.g. with

    set_instance_assignment -name CURRENT_STRENGTH_NEW 4MA -to D\[0\]

    we now use setup 1,wait 1, hold 1 cycle and 4 mA on bus signals

    (signals have less reflections)