Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

Verify Failed in Nios II

Altera_Forum
Honored Contributor II
5,096 Views

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!
0 Kudos
14 Replies
Altera_Forum
Honored Contributor II
2,798 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

 

--- 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!
0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

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!
0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

 

--- 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? 

0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

This should be sufficient to hardcode the pin high: 

 

output wire reconfig_req_n; 

 

assign reconfig_req_n = 1'b1;
0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

 

--- Quote Start ---  

This should be sufficient to hardcode the pin high: 

 

output wire reconfig_req_n; 

 

assign reconfig_req_n = 1'b1; 

--- Quote End ---  

 

 

Thanks, BadOmen,  

 

I agree with your tip, but I was looking for some way to do this in a transparent mode for the code. Please follow my thoughts. 

Regardless of a developent kit that supports Nios or not, if I want to implement a simple truth table in my development board, one of the possible ways to do this is: 

 

  1. write my truth table HDL code and compile it; 

  2. go o pin planner, perform a pin association with my logic inputs and outputs and compile my code again; and 

  3. download my .sof to the board. 

 

 

I did not perform this basic experiment yet, but according to your tip, I would have to create in my HDL code an additional input to make a logic '1' assignment, inside the code and associate this additional input with PIN_J20, in my case (EP2S60F672C5ES Nios II Stratix II Dev Board).  

 

If my thoughts are correct, my question is: is there any way to do this without have to interfere on the HDL codes? Any kind of hardware act, in Qsys, for example?  

 

ps: yes, I know that I would not have to employ Qsys to buid a truth table...lol...
0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

This hardcoding is only necessary if you have a board that has an external configuration system supporting the reconfiguration request pin. Typically the board has a pullup on the signal so if your design doesn't drive the pin then the pullup will make sure the external hardware doesn't attempt to reconfigure the device. Often designs that don't drive this signal out reserve all unusued pins as input tristate which has the same effect. 

 

The only reason why I brought up this pin is because when this thread started Quartus used to tie unused I/O to ground by default which would cause this reconfiguration cycle to constantly occur if your user design didn't contain that pin. So if your user design doesn't have that pin and you are running into this issue it might be just a matter of going into the device and pin options and changing the unused I/O setting from ground to input tri-state. 

 

Note this isn't a Nios II or Qsys thing it has to do with the board being driven a signal and the possibility of Quartus pulling that signal low if you don't have it in your design.
0 Kudos
Altera_Forum
Honored Contributor II
2,798 Views

 

--- Quote Start ---  

This hardcoding is only necessary if you have a board that has an external configuration system supporting the reconfiguration request pin. Typically the board has a pullup on the signal so if your design doesn't drive the pin then the pullup will make sure the external hardware doesn't attempt to reconfigure the device. Often designs that don't drive this signal out reserve all unusued pins as input tristate which has the same effect. 

 

The only reason why I brought up this pin is because when this thread started Quartus used to tie unused I/O to ground by default which would cause this reconfiguration cycle to constantly occur if your user design didn't contain that pin. So if your user design doesn't have that pin and you are running into this issue it might be just a matter of going into the device and pin options and changing the unused I/O setting from ground to input tri-state. 

 

Note this isn't a Nios II or Qsys thing it has to do with the board being driven a signal and the possibility of Quartus pulling that signal low if you don't have it in your design. 

--- Quote End ---  

 

 

Perfect. 

 

Thank you again!
0 Kudos
Reply