Ambit BuildGates Synthesis User Guide

7

Optimizing Before Place and Route

This chapter describes the flow and the commands used to invoke and control various optimization stages before place and route to produce a desired netlist. Logic optimization plays a key role in the synthesis process and consists of several processes, including: boolean transformations, flattening, structuring, technology-independent and -dependent mapping, hierarchical optimization, and context derivation.

The examples in this chapter are presented in command line input format and may not include all possible options; the syntax is for example only. For complete descriptions of all commands and their options, please refer to the Envisia and Ambit Synthesis Command Reference.

The hierarchical block diagram shown in Figure 7-1 will be used throughout this chapter to illustrate the use of various optimization commands.

Figure 7-1 Hierarchy of an Example Block

des_top

The purpose of this chapter is to familiarize you with the command used to optimize before place and route, consequently, only a subset of the optimize commands are provided in the way of example. Also, the optimize examples in this chapter are presented in command line input format; GUI instructions are not provided. In addition, the example syntax may not include all possible options; the syntax is for example only.

Ambit BuildGates Synthesis User Guide

Optimizing Before Place and Route

The logic synthesis process can be thought of in two steps: technology-independent optimization followed by technology dependent mapping and optimization.

After HDL modules are read, the functions (operations) are mapped to Ambit Technology

Library (ATL) cells and eXtended Ambit Technology Library (XATL) cells using the do_build_generic command. Some of the complex operations (e.g. addition, subtraction, increment) are also mapped to cells in AWACL components. If you have a license for the datapath option, a different set of components are used during mapping (refer to Datapath Synthesis on page 14 for a description of the datapath option).

For all the modules read in, a technology-independent netlist mapped to cells in ATL and

XATL libraries is created. If a module description has not been read in but the instance of such modules exist in other module descriptions that make up the design, such instances are treated as black boxes until the corresponding modules have been read and linked with the rest of the design.

Running do_optimize Command

The simplest way to optimize your design is with the do_optimize command. The do_optimize command runs a series of do_xform_ commands that provide a basic and thorough optimization routine. Figure 7-2 provides a diagram referred to as the “onion,” which shows the ”layers” of do_xform_ commands run by do_optimize. Command names within the layers of the onion are transforms and have a prefix of do_xform_. For example,

“propagate_constants” in the do_xform_optimize_generic layer is actually do_xform_propagate_constants.

Ambit BuildGates Synthesis User Guide

Optimizing Before Place and Route

Figure 7-2 Layers of the do_optimize “Onion”

fix_design_rule_violations

Note: Command names within the layers of the onion are transforms and have a prefix of do_xform_.

As shown in Figure 7-2, the do_optimize command runs the following four transforms, which in turn (with the exception of do_xform_map) run additional transforms:

■do_xform_optimize_generic

■do_xform_map

■do_xform_optimize_slack

■do_xform_timing_correction

For detail on the transforms, refer to Optimizing with Logic Transforms on page 177.

The do_optimize command applies to the hierarchy in and under the current module, set by the set_current_module command (for further information on this command, see Setting a Hierarchical Context on page 135). The results of optimization are stored in the database and must be retrieved using report_ and write_ group of commands.

Ambit BuildGates Synthesis User Guide

Optimizing Before Place and Route

The syntax of the do_optimize command is extensive and is defined in the Envisia and

Ambit Synthesis Command Reference.

Top-Down Optimization

Typically, designs that are not very large can be fully optimized in a single run. In this case, optimization is performed from the top level without first individually optimizing lower level modules. This process is referred to as top-down optimization.

The following commands are useful in top-down optimization:

■do_build_generic

■do_optimize

■set_dont_modify

■do_dissolve

■do_uniquely_instantiate

Details of these commands are provided in this chapter and in the Envisia and Ambit Synthesis Command Reference.

Bottom-Up Optimization

When a design is very large, it may take too long to synthesize the entire design in a single run. In this case, lower level modules can be optimized individually first with constraints derived from top level constraints. These optimized lower-level modules are then “stitched together” and marked dont_modify. Then the next level of hierarchy is optimized until all levels up to and including the top level are optimized. This process is referred to as bottomup optimization.

The following commands are useful in bottom-up optimization:

■do_build_generic

■do_derive_context or do_detime_budget

■do_uniquely_instantiate

■set_dont_modify

■do_optimize