®

Talus® Design Flow Guide

Magma Design Automation® Inc.1650 Technology DriveSan Jose, CA 95110

USA408-565-7500

September 2008

Talus® 1.0

Copyright © 1997–2008 Magma Design Automation, Inc. All rights reserved.

Talus Design Flow Guide, Talus 1.0This document, as well as the software described in it, are furnished under license and can be used or copied only in accordance with the terms of such license. The content of this document is furnished for information use only, is subject to change without notice, and should not be construed as a commitment by Magma Design Automation Inc. Magma Design Automation Inc. assumes no responsibility or liability for any errors, omissions, or inaccuracies that might appear in this book.

Except as permitted by such license, no part of this publication can be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without the prior written permission of Magma Design Automation Inc. Further, this document and the software described in it constitute the confidential information of Magma Design Automation Inc. and cannot be disclosed within your company or to any third party except as expressly permitted by such license.

The absence of a name, tagline, symbol or logo in these lists does not constitute a waiver of any and all intellectual property rights that Magma Design Automation Inc. has established in any of its product, feature, or service names or logos.

Registered TrademarksMagma, the Magma logo, Magma Design Automation, Blast Chip, Blast Fusion, Blast Gates, Blast Noise, Blast RTL, Blast Speed, Blast Wrap, FixedTiming, MegaLab, Melting Logical & Physical Design, MOLTEN, QuickCap, SiliconSmart, Talus, and YieldManager are registered trademarks of Magma Design Automation Inc.

TrademarksArchEvaluator, Automated Chip Creation, Blast Create, Blast DFT, Blast FPGA, Blast Logic, Blast Plan, Blast Power, Blast Prototype, Blast Rail, Blast SA, Blast View, Blast Yield, Camelot, Characterization-to-Silicon, Design Ahead of the Curve, Diamond SI, Fastest Path from RTL to Silicon, FineSim, FineWave, GlassBox, Hydra, HyperCell, MagmaCast, Merlin, Native Parallel Technology, PALACE, Physical Netlist, Quartz, QuickInd, QuickRules, Relative Floorplanning Constraints, Relative Placement Constraint, RioMagic, Sign-off in the Loop, Silicon Integrity, SiliconSmart CR, SiliconSmart I/O, SiliconSmart MR, SiliconSmart SI, Smart Sampling, SuperSite, Titan, and Volcano are trademarks of Magma Design Automation Inc.

Sun, Sun Microsystems, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the United States and in other countries. UNIX is a registered trademark of The Open Group.

All other trademarks are the property of their respective owners.

Notice to U.S. government end users. The software and documentation are "commercial items," as that term is defined at 48 C.F.R. §2.101, consisting of "commercial computer software" and "commercial computer software documentation," as such terms are used in 48 C.F.R. §12.212 or 48 C.F.R. §227.7202, as applicable. Consistent with 48 C.F.R. §12.212 or 48 C.F.R. §§227.7202-1 through 227.7202-4, as applicable, the commercial computer software and commercial computer software documentation are being licensed to U.S. government end users (A) only as commercial items and (B) with only those rights as are granted to all other end users pursuant to the terms and conditions set forth in the Magma standard commercial agreement for this software. Unpublished rights reserved under the copyright laws of the United States.

Magma trademarks, taglines, symbols, and logo are registered trademarks or trademarks of Magma Design Automation Inc., in the United States and/or other countries. This trademark list is provided for informational purposes only; Magma Design Automation Inc. does not provide any express or implicit warranties or guarantees with respect to the information provided in this document.

Printed in the U.S.A.

Typographic Conventions

Typographic Conventions

The following table summarizes typographic conventions or styles used throughout this document to improve readability.

Visual Cue What It Means

blue Indicates hyperlinked text.

Bold Used in running text to identify Magma commands and options and menu selection sequence. For example:Set the -case option of the config timing crosstalk delay command to best. To save the file, choose File > Save.

Bold italic Used in running text to identify user-replaceable strings in Magma commands. For example:Use the filename argument to specify the output file for the constraints.

Italic Used in running text to indicate emphasis, book titles, and generic unknowns such as n.

Courier Indicates commands, system prompts and output, code from files, error messages, and reports printed by the system. For example:force route power2 ring $m fpringv85

Note: Not used in running text.

Courier italic Indicates user-replaceable strings in Magma commands and code. For example:force cell temperature cell temperature

Note: Not used in running text.

- (hyphen) Precedes an option in command syntax. For example:Use the -domain option to identify the domain. orforce delay lib_group -domain domain_name

ALL UPPERCASE Used in running text and code to indicate logic functions such as AND, OR, and NOR.

/ (slash) Indicates levels of directory structure in UNIX. For example:/work/top/top.

Talus Design Flow GuideTalus 1.0 3

Typographic Conventions

\ (backslash) Used in two different ways:• In Microsoft NT, indicates levels of directory structure.• In Magma code, indicates a continuation of a command line. For

example:export spice path $m path1 -file "path1.sp" \

-run_spice "-from U1/Q -to U12/D"

[ ] (brackets) Denotes optional parameters such as:port1 [port2 ... portn]

| (vertical bar) Used in command syntax to indicate a choice among literal arguments. For example:config cell -case worst|best|both

_ (underscore) Connects words that are read as a single term by the system. For example: scan_output_pin

$l Used in Magma code to indicate either:• The replaceable string library_name. • A library that has been “set” for the design using the set command.

$m Used in Magma code to indicate either:• The replaceable string model_name.• A model that has been “set” for the design using the set command.

Menu > Command Shows a menu selection sequence using the “>” symbol to descend through menu options. For example:File > Save.

Visual Cue What It Means

Talus Design Flow Guide4 Talus 1.0

Contents

Contents

1. Overview of the Talus PlatformDifferentiating Talus Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Automated Chip Creation Flow Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Flat Flow Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2. Talus Design Flat FlowBefore You Start: Importing Libraries and RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Setting Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Importing the Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Setting RTL Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Understanding Compatible RTL Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Importing RTL into Talus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Import RTL Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Elaborating the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

fix rtl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18fix netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Configuring Area Optimization Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Using Distributed Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Configuring fix netlist for Third-Party Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Using DFT in the Talus Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24fix time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Preparing to Use fix time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Using Multiprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Setting fix time Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26fix time Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Talus Design Flow GuideTalus 1.0 5

Contents

Quality of Results Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Checking fix time Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

fix plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Reusing Floorplans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Configuring the fix plan Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Primary Floorplan and Inner Shape Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Power Domain Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Power and Ground Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Cover Macro Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Pad and Pin Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Macro Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Halo Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

fix power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Preparing to Use fix power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Configuring fix power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Defining Power Requirements Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Defining Power Requirements Automatically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Defining Power Requirements With Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Defining Additional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Defining Power Structure Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

