Possible compiler problem?

--- Quote Start ---

Hi,

I've been working on this project using a Max II w/ 240 macrocells. The program compiles without any error and the simulation gives expected results, yet when it is loaded onto the chip and tested, it does not work properly.

I'm trying to debug just one part of the program which is very simple. A computer sends various commands via a parallel port. Signals Address[0] and Data[3] are high while address[1-3] and Data[0-2] are low ( refer to the attached project file). On the rising edge of our clock or enable signal 'Strobe', the output 'Trig' is supposed to go high and stay high but in testing this did not happen.

After some debugging I saw that we had a problem with the demux that the Address bits are fed into. Looking further into it, I tested various combinations of the 4 Address bits (ie only using only A0 and A1 for example). Using only 1 Address signal worked, any combination of any 2 signals worked, a few of the combinations using 3 signals worked. The remaining combinations of 3 signals did not work as well as using all four.

I wanted to make sure I wasn't doing anything wrong logically, so I put together the same exact circuit logically using logic gate and flip flop ICs. This circuit worked perfectly yet the software which is supposed to do the same thing, did not.

Does anyone have any idea of what could be wrong? I am completely lost. I should also add I am using the web edition of Quartus v9

Thanks

--- Quote End ---

Hi,

I did not find any timing constraint ( fmax, input delay ...) in your project. Without proper

timing cionstraints it is not very likely that the design will work.

BTW: Your are using the default setting for unused pins, which is "Output driving Ground".

Make sure that this will not damage other devices. You can change the setting:

Assignments -> Settings -> Device -> Device and Pin Options -> Unused Pins

Kind regards

GPK

--- Quote Start ---

Without proper timing cionstraints it is not very likely that the design will work.

--- Quote End ---

I don't agree. Without timing constraints, the compiler will place and route the design in the easiest way and achieve a typical timing, as specified in the datasheet. Applying constraints, it can't do but modifying P&R within available limits. For a small chip as MAXII-240, there isn't much room to achieve large timing modifications at all.

The main purpose of timing constraints is to check the design implementation, which is generally meaningful of course. The present design, which is mostly using asynchronous flip flops and counters as far as I see, offers great opportunities for creating timing violations and unpredictable behaviour, I fear. To have it effectively checked in timing analysis, the timing of all input signals must be specified in timing constraints.

Although not impossible, it's no reasonable way to go, I think. Using a more synchronous design style is a better way to achieve predictable design behaviour.

P.S.: Unfortunately, it's difficult to guess, why the MAX II design doesn't work while a discrete implementation does. It may be due to the fact, that MAX II is considerably faster than e.g. standard HC logic, so it acts on small input glitches or ringing edges of level sensitive signals, that are ignored by those. Also ground bounce can be an issue. I don't see much alternatives to tracing the behaviour with an oscilloscope or logic analyzer and find out, where it fails.