Timing violations - TimeQuest vs. Compile results ?????

Are these valid multicycle setup constraints? Or are you just using them to fix timing? You can only use multicycle constraints when you know a signal will be set for longer than a single clock period. eg. you have a system with a periodic clock enables - you can put multicycle constraints on all of the registers that use the enable (but not the enable signal itself).

Timing problems are primarily a problem with your design, not your timing specs. Have you thought about increasing pipelining in the design? Setup violations occur when registers have too much logic between them.

Thank you for your quick reply

Please could you explain more by what you mean by "valid multicycle setup constraints"

It seems from what I have read that the multicycles can be used to ease up the routing of the Quartus compiler allowing better timing for the more critical signals - is that correct ?

From within Timequest for each set of violations I checked the design and the data path to see if I relax the timing requirements for the given register-to-register path, "allowing the Quartus II Fitter to place and route the design more optimally". e.g. for setup end multicycle I ensured that the latch clock could be "moved to the right" (relative to the launch clock) i.e. delay the latch clock relative to the launch clock. I checked this by verifying that if the delayed data was clocked by a latter latch clock edge the results would still be valid.

Yes, it will ease up the timing, but that is only valid if your signals behave in a multi-cycle manner. Eg. Your clock enable is high every other clock cycle - so the signals that use that enable only change once every 2 clocks, so the q output of the register is valid for 2 clock cycles - hence a multi cycle constraint.

If the registers in your design can change every single clock cycle then you do not have a valid multi-cycle constraint. If you specify one, then the design may not work properly on the board.

Thank you for that clarification. I am trying to ensure that for the specific multicycle constraint, if the latch clock is delayed it will not have an impact on the delayed data.

However I don't understand that when I run the constraints in TimeQuest and shows me that the setup violations are reduced, then when I do a compile with the same restraints the FMAX gets worse not improves and also there doesn't seem to be an improvement in the setup violations in the same magnitude as which I received in the TimeQuest ?

You shouldnt be delaying the latch clock - the clock will be a constant and always running.

It sounds like your design needs to be fixed at the code level, not in the timing analysis,

Sorry I was not clear.

When I added a multicycle constraint and the latch edge is shifted to the right relative to the launch edge I then tried to check within the design that the desired result will not be impacted.

However I don't understand that when I run the constraints in TimeQuest and shows me that the setup violations are reduced, then when I do a compile with the same restraints the FMAX gets worse and doesn't improve and also there doesn't seem to be an improvement in the setup violations in the same magnitude as which I received in the TimeQuest ?

When you rebuilt the design, the fitter now has different constraints to use - this will effect how it fits the design. It also has a random seed which is determined by the seed setting and the source code and constraints, so the fit will be different every time.

If the design meets the timing constraints, then it wont try any harder.

Adding multicycle should be a last resort to fixing timing issues, and, as mentioned, should only be used to describe how your design is actually supposed to work, like the divide-by-2 clock enable mentioned. You should look at the failing paths in your design, go back to your HDL code, and make adjustments there first. Adding pipelining is a relatively simple way of improving performance at the expense of extra cycles of latency. If you could post some code here that is failing timing, maybe we can help!

You can also check out these online trainings to learn more about TimeQuest and how to close timing on a design:

https://www.altera.com/support/training/catalog.html?coursetype=online&language=english&keywords=timing closure

https://www.altera.com/support/training/catalog.html?coursetype=online&language=english&keywords=timequest

shmueld -

In your first post you said "First I constrained all my clocks ...". How many clocks do you have, and what are the relationships between them? If you have multiple clock domains where paths exist between them Timequest by default assumes that these paths need to be constrained, even if the clock domains are independent (i.e., any paths that exist are don't care). If that's the case then you need to explicitly tell Timequest to ignore paths between the clock domains that are independent. The most efficient way to do this with with the "set_clock_groups" constraint.

If this is what's going on let us know and someone can post a "set_clock_groups" example for you.

Bob