fix power Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Checking fix power Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Talus Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Quartz Rail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

fix cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Preparing fix cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Configuring fix cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39fix cell Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Checking fix cell Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Talus Design Flow Guide6 Talus 1.0

Overview of the Talus Platform

1. Overview of the Talus PlatformThe Talus platform consists of the Talus Design and Talus Vortex products, which are most useful for block and flat chip designs and the Hydra and Automated Chip Creation products, which are most useful for larger, hierarchical designs. If you are using the Talus product (Talus Design or Talus Vortex or both) you need an optional license to use Automated Chip Creation.

Figure 1 provides an overview of the commands associated with the Talus Design and Talus Vortex products and how those flows relate to the Automated Chip Creation flow.

Figure 1: The Magma Talus Design Flows

fix top*

fix block*

fix partition*

fix shape*

fix power

fix pin*

fix budget

fix clock_hier*

fix plan

fix wire

fix time*

fix power

fix cell

fix clock

fix time*

Flat Design Flow (Chip or Block)

Hierarchical Design Flow

fix netlist

fix rtl

fix netlist

fix rtl

Talus Design

Talus Vortex

fix plan

Talus Platform

Talus Design Flow GuideTalus 1.0 7

Overview of the Talus PlatformDifferentiating Talus Flows

Differentiating Talus FlowsTalus ACC and Hydra are automated hierarchical physical design flows that begin with netlist input and contain the steps needed to automate top-down chip planning, floorplan synthesis, physical block shaping and partitioning, power synthesis, clock tree synthesis, block level constraints pushdown, block-level implementation (using Talus Vortex licenses), and top-level integration.

The Talus ACC flow provides hierarchical implementation with extensive automation for a highly automated design style using a near-abutment methodology.

The Hydra flow provides an infrastructure for designs to build a repeatable hierarchical flow using the latest Talus auto-interactive technology for both top-down and bottom-up designs. The Hydra flow supports partial designs (prototyping) and provides flexibility for flow definition and implementation. Hydra supports both channel and near-abutment design methodologies.

Talus Design is a flat flow that provides a full-chip synthesis environment that allows rapid development of RTL-level and chip-level constraints throughout the design process. Talus Design includes HDL and data-path synthesis, flat floorplan generation, and power planning.

The Talus Vortex design flow is a flat physical design flow that begins with netlist input and generates a flat floorplan including automated macro placement and power planning, clock tree synthesis, and detailed routing.

The essential difference between the hierarchical flows and either of the flat flows is the size of design each flow accommodates. Choose the appropriate product based on your design size.

Automated Chip Creation Flow Considerations

Consider the following factors when deciding to use the Automated Chip Creation flow:

• The Automated Chip Creation flow is for designs of one million or more placeable objects. There are strong advantages to running the Automated Chip Creation flow on designs of between one million and two million placeable objects. Always use the Automated Chip Creation flow on designs of more than two million placeable objects.

• There is little advantage to using the Automated Chip Creation flow on designs of fewer than one million placeable objects because of the extra setup time required to prepare a design for the Automated Chip Creation flow. Given a design of approximately one million placeable objects, you might spend a week setting up the design for the Automated Chip Creation flow.

• The Automated Chip Creation flow provides much faster runtimes than the flat flow.

For example, a million-object design can run through the Automated Chip Creation flow in about 24 hours.

Talus Design Flow Guide8 Talus 1.0

Overview of the Talus PlatformDifferentiating Talus Flows

Flat Flow Considerations

Consider the following factors when deciding to use the flat flow:

• The flat flow is for designs of up to one million placeable objects.

• Setting up a design for the flat flow takes less time than setting up a design for a hierarchical flow. For example, it can take approximately three days to set up a design with one million placeable objects for use in the flat flow.

• The flat flow requires much longer runtimes to complete the design than a similarly sized design run through a hierarchical flow. For example, a design with one million placeable objects can take between three and four days to run through the flat flow. A design with two million placeable objects can take up to seven days to run through the flat flow.

• If you intend to redo a design that has already been taped out, use the flat flow, even if the design has more than one million placeable objects.

The balance of this Talus Design Flow Guide deals solely with the functionality embodied in the Talus Design product. You need a Talus Design licence for this product.

For more information about the Talus Vortex flow, see the Talus Vortex Flow Guide. For more information about the Hydra flow, see the Hydra Flow Guide.

Talus Design Flow GuideTalus 1.0 9

Overview of the Talus PlatformDifferentiating Talus Flows

Talus Design Flow Guide10 Talus 1.0

Talus Design Flat Flow

2. Talus Design Flat FlowThe Talus Design flat flow consists of the major stages shown in Figure 2 on page 11. These stages of the flow are contained in standard fix... commands as shown in Figure 3 on page 12.

Figure 2: Magma Design Flow

Optional asNeeded

RTL Optimization

RTL Import

Area Optimization

DFT Insertion

Timing Optimization

Floorplanning

Physical Synthesis

Detailed Routing

Clock Tree Synth.

Hold Fixing

HyperCell DomainReal Cell Domain

HyperCell DomainReal Cell Domain

Incremental Optimization

fix rtl

fix netlist

fix time

fix cell

fix clock

fix hold

fix wire

fix optglobal

fix opt final

fix plan/fix power

Iterate as Needed

DevelopConstraints

Report Analysis

Iterate as Needed

DevelopConstraints

Report Analysis

Incremental Optimization

Talus Design

Talus Vortex

Talus Design Flow GuideTalus 1.0 11

Talus Design Flat Flow

Figure 3: Talus Design Flat Flow

The following sections describe the stages of the Talus Design flat flow in more detail.

fix plan

fix power

fix cell

RTL

fix netlist*

fix rtl

Generates the core floorplan, creates domains and pad rings, and places macros

Runs automatic power-grid synthesis (APS) and hierarchical power routing

Performs initial cell placement, buffering, area optimization, logic restructuring, cloning, and sizing

Performs RTL optimization on an elaborated design and generates a technology-independent implementation using Magma primitives

Converts an RTL design into a netlist of HyperCell models, performs data-path and Boolean optimizations, uniquifies the design, and performs initial technology mapping

fix time* Converts a design to Magma cell models, unmaps and remaps logic in critical and noncritical paths, adjusts gate delays, and performs area optimization

Detailed placement without clock tree or detailed routing, but with congestion and timing reports

* Multiprocessing step (multiple CPOS or multi-threading)

Talus Design Flow Guide12 Talus 1.0

Talus Design Flat FlowBefore You Start: Importing Libraries and RTL

