Nios II CPU and Firmware access Problem

[Altera_Forum]

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

[Altera_Forum]

By asynchronous RAM, do you mean you present put a read address out, it gets data from the RAM asynchronously, and then you clock the data into the FPGA, all within 10ns? Most RAMs have a sizable access time and this just isn't possible. (You might also mean that the RAM doesn't have a clock, but are doing everything over multiple stages.) 

 You don't need to know the source register to make an assignment. For something quick, just do a set_max_delay -to [get_ports addressname*]. (I'm guessing you're using TAN, but would strongly suggest switching to TimeQuest when you can.) In TAN, just put a Tco assignment on the pins in the Assignment Editor. In both cases, you don't need to know the source register's name. Recompile so the fitter now tries to meet your tight requirement. In TAN, go to the Tco panel, find the worst Tco for that bus, and right-click List Paths. It will show the path in detail below, where you can break out all the components(clock delay, data delay, etc.) The main thing you are looking for are: 1) Did it use an I/O register 2) Is the output delay chain as fast as possible(only some architectures have an output delay chain, and it is almost always bypasses unless you have min Tco requirement, so this isn't that big of a deal).  You can also find out about both of these in the Fitter Report -> Resource Utilization. There will be an Output Pins section that has a column saying if the output registers is used, and there will be a Delay Chains Report here also that tells what the delay chains are set to(0 is the fastest). Just another way to skin the cat. If you're using the I/O register and have no delay chain, then from a fitter perspective there's nothing else you can do. You can increase the Current Strength on the I/O, and in SIII you can increase the edge rate.   Note that this is not the correct way to do timing analysis, i.e. you're making up a number for your Tco and trying to get it as tight as possible. The correct way, for example, would be to calculate it off the system requirements. For example, if you have a 10ns turnaround time, and the RAM access time was 5ns and the board traces were 500ps total, then you would be using 5.5ns of that period outside the device. That would mean your Tco and Tsu requirements would have to be 4.5ns total(you'd have to split between the two requirements, which would be some trial and error), but as I said, you probably won't make timing, if that's what you're trying to do. Note that timing models will be slower than what you're seeing on the board. Static Timing Analysis slow models use worst case conditions, which is what you want to reliably ship a product, but most board tests are not under worst case Process, Voltage and Temperature(PVT).

[Altera_Forum]

--- Quote Start ---  ...and the RAM access time was 5ns...  --- Quote End ---    Are there async SRAM that fast at all?

[Altera_Forum]

--- Quote Start ---  Are there async SRAM that fast at all?  --- Quote End ---    We looked at this a few months back. The fastest we found was 8ns  http://www.gsitechnology.com/async_8mb.htm  At 100MHz leaves a 2ns margin....Pretty tight!

[Altera_Forum]

Yes there are ASRAMs from GSI Technology 7nsec at Industrial grade.

[Altera_Forum]

Mr RYSC thanks very much, 

everything you sad was helpfull and we trying it out now.