Forum Discussion

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

Verify Failed in Nios II

I keep getting some variant of the following message:

--- Quote Start ---

Using cable "USB-Blaster [USB-0]", device 1, instance 0x01

Processor is already paused

Reading System ID at address 0x000010F0: verified

Initializing CPU cache (if present)

OK

Downloading 00008020 ( 0%)

Downloaded 4KB in 0.0s

Verifying 00008020 ( 0%)

Verify failed between address 0x8020 and 0x8D93

Leaving target processor paused

--- Quote End ---

I have searched the forums and found several good pointers, but so far nothing has worked.

I've spent a lot of time now, trying to optimize my PLL for the SDRAM phase shift timing. I am using Cyclone II device, so an external (e.g. e0) PLL output is not an option. However, I am seeing the problem even when trying to Debug with the hello_world_small example, with all of the memory selections as on-chip RAM. Older designs of mine still work just fine, but if I try to change even the slightest (seemingly unrelated) thing, I run into the same problem.

Any more pointers?

Thanks in advance!

14 Replies

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

    Unfortunately my thread from the old forum was lost on this subject but here goes off the top of my head.

    • Check your top level connectivity for issues (like dangling nets or signals pulled high or low)

    • Check your pinout to make sure you are using the correct I/O in your design

    • If you are using the new "Altera ALTPLL" component don't use the PLL lock signal as a filter for reset_n (you'll get stuck in reset). This will be fixed in the next version of the IP.

    If I think of other things to check I'll add them.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    --- Quote Start ---

    • If you are using the new "Altera ALTPLL" component don't use the PLL lock signal as a filter for reset_n (you'll get stuck in reset). This will be fixed in the next version of the IP.

    --- Quote End ---

    Thank, BadOmen. Those are all good tips. I'm pretty sure everything is connected and wired to the correct pins, but I will double check. That last one is something I hadn't heard before...can you expand on that please? Specifically, what do you mean by "new"? I am doing exactly as you describe, connecting the ALTPLL locked pin to the reset_n of the CPU, so that definitely concerns me. I am using an old version of the ALTPLL though (6.0). Is this only a new problem? Maybe that's related to other problems I've had that have forced me to stick with the older version rather than upgrade...

    If it is a problem with all versions, what would you recommend as a workaround? i.e., how do I ensure that the processor only starts up cleanly with a good clock?

    Again, thanks for your responses!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hmmm couldn't find it on the web. Ok, the issue I was referring to only occurs in 9.0 with the new "Altera ALTPLL" component that was introduced in 9.0 The issue will be resolved in the next version of the tools but essentially the Avalon-MM slave port of the PLL had it's reset line wired directly into the PLL areset port. So if you filtered reset_n from outside the system with the PLL locked signal you have a reset loop and you'll get stuck. I only added this to the post just in case others run into it, I don't think you ran into this otherwise your system would have never worked.

    I thought of another thing that could cause issues. If you are using a Cyclone/Stratix II or earlier Nios development kit, make sure the reconfig_request_n signal is either pulled high, or that pin is set to input tristate (there is a pullup on that line). The board user documentation explains what that signal is for so I won't go into the details of the failure that will occur. By default Quartus II will set unused signals to ground on the older device families so if you didn't connect reconfig_request_n in your design, it would get pulled low by default..... which means you .sof would get overwritten as soon as the design comes up live. If you ran into this chances are by the time you go to download your software you are using the factory or user hardware that's programmed into flash.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hello mgirwin, (http://www.alteraforum.com/forum/member.php?u=1977)

    Check your output lines if you use external memory. Perhaps you didn't set the direction for data or address bus correct. I had the same problem with SRAM memory and the problem was the direction with data. Thus, check the direction to data bus and other outputs from Nios II system.

    Best regards!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    hi i'm new in quartus 9.0 i'm using Stratix II i have problem when i run the hello <ordl project from the nios

    Verifying 00400000 ( 0%)

    Verify failed between address 0x400000 and 0x40D073

    Leaving target processor paused

    can u help me to solve it plz i use ssram
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Hi,

    This is a very common error during building Nios systems. Just double check the following things in your system.

    1. When you generate files from SOPC, make sure that these files are the ones that are used for compilation in Quartus. Usually, the SOPC system generates a .qip file which includes all verilog/vhd files generated by SOPC system. This file must be included in the Quartus project. (you can double check in quartus project.qsf file).

    Just make sure that you are infact compiling the files that are generated by SOPC

    2. Always, always, after adding a new component in SOPC system, make sure you auto-assign all base addresses.

    3. Double check clocks and resets.

    4. If you are using Eclipse, pay attention to the warning that System ID and timestamp didnt match. This probably means that either the Nios was not able to communicate to the sysid using the system configuration in the sof. -> which means, you either have a wrong sof or the system was compiled using the wrong files( different from the ones that the SOPC generated).

    I ran into this error many times. In my case, I was able to solve this by adding the correct SOPC generated qip file to the quartus qsf project file.

    Thanks

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

    You can try to modify the .bsp changing the Linker to use the onchip_memory instead of the

    external memory. If this work, you have a problem with the memory connection our with the

    memory controller.

    Good luck,

    Rafael C
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    In my case the problem was in the reset time for the component which contains nios + on-chip memory + flash controller. Verification couldn't be performed during reset, in my case it lasted 4 seconds, so you can run or debug your nios application only after the reset time

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

    --- Quote Start ---

    Hmmm couldn't find it on the web. Ok, the issue I was referring to only occurs in 9.0 with the new "Altera ALTPLL" component that was introduced in 9.0 The issue will be resolved in the next version of the tools but essentially the Avalon-MM slave port of the PLL had it's reset line wired directly into the PLL areset port. So if you filtered reset_n from outside the system with the PLL locked signal you have a reset loop and you'll get stuck. I only added this to the post just in case others run into it, I don't think you ran into this otherwise your system would have never worked.

    i thought of another thing that could cause issues. if you are using a cyclone/stratix ii or earlier nios development kit, make sure the reconfig_request_n signal is either pulled high, or that pin is set to input tristate (there is a pullup on that line). The board user documentation explains what that signal is for so I won't go into the details of the failure that will occur. By default Quartus II will set unused signals to ground on the older device families so if you didn't connect reconfig_request_n in your design, it would get pulled low by default..... which means you .sof would get overwritten as soon as the design comes up live. If you ran into this chances are by the time you go to download your software you are using the factory or user hardware that's programmed into flash.

    --- Quote End ---

    I am new in Nios and I am running the following an excellent step-by-step tutorial at:

    https://www.badprog.com/electronics-quartus-ii-creating-your-first-sopc-with-qsys-and-nios-ii-software

    But, different from DE1 board used in the tutorial, I am using an old'2004 EP60F672C5ES Nios Stratix II Development Kit. The tutorial was adapted by me to be used on my board by the assignment of Stratix ii pins instead of the DE1 ones. After this, all steps were executed perfectly, except for the last one, which is the the download of the .elf code to the board. It generates a "verify failed" message. And my primary suspect is the setting of the signal cited by BadOmen.

    Sorry about the basic questions, but:

    1. How can I check the status of the reconfig_req_n?

    2. How can I set this in Verilog?

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

    An update:

    The fix is exactly what BadOmen recommended: the reconfig_req pin. Fantastic thread! The example of the tutorial worked perfectly.

    While I don´t know how to do a fix in a pretty way, I did the following:

    • I openned a .csv file exported by an example from my board;

    • Looking at the .csv file, I found the PLD_RECONFIGREQ_N signal associated with the PIN_J20;

    • I established such association with a push_button already planned in the tutorial mentioned in my last message: switcher_external_connection

    I liked this tutorial because it doesn´t use any pre-filled file. All steps are built from zero.

    The only thing that remains unknown for me is how to do this (to set reconfigreq_n to '1') through a more specific manner.

    Best Regards