Before You Start: Importing Libraries and RTLThe initial fix... command in the Talus Design flow, fix rtl, requires an elaborated RTL design. If you are beginning the Talus Design flat flow without such a design, use the information in the following sections to prepare your design for use with the fix rtl command.

Setting Variables

For ease of use, if you have not done so before, set the following variables:

set m /work/top/topset l /stdcell_lib_name set lr /ram_lib

By convention:

• m is the top-level model name

• l is the name of the standard cell library

• lr is the name of the RAM library

You can use any name for the secondary libraries. Talus Design assumes that $l points to your standard cell library

These variables are used by almost every Magma command. It is important to define them early in the flow.

Importing the Library

Import the previously prepared library Volcano database using the following syntax:

import volcano stdcell_lib_name.volcano $l

Setting RTL Configurations

Perform the following steps to configure RTL for ease of use during the RTL setup process.

• Set the target library configuration. For designs that contain macros within the RTL, this is necessary to resolve and bind all cells; otherwise, you will have unresolved references.

config rtl targetlib $l

Talus Design Flow GuideTalus 1.0 13

Talus Design Flat FlowBefore You Start: Importing Libraries and RTL

• Set the RTL search path. For designs that contain extensive directory structures, this makes scripts much cleaner. (You do not need to specify the full path for each RTL file.)

config rtl searchpath

• Enable Verilog 2000 support. If the design contains Verilog 2000 constructs, you must set this to parse the RTL.

config rtl verilog 2000 on

Understanding Compatible RTL Coding

Magma RTL synthesis is:

• Completely compatible with industry-standard coding styleo Talus Design fully supports the industry-standard coding style, commonly used pragmas,

instantiated DesignWare components, and hard macros.o Magma does not support design constraints as pragmas (dont_touch, dont_use, and so

forth).

• Language-neutral for Verilog and VHDLo You can mix both VHDL and Verilog blocks within a single design anywhere in the

hierarchy.

• Supportive of Verilog 2000 and VHDL-93

Pragma Support• Talus Design interprets the commonly used Synopsys pragmas (directives) for both VHDL

and Verilog.o Translate_off/ono Full/parallel caseo Function map to moduleo Asynchronous set and reset

• The following syntax is supported:o -pragma or -synopsys for VHDL designso //synthesis or //synopsys for Verilog designs

• You can also use config rtl directive to specify compiler directives

Talus Design Flow Guide14 Talus 1.0

Talus Design Flat FlowBefore You Start: Importing Libraries and RTL

Third-Party Module SupportTalus Design supports direct instantiation of these commonly used Synopsys DesignWare components and others:

DW01_add, DW01_sub, DW01_addsub, DW01_csa, DW_square, DW01_dec, DW01_inc, DW01_absval, DW01_incdec, DW01_ash, DW01_bsh, DW_shifter, DW01_cmp2, DW01_cmp6, DW01_decode, DW01_binenc, DW01_prienc, DW01_mux_any, DW01_satrnd, DW02_prod_sum, DW02_sum, DW02_mult_2_stage, DW02_mult_3_stage, DW02_mult_4_stage, DW02_mult_5_stage, DW02_mult_6_stage, DW02_mult, DW02_div_rem, DW02_divide, DW02_rem, DW02_mac, DW03_bict_dcnto, DW03_bict_scnto, DW03_updn_ctr, DW03_bictr_decode

Initially, all components are assigned minimum area architectures. During the constraint-driven optimization phase, architectures are reselected to meet timing constraints.

Importing RTL into Talus

Use the following command to import RTL into Talus:

import rtl -analyze [-vhdl|-verilog] -include directory_name file_list

You can control or configure the imported files using these import rtl options:

• -analyze – analyzes the RTL file but does not perform elaboration.

• -verilog – indicates that RTL files are Verilog.

• -vhdl – indicates the RTL files are VHDL.

• -incremental - Indicates that the tool should try incremental elaboration of the design. This means that before building any module, the tool first searches all the libraries specified using config rtl targetlib for the module. If one is found, the command uses this module; otherwise it proceeds with normal elaboration.

• -define string – defines “ifdef” variable names in Verilog.

• include dir_name – specifies the name of the directory with any include files referenced in the Verilog RTL.

• -87 – specifies using VHDL-87 mode rather than VHDL-93. (VHDL-93 is the default.)

• -arithmetic auto | small | fast – selects the default architecture that will be chosen for arithmetic operators.

Talus Design Flow GuideTalus 1.0 15

Talus Design Flat FlowBefore You Start: Importing Libraries and RTL

• -lib string– specifies the name of the Magma library where the results are to be stored. If the library does not already exist, the command creates it. By default, the library name is work.

• file_list – specifies a list of all the RTL files to import.

• -sort – allows source files to be specified in any order (for VHDL designs).

• -auto_parse - automatically picks missing modules from the search path specified by the config rtl searchpath command. The source filename of the module must match the module name with a .v extension. This option is valid only for Verilog.

• -exclude string - excludes any unwanted file taken into account as a result of -auto_parse option or through using wild-cards in file names.

• -f file_name - lets you specify one file within which the RTL files that are listed are imported. See the online man page for import rtl, for complete information about this option.

• -print_sorted_files file_name - works only when the -vhdl and -sort options are used simulteneously.; it prints out the files sorted out by the -sort option.

• -elaborate_all - continues elaboration even if errors occur. The tool looks for at least one design unit that elaborates properly, and considers that design unit the top model. If there are multiple such models, the name of the last model is returned as the output of the command.

• -verbose - performs additional diagnostics while processing the RTL code.

Example:

import rtl -analyze –verilog \-include ./include_dir chip.v cntr.v interface.v

Import RTL Directories

After you run import rtl, Talus creates:

• Two libraries called /work and./macro_lib

The Talus library /work contains the design data after elaboration.

The Talus /macro_lib library contains the basic architecture for data path components.

• A UNIX directory called ./work, which is located under the directory where Talus was started

The work directory contains intermediate binary files (.mod for Verilog modules, .ent, .pkg, and .cnf for VHDL) created after you run import rtl. These binaries are loaded into the Talus work library /work during elaboration.

Talus Design Flow Guide16 Talus 1.0

Talus Design Flat FlowBefore You Start: Importing Libraries and RTL

Elaborating the Design

After analyzing the RTL, you can elaborate the design (check the combination of files as a whole to see that they are properly connected to one another) using the following command:

run rtl elaborate object -vhdl -verilog [-parameters param_name] \-architecture arch_name -lib -add_dc -case top_model_name

You can control or configure the elaborated files using these run rtl elaborate options:

• -vhdl – performs elaboration on a VHDL design.

• -verilog – performs elaboration on a Verilog design.

• -lib – specifies the library. The default is work.

