Non deterministic behaviour in quartus II ?

Do you have any idea *why* your cicuit doesn't work when it doesn't? That would be a useful clue.

I've had a design break after a Quartus upgrade, but it was only because it was a bad design and a subtle change in timing caused it to break. (Inadequate use of timing constraints on the design concealed this.)

I've also had one which wouldn't run when the FPGA was cold - I had to ship the equipment to a factory in the Pacific North West to find that one. That was an unsynchronised state-machine input - again, just subtle timing changes in an already-broken design.

There are lots of things which make FPGA designs flakey, and despite what we'd like to believe, many of us are at least as unreliable as the toolchain... You only have to read this group for a couple of weeks to see how often people get the 'async input' stuff wrong, for example.

Unless you're using 'incremental compilation' in Quartus, I think it always does start from scratch at the earliest phase necessary (I'm assuming 'smart compilation'). If you're really suspicious then delete the 'db' directory below your design.

Will

No idea why it did not work:

Part of the original design:

signal[14..0]--|----- | XOR >----DFF------out[14..0] PN[14..0]------|-----

Even though "PN" changed at 15Mbit/s, "out" changed only at 1Mbit/s (signal data rate)

I added a single xor for the MSBs of each:

signal[14]--|----- | XOR >-----dummy_out PN[14]------|-----

and routed dummy_out outside of the block and to an output pin. Then everything is ok: "out" changes at 15Mbit/s.

The funny thing is that after removing the dummy_out, everything runs fine now.

And, yes, I am pretty sure that I did not change anything else.

Pere

Did it meet timing? Were your timing constraints actually correct? Is it a synchronous design? Are you using gated clocks?

Could be a lot of things before you point the finger at Quartus...

Did you delete your 'db' directory and compile from scratch?

Regards,

Sure, there may be problems in my design. However, the main point of my post is that the circuit behaviour is different in the following cases:

- State a). Original design

- State b). Originial design + output pin added + compiled + output pin removed + compiled

And I have observed this kind of behavior happening twice, in different designs. One aprox. one year ago and the other yesterday.

If I am the only one who has experienced this then obviously I am doing something wrong, somewhere. But where?

Sure, there may be problems in my design. However, the main point of my post is that the circuit behaviour is different in the following cases:

- State a). Original design

- State b). Originial design + output pin added + compiled + output pin removed + compiled

And I have observed this kind of behavior happening twice, in different designs. One aprox. one year ago and the other yesterday.

If I am the only one who has experienced this then obviously I am doing something wrong, somewhere. But where?

If it's a timing problem which is affected by the temperature of the circuit, then getting it working by one method might mean that the whole thing then warms up to the point where it then continues to work in the old configuration.

I'm afraid I didn't really understand your description of the design yesterday, but I expect that you make sure you're rock solid on setup times (async inputs into multiple FF's) and timing constraints, then it will all work much more consistently. If you have signals in multiple clock domains, which I suspect you do, then you probably need to treat them a lot more carefully than just XORing them together.

You're certainly not the only one to experience bizarrely inconsistent problems which are apparently related to something they later turn-out not to be related to. If it's only working by luck in the first place, I wouldn't waste time by trying to second-guess precisely what causes that luck to run out.

Will

This is not the expected behaviour of Quartus. Imagine how difficult our job would be if we could not reproduce outputs for a given set of inputs...

Quartus is deterministic. The same input source and project settings run on the same version of Quartus on the same OS, you should get the same answer.

Try diff'ing the output files of Quartus for your two cases. At what point in the compile do the report and log files differ? That may give a clue as to what is causing this difference in observed behaviuor. Are you absolutely positive that (b) gives the same inputs as (a)? For example, if you nuke your db/ directory in (a), and do the same in (b), do you then get the same results?

If you can show that this is non-deterministic, please email me so that we can arrange to get your test case. We do occasionally find non-determinism in the software due to safe but bad programming practices -- for example, hashing on non-deterministic data. But we run determinism tests on the software, so these are usually flagged in-house before the software ever reaches our users.

Regards,

Paul Leventis Altera Corp.

Thanks for your response.

