Non deterministic behaviour in quartus II ?

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.

oopere wrote:

> 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

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,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall wrote:

> And yes, as far as I understand, some PAR algorithms *are*
> non-deterministic, so two builds may result in a different bit-stream.

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

> Indeed, incremental building will almost *definitely* produce different
> results from a clean compile from scratch.

I still maintain however that this *is* true.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall wrote:

> oopere wrote:
>
> > 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
>
> 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.

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.

> 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.

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

> 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?

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 :)

> Regards,
>
> --
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266

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).

On Nov 9, 10:44 am, "Paul Leventis" <paul.leven...@gmail.com> wrote:
>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...

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

> 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.
> (?)

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
http://www.altera.com/products/software/products/quartus2/design/qts-incremental.html.

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.