• -arithmetic – specifies default architectures for datapath elements (auto|small| fast).

• -parameters – overrides default parameters or generic values of the module.

• -architecture – specifies an architecture for VHDL designs.

• -case – handles how name case is translated for VHDL designs (upper, lower, preserve).

• -incremental – requires the tool to try incremental elaboration of the design. This means that before building any module, the tool first searchs all the libraries specified using config rtl targetlib for the module. If one is found, the command will use this module, otherwise, it proceeds with normal elabration.

During elaboration, the design is loaded into the Talus /work library unless you specify the -lib option.

Example:

run rtl elaborate chip

Talus Design Flow GuideTalus 1.0 17

Talus Design Flat Flowfix rtl

fix rtlDuring fix rtl, the tool performs high-level RTL optimization on an elaborated RTL design and generates a technology-independent implementation using Magma primitives.

Individual config... commands control many of the subsidiary tasks included in the fix rtl command.

The fix rtl command requires the name of a model or design as input.

Before you run fix rtl:

• Elaborate your RTL design

• Set any desired config... commands

The fix rtl command uses the following syntax:

fix rtl model

The fix rtl command implements these major tasks:

1. Performs mandatory optimization, includingo Inference of storage elements, flip-flops, and latcheso Propagation of constantso Removal of unnecessary flow graph nodeso Mapping of design to primitives

2. Performs clockgating based on the settings you use for these commands: o To set clockgating requirements for the entire design, use the config rtl clockgate

command. Using the -test before | after option, you can choose between combinational and latched gating to control the position of test OR gates.

o To set clockgating requirements for an individual model, use the force rtl clockgate command.

You can investigate clock gating opportunities in your design before running the fix rtl command by using the report rtl clockgate command on an elaborated design.

After you have set your clock gating style, you can display the clock gating style with the query rtl clockgate command.

Talus Design Flow Guide18 Talus 1.0

Talus Design Flat Flowfix rtl

3. Performs the following kinds of expression synthesis based on the settings you use for the config rtl sharing, force rtl sharing, config rtl merging, and force rtl merging commands:o Collapses groups of arithmetic operators into large clusters for better optimizationo Performs resource sharingo Performs operand merging

4. After reading RTL files and performing mandatory optimizations, performs final, high-level synthesis. Also performs initial datapath implementation, based on the settings you use for the config rtl datapath, force rtl datapath, and run rtl elaborate -arithmetic fast commands. For example, to enable a change of architecture in physical synthesis, use:

config rtl datapath physical on|off

To select an implementation type, use:

config rtl datapath option_name value [-list]

See the man pages for these command for complete information about the implementation types and values available.

5. Flattens user hierarchy, based on the settings you use for the force keep, config rtl flatten, and config rtl autoflatten commands.

At this stage of the Talus Design flow, both full design hierarchy and some tool-introduced hierarchy are present. Although tool-introduced hierarchy is maintained at this point in the flow, user-created hierarchy is flattened too Extend the scope of RTL optimizationso Increase the clarity and readability of design files and schematics

To allow RTL flattening of small modules to increase optimization using this syntax:

config rtl autoflatten [-bitwidth_threshold integer][-min integer] \ [-max integer] [-comb]

You can prevent flattening of models using the force keep command, but use it sparingly because this affects QOR.

To generate a report of modules that can be flattened, you can use the report rtl autoflatten command.

Talus Design Flow GuideTalus 1.0 19

Talus Design Flat Flowfix netlist

6. Produces the following output data:o Clock gating reporto Area report (flat)o RTL resources reporto Verilog equation netlisto Design Volcano

For more information on RTL synthesis, see the RTL Synthesis Technology Note.

fix netlistUsing an RTL design that was previously processed by the fix rtl command, the fix netlist command performs Boolean and datapath optimizations; removes unconnected or unused logic; collapses and preserves larger gates (XOR, MUX); uniquifies the design; and performs initial technology mapping to HyperCell models. The final product is a netlist of HyperCell abstracts for a design with the least possible area.

The fix netlist command requires the following input:

• Model name

• Library name

Before you run fix netlist:

• Run fix rtl

• Set any necessary config... commands

The fix netlist command uses the following syntax:

fix netlist model library [-scan] [-effort low | medium | high] \[-parallel launch_spec]

The fix netlist command performs the following major tasks:

1. Binds each unbound model cell in the design to a model cell in the technology library.

After binding, you need to investigate any unresolved references. If you have not yet uniquified the design, even a single missing library model can cause multiple errors in your netlist.

Talus Design Flow Guide20 Talus 1.0

Talus Design Flat Flowfix netlist

2. Flattens the design:o Removes user-inferred hierarchyo Retains datapath meta cells to allow datapath architecture swapping later in the flowo Preserves cells with test-related attributes

3. Unmaps any technology-specific cells in the design to primitives and then maps those cells to to specific Magma HyperCells. (The tool does not unmap models to which you have applied the force keep command.)

Unmapping and mapping can reveal unused logic in your design.

4. Removes any unused or unconnected logic. This sweep process reduces area and allows the tool to focus on genuine paths in your design.

5. Uses the check model command to perform an RTL-level sanity check and provide a detailed list of violations.

If the check model command encounters severe errors, the fix netlist command halts.

The warnings and error messages created during the check model command generally include instructions on how to obtain further information on the violation.

6. Locates patterns and primitives in the design’s logic and collapses (consolidates) them into more complex entities. The most commonly collapsed entities are XOR gates and MUXes. (Collapsing design elements is an important precursor to further logic optimization.)

7. Performs area optimization and attempts to reduce the literal count in your design. (A literal is an internal metric roughly equivalent to a pin count.)

By default, the blocks with an initial literal count greater than 15,000 are broken into smaller pieces and optimized individually. (You can increase the literal count limit to 70,000 by using the fix netlist -effort high command.)

You can manually specify maximum literal counts with the force gate independent command. You can use this command to specify higher literal counts either on the entire design or on specific models within the design.

Note: Specifying higher literal counts increases runtime and memory usage.

8. Performs area-based mapping to HyperCells.

This mapping is similar (but not identical) to the initial mapping performed at the beginning of the fix netlist command. This “noncritical” mapping applies to designs that have already been mapped to HyperCells.

9. Removes redundant circuitry based on constant propagation.10. Uniquifies the design hierarchy by copying models

Talus Design Flow GuideTalus 1.0 21

Talus Design Flat Flowfix netlist

Most algorithms require a one-to-one relation between cells and models before such algorithms can run properly. The hierarchy is not changed, but each model is guaranteed to be instantiated only once. If more instantiations are found (multiple cells bound to the same model), the model is copied so that a one-to-one relation between cells and models is created.

