--- Quote Start ---
originally posted by sulrich@Mar 22 2006, 11:12 AM
hello,
i'm seeing odd/inconsistent behavior in my system that i'm developing. operations (hardware and software) that were working on the board stop working when unrelated vhdl code is changed and recompiled.
the board is a custom board with a cyclone 1c20, a custom asic, and various usb and interface ics. i am using the niosii processor and c-code to develop some calculation/ algorithms for the system. due to speed and throughput requirements, the calculations must eventually reside in hardware. once i determine the algorithm, i migrate the calculations to a hardware-based module in vhdl using some altera megawizard lpms and some custom vhdl code. the new module is then integrated into the main vhdl.
specifically, my problem is that as i tweaked the algorithm's vhdl (invert a signal, register another, etc.) i started seeing weird behavior in the rest of my system. for example, the nios processor initializes other chips on the board (interface, asic). functions, chips, etc. that were functioning beforehand stop working. most of these functions are not related to the vhdl code being developed. i have found that i can comment out a line of c-code or change another line in the vhdl and some functions will start functioning again.f
This problem is maddening and has halted development. Has anyone seen this behavior before? [/b]
I have seen something vaguely similar on a previous product several years ago using an Altera 20K100 part and strictly VHDL code (no NIOS). I resolved the problem by loading the design into Altera OEM versions of Leonardo Spectrum and FPGA Express which evidently had better error checking routines within the compiler. Once the syntax errors were identified (not seen in Quartus), I made the changes to the design and recompiled the design in Quartus and everything worked as designed.
I recently upgraded to Q5.1, SOPC, and IDE (and had using Q5.0 seeing the same problem)and have been seeing inconsistent behavior in my system.
I would seek help from Altera Support and may eventually do that; however, without a specific indentifiable and reproducable problem that is not specific to my hardware, I doubt if they would be able to help.
Any suggestions greatly appreciated.
thanks.
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=13689)
--- Quote End ---
[/b]
--- Quote End ---
Hi Sulrich,
I'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'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