Configuring STA environment

1. define the clock.
2. set transition time for clock (ideally at the source). This specification applies only for ideal clocks and is disregarded once the clock trees are built, at which point, actual transition times at the clock pins are used.
3. Clock uncertainity: The timing uncertainty of a clock period can be specified using the set_clock_uncertainty specification. The uncertainty can be used to model various factors that can reduce the effective clock period. These factors can be the clock jitter and any other pessimism that one may want to include for timing analysis. set_clock_uncertainty-setup 0.2 [get_clocks CLK_CONFIG] set_clock_uncertainty-hold 0.05 [get_clocks CLK_CONFIG]

Note that the clock uncertainty for setup effectively reduces the available clock period by the specified amount as illustrated in Figure 7-7. For hold checks, the clock uncertainty for hold is used as an additional timing mar gin that needs to be satisfied.

1. clock latency:
2. generated clock: Can anewclock, that is, a master clock, be defined at the output of the flip flop instead of a generated clock? The answer is yes, that it is indeed possi ble. However, there are some disadvantages. Defining a master clock in stead of a generated clock creates a new clock domain. This is not a problem in general except that there are more clock domains to deal with in setting up the constraints for STA. Defining the new clock as a generated clock does not create a new clock domain, and the generated clock is con sidered to be in phase with its master clock. The generated clock does not require additional constraints to be developed. Thus, one must attempt to define a new internally generated clock as a generated clock instead of decid ing to declare it as another master clock. Another important difference between a master clock and a generated clock is the notion of clock origin. In a master clock, the origin of the clock is at the point of definition of the master clock. In a generated clock, the clock origin is that of the master clock and not that of the generated clock. This implies that in a clock path report, the start point of a clock path is al ways themaster clock definition point. This is a big advantage of a generat ed clock over defining a new master clock as the source latency is not automatically included for the case of a new master clock. What happens if the multiplexer select signal is not static and can change during device operation? In such cases, clock gating checks are inferred for the multiplexer inputs. Clock gating checks are explained in Chapter 10; these checks ensure that the clocks at the multiplexer inputs switch safely with respect to the multiplexer select signal.
3. set_input_delay / set_output_delay.
4. set_clock_latency
5. Modelling of external attributes: While create_clock, set_input_delay and set_output_delay are enough to con strain all paths in a design for performing timing analysis, these are not enough to obtain accurate timing for the IO pins of the block. The follow ing attributes are also required to accurately model the environment of a design. For inputs, one needs to specify the slew at the input. This informa tion can be provided using: • set_drive1 • set_driving_cell • set_input_transition In summary, a slew value at an input is needed to determine the delay of the first cell in the input path. In the absence of this specification, an ideal transition value of 0 is assumed, which may not be realistic.

For outputs, one needs to specify the capacitive load seen by the output pin. This is specified by using the following specification: • set_load

Timing paths are sorted into path groups by the clock associated with the endpoint of the path. Thus, each clock has a set of paths associated with it. There is also a default path group that includes all non-clocked (asynchro nous) paths. It is important to specify the load on outputs since this value impacts the delay of the cell driving the output. In the absence of such a specification, a load of 0 is assumed which may notbe realistic

1. Design Rule Checks: max trans and max cap. These rules check that all ports and pins in the design meet the specified limits for transition time1 and capacitance. These limits can be specified using: • set_max_transition • set_max_capacitance
2. Virtual clocks: A virtual clock is a clock that exists but is not associated with any pin or port of the design. It is used as a reference in STA analysis to specify input and outputdelays relative to a clock.

1. Refining timing analysis: set_case_analysis, set_disable_timing, set_false_path, set_multicycle_path.
2. Specifying inactive signals: In a design, certain signals have a constant value in a specific mode of the chip. For example, if a chip has DFT logic in it, then the TEST pin of the chip should be at 0 in normal functional mode. It is often useful to specify such constant values to STA. This helps in reducing the analysis space in addition to not reporting any paths that are irrelevant. For example, if the TEST pin is not set as a constant, some odd long paths may exist that would never be true in functional mode. Such constant signals are speci fied by using the set_case_analysis specification. set_case_analysis 0 TEST set_case_analysis 0 [get_ports {testmode[3]}] set_case_analysis 0 [get_ports {testmode[2]}] set_case_analysis 0 [get_ports {testmode[1]}] set_case_analysis 0 [get_ports {testmode[0]}] . For example, consider the sce nario where a clock is connected to the select line of a multiplexer and the output of the multiplexer is part of a data path. In such a case, it may be useful to break the timing arc between the select pin and the output pin of the multiplexer. An example is shown in Figure 7-37. The path through the select line of multiplexer is not a valid data path
3. set_max_delay/set_min_delay: point to point specification.