At this point of the fix netlist command, all instances in the design share a single reference in the library. During this step of the fix netlist command, library models are copied to create a one-to-one correspondence between design model cells and library model cells. Although this step in the flow requires increased memory resources, this step is a necessary precursor to timing analysis.

Configuring Area Optimization SettingsYou can configure the tool to perform area optimization according to the strategy that is best suited to your design.

Note: Area optimization stops at module boundary.

• For better area QOR, flatten non-timing-critical blocks using this syntax:

data flatten /work/moduleA/moduleAdata flatten $m/moduleB_inst3

• To prevent all flattening of a particular module use this syntax:

force keep /work/moduleB/moduleB

• To retain netlist hierarchy of a particular module use this syntax:

force maintain /work/moduleB/moduleB

• If the design is timing critical, override the area optimization steps, which create more levels of logic, using the following syntax. This can be done for the whole design or part of it.

force gate opt_mode object delay/area -hier

• To prevent area optimization on a given block, use this syntax:

force gate independent /work/moduleC/moduleC 0 -hier

• For precompiled blocks, you can skip area optimization using this syntax:

force keep /work/precompiled/precompiled -content

For custom-designed blocks (such as data paths or control logic), you can skip optimization steps to preserve redundant structures.

You can also set values to preserve cells and hierarchy in the flow.

Talus Design Flow Guide22 Talus 1.0

Talus Design Flat Flowfix netlist

• To preserve specific instance that might be used later in flow (defining clock, scan control, and so on), use this syntax:

force keep /work/clkcntl/clkcntl/inst_clk_div

• To prevent an instance from being mapped to a different drive cell, use this syntax:

force keep /work/clkcntl/clkcntl/inst_clk_div -model

Using Distributed ProcessingIf you have a DPX license, you can use the -parallel string option for the fix netlist command to specify a list of elements that determine how to launch slave processes using DPX processing, when jobs are distributed over several processors. For more information about using parallel processing with the fix netlist command, see the online man pages for this command and the MPX and DPX Processing Technology Note.

Configuring fix netlist for Third-Party ToolsUse the -scan option if you are using third-party scan tools. The -scan option changes all flip-flops to scan flip-flops. It connects the SE pin to ground and loops the SI pin to Q.

If you use the -scan option, you must:

• Ensure that scan flip-flops exist in library, using this syntax:

report dft scan cell $m -lib

• Define the scan style, using this syntax:

force dft scan style $m muxed_flip_flop

You must define the scan style even if the library lacks nonscan flip-flops. If some flip-flops have both scan and nonscan, and some have only scan, hide all nonscan flip-flops to enable the tool to select from all the variations of scan flip-flops

For complete information about scan insertion and using the fix netlist command, see the RTL Synthesis Technology Note and the Implementing Design For Test Technology Note.

Talus Design Flow GuideTalus 1.0 23

Talus Design Flat FlowUsing DFT in the Talus Design Flow

Using DFT in the Talus Design FlowDesign for Test (DFT), or scan, logic must be inserted into your gate-level netlist before timing optimi-zation so that it can be optimized along with your functional logic. There is no fix… command for scan insertion. The procedure involves composing config… and force… commands to specify scan chains and control pins, determine which automatic repair functions to enable, enable them, perform the pre-scan analysis, scan repair and insertion, and perform post-scan analysis.For complete information about implementing DFT in the Talus design flow, see the Implementing Design for Test Technology Note.

fix timeIn the fix time command, the tool does initial netlist preparation, independent of net loads, and estimates timing without placement data. It works to solve timing problem using netlist changes, with minimum area overhead, using strength-based HyperCell models to reduce pessimism and runtime. This command performs constraint-based optimization on worst negative slack as well as total negative slack.

The fix time command requires as input:

• A gate-level netlist

• A logical library

• Timing constraints

Preparing to Use fix time

Before you run fix time:

1. Import the netlist and libraries using import... commands and the import lib command.2. Set the timing constraints for the design using the following commands:

o force timing clock o force timing delay o force timing check

For complete information about setting timing constraints, see the chapter about timing constraints in the Talus Clock Implementation Technology Guide.

Talus Design Flow Guide24 Talus 1.0

Talus Design Flat Flowfix time

Use the following syntax:

fix time model library [-effort low|medium|high] [-options]

The fix time command performs these major tasks in the following order:

1. Begins optimization by unsizing all cells.2. Performs the following tasks based on the value of the -effort option:

If you choose the -effort low option to fix time, it removes all the buffers from the netlist. This action corrects any buffers in the design that were inserted with an inaccurate understanding of wire loading effects. This option is recommended for designs that are handcrafted or synthesized using third-party tools.

If you choose the -effort medium or high option to fix time, it remaps the design in the following order:

A. Unmaps noncritical cellsB. Maps the noncritical cells for areaC. Unmaps timing critical cellsD. Maps the unmapped cells for timing

3. Performs area optimization.

Because fix time performs a constraint-based optimization, the QOR is strongly dependent on the quality of timing constraints. Poor or inaccurate constraints lead to poor results later in the flow.

4. Performs Boolean optimization and mapping on portions of the model that are not timing critical to reduce area without degrading timing.

5. Performs redundancy removal and strength trimming.6. Inserts the buffers in fix time based on fanout and wire load models (if you do not use the

-lib_only option).

These models affect the quality of results. Wire load models can come from the library or can be user-defined. The fix time command uses Manhattan wire models by default.

See the online man pages for complete details about the fix time command and its options.

Talus Design Flow GuideTalus 1.0 25

Talus Design Flat Flowfix time

Using Multiprocessing

If you have a DPX license, you can use the -parallel string option to specify a list of elements that determine how to launch slave processes using distributed (DPX) processing. For more information about using parallel processing with the fix netlist command, see the online man pages for this command and the MPX and DPX Processing Technology Note.

Setting fix time Options

You can configure these fix time command options to meet the requirements of your design:

• -timing_effort low | medium | high – specifies the level of effort to use for timing optimization. The default is low.

• -slack float value – specifies the target critical slack for optimization; The default is 0.0. You can use this option to over- or underconstrain the timing of a design to adjust where area optimization starts and timing optimization stops.

Positive values mean that timing is optimized to try to meet positive slack (as opposed to the usual 0 ps slack). Negative value means that some negative slack, which is smaller than the given value, is left unchanged.

• -rule_lib string – specifies the name and location of a separate technology rule library, for cases where $l contains the standard cells but not the routing technology rules. fix time then binds the models to the physical rule library.

• -libonly – indicates that physical libraries are not available, in case you want to check the architecture of a circuit to determine whether the circuit meets timing.

You can use the report timing path command to verify that a circuit meets timing after running fix time.