By this time I have fixed the problem that caused the original circuit not to work as supposed. There was some critical timing issue that caused a shift register a) not to load b) to load only certain flip-flops or c) to load correctly depending on how fast the "load" pin was deasserted after the clock edge. My fault.

Coming to the "non-deterministic" question, I am pretty sure that Quartus does a correct job. To find an explanation, I wonder if it is possible that the same schematic ,i.e. screen drawing, may be given different internal representations. I explain with an example: Many years ago I wrote a circuit simulator where I assigned each circuit node a number which was internally generated. If the user addded and removed stuff, the internal node numbers changed but the screen appearance was the same. In this case, this could not affect the circuit response.

However, in this case I can imagine that the fitter tool, if all settings are the same, starts to place things perhaps by ascending order of an internal variable which may be different even if the screen "appearence" is the same -perhaps due to repeated adding or deleting??

Could it be that, if there are no restrictions acting, the decision on where to start placing may be based on some internal ordering, which could cause those minor timing differences -which in the reported case caused big behavior diferences due do a bad design?

(Sorry that I can't send you the original state, because, as said, it worked after editing and this was done on the same project)

Pere Pal=E0

Ah. Two schematics that look the same could very well turn into different input as far as Quartus is concerned. This is just like you choosing to reorder some expressions in your HDL; I can't say for sure without trying it, but I can envision this turning into different node numbers / names in the internal representation and causing different results.

I'm glad that you were able to resolve your issue. Good luck with your design!

Paul Leventis Altera Corp.

But you're missing the point entirely.

If your design doesn't meeting timing, and/or your timing constraints are invalid/incorrect, then "all bets are off" as they say.

And yes, as far as I understand, some PAR algorithms *are* non-deterministic, so two builds may result in a different bit-stream. Indeed, incremental building will almost *definitely* produce different results from a clean compile from scratch.

My point is, under normal conditions and a 'flawless' design, Quartus may well produce different output on different builds - but it will always behave correctly. If the design is 'marginal' or just plain incorrect, then this process may yield working output *some* of the time, and non-working output others.

In your case, adding a pin causes the design to 'work'. Removing it and you've lucky enough that Quartus still places in a manner that allows it to work.

Having said that, I wonder what your sample space is?

Regards,

OK, that'll teach me to post before reading the rest of the thread! Apparently Quartus *is* completely deterministic.

I still maintain however that this *is* true.

Regards,

This is exactly what was happening in this case. I was in the first phases of the design and did not care of the design not meeting timing. I "visually" inspected the relevant waveforms in a certain part of the circuit and -incorrectly- thought they were ok.

Agreed. See my other post and Paul Leventis' response.

I occasionally have to go into FPGA design, but am primarily working at RF. As a result, I am not an "expert". However, all my designs finally worked as expected :)

I also sometimes have the impression, that Q seems to produce strange results: I observed, that a design was not fitable anymore after having changed some minimal paramters, which only should have affected the number machine cycles. Doing re resynthesis suddenly met the time reqs again. (?)

What I also sometimes recognize: The time for producing a design differs allthough done at the same machine (no other tasks running than Q). A recent (small) design used to be ready after typically 30-40min, but sometimes it took more than 60mins (no incremental compilation used).

This is why I stopped using Xilinx. I had a design that if I loaded a design file, saved it with no changes, then recompiled, I would get different timing. Sometimes failing, sometimes working.

Marc

Which specific "minimal parameters" did you change?

The algorithms that run under-the-hood in Quarus II (and any other CAD tool) are heuristic in nature. If you make any small change to the input or settings of the tool, you can end up with a radically different fitting result (synthesis, placement or routing). The result? Different wirelength, timing slacks, and even run-times.

If you have a small part of your design that you will be changing, and you want to keep the rest of the design unchanged, you can try out the Incremental Compile features of Quartus. These allow you to preserve the synthesis, placement or even routing of untouched portions of the design. The result is more stable performance and reduced CPU time, with some possibility of reduced performance since the tool no longer can optimize across your partition boundaries. If you want to see more, go to

Note: Incremental Compile *does not* require floorplanning of your design, which is very nice, since you (and I) will have a hard time beating a placer at that task!

Regards,

Paul Leventis Altera Corp.