Infamous Verify Failed

Hi Lemonoje,

THere are so many reasons for the Verify fail, that is why it is so popular. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

Here are a few that I have seen

1. Bad memory interface, physical board problem

2. Timing issue with memory

3. Lack of non-volatile memory. This confuses processor.

Hope that helps a little.

-Baycool

Hi Lemonojo,

are you sure you downloaded the right NIOS II into your board...

Cheers,

Danny

Well, the memory interface is a straight SDRAM instantiated in SOPC and then all the signals are routed to the chip. The memory in terms of timing works fine because I tested it using LabVIEW making calls to FS2&#39;s MDI to perform adderss/data bus tests, etc...

Everything works doing basic R/W peek/pokes from the FS2 CLI. Thanks for the feedback. Any other ideas?

PS - I am also getting Verify Failed from the Nios II flash programmer (from the sdk shell) when trying to load flash. I even tried re-installing Nios II 5.1 - no luck.

If you have problems with downloading programs from the IDE, I suggest to try reconfigure your FPGA with a "simple" test design that is a sub-set of your design. For example to isolate if your problem is SDRAM or SRAM, try to use/add onchip_memory to run hello world from. If the onchip_memory program runs, but loading the program to SDRAM/sram still fails, I would take a closer look at the memory timing or phase setting.

Once feature I&#39;ve found useful in sorting out a "verify failure" is to have a System ID peripheral (this is found in the SOPC Builder "other" components group) in my system design. This will sort out if I accidentally loaded the wrong system on my development board or if the board gets reset into a "safe" design on a NIOS II dev board.

When I download a program to a board, if I have the wrong system loaded it will flag a different time stamp.

Another useful part of this is if the system ID tag is something odd like FFFF_FFFF, it shows that I could have a hardware issue like:

1) some setting error in my design that is messed up my system like I forgot to set "unused IOs to tri-state" (by default Quartus II will set all unused IOs to drive ground which may cause issues with other componets on the board that are not expecting the FPGA to pull its pins to ground).

2) line noise and my JTAG port needs a pull-up resistor/cap on a signal to handle line noise or I could have a bad USB-blaster etc....

Good luck in isolating the problem

I also use the system ID feature to make sure I have the correct hardware. That&#39;s a great idea to make some internal RAM to try and run out of. The problem with that may be that the Stratix II (2S15) doesn&#39;t have much RAM in it at all (even compared to the lowest Stratix I). I know a hello_world project barely fit into my one Stratix I internal RAM design, and like I said it has much more RAM. Nonetheless, I&#39;ll try it.

I am also trying to look at the JTAG signals to see if something looks bad there...

Just as an update, I got my programs to download/verify and run again. I originally used the Altera provided calculations to phase shift the SDRAM clock, but I thought I should just try and recalculate everything. When I do this my calculations come out quite different than the Altera example where both of my lead numbers, for example, were negative. So I didn&#39;t know if I should take the lesser of the two? Take the absolute value of both and then negate one?

So, what I did was regenerate the system in SOPC, entirely recompile in Quartus, and then recalculate the SDRAM phase shift. I entered this, recompiled in Quartus, and now it seems to be working fine. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/biggrin.gif

Hi lemonoje,

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

The memory in terms of timing works fine because I tested it using LabVIEW making calls to FS2&#39;s MDI to perform adderss/data bus tests, etc...[/b]

--- Quote End ---

But, how do you get the sdram pins work fine? The IDE display download info, then verify failed. Do you know that what will be done in verify process and what is the sdram pins state?

Thank you,

LiangYi

--- Quote Start ---

originally posted by liangyi@Jan 19 2006, 02:36 AM

hi lemonoje,

<div class='quotetop'>quote

--- quote end ---

--- quote start ---

the memory in terms of timing works fine because i tested it using labview making calls to fs2&#39;s mdi to perform adderss/data bus tests, etc...

--- Quote End ---

But, how do you get the sdram pins work fine? The IDE display download info, then verify failed. Do you know that what will be done in verify process and what is the sdram pins state?

Thank you,

LiangYi

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12281)</div>

[/b]

--- Quote End ---

I&#39;m sorry I have no idea what you&#39;re asking.

--- Quote Start ---

originally posted by liangyi@Jan 19 2006, 12:36 AM

hi lemonoje,

<div class='quotetop'>quote

--- quote end ---

--- quote start ---

the memory in terms of timing works fine because i tested it using labview making calls to fs2&#39;s mdi to perform adderss/data bus tests, etc...

--- Quote End ---

But, how do you get the sdram pins work fine? The IDE display download info, then verify failed. Do you know that what will be done in verify process and what is the sdram pins state?

Thank you,

LiangYi

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12281)</div>

[/b]

--- Quote End ---

If I understand what you are asking -- From talking with other users, if you have "boarderline" timing issues with memory doing peeks and pokes to a few memory locations will not always show a problem. Peeks and pokes only help show "major" timming issues or incorrectly connected memories.

If you hit the memory with a large block of data transfers the "boarderline" memory timing issues will start to up. For example

1) A DMA transfer to memory and back shows different results

2) If you load your program into SDRAM memory that has borderline timing issues, the processor is always accessing its next instruction so the memory problems will show up quickly by your program locking up.

3) If you use the IDE download a new program onto your board (writes are ok) and it fails verify (read fails) then one cause could be memory timing or I incorrectly connected the memory.

Hi,

I resolve my problem.

I recheck the hardware connect and jointing. I found there has a data pin jointing to gnd. So, I re-solder this pin, now it works OK.

Thank you,

LiangYi