fix time Examples

fix time -effort high -timing_effort high $m $l

This example performs delay optimization on the design using area recovery to decrease area, while using a higher effort for timing optimization. Use these options if the design is both timing critical and area critical. Using both options results in the longest runtime.

fix time -slack 500p

Talus Design Flow Guide26 Talus 1.0

Talus Design Flat Flowfix time

This example performs timing optimization on the design using a target slack of 500p, effectively overconstraining the design by 500p.

Quality of Results Improvements

Sometimes it is desirable to do incremental optimization after fix time

• If you make incremental changes in constraints

• If macros are blocking optimizations of critical path

• If you want to optimize all but the most critical path from fix time

• If your I/O constraints are not realistic, and they are blocking optimization in fix time

At the end of fix time, all cells have strength trimmed. For architecture optimization, you can set strength back to 1 using this command:

run gate unsize $m $l

You can use the following commands for extra optimizations:

run gate speed $m $l [options]run gate map $m $l [options]

After optimizations are done, you can trim the design to prepare for global placement using this command:

run gate trim $m $l

Checking fix time Results

After you run the fix time command, if you are not satisfied with the results, you might want to check:

• The constraints you specified

• The level of effort you specified

If you need to adjust the constraints, see the Timing Constraints and Reports chapter in the Timing Constraints and Analysis Technology Guide. In the same document, for more information about viewing timing paths, see the chapter about Viewing Timing Paths in the GUI.

Talus Design Flow GuideTalus 1.0 27

Talus Design Flat Flowfix plan

fix planThe fix plan command generates the floorplan along with power and ground mesh for a flat design. It performs the following specific operations:

• Binds the physical rules library to the design model

• Locates the top-level ports for the design model

• Generates the primary floorplan and inner shape

• Performs pin, pad, and macro placement

• Performs cover macro creation

The fix plan command applies rules derived from the physical rules library.

Before running this command, if you have not done so already, you need to complete the following steps:

1. Fix the time for your design with the fix time command. 2. Define power and ground meshes with the force plan mesh command. 3. Define the power and ground ports with the force plan net command. 4. (Optional) Define a fixed core size with the force floorplan parameters command.

The fix plan command requires as input:

• The name of a model or design

• The name of the standard cell library to be used

Use the following syntax:

fix plan model library [-options]

Talus Design Flow Guide28 Talus 1.0

Talus Design Flat Flowfix plan

Reusing Floorplans

A floorplan can be reused in any of the following formats:

• DEF – use the import def all command

• PDEF – use the import pdef command

• Tcl – source the script

A floorplan can have X- and Y-dimensions, pins placement, power plan, and full or partial macro placement.

Configuring the fix plan Command

You can use the fix plan options described in the following section to influence the placement of the elements of a block or chip.

Primary Floorplan and Inner Shape CreationThe fix plan command generates the primary floorplan and inner shape using the specifications you supply with these options:

• -width string -height string – specifies the width and height of the chip.

• -lower_left {x y} – specifies the lower left coordinate of the chip. The default is 0 0).

• -floorplan_only – halts the flow after floorplan creation. You can continue the flow from the last step by running fix plan again.

• -keep_primary_inner – maintains the original boundary of the inner shape; otherwise, fix plan creates a new inner boundary that contours through all the pads.Area I/O designs require this option; otherwise, fix plan creates split floorplans, which break the flow.

Talus Design Flow GuideTalus 1.0 29

Talus Design Flat Flowfix plan

Power Domain CreationThe fix plan command automatically creates a default power domain named dom1 for the primary floorplan.

You can create additional domains with the data create domain command.

You can control power domains using these options:

• -domain_name string – changes the domain name.

• -no_auto_domains – skips default domain creation.

• -cust_dom_script – supplies a custom domain script. The script must include the definition of the domain, the power and ground ports, and the power and ground nets.

• -complement_dom_script string – specifies the full path to a Tcl script that the tool executes at the end of the power domain definition. You can use this script to provide supplemental commands to your custom power domain.

Power and Ground CreationThe fix plan command defines power and ground ports and nets with the name specified in these options:

• -p_pwr_net – defines the primary core power net. The default is VDD.

• -p_gnd_net – defines the primary core ground net. The default is VSS.

• -pwrport – defines the list of port names connected to the primary power net. The default is VDD. You can specify multiple port names with this option.

• -gndport – specifies the list of port names connected to the primary ground net. The default is VSS. You can specify multiple port names with this option.

Cover Macro CreationBy default, the fix plan command does not build a cover macro. However, flip chip designs require the definition of power bumps before the power mesh can be created. To allow rapid prototyping, fix plan can create a temporary cover macro that creates a prototype cover cell to power only the core (if one does not exist). These options are used to create and configure the cover macro:

• -build_core_supply_cover – creates the prototype cover cell.

• -cover_pin_size real_number – specifies the size of a square cover pin. The default is 100u.

Talus Design Flow Guide30 Talus 1.0

Talus Design Flat Flowfix plan

• -cover_pin_pitch real_number – specifies the cover cell pin pitch. The default is 300u.

• -cover_pin_margin real_number – specifies the distance from the model box boundary that defines the rectangle containing the cover pins.

Pad and Pin PlacementThe fix plan command operates on a pad planned or unplanned design. It automatically places the pad ring for an unplanned design. However, if pad placement exists, fix plan must be directed to skip this step.

To disable automatic pad or pin placement, use the -keep_pad_placement option if:

• Pads are not marked FIXED.

• Model pins (not connected to pads) do not have geometry.

Automatic pad placement is useful for prototyping and should be replaced with actual pad placement.

The design is initially placed using minimum wire length algorithm. Then, I/O pads are placed in a single ring. For complicated or custom rings, create them externally.

If corner or filler cells are defined in the library, the placer automatically uses them to construct the ring. You can use these options configure the placement of pads or pins:

• -pad2core_dist_mic – specifies the distance between the inner primary floorplan and the inner edge of the pads. Distance is expressed as a real number, for example, 25.0e-06.

• -pad2core_dist_row – specifies the distance between the inner primary floorplan and the inner edge of the pads. The distance is expressed as number of rows. If no row is defined in the floorplan, the height of the $l/INV/INV_HYPER is used.

• -ring_layer_maxw_percent – specifies the distance between the inner primary floorplan and the inner edge of pads.This option considers the layer with the highest maximum width, max_w. The gap distance is given in this form:

gap = 2 * max_w * percent + 3 * spacing

Spacing is the distance required to avoid spacing DRCs between the two stripes.

Talus Design Flow GuideTalus 1.0 31

Talus Design Flat Flowfix plan

Macro PlacementYou can further configure fix plan macro placement using these options:

