I have some custom boards (cyclone, NiosIIe 33Mhz) that exhibits strange behavior on reset (either full POR OR soft reset (DEV_CLRn)). The behavior is that the Nios sometimes executes the code at the reset address as it should, but sometimes executes code located elsewhere in memory. The problem was not obvious until multiple applications were loaded in flash. Power and clocks seem OK. All memory tests so far have passed, and once an application is running, the other apps can also be run (by jumping directly) and they all appear stable. For testing, I have modified "hello_world#1","#2","#3" builds loaded at different locations in flash. They all have have the bootstrap loader and load to the same place in SRAM.1) Looking at the configuration signals on the EPCS1S (AS) device, I see a couple of strange things. nCS is asserted 3 times during configuration, two short pulses and one long one. The cyclone data sheet shows one long assertion. Also, DATA shows some slow rise ramping during the first two nCS assertions, but is clean after that. DCLK is clean but is active during some the data ramping where the data could not possibly be valid. Both CONF_DONE and nSTATUS behave as if all went OK. Should I be concerned about these signals, or is CONF_DONE and nSTATUS enough? 2) I notice that Quartus has an option to make DEV_CLRn a global reset. The default is no. The Nios is being reset without this enabled, but is it just the core? When would I want to enable this? 3) There are several posts about the reset signal, and using the PLL to delay reset. I do see a bunch of narrow pulses/edges on my reset (DEV_CLRn) which could be the cause of my problem. I am looking into fixing this first. The cyclone data sheet lists a max rise time for inputs of 40ns. Does this apply to DEV_CLRn as well? Is there some additional logic on this signal to make it more robust or is it just like any other input? thanks
if you are using NIOS 1.1also check http://www.altera.com/support/ip/processor...vkit1.1-er.html (http://www.altera.com/support/ip/processors/nios2/ips-nios2_devkit1.1-er.html) - Errors when booting from EPCS Device - JTAG UART is unstable after device-wide reset perhaps this helps
Thanks,I was not using the global reset, and I guess this is a good reason not to. I am not loading SW from the EPCS, only FPGA config. My SW comes from a separate Flash.
What does your reset circuit look like?Also the CONFIG_DONE, nSTATUS pins are pulled high in some designs. I would read up on those pins to learn more though. The posts about the delay on reset are talking about delaying the reset signal so that you can be assured the clock coming out of the PLL are stable (if you don't use PLLs then you may not need this circuit, but it would be handy to help debounce a reset switch if that's present). To see this circuit look at a reference design in your Nios II installation folder.
My reset is provided by a LT power supervisor that monitors 5,3.3,1.5. I have probed the sensing pins and there are no glitches. It would have to be very noticable since the chip filters out power glitches. The noise on reset has to be xtalk from adjacent traces or from one of the half dozen devices it drives. My rise time is 4x slower than the 40ns specified, but it is not the source of noise. CONF_DONE and nSTATUS are pulled up as indicated in the cyclone datasheet for one EPCS device.Hmm.. I just noticed an odd thing. I was probing the reset signal and the flash CS on the same pod of a logic analyzer. When I remove the probe from the flash, the reset cleans up. There is some loading from the probe - I'll have to investigate further.
If you have an active probe for an oscilloscope kicking around (well something that expensive you don't just have it kicking around anyway), you may want to probe with it to limit the load you put into the circuit.Good-luck (I know how much a pain these issues can be)
No need for active probes - simply using a scope instead of the analyzer greatly reduces the loading (1M vs 100k).Comparing the reset (DEV_CLRn) against the flash CS shows a problem. The Nios comes out of reset and starts fetching instructions from flash when DEV_CLRn gets to about 1.2v. The flash is not even ready at this point since its own reset is not considered high until about 2.3v. I have to assume the Nios is occasionally fetching junk during reset. Clearly it is not a good idea to use the same reset signal for both devices unless you can guarantee a very fast edge. The Nios core reset would probably need to be delayed in most designs using flash. I have few resources (LEs or pins) to implement an internal solution but that is still preferrable to adding components. Does enabling the PLL really use any LEs, and is there a mininum delay associated with waiting for lock? thanks
The PLL is a dedicated circuit in the FPGA so you do not have to worry about LE resources being used. The delay circuit in the reference designs are based off a 50 MHz clock (it's clocked off a crystal), and counts up. I looked at it and made my own reset block (easier to copy it between designs). It has 10 bits and when it rolls over it stops, so it counts for 1024 clock cycles off a 50Mhz clock that's 20ns * 1024 = 20 us (that's overkill so you may not need that much but if you don't care about startup delay that should work fine). I would give yourself at least 1us or the amount of time for the reset voltage to hit the right value (whatever is longest).The reset block is a 10 bit counter with a little bit of logic so it's going to be around 12-15 LEs. So you are looking at a PLL and 15 LEs to help stabilize things. But if you don't already use a PLL in your circuit you don't need to add it (the delay was to implement a wait for the Nios core that was driven from the PLL, so in your case you just want to delay the core until the flash is ready).
Adding the reset delay block solved it. Now the flash is well out of reset before the Nios does its first fetch. There is still some hash on the reset signal that looks like xtalk from the flash CS (less than optimal routing on the board). Before, that hash would strike when reset was still down at switching thresholds. Now it does not occur until reset is up at VCC - gotta like that. Still I think the erratic boot behavior had more to do with fetching (bad) instructions too early than with noise.
I agree you were probably fetching garbage at startup. Well glad that worked for you, now you just need to worry about routing (or if it's good enough might as well not touch anything since it's working lol).
You might be able to eliminate xtalk from Flash_CS to RESET line by setting slew rate control on Flash_CS pin in Quartus and / or setting the Flash_CS output pin to have a lower max current drive capability in Quartus (both are options in the Assignment Editor, reached from the Assignments -> Pins menu option). This will only work for you if you can aford the extra setup time requirement this adds to your flash access cycle. If on the Avalon bus you've set a 1 clk setup state on transaction, you should be fine...
Good idea. Both settings seem to be supported on cyclone parts. Do you know if there is a way to apply these settings globally if I wanted to try it out on the entire chip?
Probably through the Assignment editor (I think you may have to do this setting to individual banks though).Good idea Respun, you may have saved him a Re-spin lol
As an update I did try the slew rate and current strength options.Setting slew rate to Slow for my flash CS made no discernable difference to the rise time of this signal. Perhaps this is the default? Setting current strength to minimum did reduce xtalk considerably. Rise time on the troublemaker went from < 3ns to about 7ns. I'd like to know where I look to see what the global defaults are, or if there is a automatic pin by pin assignment based on timing constraints. I assume most would want to have the slowest edge that still provides some timing margin.