The inconsistent results of the Timequest

The standalone TQ uses the slow timing model by default. Your warning during compilation, using multicorner analysis, are at the fast models.

vjAlter nailed the issue. When you double-click on Create Timing Netlist in the Task bar, it automatically creates a model in the Slow Corner, since this is what users want 98% of the time. You can go to the Netlist Pull-down menu and go to Create Timing Netlist, where a pop-up appears allowing you to choose a different timing model. Or, if you had already created a timing netlist in the slow model, you can go to Netlist -> Set Operating Conditions and change it there. If you've created some timing reports, you can right-click and re-generate them.

vjAlter and Rycs thank you very much for your reply. Would you please give me some hints that on which documents I can find the descriptions of these models and how to use them, because the The Quartus II TimeQuest Timing Analyzer user manual doesn't give details about these topics.

I don't think I've seen any documentation on this. The slow model, which is the main one people use, basically models the worst possible delays. These are over PVT(Process, Voltate and Temperature). Setup failures are generally in this model. The Fast Model is the fastest the delays could be and is generally where hold violations occur. The middle model was added for 65nm, and shows something called Temperature Inversion, whereby not all delays follow a straight line in performance between the slow and fast model. Occasionlly you'll see failures in this model, but usually it's similar to the other two.

I'm not completely sure where the hold time on the right comes from. (I could probably figure it out, but if it's a different timing model, then the info on the left wouldn't help. That's another problem with Report Datasheet, in that it doesn't give details so you can check how everything was calculated.) I stick to the hold timing report on the left, since that's what your constraint controls and the fitter is optimizing for.

Actually, the top_fsd[*] is the data bus for an very slow asynchronous SRAM, so I think there should be no critical time requirement on these ports. But I don't want to leave unconstrained ports in my design, so I used the hold time in the datasheet report to set the minium input delay. Is it a right way to do it?

No. Technically the hold time in the datasheet report should be the same thing as your requirement. If you want to loosen the constraint, then either make the value larger, or add a set_multicycle_path -hold assignment. (Although multicycles tend to imply synchronous transfers, which is not the case here.)