• -no_macro_placement – skips macro placement.

• -timing_effort – controls the timing effort in cluster placement.

• -margin string – specifies the margins globally, by indicating the minimum distance between the sides of the outer and inner shape of a rectangular floorplan.

• -left_margin string, -right_margin string, -bottom_margin string, and -top_margin string – specify the margins at each side, by indicating the minimum distance between the left, right, bottom, and top of the outer and inner shape of a rectangular floorplan. The default is 0u. If no units are specified, meters is assumed.

• -scribe_line_margin floating-point number – specifies the distance from chip boundary to the outer boundary of the pads.

Halo SpecificationsYou can use the following options to the fix plan command to set values for macro halos:

• -macro_halo integer – specifies an integer that specifies a number of row heights that define the hard macro halos. The clearance is set to half a row height. The default is 5 rows. The default sets the macro-to-macro distance to 10 rows.

• -floorplan_halo integer – specifies the number of row heights that define the primary floorplan halo. If the floorplan halo is smaller than the macro halo, the floorplan halo is set to 0 so it does not collide with the macro halo. The default floorplan halo is 7 rows. This default maintains 7 rows of spacing between the primary floorplan and the hard macros. If -floorplan_halo is set to 0, the tool determines the spacing by using the -macro_halo value.

• -reset_macro_halo – resets the value of the -macro_halo option for all macros to the default value. You can use this option if you run fix plan multiple times and you do not want to use a previously set halo value for one of the runs.

The fix plan command uses enwrap commands to save reports, data files, and Volcano databases at key points within the flow. The reports and data are written to the snap directory, which is below the current directory.

See the online man pages for details about the fix plan command and its options.

Talus Design Flow Guide32 Talus 1.0

Talus Design Flat Flowfix power

fix powerThe fix power command creates power routing (including ring and mesh) for the chip. It implements the power routing inside each soft macro and at the top level.

If you do not use the -keep_primary_inner option of the fix partition command when you perform partitioning, fix power defines a gap or pad-to-core distance that is saved and used to create a core ring. If the gap varies, ensure that the ring is valid.

Preparing to Use fix power

The fix power command requires as input:

• The name of a model or design

• The name of the standard cell library to be used

Use the following syntax:

fix power model library [-options]

Configuring fix power

You can define power requirements manually, by specifying such parameters as mesh density and layers, or automatically, using automatic power-grid synthesis (APS) by specifying an activity ratio. Using other options, you can further specify functionalities for fix power.

Defining Power Requirements ManuallyManually specifying the parameters of a default power network results in a quick and complete power solution that presents an accurate congestion picture. This specification-based power grid can be optimistic or pessimistic, based on the specification numbers given. You can use the following options to specify the parameters:

• -default_mesh – enables the use of default rules in the technology library to build a regular power grid. The meshes follow the soft macro shaping grid with a half grid offset so that they do not overlap with the soft macro boundaries. The mesh is made of pairs of stripes.

• -percent_mesh – specifies the spacing of the default mesh (both power and ground). The default is 0.1 (10%), meaning the command uses slightly more than 20% (10% each for power and ground) of the area per layer. This also defines the width of a power stripe as a percentage of the soft macro shaping grid.

Talus Design Flow GuideTalus 1.0 33

Talus Design Flat Flowfix power

• -mesh_range – supplies a list of metal layers to use in constructing power mesh if you use the -default_mesh option.

• -local_mesh_over_macro – specifies the layer of the pinson which to build a local mesh over the hard macros. If you specify Metal4, then a Metal5 local mesh is built.

• -mesh_detail_spec – specifies the density per layer or utilization. Using this option replaces the need to use the -default_mesh and -mesh_range options.

The following command creates a regular mesh that uses layers M5 and M6 and has 20% density:

fix power $m $l –build_core_supply_cover –default_mesh \–percent_mesh 0.2 –mesh_range {M5 M6}

Defining Power Requirements AutomaticallyYou can use APS to create a more efficient power network and less routing congestion. This requires a minimum of design effort but more runtime for analysis. APS automatically determines widths of individual mesh sections. You can use the following options to configure APS:

• -auto_mesh – enables APS.

• -activity_ratio – specifies an activity ratio for APS. The default is 0.2 (20%).

• -lower_mesh – defines the lowest layer used for building the mesh (if -auto_mesh is used). The default is 4, which means that the fourth layer, typically metal4, is chosen. If this option is set to 0, this means that if metal2 is vertical, the lowest layer is metal4; otherwise, it is metal5.

The following command automatically synthesizes a power mesh based on 20% gate activity.

fix power $m $l –build_core_supply_cover –activity_ratio 0.2 –auto_mesh

Defining Power Requirements With ScriptsYou can create scripts to build a custom mesh or create other power structures by using these options:

• -cust_mesh_script – specifies the full path to an existing custom script that defines a power mesh.

• -custom_dom_script – specifies the full path to a script defining the power domains. If you specify an existing file, the command ignores the -auto_domains option.

Talus Design Flow Guide34 Talus 1.0

Talus Design Flat Flowfix power

• -complement_dom_script string – specifies the full path to a Tcl script that is executed at the end of the power domain definition. You can use this for supplemental commands to your custom power domain.

• -macro_ring_script – specifies the full path to a script that defines the hard macro rings, including customizations such as special pin tapping distance, custom ring creation, connection to the mesh, and so on.

• -cust_padring_routing – specifies the full path to a script that defines special power routing inside the pad ring.

If you use these scripts, be sure each script defines and builds only the mesh definition related to that option. The fix power command uses each script you source at the appropriate place in the flow. If you do not source a customized script for any part of the mesh, the command creates that part by using the default method.

Defining Additional RequirementsYou can use additional options to the fix power command to accomplish these tasks:

• -auto_domains – automatically defines power domains.

• -auto_core_ring – builds a core ring.

• If a cover cell is detected, use the -build_core_supply_cover option to create a mesh to connect the cover cell pins. This option creates a prototype cover cell to power only the core of the chip. These options configure the operation of the -build_core_supply_cover option:o -cover_pin_size and -cover_pin_pitch – modify the size and pitch of the pins. o -cover_pin_margin – modifies the distance or margin from the chip boundary where

signal pins are built. o -cover_mesh_limit – specifies how the mesh that connects the cover pin cells is

stretched toward the boundaries of the chip.

• -core_ring_detail_spec string specifies the number, sizes, offsets, and layers of the core rings. See the fix power man page entry for this option for a complete example.

• -pad2bump_routing – creates the biggest via possible on top of the pad pin to connect the pad pin and the RDL routing if the RDL routing between the signal bumps and the pad pin is missing a via.

