- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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:
- How can I check the status of the reconfig_req_n?
- How can I set this in Verilog?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This should be sufficient to hardcode the pin high:
output wire reconfig_req_n; assign reconfig_req_n = 1'b1;- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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:
- write my truth table HDL code and compile it;
- go o pin planner, perform a pin association with my logic inputs and outputs and compile my code again; and
- download my .sof to the board.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page