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.
Honored Contributor
