静态时序相关博文连载目录篇：

http://blog.chinaaet.com/justlxy/p/5100052092

不知不觉，就第十篇了……所以决定偷个懒……这一篇直接就是英文的复制粘贴过来了……

首先标题是：

Recommendations for Using Timing Preferences

Rule number 1: Preferences defined in an LPF file take precedence over attributes and directives defined in the HDL code.
    For example, if you have a FREQUENCY attribute defined in your HDL code, it will be overwritten by a FREQUENCY preference in your LPF file if they constrain the same clock. One example of a FREQUENCY attribute defined in the HDL code is PLLs generated from IP Express

Rule number 2: Preferences that are more specific take precedence over less specific ones. This means that individual net or path preferences supersede group (bus) preferences, and group preferences supersede global preferences.
    For example, if you have the following two INPUT_SETUP preferences in your LPF,
    INPUT_SETUP ALLPORTS INPUT_DELAY 3.000000 ns CLKNET "clk1_c";
    INPUT_SETUP PORT "data1" 4.000000 ns CLKNET "clk1_c";
    The input “data1” will have 4ns setup time requirement. In the following example,
    CLOCK_TO_OUT "cout" 1.0 ns CLKPORT "clk" CLKOUT PORT "clkout";
    CLOCK_TO_OUT "cout" 2.0 ns CLKPORT "clk" FROM "c2" CLKOUT PORT "clkout";
    the CLOCK_TO_OUT requirement for “c2” is 2ns instead of 1ns, which is more general.

Rule number 3: Preferences defined later in an LPF file take precedence over preferences if these preferences are at the same level and are in conflict.
    For example, if you have the following 2 FREQUENCY preferences in your LPF:
    FREQUENCY NET "clk_c" 300.000000 MHz;
    FREQUENCY NET "clk_c" 200.000000 MHz;
    “clk_c” FREQUENCY will be 200MHz.
    It is best to avoid this kind of conflict in your LPF file. 

Rule number 4: Timing Preference Dependency – FREQUENCY/PERIOD FREQUENCY and PERIOD preferences are the primary timing requirements, and all other timing preferences depend on them. If none of these preferences is defined, MAP will generate default FREQUENCY preferences, and this will usually over-constrain your design.

Appropriate FREQUENCY or PERIOD preferences should be defined for each and all clocks in your design, either in your HDL (such as using PLLs) or in your LPF.

Rule number 5: Appropriate Timing Preferences From the case studies previously discussed, you should understand that in order to properly drive the timing-driven engine and TRACE, every design should include appropriate timing constraints:
    The two default BLOCK preferences should always be included and stay at the top of your active LPF file.
    All unrelated clocks must be constrained using either the FREQUENCY or the PERIOD preference. The Clock Domains Analysis section in the TRACE report should help identify the number of clocks in your design and whether they are properly constrained.
    INPUT_SETUP preferences for all inputs should be defined according to your PCB timing requirements.
    CLOCK_TO_OUT preferences for all outputs should be defined according to your PCB timing requirements.
    If your design has multiple clocks, you should examine your design and determine whether any cross-domain paths exist in your design.
    If there are cross-domain paths between related clocks in your design, you should use MULTICYCLE preferences to define the timing requirements for all those cross-domain paths.
    If there are cross-domain paths between unrelated clocks in your design, you should first establish the relationship between the clocks using the CLKSKEWDIFF preference, and then you should define the
timing requirements using MULTICYCLE preferences.
    You should not over-constrain your design, but you should appropriately constrain your design with your actual timing requirement.
    If you need to use BLOCK preferences, you should fully understand what each of them does and what effect it could have on your design. As a good practice, you should put all the BLOCK preferences at the
top of your LPF file for easy debugging.
    It is strongly suggested that you not use the BLOCK INTERCLOCKDOMAIN PATHS preference. If you use it, all crossdomain paths will be blocked and will not be considered by the engine and TRACE, even if you have MULTICYCLE preferences defined and even if the BLOCK preference comes after the MULTICYCLE preferences.

Last Check: Complete Timing Preference Coverage
To ensure that your design and the engine are neither over-constrained nor under-constrained, you should carefully examine your LPF file. In addition to all the recommendations you have read so far, you should make sure that your LPF file includes all of the following preferences, if applicable, and that they are complete and correct:
    The basics:

        FREQUENCY or PERIOD for each and all clocks. An inappropriate value could over-constrain or under-constrain your design.
    Preferences for tightening the engine with the appropriate values:
        INPUT_SETUP
        CLOCK_TO_OUT
        MAXDELAY
        CLKSKEWDIFF
    Preferences for relaxing the engine with the appropriate values:
        MULTICYCLE
        CLKSKEWDISABLE
        MAXSKEW
        BLOCK
Finally and importantly, you should check the preference coverage section in your TRACE report to ensure a high percentage of coverage. To find out those paths that are neither covered nor analyzed by TRACE and PAR, turn on the “Check Unconstrained Paths” option in the TRACE strategy settings
and examine the result in the TRACE reports.