Ambit BuildGates Synthesis User Guide

Optimizing Before Place and Route

The following command preserves the clock network (connected to clk port) in des_top and its submodules:

set_dont_modify -network -hierarchical clk

If a module or list of modules are specified, the entire module(s) is marked for no modification during the optimization phase. Then, if the hierarchical option is used, all the instances in the current module are traversed recursively and the corresponding modules are marked dont_modify. Once a module is marked for no modifications, you cannot apply do_uniquely_instantiate or do_dissolve commands on the module. Lower level modules in the hierarchy of a dont_modify are implicit dont_modify.

Preserving modules is also useful to maintain cells (macros, mega-functions, RAM, etc.) from the library. For example, to preserve a hand-built RAM module, use the following command:

set_dont_modify -hierarchical myRAM

An instance or list of instances can be marked dont_modify.The modules referenced by these instances are implicit dont_modify.

For example, if blk22 is an instance of a counter that you want to preserve in the hierarchy, use the following command:

set_dont_modify blk22

Uniquifying Instances

When a module in the design is instantiated more than once, each instantiation may have a different environment. In such cases, one instance may need to be optimized differently from another by placing different constraints on each. Therefore, each instance must be uniquely associated with a module.

The following command creates a unique module for each of the instances:

do_uniquely_instantiate [-hierarchical] [instance_list | module_list]

where:

■instance_list is a list of instances that will be instantiated uniquely.

■module_list is a list of modules that will be instantiated uniquely.

Each instance in the instance_list is now referenced by a unique module, so that different constraints can be applied on each module and different transforms may be performed on each module. If instance_list is not specified, unique modules will be generated for all instances referring to the current module as set by set_current_module

Ambit BuildGates Synthesis User Guide

Optimizing Before Place and Route

command. The modules that contained the uniquely instantiated instances will be modified to reflect the change in binding of the instances to their respective unique modules.

If the hierarchical option is used, all instances in the hierarchical tree of each instance in the current module are associated with uniquely created modules.

For example, if blk11 and blk23 are instances of an adder (mod_adder) that need different constraints during optimization, the command is as follows:

do_uniquely_instantiate blk11 blk23

or, if blk11 and blk23 are the only two instantiations of mod_adder:

do_uniquely_instantiate mod_adder

After the unique module names have been generated, the two instances will appear as follows:

mod_adder_0 blk11(…port connections…); mod_adder_1 blk23(…port connections…);

where mod_adder_0 and mod_adder_1 are the names of the unique adder modules created from mod_adder.

All timing optimizations can be performed on an instance only if it is uniquely instantiated. All non-uniquely instantiated modules are implicitly treated as a don’t modify.

Collapsing Hierarchy

Hierarchies in the design tend to restrict optimization such that logic across the boundaries cannot be combined or restructured. Therefore, flattening the hierarchy can produce better results. Moreover, too many small hierarchies tend to produce inferior results and create unnecessary overhead CPU time.

The do_dissolve_hierarchy command dissolves hierarchical instances of modules by flattening the hierarchy of the instance. The command syntax is as follows:

do_dissolve_hierarchy [-hierarchical] [instance_list | module_list]

where:

■instance_list is a list of instances whose reference modules are to be dissolved to their respective parent modules.

■module_list is a list of modules to be dissolved to their respective parent modules.

Ambit BuildGates Synthesis User Guide

Optimizing Before Place and Route

Each instance in the instance_list is expanded into its parent module such that all the logic in the module referred to by the instance is now in the parent module. For user-specified instances (as opposed to software-generated hierarchies that are dissolved), the new names of the instances in the parent module are derived by appending a the hierarchical instance name to the original instance name. The hierarchical components inside the modules referenced by the instances are now components in the current module.

If the -hierarchical option is used, all hierarchical components are recursively expanded starting from and including the specified instance or module.

If neither instance_list nor module_list is specified, but the -hierarchical option is specified, all hierarchical components are recursively expanded to flatten the current module. After expansion, the current module will have only instances of library cells and instances of modules marked by set_dont_modify command.

If neither module_list nor instance_list is specified and the hierarchical option is not specified, all instances referring to the current module are expanded in their respective parent modules.

For example, to dissolve unit2 in the design shown in Figure 7-1 , the command is as follows:

do_dissolve_hierarchy [find -instance unit2]

The new design will appear as shown in Figure 7-5. Once dissolved, constraints cannot be placed on unit2 since there is no longer an instance by that name in the design.

Figure 7-5 Design Hierarchy After Dissolving unit2

des_top

blk11 blk12

Incremental Optimization

In full design optimization, gate level structures are built from scratch and mapped to the target technology. If the design has been synthesized once, the quality of design can be

Ambit BuildGates Synthesis User Guide

Optimizing Before Place and Route

improved using incremental optimization approach. In this process, portions of the design

(combinational logic, clock net, registers, etc.) can be extracted from the netlist and transformations applied (resizing drivers, fixing hold time, etc.) to guide the tool for specific improvements.

The following commands are useful in incremental optimization:

■do_extract

■do_xform_timing_correction

■do_xform_optimize_slack

■do_xform_fix_design_rule_violations

■do_xform_fix_hold

■do_xform_map

■do_xform_resize

■do_xform_structure

Applying Timing Corrections

Once the design is synthesized, certain amount of fine tuning can be done by applying specific transformations to the netlist. One such transformation is to improve on timing of the critical path using do_xform_timing_correction command. The timing corrections for improving and for fixing late slack are already applied as part of the do_optimize command. Re-running of this transform may be useful if logic is extracted and changes are made, or if hold time or design rule violations are ignored during optimization and require fixing. The do_xform_timing_correction command supports incremental optimization strategy.

The syntax of the do_xform_timing_correction command is extensive and is defined in the Envisia and Ambit Synthesis Command Reference.