Weird: Different results just by hitting "Start Compilation"

Is your design fully timing constrained? When it doesn't work, does it fail timing? You don't want to get to the point where determining if it works or doesn't work is done by running actual hardware. You really need all the timing constraints, and if it passes timing be confident that it will work in hardware. (And if it doesn't work, debug why, which usually leads to something invalid in the design or the timing constraints).

As for whether the design re-uses anything on the next compile. The general answer is no. If I want to check, I generally look at my setup slacks. If anything changed in the design at all, those values will be different. (If you don't have the previous compile, there's no way to tell).

- Incremental Compilation can cause different results compile to compile, under some very specific circumstances. Unlikely.

- There's a perpetual rumor of people getting different results, but it's been nearly impossible to track down. I've heard it enough that I assume it's true, but whenever we try to debug, the result is that a) the original compile with /db is no longer around and b) it can't be reproduced.

- I also know of a problem with the JTAG controller that caused this behavior. I believe it was in Quartus 12.0/12.1 and fixed in 13.0, but not positive on the releases. In this case, if you compiled without a /db you always got result A, and if you compiled with the /db you always got result B(you could re-compile as many times as you wanted and get B). Looking through the hierarchies, it was the jtag logic that changed sizes. Basically the JTAG logic puts an ID into the device to link to the image. This is used by many of the JTAG functions that are run on a computer(SignalTap, SystemConsole) to make sure the image in the FPGA matches the SignalTap image, etc. It was pulling something out of the /db to calculate this ID, which was incorrect.

Though you should get the same results on each compile, I can't stress how much having proper timing constraints is, and therefore even if it's a different fit, as long as it passes timing it will work. Without this pass/fail test, it's impossible to tell what you put into hardware works across PVT.

My design should be fully constrained. At least the Compilation tells me so and there is nothing unconstrained in the "Unconstrained Path Report". But I must confess that some of my Timing requirements doesn't meet.

Oh, and yes, I test it on running hardware (hoooraaaaay!!) ;-). My speed-optimized Design works just fine, and after recompiling the power-optimized design (I did this several times now) every design ended in a functional device. It was only the very first compiler-result which didn't work.

You noticed the /db folder. Isn't it possible that Quartus makes some changes there while compiling?

Actually there are some files with new date and timestamps.

I am using the Logic-Analyzer-Interface. May this affect the changings you noticed on the SignalTap Logic Analyzer?

Besides, I know you're a pro in .sdc-Files.

Are this good values for a Source-Synchronous Interface (Single-Data-Rate)?

set_max_skew -from [get_ports {SERDES_RD

[*]}] -to * 0.500

set_max_skew -from * -to [get_ports {SERDES_TD

[*] SERDES_Clk}] 0.500

set_max_skew -from * -to [get_keepers {altera_reserved_lai*}] 0.500

I don't believe LAI by itself should, since I don't think it uses JTAG.

1) I would recommend checking if it is changing by looking at the slacks.

2) Although it shouldn't, again it probably doesn't matter. Every time you make a change it will be a different compile, and so if there's a marginal problem in the design that might or might not work compile to compile, it's more important to find that problem than worry that the compile might change. Of course, if you can't repeat it there's not much you can do.

3) If you do repeat it, and want to spend the time debugging it, then I make a copy of the entire project with /db. I set the top level partition to post-fit, which locks the placement and routing down, and add SignalTap to start looking at these post-fit nodes, trying to find what's wrong. It can be time consuming, but should get you there without the problem ever disappearing because you recompiled. (You will run a full compile, and it will preserve all of your logic while re-synthesizing/fitting the SignalTap logic, so the compiles should be much quicker too). I don't know if this works with LAI, to be honest, but think it should.

4) Since it doesn't meet timing, that is another concern. If it's off by a decent amount, that could easily be it, and rather than investigating why, it's worth spending the time to get it to close timing. Heck, it's worth spending that time regardless.

5) As for the timing constraints, I don't use set_max_skew for source synchronous as they're not exactly correct. (For example, it compares the skew between data pins, which you don't care about. You only care about skew between data and clock). I have a document on alterawiki about source-synchronous interfaces. That being said, what you have probably works fine and is quick and easy, so unless you suspect there are problems with the LAI, it's probably fine to leave as-is. The LAI won't be part of the final design, so you just need it to work under lab conditions, which I'm guessing it easily does. (Source-synchronous interfaces can be hard to constrain, and sometimes hard to close timing, but they're surprisingly robust in the LAB. I've seen cases where the constraints were way off, and the fitter was doing the wrong thing, and it still worked in hardware in the lab)

OK, I'm still trying to meet timing requirements, but I think this is nearly impossible.

The failing paths are ALL inside my QSYS-System, especially INSIDE the PCIe-HIP!!!!

How the (beep) is this possible????

The most problems are with "Long combinational Path".

OK, I have to try some other Compiling-Options I think. Hmmmm, what's this "Seed" thing I'm reading about? What effect does it have?

This talks a bit about them:

http://www.alterawiki.com/wiki/the_quartus_ii_fitter_and_seed_sweeps

Quickly put, the solution space is enormous, and so the smallest change in your design will cause variance in the final fit. The seed is the one thing in the project you can change and don't care about it's value, so it's an easy way to perturb the design and get a different result. So let's say running multiple seeds, your design runs at 103MHz on average, with a variance of +/-4Mhz. So let's say 1/10 seeds doesn't meet timing. So if you occasionally have one that doesn't meet timing, running another seed most likely will fix it. But if your design only meets timing 1/10, you're much better off doing something to the design to try and close timing with something that gets it to consistently meet timing.

I've run many designs with the PCIe HIP in it without problems. Obviously check if something broke in the path compared to what you would normally expect. I often create a separate project with just the core and see if it meets timing. If it does, compare the failing critical path to the stand-alone project and see what's different. Feel free to take the critical path, run:

report_timing -setup -npaths 10 -detail full_path -panel_name "Critical_paths" -file "TQ/TQ_10paths.txt"

and post it if you want someone to take a quick look.

Well, here is the result.

I hope you can use this to help.