Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,306 Views

Unable to use Nios II/e?

I've been trying to instantiate a Nios II/e core with no success. I am using external SRAM, one 16 bit PIO, and a 50Mhz clock. 

 

I am able to synthesize the design, generate the sof file, and configure the Cyclone II. However, when I try to load an application (via JTAG), I get the following message from Nios II EDS: "Downloading ELF Process failed". Additionally, I see the following in the Eclipse console: Using cable "USB-Blaster [USB-0]", device 1, instance 0x00 

Pausing target processor: not responding. 

Resetting and trying again: FAILED 

Leaving target processor paused 

Finally, this is what I don't get, using the exact same design, if I switch to Nios II/s, the design works perfectly. I've searched this forum and Google, but I can't seem to find anything which might point me in te right direction. Does anyone here have any ideas which might help me? 

 

(I am using Quartus II 32bit Version 11.1 Build 216 11/23/2011 SJ Web Edition Service Pack 1 with a Terasic DE1 board - Cyclone II)
0 Kudos
10 Replies
Altera_Forum
Honored Contributor I
74 Views

I'll just copy/paste what I wrote here (http://www.alteraforum.com/forum/showpost.php?p=141303&postcount=2): 

 

 

--- Quote Start ---  

When the CPU isn't responding, it can be either because the .sof file hasn't been loaded, it isn't the right .sof file, or one of the critical signals (clock, dada) isn't correct. Check all those points:[list][*]did the project compile successfully?[*]are you using the correct .sof file? If you are missing some licenses, the design could be compiled in a *_time_limited.sof file instead. Check the report[*]did you assign the ports to the correct FPGA pins? Especially reset and clock[*]is the clock running?[*]does the reset signal have the correct polarity. The reset_n pin from the SOPC builder project is active low[/list] 

--- Quote End ---  

Altera_Forum
Honored Contributor I
74 Views

Thanks for your response. I have a few clarifications/questions, though: 

 

Here are things I already checked: 

  • The design compiled successfully 

  • I used the correct sof file 

  • The clock pin is assigned correctly and is working (I added a 1 Hz LED "blinker" running off that clock just to be sure) 

  • Switching to the Nios II/s does work. 

 

 

There is one thing I did which I now suspect might be a "stupid mistake" -- I tied the reset signal to logic level high (because I did not have an incoming reset signal). Is this correct? Or should I at least tie this to a push button or something? 

 

In any case, though, it's only the /e version which doesn't work...
Altera_Forum
Honored Contributor I
74 Views

oh I forgot something. Do you have a license for the Nios CPU? If not then you will have to use the *_time_limited.sof file instead of the regular one, and you'll have a window open just after you programmed the FPGA saying you are in evaluation mode. You mustn't close that window or the CPU will stop running.

Altera_Forum
Honored Contributor I
74 Views

 

--- Quote Start ---  

oh I forgot something. Do you have a license for the Nios CPU? If not then you will have to use the *_time_limited.sof file instead of the regular one, and you'll have a window open just after you programmed the FPGA saying you are in evaluation mode. You mustn't close that window or the CPU will stop running. 

--- Quote End ---  

 

 

No I do not. But as I said, I've already gotten the /s version (which requires a license) to work, albeit time limited/JTAG bound. 

 

It's the /e version (which does not require a license) that I can't get working.
Altera_Forum
Honored Contributor I
74 Views

Ahhh sorry I mixed up the two. Is the CPU the only thing you change between the two designs? Is the project fully constrained and does it meet all timing requirements? 

Is the JTAG module slave interface on the CPU connected to both the instruction and data masters? In some cases you need to add a pipeline bridge between those masters and the JTAG debug module in order to meet timing requirements.
Altera_Forum
Honored Contributor I
74 Views

As a final resort, I created a fresh project with just the CPU, on-chip RAM, and a PIO connected to LEDs. I did not constrain the LED I/O pins (to be honest, I don't know how to... yet), but I did constrain the input clock. Other than the LED I/O pins not being constrained, all timing requirements were met. 

 

Same result: /s works, /e does not. 

 

I don't remember how I connected the JTAG module. I'll check when I get home.
Altera_Forum
Honored Contributor I
74 Views

By the way, suppose I need to add a pipeline bridge to meet timing, what's the best way to do it? 

 

Would this be correct? 

JTAG MM Master --> Pipeline Bridge --> <Nios II Avalon "system bus">
Altera_Forum
Honored Contributor I
74 Views

It's the other way round, the JTAG module is a slave. You'd need to so something like: 

Nios Instruction master + Nios data master -> Pipeline Bridge -> JTAG debug module. 

It's a good idea to try to do a minimal system that still reproduces the problem, it can make it easier to debug. Could you also add a small signaltap instance (that for example monitors the reset signal) and try to connect to it once the FPGA is programmed? That way we can determine if the problem comes from the Nios CPU itself or the JTAG interface. 

The LED pios are easy to constrain, just declare them as false paths so that Timequest doesn't verify their timing. But if this is the only error that Timequest gives then you have nothing to worry about, timing wise.
Altera_Forum
Honored Contributor I
74 Views

Dammit... turns out the problem wasn't with the hardware or the design. 

 

The /s started giving me problems too. After mucking around, I finally figured out it was a problem with the Nios II EDS. (I'm running Ubuntu 11.10... I've already had to fix a few problems with Quartus on Ubuntu). Invoking nios-download directly from a terminal worked for both /e and /s.
Altera_Forum
Honored Contributor I
74 Views

Another possible cause using the stock DE0 project example is the PLL. Our build used the legacy pll. There were no warnings from SOPC_Builder (11.0) other than it was being phased out and should be replaced with altpll. 

No errors from compiling but lots of warnings, and a compilation that showed no use of PLLs and very little logic in the design. Replacing the PLL with AltPLL fixed it.
Reply