Set constraint for timequest

[Altera_Forum]

hi. i just start to use timequest. some simple question wondering me and needs confirmation.  

 1. If use the clock enable method as frequency divider, is necessary to set constraint?  2. i starts using time quest with shift register module, is there any constraint need to be set besides creating the clock?   3. I am using a NCO. I get warning messages when use timequest. What action should i take? FYI, i already create_clock for NCO.  One of the warning: "Warning: Node: pzdyqx:nabboc|pzdyqx_impl:pzdyqx_impl_inst|MDCK2395:\cycloneiii_WCRO7487_gen_0:cycloneiii_WCRO7487_gen_1|EPEO2888_6 was determined to be a clock but was found without an associated clock assignment."     thanks

[Altera_Forum]

1.  

Besides constraining the clock as usual, you don't have to set more constraints. However, this will result in a over-constrained circuit: TQ will ignore the clock enable and analyze the circuit as if the clock is always enabled. If the circuit can meet your required timmings in thisway and you're happy with the area it's taking, then fine. If not, you'll have to relax the timing constraints for the clock-enable driven circuit by setting mutli-cycle constraints.  2. No.  3. Not familiar with the NCO, but are you using any of it's outputs as a clock signal?

[Altera_Forum]

--- Quote Start ---  However, this will result in a over-constrained circuit: TQ will ignore the clock enable and analyze the circuit as if the clock is always enabled.  --- Quote End ---    May you explain? i have no idea why it cause this.    --- Quote Start ---  If the circuit can meet your required timmings in thisway and you're happy with the area it's taking, then fine. If not, you'll have to relax the timing constraints for the clock-enable driven circuit by setting mutli-cycle constraints.  --- Quote End ---    FYI, there is a lot of articles advice to use the clock enable method instead of frequency divider to avoid clock skew. Besides, will this method caused multi-cycle? May i know the reason?  2. No.    --- Quote Start ---   Not familiar with the NCO, but are you using any of it's outputs as a clock signal?  --- Quote End ---    Nope. The are a lot of internal pins that i can't access causing a lot of warning.

[Altera_Forum]

To understand the point about your logic being overconstrained, consider the following example: 

- Your logic is driven by a clock, called 'clk', which is running at 200MHz. - You are using an enable signal to capture data on FFs clocked by 'clk' once every two clock cycles. This means that your logic delay can be as long as 2x 'clk' period and still meet setup time at the capture FF. - To properly constrain your design for P&R, you will define 'clk' to have 5ns period (200MHz).  The P&R tools have no knowledge about the effective clock division that is taking place by the enable. As such, the P&R tools will attempt to optimize your design so that paths between FF's are minimized to meet 200MHz timing. By design, you know that you have 2 'clk' cycles and really only need to meet 100MHz timing. Hence, you are overconstraining the P&R tools. Overconstraining the tools will result in increased area as it tries to meet the unncessary 200MHz timing. If your design fits and meets timing, it will operate correctly from a timing standpoint...however, it is not required to operate this fast.  What you can do is setup a multicycle path on the 'clk' domain to describe the effective divide properties of the enable signal. This will cause the P&R tools to consider that there is more than one cycle available to meet the time-of-flight requirement between two flip-flops. After applying a multicycle constraint, you should be able to use report_timing in TimeQuest to verify that you now have multiple cycles between the launch clock edge and the capture clock edge. One cautionary note, you need to be careful with the enables. The enable signals will still need to be timed at the faster clock rate, not the divided down clock rate. So, be sure to verify that paths to the enable pins of FFs are allocated one clock cycle.

[Altera_Forum]

Thanks for details explanation. I learn a lot.. 

 Some fact confuse me: "the P&R tools will attempt to optimize your design so that paths between FF's are minimized to meet 200MHz timing" causing area bigger.  From my point of view, if paths between FF's are minimized to meet 200MHz timing, then the area should be getting smaller instead of bigger due to the FF related have to placed closer, shortening the length of wire.   Pls correct me if i am wrong..  Question: In the case of setting multicycle for the path related, then it would be a lot. It is because my whole project is done like this(using clock enable). So, any efficient way like to set multicycle for whole design except the frequency divider?  thanks

[Altera_Forum]

What you describe is a win-win situation. 

But there a number of techniques that can improve timming at the expense of increasing area, ie, register replication.  If you use TimeQuest (I am completly ignorant of the Classical Timming analyzer), you can easily set multi-cycle constraints to all registers that are enabled by a given signal.  Check http://www.altera.com/support/examples/timequest/exm-tq-clock-enable.html for an example.

[Altera_Forum]

What rbugalho is right on. You do not have to set multicycle path constraints on a path by path basis. There are a number of ways to do so. For example, one technique would be to set the constraint for an entire clock domain. As I stated earlier, beware...you need to verify that your enable path is still timed as a single-cycle path. 

 Agree with rbughalo comments on area. Optimization to meet a higher frequency may require techniques that cause area increase.

[Altera_Forum]

click wrongly

[Altera_Forum]

rbugalho (http://www.alteraforum.com/forum/member.php?u=27812), 

 i have look at the example, and some constraints confuses me. Can you clear my doubt on the question below?  constraints: 1. create_generated_clock -name clk_div_2 -source [get_ports {fast_clk}] -divide_by 2 [get_pins {enable_reg|q}]  2. set_multicycle_path 2 -to [get_fanouts [get_pins -hier enable_reg|q*] -through [get_pins -hier *|*ena*]] -setup  Question:  1. Why they don use -hier before {enable_reg|q} in 1st constraint and use it in 2nd constraint?   2. In the second constraint,the syntax through is exception?  Besides, how to apply constraint for certain module only?  thanks