The inconsistent results of the Timequest

[Altera_Forum]

Dear all, 

 I'm a newbie with Timequest. Currently I'm working with Cyclone III development kit. When I was compiling my system something strange happened. That is every time when I run 'Start Compilation', Timequest will give me two critical warning shown in the attachment picture. But when I'm trying to find the detailed problems by opening a stand alone Timequest and running it, there is no critical warning at all. I've checked the .SDC files in the Timequest setting table and the project file table, they are consistent. And I've compiled times, the same problem always was there. By the way, the design is working on the hardware. Sorry for my awkard english. Hope my description is clear enough. I'd like to thank anyone who can help me.  Best regards,  Dayu

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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. 

Thank you again.  Regards,  Dayu

[Altera_Forum]

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.

[Altera_Forum]

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. 

So stepping back, what does the data coming into the FPGA look like compared to the clock? In essence, you're saying it could hit the FPGA's port up to 500ps before the clock, and so if the data delay to the register isn't at least 500ps larger than the clock delay, we have a hold violation at the register. Is this what's going on in hardware?

[Altera_Forum]

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? 

 Regards,  Dayu

[Altera_Forum]

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.)