Inconsistent HW behavior

Hi ATJ,

Thanks for taking the time to respond. The VHDL code I am modifying is not part of a SOPC component. In my search for the problem I have modified NIOS components but have deleted the component within the NIOS, added the modified component, re-generated NIOS, and then recompiled my design. That approach should be clean.

Regarding the IP critical issue, I have seen this notice and downloaded the patch. I "upgraded" from 5.0 earlier this week because of a critical issue seen with altsyncram LPMs. My design uses several comonents with altsyncram LPMs and even though I'm not using them in the way described in THAT critical issue, I decided to update to 5.1 plus SP1.

Regarding the db directory, I forgot about this approach. I have used it on several occasions, kind of a "Hail Mary" approach. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/tongue.gif I have not tried it here but may resort to that. I don&#39;t believe I&#39;m doing incremental compilation but should check my project settings just to be sure.

I will certainly back my project up before doing anything drastic. As you re-iterated, the difficulty in getting support is demonstrating the problem without having MY hardware present.

I did have a bit of good news last night. After fighting this problem for over 10 days I saw a glimmer of light just before I shut down for the evening. I noticed that some of an external chip&#39;s registers which were being read back after initialization were not correct. I know I had checked this before and everything was OK (there&#39;s that inconsistent behavior again). My suspicion is that my modifications, no matter how small, are affecting the P&R and changing overall timing. Perhaps everything "appears" to be executing fine but in actuality there&#39;s a slight timing change which violates the external parts&#39; timing constraints. My plan is to:

1) look at prop delays, timing, etc. in my compilation report

2) look into Timing constrained compilation

3) look into Logic Lock (I believe?) to freeze sections of logic which are working.... assuming I can get back to "working". http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/laugh.gif http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/laugh.gif http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/laugh.gif

Once again, thanks for you insight. I&#39;ll post a response when (there will be a when) I resolve this problem.

thanks,

sulrich

--- Quote Start ---

originally posted by atjung@Mar 22 2006, 06:30 PM

hi sulrich,

i&#39;m not sure what may be happening in your system, but is the vhdl code you are modifying an sopc builder component or some vhdl code that is outside the system? if the vhdl code is part of an sopc builder component be sure you are modifying the sopc builder component source files in the component dir&#39;s hdl directory not the "copy" of the source files in the quartus project directory.

also since you are using a nios processor in your design, are you aware of this critical issues patch that inpacts all ip cores (including the nios processor?)

http://www.altera.com/support/software/dow...ical-issue.html (http://www.altera.com/support/software/download/service_packs/quartus/dnl-q51-critical-issue.html)

it is also fixed in service pack 1 for quartus 5.1.

it sort of sounds like what you have been encountereing with odd functional failures.

if you still have odd functional failure do what i do, deleate the db directory and re-compile the design again. it is possible that the design database (db) got corrupted. i know in 5.x quartus ii introduced incremenal recompilation, so that the software could do partial updates of a design without rebuilding the whole design (saves compilation time).

but, before you start deleting the db dir, do a whole zip of your project directory first so that you have a snapshot of the problem. in that way you can send a "good" and "bad" version of your project to altera support - this will help them isolate the software problems and get a fix out in the next release. altera support can be a great help if they have a test case showing the problem clearly so that they can file bug reports and fix the problem with a known test case. if the problem is a corrupt design database then your two zip versions of your should show a difference in the design database - it is a lot of low level debuging so it may take some time to determine the cause.

i hope this help.

regards,

-atj

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

--- quote end ---

--- Quote End ---