Altera's Quartus II "smart compilation" feature killed my design?

> Hi Yi,
> 
> The smart recompile feature in Quartus skips only entire steps in the
> compilation process that aren't needed.  So if you move pins, it knows
> that your design does not need to be re-synthesized & mapped, but it
> does need to be re-placed and routed (fit).  So you still wind up
> paying the CPU time for a full place and route, even though you moved
> only a few pins.
> 

Vaughn,

Thank you very much for your detailed explaination! I really
appreciate it!!

I kind of realized that "need to be re-placed and fitted" even I move
a few pins before too. But I did notice in this case, the synthesis is
also repeated, takes about 15 minutes on an AMD 1700+ machine with 1G
memory.

> To speed things up, you can back-annotate your design to LABs before
> you recompile.  Back-annotate, move the pins you want to move, and
> recompile.  It will now be a lot faster, since your logic is locked
> down, so placement is trivial.  It will still need to be routed and
> timing analyzed though, but it should still be 3x or so faster to
> compile.
> 

I will try this and hope it works. Thanks!

> 
> Now for your second issue:  why did your design not work after a smart
> recompile?  I can think of two possibilities:
> 
> 1.  There is some dangerous timing in your design (race conditions,
> asynchronous transfers without handshaking, transfers between clock
> domains without timing constraints, etc.).  By re-placing and routing
> your design, a race condition that was latent may have become a
> problem.

Yes, you are right. The clocking is kind of messy in my design, lots
of clock gating and other manipulations. So, I can accept it if the
compiled design never worked, that may even make me feel better: I
really shouldn't do those nasty things on clock.

If I change any logics around cross-clock domain region, clock
generator (not pll), clock pll or even an inverter anywhere, I can
probably accept the fact that re-placing and fitting kill the design.
However, failing after moving a few output pins, which have no timing
constraints at all, is hard to understand.


Yi

> > 
> > Now for your second issue:  why did your design not work after a smart
> > recompile?  I can think of two possibilities:
> > 
> > 1.  There is some dangerous timing in your design (race conditions,
> > asynchronous transfers without handshaking, transfers between clock
> > domains without timing constraints, etc.).  By re-placing and routing
> > your design, a race condition that was latent may have become a
> > problem.
> 
> Yes, you are right. The clocking is kind of messy in my design, lots
> of clock gating and other manipulations. So, I can accept it if the
> compiled design never worked, that may even make me feel better: I
> really shouldn't do those nasty things on clock.
> 
> If I change any logics around cross-clock domain region, clock
> generator (not pll), clock pll or even an inverter anywhere, I can
> probably accept the fact that re-placing and fitting kill the design.
> However, failing after moving a few output pins, which have no timing
> constraints at all, is hard to understand.
> 
> 
> Yi

Hi Yi,

When you change anything in your design, and you haven't
back-annotated, and aren't using incremental fitting, nothing stops
the compiler from changing the placement and routing a lot.  In
general the placement and routing will change a lot, but will still
achieve similar speed and routability -- that's all that matters.

There are many (millions, billions?) of placement and routing
solutions to a given design with similar performance.  Unless you do
things to force Quartus to get a very similar place and route after a
design change, your place and route will change a lot, but will be
comparable on all the metrics you care about.

The problem with race conditions are that there are things that you
haven't told Quartus about which will make your design work or not
work.  Whether a given placement and routing works in the presence of
race conditions will be random.

Vaughn

> Hi Yi,
> 
> When you change anything in your design, and you haven't
> back-annotated, and aren't using incremental fitting, nothing stops
> the compiler from changing the placement and routing a lot.  In
> general the placement and routing will change a lot, but will still
> achieve similar speed and routability -- that's all that matters.
> 

Hi, Vaughn,

I totally agree with what you said above. I am just a little
frustrated when I simply bring one internal node (memory lock
indicator, quite static signal) to one LED on board, without changing
anything else, the compilation result changed from "no timing
violation" to "300,000 timing violations" and the longest datapath
increase from 180ns to 210ns.

One friend suggested to me to increase the clock-to-output time for
all the 5MHz output bus to 200ns (otherwise, Quartus will
automatically use the 40MHz input clock to calculate the tco for the
5MHz output signal). That worked 80% of the time.

Anyway, there seems just too many unrelated issues that can affect the
compilation result.

...... waiting for Quartus II 4.0 .... :-)

Yi