Quartus II 10.0 SP1 to 10.1 - Timing Worse?

Sandor,

Is your design fully constrained using SDC/Timequest (no unconstrained paths)? If not, then addressing that should be your first order of business as going forward this will become a necessity (already is in newer chips). If you've already done this, then I would certainly file this as a bug.

Regards,

slacker

--- Quote Start ---

Sandor,

Is your design fully constrained using SDC/Timequest (no unconstrained paths)? If not, then addressing that should be your first order of business as going forward this will become a necessity (already is in newer chips). If you've already done this, then I would certainly file this as a bug.

Regards,

slacker

--- Quote End ---

Dear "Slacker", it sounds like you are very close to Quartus. I like that you have a sense of humour about this! :)

Being under time pressures, as ever, I will stay with 10.0 for now but intend to further investigate things, later.

Many thanks for the pointers. (As far as I recall, we do have a few unconstrained nets, but they are truely not critical, such as async inputs etc.)

Seeing that 10.1 works significantly faster than 10.0, my fear was that with much larger devices than my mid-range Cyclone II, compilation times were blowing out and some compromise was implemented where effort was scaled back to improve on average compilation times. This would be an acceptable approach in some situations but I have high logic utilisation (92% of total logic elements) where effort matters a lot and an extra-high effort option should still be available, to meet timing.

I also thought the worse timing may be due to more conservative device modelling in 10.1 but the difference is not subtle. It went from quite comfortably meeting timing (w.c. >1ns, second worse >3ns) to failing by more than 8ns in one case.

I found an aging version 6.1 installed on a PC and it is also happy with the design, although compilation times are longer than 10.0.

I have no doubt that 10.1 can be made to meet timing requirements and I'll learn more about the new features and options in 10.1. I suppose progress requires continuous learning but in this time-starved world, it was a surprise I could have done without.

I thought that before I jump in and spend a lot of time tweaking, I find out if anybody else has seen anything similar. The coming weeks probably will see more and more people using 10.1 and I'd appreate to hear about the experience of people who migrated their design to 10.1.

Sandor

I wanted to confirm that Quartus 10.1 does NOT have any conscious reduction in timing closure effort. Any compile time savings you are seeing could be due to your assignment issue (if Quartus thinks timing is easier, it can speed up your compile time significantly). Every release also has various improvements to the compile times that do not degrade timing. Of course, each design is different so there can always be something degrading specific to your design's topology.

In 10.1 and beyond, there is also a new feature where Quartus gives you more information on your failing timing paths (you can access it from TimeQuest by asking for "Report Timing Closure Recommendations"). You can find more details in the Quartus handbook at http://www.altera.com/literature/hb/qts/qts_qii52005.pdf

Thanks, kpad.

I'm now certain that the problem was that the constraints did not translate well from my old version.

I've read this about TimeQuest: "The Generate SDC File from QSF command runs a Tcl script that converts the Classic Timing Analyzer constraints in a QSF file to an SDC file for the TimeQuest analyzer."

I liked the idea. Quick and easy. Unfortunately the conversion script bombed out with an error. I don't have my notes about the error with me but I remember that it wasn't too specific about what it was choking on.

The way I read it, the Quartus documentation implies that you can still use the Classic Timing Analyzer but this seems to be strongly discouraged and every path you take seems to turn towards TimeQuest. This is great but for a smallish modification to a reasonably complex old design that was actually working well in "classic timing mode", it's a nuissance. Using QII 10.1, the classic time constraints in QSF doesn't seem to do their job and conversion of constraints to TimeQuest crashes out. For this design, I think I'll stay with my ancient QII 6.1 for as long as I can.