Forum Discussion

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

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)

10 Replies

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

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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.