little change - big mess

[Altera_Forum]

Hi, 

 I worked for months with Quartus II and a Cyclone II device without getting big trouble. But since a few weeks I'm working on a new part of the design and I can't get this thing stable. I use modules I wrote long time ago an that worked well so far. But now, combinded with new modules (or slightly modified old ones) they do weird things - in simulation and on the hardware. The new design parts work well without the old ones (in simulation). The problem appears only in combination.  I tried a few things such as play with the Analysis and Synthesis Settings (restructure multiplexers = on/off etc.) or use another implementation for my state machines. Most of these things changed the behavior in any way. But the change that helped the one module to work in most cases had a negative effect on another module.  So how can I ever be sure that a part of my design, checked for proper operation, will work in future after adding new functionatity to the design. Is the described behavior revealing of basic design mistakes? Is it possible to separate a certain module, to define settings only for this one? Could that solve the problem at all?  Many thanks in advance!

[Altera_Forum]

--- Quote Start ---  Hi,  I worked for months with Quartus II and a Cyclone II device without getting big trouble. But since a few weeks I'm working on a new part of the design and I can't get this thing stable. I use modules I wrote long time ago an that worked well so far. But now, combinded with new modules (or slightly modified old ones) they do weird things - in simulation and on the hardware. The new design parts work well without the old ones (in simulation). The problem appears only in combination.  I tried a few things such as play with the Analysis and Synthesis Settings (restructure multiplexers = on/off etc.) or use another implementation for my state machines. Most of these things changed the behavior in any way. But the change that helped the one module to work in most cases had a negative effect on another module.  So how can I ever be sure that a part of my design, checked for proper operation, will work in future after adding new functionatity to the design. Is the described behavior revealing of basic design mistakes? Is it possible to separate a certain module, to define settings only for this one? Could that solve the problem at all?  Many thanks in advance!  --- Quote End ---     Hi,  what kind of simulation do mean ? RTL or gatelevel , only functional or with timing? What kind of simualtion tool are you using ?  Kind regards  GPK

[Altera_Forum]

Too little information to tell. Is the design well constrainted? Do you get any warnings in the compilation? 

 Hua

[Altera_Forum]

--- Quote Start ---  Hi,  I worked for months with Quartus II and a Cyclone II device without getting big trouble. But since a few weeks I'm working on a new part of the design and I can't get this thing stable. I use modules I wrote long time ago an that worked well so far. But now, combinded with new modules (or slightly modified old ones) they do weird things - in simulation and on the hardware. The new design parts work well without the old ones (in simulation). The problem appears only in combination.   --- Quote End ---    After creating a new wrapper design with some previously verified blocks, and some new unverified blocks, make sure this works correctly in functional simulation. Given the description, I tend to think that even though your blocks are working well in isolation, when interfaced together, there are some issues that are causing functional problems.  Changing settings in Quartus II (or in any other EDA tool for that matter) can help you only in implementation, but functionally the design has to be correct to start with.

[Altera_Forum]

You've got a problem in the design, and I would stay away from randomly changing settings and seeing if it works. Very seldom does that help, and worst case, it works today but you don't know why, and the problem crops up again. I would first cover the things you absolutely should be doing - functional simulation, static timing analysis(core and I/O should be constrained) and going through all the messages. You could also run the Design Assistant. 

At that point, it's worth the time to roll-up your sleeves and do some low-level debug. SignalTap is almost a must, or possibly SignalProbe/LogicAnalyzer Interface. You need to get in and see what's failure, and once you diagnose it, can you determine the best way to fix it. I can't tell how many times I've seen designers waste more time over the long run by trying to go for a quick fix.  Finally, the most common culprit is something timing related, either an unconstrained path or an incorrectly constrained path. But if you feel you've already constrained the design, then basic debug is the way to go.

[Altera_Forum]

Thanks for the fast reply! 

 @ pletz I'm using the Quartus II Simulator tool and I did timing simulations.  @ Hua Yes I got some warnings. But none of them dangerous.  @ Rysc I'm afraid you are right. Low level debugging will be necessary.   The Design Assistent finds "Combinational logic used as a reset signal" in one case. I will fix that.   Functional simulation shows in principle the correct behavior except for one failure. But this one does not appear in timing simulation.   The results of Static Timing Analysis seem to be uncritical. But if my constraints are wrong this is worth nothing. Do I have to constrain my design using the TimeQuest Timing Analyzer? Till now I made pin assignments using the pin planner and specified my clocks in the individual clocks settings box of the Classic Timing Analyzer - and that worked so far. If this is all I have to do the next task is search and look at the failing signals (using the SignalProbe/LogicAnalyzer Interface approach because I can't use SignalTap with my Web Edition license). If not I have to concentrate on constraining my design at first. Is there any usefull document available that tells how to constrain correct?  Kind regards Jasmin

[Altera_Forum]

I don't have links to examples, but there's a decent amount of documentation on the web, with some searching. If you're not an expert at the Classic Timing Analyzer, I would recommend using TimeQuest just becaue it's the analyzer of the future(i.e. if you're going to spend time, do it with that). It also gives you more tools to analyze specific paths. 

 If your design is a single clock coming in(and maybe a PLL), then internal timing is probably not a problem. (Any gated clocks?) I/O is interfaces are where timing constraints are the most critical(but also the most difficult to do). Note that you can do a combination of both, i.e. add some debug logic(sometimes it's not too hard to add some checking logic inside your own code and bring it out to SignalProbe. If the data passes, then you know that interface is all right and you move on. Kind of do a high-level search on where the data is bad, and then start narrowing down from there. Once you have a general idea, then start constraining that I/O first, or if it's not a timing issue, dive deeper with debug.