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.
Followup to: By author: enq snipped-for-privacy@yahoo.com (enq_semi) In newsgroup: comp.arch.fpga
Try removing the db directory and recompiling.
-hpa
--
at work, 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
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:
Why with "smart compilation" turned on it still recompiles everything?
Why the compilation didn't work after I moved 8 wires?
"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.
-- 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.
Followup to: By author: enq snipped-for-privacy@yahoo.com (enq_semi) In newsgroup: comp.arch.fpga
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
--
at work, 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
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:
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.
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.
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. :-)
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.
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.
I will try this and hope it works. Thanks!
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.
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.