• -no_opt_strength – skips the strength optimization step if run optimize strength has already been run and the design contains HyperCell models, a situation in which APS requires the design to be strength optimized.

Talus Design Flow GuideTalus 1.0 35

Talus Design Flat Flowfix power

• -push_down_highest_layer – specifies the highest layer to be pushed down. The default is the layer used by the cover pins.

• -scribe_line_margin – specifies the distance between the boundary of the chip and the outer edge of the pads.

• -ring_layer_maxw_percent – specifies a percentage (for example, 0.5 for 50%) that is used to calculate the distance between the inner primary floorplan (core) and the inner edge of the pads. See the online man pages for complete details.

• -block_hor_edges – prevents building power rails on the horizontal edges of the secondary floorplans, preventing any via dropping from the lower mesh layer to the power rails.

• -repeated – specifies that the regular meshes, not the meshes generated by -auto_mesh have a special structure. Instead of a regular pair (VDD VSS) with same width wire, the mesh are built VSS VDD VSS, with the VSS wires having half the width of the VDD wire. This allows repeated blocks to be flipped vertically or horizontally. The meshes are built that way across the entire core.

Defining Power Structure NamesYou can use these additional options to define power structure names:

• -p_pwr_net – specifies the name of the primary power net.

• -pwrport – specifies the generic names for ports connected to the primary power net.

• -p_gnd_net – specifies the primary ground net.

• -gndport – specifies the generic name for ports connected to the primary ground net.

• -ring_layer_top – specifies the name of the layer used as the highest layer to build the core ring. The core ring uses four layers.

fix power Example

fix power $m $l -auto_core_ring -ring_top_layer M6 -default_mesh \ -percent_mesh 0.1 -mesh_range {M4 M6}

Talus Design Flow Guide36 Talus 1.0

Talus Design Flat Flowfix power

This example builds a core ring in the gap between the pads and the primary inner floorplan. The highest layer used by the ring is M6 and the ring uses four layers. A regular mesh is built using layers M4, M5, and M6. The mesh uses the soft macro shaping grid shifted by half the soft macro shaping grid pitch. The nets used for building the mesh are the two primary power and ground nets. Each stripe width is 10% of the soft macro shaping grid.

Checking fix power Results

Before you continue the design flow, you can use the GUI to check whether the following are correct:

• Power and ground connections

• Power and ground mesh placed on the layers you specified

• Power vias

• Connections to the ring

If you need to adjust any of these parameters or need more information about hierarchical floorplanning, see the Prototypes and Block Abstracts Technology Guide and the Power Analysis Technology Guide.

Important: Results of the fix power command are temporary values generated to be used by the fix cell command and are not used in the final design.

Talus Power

If you have purchased the Talus Power option, you can take advantage of its advanced power optimization and management abilities, including:

• Power-aware synthesis

• Clock gating and power-aware clock implementation

• Leakage power minimization using multi-Vt libraries

• MTCMOS switch insertion and analysis

• Support of designs with voltage islands

• Automatic optimization and insertion of decoupling capacitance (decap) cells based on transient analysis

For more information about the Talus Power product, see the Talus Power Technology Guide.

Talus Design Flow GuideTalus 1.0 37

Talus Design Flat Flowfix cell

Quartz Rail

If you have purchased the Quartz Rail option, you can use its advanced features to perform:

• Streamlined rail analysis

• Abstraction and advanced macromolecule creation

• Embedded thermal analysis

• Transient rail analysis

• Static and dynamic power analysis

For more information about the Quartz Rail product, see the Quartz Rail Technology Guide.

fix cellThe fix cell command performs a series of optimization steps that adjust loads and timing budgets to meet circuit timing requirements. The fix cell command performs incremental global placement and final logic optimization steps in the flow, and converts the design from HyperCell models to standard cells. In addition, if config scan optimize has not been set to off, fix cell minimizes wire length by reordering scan chains.

Preparing fix cell

If you have defined scan chains by using the force dft scan chain command and if you have not set the config scan optimize command to off, the fix cell command optimizes the scan chains after placement.

See the scan chain information in the Implementing Design for Test Technology Note for more detailed information about scan chain reordering and repartitioning.

Talus Design Flow Guide38 Talus 1.0

Talus Design Flat Flowfix cell

Configuring fix cell

The fix cell command uses the following syntax:

fix cell model library [-timing ] [-congestion ] [-prototype] \[-iterations integer] [-multipass_skew] [-noprune] [-sa] [-skew_budget]

You can use these options to the fix power command to configure the command to best accomplish your design needs:

• -timing – increases the effort spent on placement, buffering, cell sizing, and, if applicable, scan optimization to resolve timing issues. o Almost always comes with a cost of increased wire lengtho Increases effort in some of the logic optimization steps to get better timingo Changes the order of the flow to translate HyperCell models to real cells a little earlier

than without -timing

• -congestion – increases the effort spent on scan chain reordering to resolve congestion issues and increases the effort in wire buffering to develop lower wire length solutions.o Increased wire buffering comes at increased cost in runtime due to additional timer

updates as it tries to identify where buffering needs to be aggressive for timing and where it can try to save wire length.

o A side effect is that, in many cases, if high fanout nets are in the critical path, this additional runtime can come with improved timing.

• -prototype – runs an abbreviated version of the fix cell command. Use this option if you want a quick result, and getting an ideal result is not as important to you.

• -iterations – specifies the number of iterations to perform. The default is 1 iteration.

• -multipass_skew – calculates useful skew at clock endpoints for each iteration except the final iteration (near the end of fix cell. It is recommended that you use -weight smart_skew with the fix clock command if you use this option. This option is effective during a multipass flow and has no effect if the -iterations option is set to 1.

• -noprune – prevents the removal of unused models and entities from the cell libraries during the run of fix cell.

Talus Design Flow GuideTalus 1.0 39

Talus Design Flat Flowfix cell

• -skew_budget – redistributes slack by introducing useful skews at clock endpoints to ensure that the slack-to-delay ratios of the paths are balanced in the design. It affects the timing optimization performed by the fix cell command. This option cannot be used with the -multipass_skew option.

• -sa – performs structured-ASIC-specific operations.

See the online man pages for complete details about the fix cell command and its options.

The fix cell command uses enwrap commands to save reports, data files, and Volcano databases at key points within the flow. The reports and data are written to the snap directory, which is below your current directory.

fix cell Example

The following command:

fix cell $m $l

fixes timing and global placement, converts HyperCell models to standard cells, and performs final logic optimization on the design $m, using the standard cell library $l.

Checking fix cell Results

If you are not satisfied with the timing at this point, you can run the fix opt global command to improve timing.

Talus Design Flow Guide40 Talus 1.0