Ambit BuildGates Synthesis User Guide

Optimizing Before Place and Route

Details of these commands are provided in following sections of this chapter.

Deriving Constraints from Context

A context-based optimization requires that constraints for lower level modules be derived from the higher level modules.That is, constraints set at the top level of the design are pushed down the hierarchy so that each lower level module is optimized with the correct set of constraints. This approach is the basis for bottom-up synthesis.

The syntax for the command to derive constraints from each instance’s environment is as follows:

do_derive_context [instance_list]

where:

■instance_list is a list of hierarchical entities for which the context is derived. The derived constraints are applied to the modules referred to by the instances in this list.

The context is derived by extracting the following three types of constraints from the surrounding environment of the instances specified in instance_list: interface timing constraints, electrical constraints. If instance_list is not provided, context is derived for the current module.

The instance_list may contain hierarchical path names, in which case the context is derived for those instances in the hierarchy. Each instance must have been uniquely instantiated using the do_uniquely_instantiate command if the module it references has more than one instantiation.

The interface timing constraints include timing information about clock definitions, arrival time on input ports, required time on output ports, and identification of multi-cycle and false paths. Electrical constraints include port capacitance and resistance, number of drivers, and load for each port.

The derived context information is stored in the database, written out using the write_assertions command, and used to synthesize the individual modules.

Time Budgeting

Time budgeting is the process of splitting the combinational delay requirements across module boundaries to allocate slack across all modules in a fair manner. It allows you to start with initial time budget values rather than constraints derived from context, enabling fewer

Ambit BuildGates Synthesis User Guide

Optimizing Before Place and Route

synthesis iterations and quicker convergence to target performance. The time budgeting is applied to the entire hierarchy below current top level.

Note: For complete information on time budgeting, refer to “Bottom-Up Top-Down

Methodology” in the “Choosing a Methodology” chapter in the Envisia Timing Analysis User Guide.

The syntax for time budgeting command, do_time_budget, is as follows:

do_time_budget [-top list_of_top_instances] [instance_list]

where:

■instance_list is a list of hierarchical entities that will be resynthesized after time budgeting is performed. Instances in this list should be subdesigns of instances in list_of_top_instances.

■-top list_of_top_instances is a list of instances from which to start the synthesis. Only sub-designs under the list of specified instances are synthesized.

Blocks that cannot be changed, (therefore, will not be resynthesized) should not be on the time budget list. This situation arises when certain blocks are treated as “Intellectual Property” (IP) blocks, or need to be retained “as is” for various legacy or compatibility reasons.

The synthesis strategy with time budgeting is similar to characterizing the blocks, writing scripts and resynthesizing the blocks. The significant difference is that the time budgeting algorithm automatically distributes the slack evenly on paths across multiple modules. These new constraints are written out in a script form using write_assertions command for next iteration of synthesis. The slack distribution strategy employed by do_time_budget command reduces the number of synthesis iterations required to reach the target.

The time budgeting step performs time budget for paths with positive slack as well as negative slack. In case of paths with positive slack, the time budget step ensures that the new constraints will not cause negative slack. In case of paths with negative slack, the time budget step ensures that the new constraints will not make new negative slacks worse than the original negative slacks.

The slack time is redistributed on arrival times and required times at various ports/nodes in the path proportional to the delay of the path through an instance compared to the total path delay.

It is possible to use the set_data_budget_time command to force arrival and required times on particular pins. Such situations arise when hard coded time budgets are required due to specific design requirements. When time budgeting is performed, the forced values will

Ambit BuildGates Synthesis User Guide

Optimizing Before Place and Route

override the automatic slack allocation, thereby providing manual control over the automatic time budgets.

For example, in Figure 7-3, if path1 has a positive slack of 3ns and the delay through I1 is twice as long as the delay through I2, the required time for I1/p1 will get positive slack of

2ns and I2/p2 will get positive slack of 1ns.

Figure 7-3 Example of Slack do_time_budget Results

path1 positive slack path

If a 2 ns delay is forced at I2/p2 port (using set_data_budget_time command), then the arrival time will have a slack of only 1ns at I1/p1.

The do_time_budget command generates (derives) constraints for all ports of the instances in the instance list and saves it in the database. These constraints must be written out using write_assertions command. The new constraints files may then be used to resynthesize the instances I1, I2, I4, and I5.

Preserving Module Contents

Use the set_dont_modify command to preserve the optimization applied to modules, instances, or net.

The command syntax is as follows:

set_dont_modify [-network] [-hierarchical] list_of_object_id

where:

Ambit BuildGates Synthesis User Guide

Optimizing Before Place and Route

■list_of_object_id is a list of input ports or output instances, nets, or instance pins to preserve.

The ports must be input ports and instance pins must be output pins. When ports or instance pins are specified, it is equivalent to applying set_dont_modify on the net connected to the port or instance pin. In effect, this command instructs a don’t modify of the net connected to the port or pin.

The network option specifies the network connected to each port or net. The specified network is identified by traversing forward through all the nets starting from the port or driving pin of the specified net. The path goes through the combinational cells to which the nets connect and follows the output nets of the combinational cells until reaching a sequential cell or a black-box component. All nets and components on the specified network are marked as dont_modify during the optimization phase.

Using the hierarchical option, the traversal is continued at lower levels of hierarchy in the current module to preserve the network. If the hierarchical option is not used, only the network visible at the current module is preserved; the network inside the hierarchical instances in the current module may be modified.

Due to its global nature, the clock network or reset network is frequently designed manually (i.e. routing, load balancing, etc.) and must be preserved through the optimization process.

For example, consider the block diagram shown in Figure 7-4, where the effect of the following command is shown in the highlighted path.

set_dont_modify -network -hierarchical rst

Figure 7-4 Example of Preserving a Net Using set_dont_modify Command

If the hierarchical option was not used in the example above, the highlighted path in the instance I4 (shown by the dotted line) and the nets n1 and n2 would not be preserved.