> 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

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

> Doesn't look good. What version of Quartus are you running? 2.2 or 3.0? Did
> you later retry using a normal compile, and did that work?
> 

Ben,

I used Quartus II 2.2, then a few weeks ago I upgraded it 3.0.

I still have the same problem.

Yi

> "Smart Compilation" just means save the cache files
> in case they can be reused. It doesn't make the cache
> any more likely to be reusable. That is a function
> of device utilization, routing strategy and the
> impact of the design change.
> 

Now it looks like that's really the case here. I was mistaken and
thought it is something like Design Compiler's incremental compile or
ECO changes of final layout. I should have realized that for the prize
that I paid for the board + software, it is too good to be true. :-)

> 
> -- Maybe "didn't work" means
> "routed successfully, but did not function correctly"

It is different from in asic design that I changed 8 pads without
running any simulations, I could mis-connect those pads. Here is FPGA
you just "assign" the output signals to different pins using
"assignment editor". How can it be "not function correctly" is beyond
me.

> 
> The other thing is that if *any* logic changes it has to re-run the
> fitter, which at least for my designs is 60% of the compile time.
> 

Well, I guess a few wires change is also "any logic changes". 

poor me ...

enq_semi@yahoo.com (enq_semi) wrote in message news:<cd4a30b8.0309110632.7ee5a488@posting.google.com>...
> Hi, there,
> 
> I have a design contains 12K logic cells and 300K bit memories and
> runs at 5MHz. I compiled it for an EP20K1500 device and it worked
> (tested on FPGA).
> 
> Then I wanted to switch 8 output bits from pin location AF1, AF2, AF3,
> AF4, G4, G5, G6 and H2 to DAC0 pins (AE1, AD1 -- AD6 and AC6).
> 
> I had the smart compilation option turned on when I successfully
> compiled and tested the design. So when I move 8-bit signals to new
> pin locations it should be as easy as a few top-level re-wiring. No
> need to recompile and re-fit the design.
> 
> However, the tool spent one hour re-do the whole synthesis and
> fitting. Worst of all, the compiled the design does NOT work on FPGA
> at all!
> 
> When I say "does NOT work at all", it means not only I cannot get
> anything from the DAC0 pins, but also I cannot bootload the FPGA (I
> have bootloader in the design) after I download the new design.
> 
> Somehow during the re-compilation, the bootloader (8051 processor,
> intruction ROM and RAM) are affected, which should have nothing to do
> with the 8 wires I changed at the top level.
> 
> Any help/suggestions are greatly appreciated.
> 
> Yi Zhang
> ENQ Semi.

Hi Yi,

There seem to be two issues here.  First, you're wondering why it
takes so long for smart recompile to occur after you move some pins.

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.

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.

Our most recent families (Stratix and Cyclone) have two other features
that help speed up recompiles like this -- incremental fitting, and
back-annotated routing.  Unfortunately they won't help you with an
APEX design.

Incremental fitting does what I think you want here -- just figure out
what changed in the design, and make only the changes needed to
re-place and route those changes.

An alternative (again only for Stratix & Cyclone) is back-annotated
routing.  This lets you back-annotate your design, including routing,
move the pins you want, and recompile.  Now the placement is trivial,
and most of the routing is re-used too, so the compile time is much
faster.

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.

2.  Something strange happened in the smart recompile.  As another
poster suggested, try deleting the db/ subdirectory before
recompiling.  This will force a full recompile with no information
re-use.  If that fixes your problem, I'd be interested to hear the
details so I can open a bug report on this.

Hope this helps.

Vaughn
Altera

Followup to:  <cd4a30b8.0309120454.734ddc0a@posting.google.com>
By author:    enq_semi@yahoo.com (enq_semi)
In newsgroup: comp.arch.fpga
>
> > 
> > Try removing the db directory and recompiling.
> > 
> > 	-hpa
> 
> I think the title I used was not accurate: it should be "smart
> compilation did not SAVE my design".
> 
> The fact it runs for more than one hour can only mean that Quartus did
> recompile everything (even the design has no change except 8 wires and
> I didn't remove the db directory).
> 
> So, let me redefine my questions:
> 1. Why with "smart compilation" turned on it still recompiles
> everything?
> 2. Why the compilation didn't work after I moved 8 wires?
> 

I have found that changing a file while a compile is in progress (at
least across a network; haven't tried it on the same machine) messes
up the dependency generation in smart compile.

The other thing is that if *any* logic changes it has to re-run the
fitter, which at least for my designs is 60% of the compile time.

However, if the only thing that has changed is .mif files, smart
compile can take the time down from 15 minutes to 15 seconds and
such, since all it needs to re-run is the assembler.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Hi Yi,

> 
> When I say "does NOT work at all", it means not only I cannot get
> anything from the DAC0 pins, but also I cannot bootload the FPGA (I
> have bootloader in the design) after I download the new design.
> 
> Somehow during the re-compilation, the bootloader (8051 processor,
> intruction ROM and RAM) are affected, which should have nothing to do
> with the 8 wires I changed at the top level.
> 
> Any help/suggestions are greatly appreciated.
> 
> Yi Zhang
> ENQ Semi.

Doesn't look good. What version of Quartus are you running? 2.2 or 3.0? Did
you later retry using a normal compile, and did that work?


Best regards,



Ben

enq_semi wrote:

> So, let me redefine my questions:
> 1. Why with "smart compilation" turned on it still recompiles
> everything?

"Smart Compilation" just means save the cache files
in case they can be reused. It doesn't make the cache
any more likely to be reusable. That is a function
of device utilization, routing strategy and the
impact of the design change.

> 2. Why the compilation didn't work after I moved 8 wires?

-- Maybe "didn't work" means
"routed successfully, but did not function correctly"

When you gamble by making design changes on the back end,
sometimes you lose. Consider making all design changes
at the front end and rerunning your functional sim
and synthesis before place+route.

-- Maybe "didn't work" means "did not route successfully"

When device utilization is high, changing even one
pin can lose you the route.


     -- Mike Treseler