Forum Discussion

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

Access to external RAM

I have a system that appears to work at a system clock of 70 MHz but fails to work at 85 MHz. @85MHz, when we run the firmware it behaves in a very strange manner. Often it will get to a specific point and hang. We tried to analyze the problem in debug mode but found that at different points in the code the debugger seems to "fly" to some unknown place. When this happens, no matter what we do, the debugger will no longer continue to step through the code and we are left to rebuild and download again.

We thought that possibly there were instructions that were being lost in either the writing to or reading from the ASRAM. How can I check this ? I know that the firmware that is written in c code is translated into instruction sets – and we can get a listing for it. But what is stored directly into the ASRAM and how can I view this ?

Anyone have any other suggestions?

Note 1. Our ASRAM has an access time of 10nS. It is for this reason that we think that the problem is with the ASRAM since the system seems to work @70MHz.

Note 2. I have implemented a custom tri-state slave as the interface for ASRAM without any adjustments to any of the timing configurations. This is the only slave component that is connected to the associated registered tri-state bridge. I tried to implement the ASRAM as a direct slave without a tri-state bridge but it didn’t work at all. I am not sure why but I guessed that that the registering of the signals from the tri-state bridge possibly help with the synchronization of the signals ?

6 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    tried already with inserting a waitstate?

    Has the outputs to the RAM registers? Otherwise the tco will eat some of the timing budget for the RAM. (also the setup time (input registers??).

    Of course this will make the interface slower.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    I have a system that appears to work at a system clock of 70 MHz but fails to work at 85 MHz. @85MHz

    --- Quote End ---

    I have a Nios system running @ 80MHz from PLL.

    I am interfacing to an external asynchronous SRAM with a nominal 10ns access time.

    I have to use 1 setup cycle and 1 wait cycle to make it work.

    How is the timing set in your SOPC module?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    How about writing a memory test program that runs in on-chip memory?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    With the higher clock speed, would you need to change the phase of the clk to the RAM? You could be violating s&h times, perhaps you should shift the phase of the clock +45' relative to the nios2 clk and see what happens.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    He is talking about Asynchronous SRAM which does not have the clock signal going into.

    What clock are you going to shift the phase of?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Good point.

    Have you been able to confirm with a scope that the access time is not being violated?