Strange problem: design works with SignalTap, but not without it.

[Altera_Forum]

I'm running into a strange problem that I hope someone out there can help me out with. I had a system that consisted of a single SOPC System that instantiated two NIOS II/f CPUs. The CPUs do not share any address space -- the primary one has a dedicated SRAM interface and the other is small enough to have code reside entirely in on-chip memory. The two CPUs run autonomously with the exception of two FIFOed UARTs that I implemented so they could communicate to one another for testing purposes. All I've done is to swap the tx/rx lines so they can communicate. This system worked just fine.  

 The plan is to eventually drop one of the CPUs when we get closer to production. So, I took the secondary one out of the "main" system and created a new SOPC System. The gives me two SOPC systems: a 'primary' one and a 'secondary' one. These two are instantiated by a top-level VHDL file that brings them together and connects them to off-chip peripherals.   Here's where the strangeness sets in. In this two SOPC System configuration, I cannot use nios2-download to successfully download the primary CPU's .elf file. The secondary CPU's .elf file loads correctly. As mentioned above, the primary has code allocated in SRAM. When I try to download, there is a consistent verification error in a section of the SRAM. In other words, because the .elf is not successfully verified, the processor is left in a paused state.  To try and trouble-shoot the problem, I added in Signal Tap II. I configured a single signal to trace the reset line to begin with (assuming there may be a reset problem or something) and gave it 32k samples. I built this, deployed it to the target and hit run. I then loaded in my primary CPU's .elf file. No problems. It all verified consistently and successfully ran.  So, I removed Signal Tap. Rebuilt. Redeployed. Tried to load the primary CPU's .elf file -- verification failure. Huh? Added Signal Tap back in -- I can now load the .elf file successfully.  What gives? Is it a floor planning issue? Is it a timing issue? We had an Altera FAE on-site that helped us build our SDC file. I can only assume that's correct. I do have to admit that the SDC file was developed prior to our adding the secondary CPU so it still could be potentially incorrect for this configuration.  Any and all help would be appreciated.  Thanks, --tim

[Altera_Forum]

One additional tidbit of information -- we are using Quartus II 10.0sp1. 

 --tim

[Altera_Forum]

My first answer would be a timing problem... Check that your sdc file gives the correct constraints for all the input outputs, and that your design does meet all the timing requirements (when it doesn't, Timequest just generates a critical warning, not an error).

[Altera_Forum]

Hi, i have a likewise problem.  

The device doesn't always to the same thing when i compile identical code.  Also i don't work with SDC file (don't know how to) and the compiler generates these warnings. is there a tutorial to learn to work with sdc files. Or techniques to prevent those warnings?

[Altera_Forum]

Rsyc's timequest user guide (http://www.alterawiki.com/wiki/timequest_user_guide) could be a good place to start.

[Altera_Forum]

--- Quote Start ---  Rsyc's timequest user guide (http://www.alterawiki.com/wiki/timequest_user_guide)   --- Quote End ---     marvelous ! Thx

[Altera_Forum]

Just a quick follow-up, I haven't corrected the problem yet but I do believe it's a timing issue. I don't think we have our Asynchronous RAM configuration set up correctly. The SRAM is a 20ns part, we are running at 50MHz, and we've left the setup / hold / etc. times to 0ns -- where the data sheet indicates they are small but are definitely non-zero. That puts running at 50MHz on the hairy edge. 

 I'll post another follow-up if correcting that fixes things.  Thanks for the tip on the TimeQuest doc written by rysc! I'll have to check it out. That's one area in FPGA design that is still a bit of "black magic" to me.

[Altera_Forum]

I solved this be decreasing the sample depth. For some reason maybe there was some memory issues.