Forum Discussion

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

Nios II CPU and Firmware access Problem

About the application: We have a multichannel application. Each channel design is based on a Altera Cyclone FPGA, which includes an internal NIOS II processor and an external program 32bit ASRAM (asynchronous sram). The Nios runs at 100MHz and is fetching program data from the Asram, each 10nsec. There is an Avalon-tri-state-bridge-slave peripheral and associated custom component within the Nios block which serves as the interface to the Asram.

About the problem: The design works OK in some channels within the required temperature range of -40 to +85’C. But in some channels the design fails when the temperature rises above +74’C. In such a case the Nios program fails. We’ve found that in the failed channels the Asram’s address and data lines routing on pcb are longer and therefore additional delays are inserted and the provided data doesn’t meet the required Tsu time of the NIOS CPU read cycle.

Our goal: Without changing the PCB, we are trying to compensate this additional delay by setting some constraints within the FPGA or changing the Asram interface block within the SOPC builder to force faster paths between the pins and the Nios block.

Our questions: Does anyone have any suggestion of how to fix out problem ? Which assignment functions could we use in the Quartus II Assignment Editor to set minimum delays on the Asram data and address path\pins??(We’ve tried to use the ‘Maximum Delay’ assignment but couldn’t find the ‘From’ path signal, which resides within the Nios block. We used the RTL editor but all the signals we chose, always ended in the Ignored Timing Assignments.

Thanks in advance and regards,

M. Kopolovich

Engineering Department

Em: menachem_k@excalibur.co.il

Excalibur Systems

Manufacturers of Quality Avionic Equipment

Wb: http://www.mil-1553.com

3 Replies

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

    Hello,

    This was a similar posting albeit about SDRAM. I reckon a lot of the comments are relevant though.

    The Fast Output Enable Register option would probably help you here too. Apply this to the address and control pins (Only works if they are driven direct from a register). Hopefully this would reduce the control and address latency to the RAM
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Hi,

    You are correct the Fast Output Register is the right way. But we already found out that the NIOS SOPC builder set those definitions on all ASRAM pins, so no additional delay can be spared inside the FPGA. The only solution we came up is degrading the Nios speed to 95MHz.

    thanks and regards,

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

    you could change the waitstates on the asram component. You would add a cycle of latency to the asram interface, but that could be compensated for perhaps by increasing the cache?

    --dalon