BuildGates User Guide

BuildGates User Guide

Cadence Design Systems, Inc.2500 Augustine Drive, Suite 200Santa Clara, CA 95054 USA408 988-3232 Fax: 408 988-3233Toll free: 888 GOAMBIThttp://www.cadence.com

Part No.900-70057-0101Release 2.3, March 1999

ledia

dance

areroughterms

s, Inc.

Cadence Design Systems, Inc. 1994 - 1999. All rights reserved.

BuildGates Release 2.3, March 1999

Use of Ambit software source code is governed by the license agreement accompanying your originamedia. The Ambit software source code and its documentation may not be transferred to any other mwithout the express written permission from Cadence Design Systems, Inc.

The provision of Ambit software source code to the U.S. government is with restricted rights in accorwith the terms defined as follows:

The software is a “commercial item”, defined according to 48 C.F.R. 2.101 (OCT 1995) consisting of“commercial computer software” and “commercial computer software documentation” as such termsused in 48 C.F.R. 12.212 (SEPT 1995). Consistent with 48 C.F.R. 212 and 48 C.F.R. 227.7202-1 th227.7202-4 (JUNE 1995), all U.S. Government End Users acquire the program in accordance with thedefined herein.

Trademarks

BuildGates, Ambit, and ac_shell are trademarks or registered trademarks of Cadence Design System

The Tcl debugger code used in the BuildGates software was originally written by Don Libes of NIST.

All other products and trademarks are the property of their respective owners.


3

1

4

0

01

33

12

5

Table of Contents

1Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1AMBIT Tools and Methodology Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Organization of This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Conventions Used in this Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

2Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-The Simple Design File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1Invokingac_shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

•Command Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2•Command File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3•Setting up the Technology libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3•Using Command Short-names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3•Shell Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Getting Started — Logic Synthesis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-•The read_verilog Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4•Build a Generic Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Finding Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Setting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

•Setting the Top Level Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7•Defining all Clocks Used in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7•Setting Data Arrival Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7•Setting Data Required Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8

Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8•Reading The Technology File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8•Optimize command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

Generating Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9•Writing A Verilog Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10•Writing the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10•Looking at hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1•Area report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Figure 2.2 —Timing reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Figure 2.3 —The Timing Report Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Exiting from BuildGates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14

3Verilog Modeling Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Register Inferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Latch Inference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3Asynchronous set-reset on a latch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-

Flip-Flop Inference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3Note:Synchronous set-reset on a flip-flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3Note:Asynchronous set-reset on a flip-flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

Combinational Logic Inferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5Case Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5

Incomplete Case Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-

Cadence Design Systems Inc. i Cadence Confidential


-6

900

111

4

77

79

1

3

77

0101

35779

990122

23

Use of Casex and Casez Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3For Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8Synthesis Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8

Code Selection Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9Case Statement Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-

Note:Full Case Directive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1Note:Parallel Case Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1Note:Mux Directive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Set_Reset Synthesis Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-Figure 3.1 —Block directive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12Figure 3.2 —Signal Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1Figure 3.3 —Signals in a Block Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15

Architecture Selection Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1Finite State Machine Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Figure 3.4 —Enum Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1Example1.5 -State_vector Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

FSM Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19

4VHDL Modeling Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Associated Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-Combinational Logic Inferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Register Inferencing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2

Latch Inferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2•Asynchronous set-reset on a latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-

Flip-Flop Inferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4•Synchronous set-reset on a flip-flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4•Asynchronous set-reset on a flip-flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5

Specifying Clock Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6The Case Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7

Incomplete Assignments in the Case Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-Complete Assignments in the Case Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-

The For Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8Synthesis Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9

Code Selection Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9•Synthesis on/off Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9•Translate on/off Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Set_Reset Synthesis Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-Figure 4.2 —Process Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Figure 4.3 —Signal Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Figure 4.4 —Signals in a Process Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Architecture Selection Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Enumeration Encoding Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Signed Type Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Mux implementation Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Finite State Machine Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Table 4-1 —Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2Resolution Function Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2Template Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2Type Conversion Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2

Reading VHDL designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-22Defining Logical Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2Predefined VHDL Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2

Cadence Confidential ii Cadence Design Systems Inc.


67

7

8999

3132

1

1

8

141616

788

199

-2001212

22232

1

Table 4-4 —Using Arithmetic Packages From Other Vendors . . . . . . . . . . . . . . . 4-25Switching between VHDL’87 / VHDL’93 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26Reusing previously analyzed entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Modifying case of VHDL names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Writing VHDL Netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27Selecting bit-level representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2VHDL’87 / VHDL’93 netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28Referring to VHDL packages in netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Writing Component Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Hierarchical VHDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Component Instantiations and Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Restrictions on Entities with Multiple Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30Precedence Rules for Architecture Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-

VHDL Related Commands and Globals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-

5Setting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Setting a Hierarchical Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-Units in Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Setting up Timing Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Ideal Clock Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3Clock Arrival Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4Data Arrival Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6

Figure 5.5 —Early and Late Arrivals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6Figure 5.6 —Setting Arrival Time for All Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

Data Required Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-External Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10Multi-cycle Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Setting Drive Cell for Input Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Setting Drive Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-Slew Related Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-

Figure 5.15 —Setting Slew Limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17Figure 5.15 —Setting Slew Propagation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Figure 5.15 —Fast Slew Propagation Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Figure 5.16 —Worst Slew Propagation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Figure 5.17 —Critical Slew Propagation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19

Technology and Design Rule Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-Operating Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Estimating Capacitance and Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Figure 5.18 —set_wire_load command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Figure 5.18 —set_wire_load_mode command. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Port Capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-Capacitance Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Fanout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22Fanout Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22External Sources and Sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-Wire Capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-Wire Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

6Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-

Cadence Design Systems Inc. iii Cadence Confidential


4

0

111

1

-2

1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1Optimization Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2

Hierarchical Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2Context Based Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2Incremental Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2Post-placement Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3

Module Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3Building Technology Independent Netlist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3Dealing with Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4

Preserving Module Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-Treating Instances Uniquely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-5Collapsing Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6

Optimizing Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7Deriving Constraints from Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8Time Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9Applying Timing Corrections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1Physical Tool Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11

Reading SDF Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-Reading Library Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

7Report Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-Report Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1Reporting Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2Current Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2Hierarchical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2

Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3Timing Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3

•The Path Delay Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4Customizing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4

Column Width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4

AVerilog Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1Fully Supported Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-1Partially Supported Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .AIgnored Constructs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-3Unsupported Constructs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-3Verilog Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-4

BThe Verilog Pre-Processor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-Compiler Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-1

‘for . . . . . . . . . . . . . . . . . . . . . . . . . . B-1‘if . . . . . . . . . . . . . . . . . . . . . . . . . . B-2‘eval . . . . . . . . . . . . . . . . . . . . . . . . . B-2‘{} . . . . . . . . . . . . . . . . . . . . . . . . . . B-3

Command Line Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-3VPP Flag Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-3

Cadence Confidential iv Cadence Design Systems Inc.


-4

-5566677

1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3

CWire Load Model Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1

DVHDL Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1VHDL Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1Notes on Supported Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D

Table D-1 —Design Entities and Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . D-4•Subprograms and Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D•Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-•Declarations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-•Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-•Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-•Sequential Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-•Concurrent Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-

Predefined VHDL Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-7VHDL Predefined Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-9

Table D-5 —Notes on Pre-defined Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-9

EMixed VHDL/Verilog Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-1Reading in RTL Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-Mixed VHDL/Verilog Instantiations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-1Generic Build for a Specified Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-2

Cadence Design Systems Inc. v Cadence Confidential


Cadence Confidential vi Cadence Design Systems Inc.


o

1Introduction

The BuildGates® tool is used to perform logic synthesis operations. It can be run in twmodes of operation; command line mode usingac_shell, the command line interface, andvisual mode using the visual interface, NaviGates.

This document describes the use of BuildGates through theac_shell® command lineinterface. For information on running BuildGates in visual mode, see the"NaviGates UserGuide".

AMBIT Tools and Methodology FlowThe following diagram shows an overview of BuildGates usingac_shell as the commandline interactive interface.

Figure 1.1 — BuildGates Program Overview

DatabaseNetlist

CommandHandler

Opt

imiz

er

Tim

ing

Analyzer

Output Generator

ReportsOptimizedNetlists

HDLDescriptions

Constraints

TechnologyLibraries

Cadence Design Systems Inc. 1 - 1 Cadence Confidential


logy

the

ac_shell is an interactive program that does the following:

• It reads in Register-Transfer Level (RTL) models written in Verilog HDL

• It reads in a target technology library description and accepts timing and technoconstraints suitable for the design.

• It generates the netlist for the design as interconnected components (cells) in target library

• It provides various reports to help analyze the synthesized design.

FeaturesBuildGates differs significantly from other logic synthesis programs in the followingareas:

• Advanced technology cell mapping techniques

• Fast, accurate, and incremental timing analysis

• User accessible, open netlist architecture

• Full TCL programmability

Organization of This Document

TheBuildGates User Guide is organized as follows:

1 Introduction This chapter provides the overview of BuildGates and the

contents of the User Guide. It also shows the conventions

used throughout this document.

2 Tutorial This chapter walks you through various steps in the logic

synthesis process using a simple counter design (in Ver-

ilog) as an example. It introduces the functionality of sev-

eral BuildGates commands and presents an analysis of the

reported data.

3 Verilog Modeling Style This chapter describes the Verilog modeling style in

BuildGates. It explains issues with modeling styles and

the implication of different styles on the logic synthesis

results.

4 VHDL Modeling Style This chapter describes the VHDL modeling style in Build-

Gates. It describes the impact of different modeling styles

on logic synthesis and netlist generation.

5 Setting Constraints This chapter explains how various timing and electrical

constraints are specified and are used to control the out-

come of the optimization and mapping steps in logic syn-

thesis.

6 Optimization This chapter explains the module level and the hierarchi-

cal process for optimization including incremental compi-

lation and in-place optimization.

7 Report Generation This chapter explains the reports that may be generated

after synthesis, and also explains the usefulness of it’s

contents as feedback to improve the input description and

constraints.

A Appendix A This Appendix discusses all the constructs of Verilog HDL

with respect to their support for synthesis.

B Appendix B This Appendix discusses the Verilog pre-processor and

the associated compiler directives.

C Appendix C This Appendix shows the algorithm used for selecting a

Wire Load model for a net.

Cadence Confidential 1 - 2 Cadence Design Systems Inc.


Conventions Used in this DocumentThe following conventions are used in this document:

Related DocumentsThe following documents are useful references:

• The “BuildGates Command Reference”

• The “NaviGates Reference Guide”

• The “BuildGates Application Notes”

• IEEE 1364 Verilog HDL LRM

• TCL Reference, “Tcl and the Tk Toolkit”, John K. Ousterhout, Addison-WesleyPublishing Company

• Logic Synthesis Books

• Verilog HDL Books

• VHDL Books

D Appendix D This appendix lists the VHDL constructs supported by

BuildGates/VHDL and shows the category to which each

of them belong.

E Appendix E This appendix describes how BuildGates synthesizes

VHDL/Verilog modules in the same session.

Convention Description

Times-roman main text, explanations

Courier output from command execution, source code listing, command

syntax

Courier-bold input text (usually commands)

Italic variable names, i.e., report_area filenamewhere report_area is a command and filename is an argu-

ment.





e

L),

r the

we e

put.

x

2Tutorial

This chapter walks you through the fundamental features in BuildGates. It is a simplintroduction to the tool. It enables you to become familiar with theac_shell environmentand the Tcl command language.

We assume that you are familiar with the Verilog Hardware Description Language (HDand are able to write a Verilog HDL description from a given specification.

Logic synthesis consists of the following steps (using BuildGates):

• Preparing a Verilog HDL model of the design

• Startingac_shell

• Reading the model intoac_shell

• Reading technology library intoac_shell

• Setting up constraints

• Running the optimizer

• Generating reports and analyze the design

• Writing netlist and database files

• Changing the model and its constraints, if necessary, and repeating the steps fonewly defined model and constructs.

Each of these steps are described in detail in this chapter. As you follow the tutorial,recommend that you runac_shell and execute the commands.

The Simple Design FileThe sample design is an 8-bit synchronous up-down counter with an even parity outThe verilog model can be found in the following location:

/ambit/release/BuildGates/<version>/tutorial/counter.v/ambit/release/BuildGates/<version>/tutorial/counter.tcl

where/ambit/release is the appropriate environment path to your installation, andversion is the version of the release that you installed.

You should simulate the counter model shown here to ensure that there are no syntaerrors and that the model simulates correctly.



d:

ser- of

tion

aacter

The Verilog HDL model description of the counter is shown below.

/* 8-bit synchronous counter with parity */module Amcount(clk, din, cntrl, out_en, dout, parity);input [7:0] din;input [1:0] cntrl;input clk, out_en;

output [8:0] dout;output parity;

reg [8:0] dreg;

always @(posedge clk) begincase (cntrl)

2’b00 : dreg = 9’h0; // clear2’b01 : dreg = {din[7],din}; // load2’b10 : dreg = dreg + 2’b11; // upcnt 32’b11 : dreg = dreg - 3’b101 ; // Dncnt 5

endcaseend

assign dout = (out_en) ? dreg : 9’hz ;assign parity = (out_en) ? ^dreg : 9’hz ;

endmodule

Invoking ac_shellTo invoke BuildGates using theac_shellcommand line, enter the following command atthe UNIX prompt:

% ac_shell

To invoke NaviGates, the visual interface to BuildGates, enter the following comman

ac_shell -visual

For more information on NaviGates, please see the"NaviGates User Guide".

Theac_shell command line interface is a text-based interactive program that allows ucontrol of the logic synthesis process. The underlying interactive command languageac_shell is Tcl .

The interactive command prompt, by default, isac_shell[1]> where the integer specified,[1], is the current command number.

Note that the default command prompt can be changed and reset. For more informasee the set global command in the"BuildGates Command Reference Manual".

Command Description

All interactive commands entered at the keyboard or read in from a command file aresequence of words separated by a space, tab, or punctuation marks. A newline char(Carriage Return) completes the command and thenac_shell executes it. A semi-colon isalso used to terminate a command.

The conventions followed here are those used within the Tcl interface.



and

utedame

ent

ore

If

Command File

Interactive commands entered intoac_shell are saved in a command file calledac_shell.cmd . A command file, created from a previous run ofac_shellor edited manually,can be used as input toac_shellusing thesource command. This allows you to re-createthe previous execution ofac_shell.

ac_shell[2]> source last.cmd…# output from commands in last.cmd

If there are a number of repetitive commands, you can put those commands in a fileexecute them by sourcing the command file.

If ac_shellis invoked with a file name as an argument, the contents of the file are execas a series of commands. This is similar to using the source command with the file nas its argument.

All the executed commands can be recorded in theac_shell.cmd file using the-cmdfile

option when invokingac_shell. You can also specify a different file for output, forexample, the command

% ac_shell -cmdfile newrun.cmd

records all the interactive commands and saves them to the filenewrun.cmd .

Setting up the Technology libraries

A technology library is required for successful mapping of RTL operations ontotechnology specific cells. The search order can be specified by setting the environmvariableAMBIT_SLIB_PATH as follows:

% setenv AMBIT_SLIB_PATH .:~/techlib:/lsi/techlib

The read_alf command is used to read the technology library. This is discussed in mdetail later in the chapter.

Using Command Short-names

Typing a shortened version of a command name at the prompt causes theac_shell toattempt to match the typed string to all commands containing the same string prefix.there is a unique (one-to-one mapping) matching,ac_shell executes the command. Forexample, if you enter:

read_ver counter.v

ac_shellexpands theread_ver command to theread_verilog command and executes thenewly expanded command to read thecounter.v file.

If more than one command matches the string,ac_shelldisplays all the known commandsmatching the prefix. For example, entering the commandset_ on the ac_shell commandline displays all commands with that prefix, for example,

set_attributeset_cell_propertyset_clock...set_wire_capacitanceset_wire_loadset_wire_load_modeset_wire_resistance



salltheg the

tke up

.

s for

cal

,ess.

Shell Commands

Tcl is the command language used inac_shell. A command typed at the prompt that doenot match anyac_shell command is sent to the UNIX shell for execution. You can use the standard UNIX system commands in the Tcl interface. You can get a list of files incurrent directory using the ls command, or you can get the current date and time usindate command.

ac_shell[5]> lsac_shell.cmd counter.vac_shell[6]> dateTue Apr 15 14:59:32 PDT 1997

Getting Started — Logic SynthesisNow that you are familiar with theac_shellbasic features, you will now get more involvedwith the steps of logic synthesis. The design source files are read intoac_shell and thenthe loaded design is compiled into a technology independent netlist.

The read_verilog Command

Theread_verilog command initiates theac_shellto read the filecounter.v and reportsany syntax errors or any other problems with the parsing of the model.

read_verilog counter.v

The read_verilog command reads Verilog files and builds a parse tree for subsequencommands and analysis. To read more than one file, you can list all the files that mathe design. It can take one or more files as parameters.

UsingTcl ’s glob command, you can also list files using a regular expression:

read_verilog [glob *.v]

Note that the square brackets are required.

TheTcl interpreter evaluates the command and expands*.v before executing theread_verilog command. It looks for all files having a.v extension and reads these files

Build a Generic Netlist

After the HDL source files have been read, you must allocate generic logic resourcethe design. This is done by entering the following command:

do_build_generic

Thedo_build_generic command generates Control Data Flow Graphs (CDFGs),performs high level optimizations and resource allocation, and generates a hierarchinetlist for all the modules defined in the source files.

The netlist created by thedo_build_generic command uses technology independentlogic gates(AMBIT Technology Library cells or ATL cells). Operators such as addersshifters, and so on are instantiated as blackboxes at this stage of the synthesis proc

The following messages are output from thedo_build_generic command:



bere are

and

ing the

Each sequential device that is inferred by thedo_build_generic command is reported ina table using the following columns:

If a multiplexor (mux) is inferred, an additional table is displayed that shows the numof inputs to the mux, the width of each input, and the number of bits necessary for thselect lines to the mux. The module name and the line number from the source codealso reported.

Finding ObjectsThefind command is used to search for objects in your design using pattern matchingobject type selection. For example,

find -ports *out*

returns a list of all the ports that contain the stringout . In our model, theout_en anddout

ports are selected.

The find command first searches for all the objects in the current module (see “Settthe Top Level Module” on page 2-7) and then selects the port objects. It then selectsports containing the search string as a partial or complete string.

Field Value Description

Line 16 Line number in module description

Name dreg_reg Name used for this register in the netlist

Type D_FF The generic cell chosen to implement this register

Width 9 This is the width of the register

Bus Y This register will be treated as a vector (bus)

Clk Y This register is synchronous

AS N This register does not have an asynch set control

AR N This register does not have an asynch reset control

SS N This register does not have a synch set control

SR N This register does not have a synch reset control



ore arees

on

k onlete

The general syntax for thefind command is:

find ?-glob | -regex? ?-exact? ?-hierarchical? ?-instances??-nets? ?-pins? ?-ports? ?-modules? ?-cellrefs? ?-techlib??-inputs? ?-outputs? ?-registers? ?-dont_modify? ?-clocks??-no_clocks? ?-blackboxes? ?-of_cell_type <cell_name>? ?-top? ?-bus? <context>

The find command takes object types, filters, and names as arguments. It can take mthan one of these at a time. Only those filters associated with a particular object typeapplied to the objects. If no filters are given, all object names matching the list of namare returned.

By default, glob style pattern matching is performed using the special characters andsymbols shown in the table below.

If the -regexp option is used, the following symbols may be used for regular expressistyle pattern matching of partial names:

The find command returns a list of names that can be used with any command thataccepts a list as input, e.g.set_data_arrival_time

Some more examples of using thefind command are shown below:

# find all input portsfind -ports -input *# find all inout portsfind -ports -input -output *# find all technology libs that have LCA prefixfind -techlibs -regexp ^LCA# find R3 register in instancesfind -instances -registers -regexp ^R3$# find top level modulefind -module -top -regexp

For more information about regular expressions and pattern matching, refer to a booTcl such as the book recommended in the introduction to this User Guide. For a compdescription of the syntax and a set of examples, see the appropriate section of theCommand Reference manual.

Symbol Match

* matches 0 or more occurrence of any character

? matches any single character

Symbol Match

. any character

* zero or more occurrence of preceding character

or regular expression

+ one or more occurrence of preceding character or

regular expression

^ matches at the start of a string

$ matches at the end of a string

\x matches character x

[chars] matches any character from the set

regexp1 | regexp2 matches anything that matches regexp1 or

regexp2



e

t

is

dule

, all

ockips.

ule

ps

Setting ConstraintsYou must establish some constraints for the counter model.ac_shellalways optimizes forthe minimum area, therefore we do not need to put any constraints on the area of thdesign. For the counter design, we will apply the constraints outlined below.

Setting the Top Level Module

Before setting any constraint, you must identify the module for which you want to seconstraints. Do this using theset_top_timing_module command.

set_top_timing_module Amcount

TheAmcount module is now the focus of all the constraints that follow. This module referred to as thetop module.

If the design had more than one module, each module must be set to be the top mobefore applying constraints with its ports.

Defining all Clocks Used in the Design

For all sequential logic, the constraints are specified with respect to a clock. Thereforeclocks used in the design must be defined.

You must define the period and duty cycle for an ideal clock. You can derive other clsignals from the ideal clock by specifying skew and inversion (among other) relationsh

set_clock clock -period 10.0 -waveform {0.0 5.0}

In this example theset_clock command defines an ideal clock,clock , having thefollowing attributes:

• a period of10.0ns

• a rising edge at0.0ns

• a falling edge at5.0ns

• generating a50% duty cycle clock

The definition of an ideal clock allows the logic synthesis process to determine theintended relationship between various clocks (and clock ports).

Note that theset_clock command does not refer to any port of the design. The actualarrival times (rising edge and falling edge) for a clock signal on the clock port of a modmay be different from the ideal clock.

You must specify how the clock port of the counter (clk) behaves in relation to the idealclock (clock ) defined above.

set_clock_arrival_time -rise 0.1 -fall 5.1 -clock clock clk

Theset_clock_arrival_time command associates theclk signal with the ideal clocksignal,clock , by establishing a rising edge at0.1ns and a falling edge at5.1ns .

Setting Data Arrival Time

To set the data arrival time you can set the arrival times for the input ports of the topmodule.

set_data_arrival_time 0.0 -clock clock [find -port -input *]

Theset_data_arrival_time command specifies that the changes to all input signalsarrive at0.0ns with respect to the ideal clock (-clock clock option). This helps toestablish the setup time between the clock and the data ports of register cells (flip-floand latches).



the.

stlockts

ellies.

ec

aveis

the

e the

es

The last argument[find -port -input *] is a Tcl expanded list. Thefind commandreturns a list of all ports that are input ports in the top module (Amcount ). The commandset_data_arrival_time is executed for each port in the list byac_shell.

For a combinational input port, the data arrival time is independent of the clock. Hence-clock clock option is absent when data arrival is set for a combinational input port

Setting Data Required Time

You must set the required times for the output ports.

set_data_required_time 8.4 -clock clock [find -port -output*]

The set_data_required_time command specifies the latest time at which the data muchange (arrive) at a given port. It determines the hold time constraints between the cand the data ports on register cells. The constraints are applied only on the data porassociated with the specified clock signal (-clock clock option).

OptimizationThe logic synthesis process so far has been technology independent. However the cmapping and logic optimization process can differ significantly between two technologTherefore, we must carry out two steps to generate the netlist:

• Read the technology library needed as the target technology

• Perform optimizations

Reading The Technology File

All technology library files are provided in pre-compiled form, and has.alf suffix. Theselibraries are generated by theAmbit Technology Compiler, and contain compacted,optimized and pre-computed data that can be loaded intoac_shell very quickly.

You can read in multiple libraries but you can only select one technology library as thtarget library for mapping. Note that if your source files instantiate technology specificells from different libraries, you must first load these libraries.

The library file name can be a fully qualified file name or a relative file name. If you hset theAMBIT_SLIB_PATH variable, this path is searched to find the given file. If the file found, a message is printed stating the source location of the library.

In this tutorial we use LSI Logic’s 300K library for targeting our design. We can read technology library file using theread_alf command (read AMBIT library file).

read_alf lca300k.alfLoaded library /ambit/libs/lsi lca300k.alf

After reading the technology library file, we must identify this technology library as thtarget library. To see the technology libraries that have been loaded at this point, useget_names command.

get_names [find -techlibs *] atl ambit_xatl lca300kv

Theatl and theambit_xatl technology libraries refer to AMBIT Technology Libraryand AMBIT eXtended Technology Library, respectively. These are the generic librarithat are automatically loaded whenac_shell is invoked. When thedo_build_generic

command generates a high level netlist, the cells fromatl andambit_xatl are used as thegeneric cells.



ol

nilable

the

have

ify

ts,

The lca300kv refers to the name of the technology library in the filelca300k.alf . Letus setlca300kv as our target technology library usingtarget_technology globalattribute.

set_global target_technology lca300kv

The commandset_global is used to set the value of various global attributes that contrthe behavior of howac_shell executes certain steps.

Optimize command

Now we are ready with the actual optimization and technology mapping steps.

do_optimize

Thedo_optimize command performs logic optimization of the generic netlist based othe constraints specified for each module and maps the resulting logic to the cells avain the technology library so that the constraints are not violated.

The output from thedo_optimize command for the counter design appears as follows:

Info:Dissolved instance ‘Amcount_ext_0’ (cellref‘Amcount_ext_0’) in module ‘Amcount’ <FNP-701>.Timing correction for late slack …<TOPT-500>.

Current slack 2.6607cell area = 257.000000, slack = 2.660693

The optimization takes place in two steps. Firstly, the generic netlist is mapped to thetechnology library cells and the cell area and timing slacks are reported. Secondly, ifconstraints are not met successfully (i.e. timing slack is negative), the netlist isrestructured to meet the constraints.

The results of the optimization can vary considerably based on the types and thecharacteristics of the cells in the technology library as well as the constraints that youset. The results will also depend on the options used for thedo_optimize command. Inthis simple example the default optimization steps were executed as we did not specany options on the command line.For more information about options for thedo_optimize

command, see the Optimization chapter.

Additional timing-driven optimizations can be performed using thedo_xform_timing_correction command among otherdo_xform_ commands. For moreinformation, please see “Applying Timing Corrections” on page 2-10.

Generating NetlistBuildGates maintains all the data for logic synthesis in memory (i.e. netlist, constraintechnology library). The information in memory can be written out in Verilog netlistformat or AMBIT database format (ADB).



nces

utt.

re

thereport. The

Writing A Verilog Netlist

The Verilog netlist can be written out using thewrite_verilog command.

write_verilog -hier counter.v.net

The netlist is written in thecounter.v.net file. The option-hier indicates that the netlistshould be written out as a hierarchical netlist. If-hier is not specified, thewrite_verilog

command writes out a flat netlist. The netlist listing is in thecounter.v.net file in thetutorial directory.

You can write a Verilog netlist after running thedo_build_generic command or thedo_optimize command. Using thedo_build_generic command the netlist is written outusing instances of ATL and XATL cells. Using thedo_optimize command, the logic ismapped to the target technology library. In that case, the Verilog netlist contains instaof the cells in the target library.

The Verilog netlist can be used for gate level verification. If you use ATL cells to write oa generic netlist, you must provide AMBIT Verilog Library (AVL) to simulate the netlisIf you write out the optimized netlist, you must provide Verilog library of the targettechnology to simulate the netlist.

Writing the database

The synthesis data stored by BuildGates in a database can be written out using thewrite_adb command.

write_adb counter.adb

The database for our counter design is written out to thecounter.adb file. Once thedatabase is written out in ADB format, it can be loaded quickly into BuildGates for futuruns ofac_shell, to perform further synthesis or analysis of the netlist.

This is a binary data file and you should not decompile it for any purpose.

ReportsThe database contains a variety of information about the design, the constraints, andstate of synthesis. Several commands are available to analyze the netlist and also tothe quality of the results of synthesis. A subset of the commands are described hereremainder are discussed in the Report Generation chapter.

Looking at hierarchy

You can look at the hierarchy of the design using the report_hierarchy command.Executing this command prior to optimization outputs the following:

report_hierarchy

|-Amcount(g)| |-ACL_SUB_1_9_4(o)| |-ACL_ADD_1_9_4(o)

This levelized diagram shows that Amcount is the top module and that the children(ACL_SUB_1_9_4 ACL_ADD_1_9_4) are at lower levels (viewing from right to left).



ters

This

usedl

The letter in parenthesis, following the name, shows the state of the module. The letare explained below:

Execute thereport_hierarchy command after thedo_optimize command has generatedthe netlist.

report_hierarchy

|-Amcount(m)| |-ACL_SUB_1_9_4(m)| |-ACL_ADD_1_9_4(m)(X) #assuming we attached don’t touchproperty

TheAmcount module is now mapped to thelca300kv technology library. This isshown by the letterm in parenthesis.

Area report

Thereport_area command produces a report on area, as shown below:

Figure 2.1 — Area Report Summary

The report identifies the name of the module for which this area report is generated.is the same module that we had set as the top level module usingset_top_timing_module

command. The summary report includes the hierarchical blocks, the wire load modelduring optimization, cell area, estimated net area, and total area for each hierarchicamodule.

To get a detailed area report use the-cells option. For example,

report_area -cells

b module is a blackbox (no subcomponents)

g module contains generic cells

m module contains technology specific cells

o module contains an optimized netlist mapped to tech-

nology specific cells

x module has “don’t touch” property set



the

ein the

n the

Figure 2.2 — Area report with cell usage information

This area report includes a summary of the combinational and sequential instances,area used by these instances, the estimated net area, and the total area.

The tabular output names the selected (mapped) cells from the technology library, thnumber of instances of that cell used in this module, the area of that cell as defined technology library, and the total area used by all instances of that cell.

Thereport_area command takes a file name as an argument and the report is saved ifile specified. For example, the following command saves the area report to a file,amcount.area .

report_area amcount.area



lock

ect tot is

n

romtion

l

in,t

Timing reports

The timing report can be generated using thereport_timing command.

Figure 2.3 — Timing report

The Timing Report Contents

The first part of the timing report refers to late mode analysis. This is the timing analysisbased on the latest possible arrival of a change on the data port with respect to the cport to meet the setup time constraints of the register cells.

The second part of the timing report refers to early mode analysis. This is the timinganalysis based on the earliest possible arrival of a change on the data port with respthe clock port to meet the hold time constraints of the register cells. The report formathe same as the late mode analysis

Pin — The hierarchical path name of a pin. All timing information is reported betweetwo pins. The delays can be from an input pin of an instance to an output pin of thatinstance, or it can be from the source pin of a net to its sink pin.

Cell — The name of the cell to which the instance is bound. Column 3: is the delay fthe previous pin (in the previous row) to the current pin This is due either to propagadelay through the instance or the net delay.

Delay —The arrival time at that pin. This is the cumulative delay plus any input arrivatime.

Arr — The required time at that pin. The required time is calculated from the output pwhich is either asserted directly by the user, or derived from the clock constraints if iinvolves a register input pin. The difference between required time and arrival time iscalled slack time.

Req — The clock phase with respect to which all the delays are calculated.

Phase — Indicates whether the timing arc is for a rise or a fall transition.



enin in

ands

nding

Edge — The report prints the worst path in the design. If the slack time is negative thsome of the timing constraints are not satisfied. The slack time is the same on every pa critical path.

Several other kinds of analysis can be done and reports can be generated. More commfor report generation and analysis are presented in the Report Generation chapter.

Exiting from BuildGatesYou can use theexit command or thequit command to end the interactive session.

The command file is written out and closed prior to exiting. You can look at the commafile, ac_shell.cmd, to see all the steps carried out and to examine the correspondoutput from running in theac_shellenvironment. The fileac_shell.log contains a logof the tutorial session.



sistheelsea),

,

red

3Verilog Modeling Style

This chapter describes the impact that different modeling styles have on logic syntheand netlist generation. Two functional models may simulate identically and describe same behavior (functionality) of a design. However, the implementation of the two modthrough the logic synthesis process differs significantly in terms of their gate count (arcritical paths, and physical characteristics.

In addition to specific modeling styles and their impact on the netlist, a set of specialcomments, known assynthesis directives, are also described at the end of the chapter.

Register InferencingAmbit infers registers from the syntax of the HDL as mentioned below in the sectionsLatch Inference andFlip-Flop Inference.

Latch InferenceConsider the following example of inferring a latch where a reg type variabledata_outis used.

reg data_out ;always @(data_in or enable)if (enable)

data_out = data_in ;Here,data_out is modified if signalenable is high. However, the model does notspecify what happens whenenable is low (or unknown). The default behavior impliedby Verilog HDL is that the variabledata_out will retain its previous value. Thisrequires thatac_shellinfer a storage element to implement the variabledata_out . Sincethere is no clock edge (either a rising or a falling edge) involved here, a latch is inferwhen data input isdata_in , enable input (sometimes called gate) isenable , andoutput isdata_out .



n as

esis

When thedo_build_generic command is run fromac_shell, you will get a report ofa latch inference as follows:

read_verilog latch.vdo_build_generic

Asynchronous set-reset on a latch

A latch with asynchronous set and reset operation is inferred when the model is writtefollows:

reg data_out ;always @(data_in or enable or set_sig or reset_sig)if (set_sig)

data_out = 1’b1 ;else if (reset_sig)

data_out = 1’b0 ;else if (enable)

data_out = data_in; // line 16:latchsr.vThealways block is triggered whendata_in , enable , set_sig or reset_sigchange, but the assignment todata_out is first controlled byset_sig andreset_sig signals.

Note: data_out is assigned todata_in only whenset_sig andreset_sig areinactive andenable is active.

The report from thedo_build_generic command is shown below.

ac_shell[1]> read_verilog latchsr.vac_shell[1]> do_build_generic

To control the set and reset connections in the generic netlist, see “Set_Reset SynthDirectives” on page 3-11.



s

itten

ust

Flip-Flop InferenceWhen analways block is triggered by a rising edge or a falling edge transition on asignal (typically, a clock signal), a flip-flop is inferred to implement the variable on theleft-hand side of a procedural assignment.

reg data_out ;always @(posedge clock)data_out = data_in;

For this example, a rising edge triggered D-type flip-flop is inferred when data input iconnected todata_in , clock input is connected toclock , and output is connected todata_out .


ac_shell[1]> read_verilog ff.vac_shell[1]> do_build_generic

Synchronous set-reset on a flip-flop

A flip-flop with synchronous set and reset operation is inferred when the model is wras follows:

reg data_out ;always @(posedge clock)if (set_sig)


data_out = 1’b0 ;else

data_out = data_in; // line 13:ffsr_sync.vIn this example, thealways block is triggered only on the rising edge of theclock , butthe assignment todata_out is controlled byset_sig andreset_sig signals.

Note: data_out is assigned todata_in only whenset_sig andreset_sig areinactive. If either a set or a reset is not required, the corresponding condition mnot be specified in theif statement.



esis

tten

is


ac_shell[1]> read_verilog ffsr_sync.vac_shell[1]> do_build_generic

To control the set and reset connections in the generic netlist, see “Set_Reset SynthDirectives” on page 3-11.

Asynchronous set-reset on a flip-flop

A flip-flop with asynchronous set and reset operation is inferred when the model is wrias follows:

reg data_out ;always @(posedge clock or posedge set_sig or posedgereset_sig)if (set_sig)


data_out = 1’b0 ;else

data_out = data_in; // line 13:ffsr_async.vThealways block is triggered when a rising edge is detected onclock , set_sig , orreset_sig .

Note: data_in is assigned todata_out only whenset_sig andreset_sig areinactive and there is a rising edge onclock .


ac_shell[1]> read_verilog ffsr_async.vac_shell[1]> do_build_generic

Asynchronous set and reset operations for flip-flops are always controlled throughasynchronous set and reset pins on the flip-flop components. The set_reset synthesdirectives have no effect on the set and reset operations.



uraln

the

ic:

nriable,

deled

Combinational Logic InferencingVerilog HDL semantics require that all variables used on the left-hand side of a procedassignment must be declared asreg (a storage data type as opposed to wire declaratiowhich is a connection data type). However, not all variables declared asreg data typeneed a flip-flop or a latch for logic implementation.

Specifically, if it can be inferred from the model that the left-hand side variable isunconditionally assigned a new value when any of the input variables changes, thenleft-hand side variable is treated as an output of combinational logic derived from thedescription of the block. Consider the following example of inferring combinational log

data_out;always @(a or b or c)if (b)

data_out = a ;else

data_out = c ;For this example, there is no need to use a storage element (a flip-flop or a latch) toimplement the corresponding logic; a multiplexer withb as the selector anda andc astwo data inputs can drive the outputdata_out .

In addition toreg data type, procedural assignment to a variable declared as aninteger data type is also supported.

Case StatementA case statement represents multi-way branching in a functional description. Whea case statement is used as a decoder to assign one of several different values to a vathe logic can be implemented as combinational logic or sequential logic.

There are two specific usage of thecase statements explained below as it relates toregister inference.

Incomplete Case StatementWhen acase statement specifies only some of the values that thecase expressioncan possibly have, a latch is inferred. For example, a state transition table may be moas shown below.

reg [2:0] curr_state, next_state, modifier;case (curr_state)

3’b000 : next_state = 3’b100 & modifier ;3’b001 : next_state = 3’b110 | modifier ;3’b010 : next_state = 3’b001 & modifier ;3’b100 : next_state = 3’b101 | modifier ;3’b101 : next_state = 3’b010 & modifier ;3’b110 : next_state = 3’b000 | modifier ;

endcaseThenext_state variable is assigned a new value ifcurr_state is any one of the sixvalues specified. For the other two possible states, thenext_state variable will retainits previous value. This behavior causesac_shell to infer a 3-bit latch fornext_state .

If you do not wantac_shellto infer a latch, thenext_state variable must be assigned avalue under all situations. In other words, thenext_state variable should have adefault value.



There are two possible ways we can assign a default value tonext_state .

next_state = 3’b000 ; // unconditional assignmentcase (curr_state)…endcase

Here, thenext_state variable is assigned a value unconditionally and then it ismodified appropriately by thecase statement. An alternative approach is to use thedefault case in the case statement to capture all the remaining cases where thenext_state variable is assigned a value.

case (curr_state)…

default : next_state = 3’b000 ; // all other casesendcase

Both solutions above will preventac_shell from inferring a latch.

A third solution is to use thefull case synthesis directive as discussed inthe section “Full Case Directive” on page 3-10. As noted there, the simulation resultsbetween functional and gate level models may mismatch due to use of this synthesisdirective.

Use of Casex and Casez StatementsThecasex andcasez statements allow thex andz values to be treated likedon’t careconditions when comparing for the matching case. These two statements are treatedsimilar to thecase statement with the following differences:

- casez statement allows0, 1 andz to be treated as don’t care condition

- casex statement allows0, 1, z andx to be treated as don’t care condition

Consider the following example where acasez statement is used with don’t careconditions to mask three of the four bits in decoding select line (inputsel ). The maskedbits can be0, 1, orz . The remaining bit is required to be1.

module casez_example(sel, out);input [3:0] sel;output [1:0] out;reg [1:0] out;always @( sel ) begin

casez ( sel )4’b???1 : out = 2’b00;4’b??1? : out = 2’b01;4’b?1?? : out = 2’b10;4’b1??? : out = 2’b11;

endcaseendendmodule



at the

If we perform technology independent mapping, we get the following information:

read_verilog casez.vdo_build_generic

The warning message indicates that the implementation of thecasez statement in anetlist form may have different results than the RTL model (e.g. whensel has one ormore bits unknown).

In the following example acasex statement is used with don’t care conditions in thesame way as the example above. The main difference between the two examples is thexample below masks three bits of select line that would match0, 1, z or x but theexample above will not maskx in select line.

module casex_example( sel, out);input [3:0] sel;output [1:0] out;reg [1:0] out;always @( sel ) begin

casex ( sel )4’bxxx1 : out = 2’b00;4’bxx1x : out = 2’b01;4’bx1xx : out = 2’b10;4’b1xxx : out = 2’b11;default : out = 2’bxx;

endcaseendendmodule

The messages from thedo_build_generic command are shown below:

read_verilog casex.vdo_build_generic



of a

.ns:

luate

with

For LoopThe for statement is used for describing repetitive operations. For example, all the bitsvector (in ) can be stored in a reversed order using afor statement.

for (i = 0 ; i ≤ 7 ; i = i+1)out[7-i] = in[i] ;

wherei is declared asinteger , out is an 8 bitreg andin is an 8 bitwire or reg .

Thefor statement is expanded to repeat the operations over the range of the indexTherefore, the example above would be treated equivalent to the following 8 operatio

out[7] = in[0] ;out[6] = in[1] ;out[5] = in[2] ;out[4] = in[3] ;out[3] = in[4] ;out[2] = in[5] ;out[1] = in[6] ;out[0] = in[7] ;

The following four forms of thefor statement are supported.

for (index = low ; index < high ; index = index+step)for (index = low ; index ≤ high ; index = index+step)for (index = high ; index > low ; index = index-step)for (index = high ; index low ; index = index-step)

whereindex is declared asinteger or reg ; high , low andstep are integers, andhigh must be greater than or equal tolow . High , low andstep must evaluate toconstant numbers at compile time. A warning is generated if one of them does not evato a constant number.

Note that afor statement can be nested inside anotherfor statement.

Thefor statement can not contain any form oftiming controlor event control.Therefore,the following usage of the for statement is illegal:

for (i=0; i ≤ 7; i = i + 1)@(posedge clock) out[7-i] = in[i] ;

Synthesis DirectivesSynthesis directives are comments. These comments should not to be confused withVerilog HDL compiler directivesthat begin with‘. Two forms of synthesis directives aresupported in BuildGates; long comments and short comments. Each comment beginsthe wordsambit synthesis . The syntax for the directives are shown below:

• short comments, terminating at the end of the line

/ / ambit synthesis <comment>

• long comments, extending beyond one line

/* ambit synthesis <comment> */

The value for <comment> can be selected from the table below.

Note: Comments used to specify synthesis directives should not contain any extracharacters other than those necessary for the synthesis directive.



.:

es

t

The available synthesis directives and the syntax for the directive is outlined in thefollowing table. Each synthesis directive is described in detail in the following section

Code Selection DirectivesBy default, theac_shell compiles all the Verilog code from a file. The code selectionsynthesis directives are typically used in pairs around Verilog HDL code thatshould notbecompiled byac_shell for logic synthesis. All the code following the synthesis directive

// ambit synthesis off

up to and including the synthesis directive

// ambit synthesis on

is ignored byac_shell.

For example, there may be certain initialization code in your model for debug purposthat is not meant to be synthesized. If theinitial block is surrounded by thesesynthesis directives,ac_shell will skip over the entire block.

// ambit synthesis offinitial begincond_flag = 0 ;$display(“cond_flag cleared at the beginning.”) ;end

// ambit synthesis onalways @(posedge clock)if (cond_flag)…

Case Statement DirectivesA case statement can be interpreted in many ways. The default interpretation is thathere is a priority decoding of thecase labels in the order listed in the model. In otherwords, thecase statement is interpreted as a nestedif-else statement.

Synthesis Directive Directive Syntax

Code Selection // ambit synthesis on// ambit synthesis off

Case Statement // ambit synthesis case = full | parallel | mux

set_reset

Block //ambit synthesis set_reset asynchronous blocks =namelist//ambit synthesis set_reset synchronous blocks = namelist

Signal //ambit synthesis set_reset asynchronous signals= siglist//ambit synthesis set_reset synchronous signals= siglist

Block signal //ambit synthesis set_reset asynchronous block(name)=siglist//ambit synthesis set_reset synchronous block(name)=siglist

Architecture selection // ambit synthesis architecture = cla | ripple

Finite State Machine //ambit synthesis enum <enumeration_name>//ambit synthesis state_vector sig state_vector_flag



lt

istedly

ctives.

labels

no

ified

).

te

de

lines

The case statement synthesis directive provides the mechanism to modify the defauinterpretation to capture the design intent. The directive is used as follows:

// ambit synthesis case = valuewhere value = full, parallel, or mux

This synthesis directive can take on one, two, or three comma separated values as labove. The order of the values is unimportant. This directive must appear immediateafter thecase expression .

If the case statement has sufficient information, thenac_shellwill infer full case, parallelcase or mux case directive automatically, even in the absence of these synthesis dire

Full Case Directive

If the synthesis directive value includesfull , thecase statement is interpreted tomean that the case expression can evaluate to only those values specified by the casein the case statement. In turn, this implies that all other possible values of the caseexpression can be treated as don’t care conditions. This further implies that there is need for a default clause in the case statement and no latch should be inferred. thefollowing is an example of using the full case synthesis directive:

case (arith_opcode) // ambit synthesis case = full4’b0000 : result = 32’h0 ;// clear4’b0001 : result = src1 + src2 ;// add4’b0010 : result = src1 + 1’b1 ;// inc4’b1001 : result = src1 - src2 ;// sub14’b1101 : result = src2 - src1 ;// sub24’b1010 : result = src1 - 1’b1 ;// dec

endcase

Note that the latch inference is suppressed using the full case directive only if theprocedural assignments in each individual case item is made to all the variables modin thecase statement . For example, in thecase statement below, the secondcase item does not modifyreg2 , causing it to be inferred as a latch (to retain last value

case (cntr_sig) // ambit synthesis case = full2’b00 : begin reg1 = 0 ; reg2 = v_field ; end2’b01 : reg1 = v_field ; // latch inferred for reg22’b10 : begin reg1 = v_field ; reg2 = 0 ; end

endcase

If the full case synthesis directive is incorrectly used, RTL and gate level simulationresults may mismatch. When an unspecified case occurs during the simulation, RTLmodel will preserve the value of the variable because it is a reg type variable. The galevel simulation would have implemented combinational logic, possibly generating anincorrect output.

Parallel Case Directive

If the synthesis directive value includesparallel , thecase statement isinterpreted to mean that all thecase labels have equal priority of matching thecaseexpression . The optimizer uses this information to avoid building a decoder to deco

for 2n alternatives wheren is the size (in bits) of thecase expression . The optimizerbuilds a parallel decoding logic instead of a priority encoder logic to drive the select for the multiplexer.



ic

use

ls.

ys a

sehes” onreset

thehenser’son the

inac-

ndf thee.

The following is an example of using the parallel case synthesis directive:

case (1’b1) // ambit synthesis case = parallelcc[0] : cntr = 0 ;cc[1] : cntr = data_in ;cc[2] : cntr = cntr - 1 ;cc[3] : cntr = cntr + 1 ;

endcase

During simulation, if the case expression matches more than one case label, the logcorresponding to each case label will be enabled. This will cause the results to differbetween RTL simulation and netlist simulation. Such situations may also arise if youcasex or casez statements to mask certain combinations. The RTL simulationwill execute the procedural assignment corresponding to the first case label match,whereas the gate level simulation will enable the logic for all the matching case labeTherefore, you should ensure that only onecase label can be matched in thecasestatement before using the parallel case directive.

Mux Directive

If the synthesis directive value includesmux, thecase statement isinterpreted to mean that the decoding logic for loading the value in the register is alwamultiplexer instead of a priority encoder.

Set_Reset Synthesis DirectivesWhen thedo_build_generic command infers a register from a Verilog HDLdescription, it also infers set and reset control of the register and defines whether thecontrols are synchronous or asynchronous. For examples showing flip-flops and latcwith set and reset operation, refer to the sections “Asynchronous set-reset on a latchpage 3-2, “Synchronous set-reset on a flip-flop” on page 3-3, and “Asynchronous set-on a flip-flop” on page 3-4.

Table 1 summarizes the condition in which the set and reset operation is inferred frommodel. This automatic detection of set and reset operation is always in effect even wthe synthesis directives are not used. The synthesis directives notify the tool of the upreference to implement the set and reset operation by using the set and reset pins storage element components.

Table 1 — Register Inference - Set-Reset Control

Figure 3.1 provides the schematic representation of the logic and shows two ways toimplement synchronous set and reset logic for inferred flip-flops.

• One method (Figure 3.1.A) is to control the input to the data pin of the flip-flopcomponent using set and reset logic, so that the data value is1 when set is active,0when reset is active, and driven by the data source when both set and reset aretive (default).

• An alternate method (Figure 3.1.B) is to implement set and reset operation byselecting the appropriate flip-flop component (cell) from the technology library aconnecting the output of set and reset logic directly to the set and reset pins ocomponent. The data pin of the component is driven directly by the data sourc

Flip-Flop Latch

Sync @(posedge clk) Not-Applicable

Async @(posedge clk or negedge set

or posedge reset)

@(data or enable or set

or reset)



ationtivesset

codessued

rs

ded

Figure 3.1 — Implementation of Set-Reset Control Logic

There are six synthesis directives to support the selection of set-reset logic implementat the block level or at the signal level for each register inferred. These synthesis direcare advisory directives only. They do not force the optimizer to implement set and relogic with one approach; rather, they drive the selection of the component from thetechnology library to provide the option for the optimizer.

These synthesis directives do not change the behavior of the netlist in any way. If theis written with synchronous control on a flip-flop, and the synthesis directive specifieasynchronous selection, the resulting implementation is synchronous. A warning is isif the synthesis directive conflicts with the model.

Block directive

The synthesis directive for block level set and reset signal selection are specified asfollows:

// ambit synthesis set_reset asynchronous blocks = namelist// ambit synthesis set_reset synchronous blocks = namelist

These synthesis directives indicate that the set and reset control logic, for the registeinferred from the named blocks listed, should be connected to the componentasynchronous and synchronous pins respectively.

Thenamelist is a comma separated list of simple block names in string form (surrounby quotes). Hierarchical block names are not supported.

These directives must be used inside a module and precede thealways blocks whosenames are listed. It is an error to list an undefined block name.

set

resetdata

clock

data_out

data_out_

clock

set

reset

data data_out

data_out_

(A)

(B)



The following example uses the “set_reset synchronous blocks” synthesis directive:

module sync_block_dff(out1, out2, clk, in, set, rst) ;output out1, out2 ;input in, set, rst, clk ;reg out1, out2 ;// ambit synthesis set_reset synchronous blocks = “blk_1”always @(posedge clk) begin: blk_1if (set)

out1 = 1 ;else if (rst)

out1 = 0 ;else out1 = in ;endalways @(posedge clk) begin: blk_2if (set)

out2 = 1 ;else if (rst)

out2 = 0 ;else out2 = in ;endendmodule

In the above example,out1 is inferred as a D-type flip-flop with connections to thesynchronous set and reset pins,out2 is inferred as a D-type flip-flop with synchronousreset and set operations through logic (refer to Figure 3.2).

Figure 3.2 — Implementation of Set-Reset Synchronous Block Logic

DSENASARSSSRCLK

Q

Q_

DSENASARSSSRCLK

Q

Q_

set

in

rst

clk

100

10000

out1

out2



the

ule.

s

nous

Signal Directive

The synthesis directives for signal level set and reset signal selection is specified asfollows:

// ambit synthesis set_reset asynchronous signals = siglist// ambit synthesis set_reset synchronous signals = siglist

When set and reset control logic is inferred for a register, it is possible to selectivelyconnect some of the signals directly to the set or reset pin of the component and let other signals propagate through logic on to the data pin.

Thesiglist is a comma separated list of signal names (surrounded by quotes) in a modHierarchical signal names are not permitted.

These directives must be used inside a module and precede allalways blocks. It is anerror to list an undefined or an unused signal.

Consider the following example of using the set_reset synchronous signals synthesidirective:

module sync_sig_dff(out1, out2, clk, in,set1, set2, rst1, rst2) ;output out1, out2 ;input in, clk, set1, set2, rst1, rst2 ;reg out1, out2 ;//ambit synthesis set_reset synchronous signals=“set1, rst1”always @(posedge clk) beginif (set1)

out1 = 1 ;else if (rst1)

out1 = 0 ;else out1 = in ;end

always @(posedge clk) beginif (set2)

out2 = 1 ;else if (rst2)

out2 = 0 ;else out2 = in ;endendmodule

The example above shows that the outcome is similar to the example in the “BlockDirective” section. Although similar, in the case with the block directive, the flip-flopinferred forout1 is connected so that the set and reset signals connect to the synchroset and reset pins. In this case, the signalsset1 andrst1 are connected to the inferredflip-flop’s synchronous set and reset pins. Figure 3.3 shows the generated logic.



ins.

sing

s settively.t.

Figure 3.3 — Implementation of Set-Reset Synchronous Signal Logic

All flip-flops controlled by the named set and reset signals (rst1 andset1 in theexample above), have set and reset signals connected directly to the synchronous p

Signals in a Block Directive

Both the block and the signal name can be specified for set and reset operation by uthe following directives:

//ambit synthesis set_reset asynchronous block(name)=siglist//ambit synthesis set_reset synchronous block(name)=siglist

Only the listed signals in the named block that perform synchronous or asynchronouand reset operation are connected to the synchronous or asynchronous pins respecFor registers inferred from other blocks, these signals are connected to the data inpu

DSENASARSSSRCLK

Q

Q_

DSENASARSSSRCLK

Q

Q_

set2

in

rst2

clk

100

10000

out1

out2

set1

rst1



k

ic.

Consider the following example of using the set_reset synchronous signals in a blocsynthesis directive:

module sync_block_sig_dff(out1, out2, clk, in, rst) ;output out1, out2 ;input in, clk, rst ;reg out1, out2 ;/* ambit synthesis set_reset synchronousblock(blk_1) = “rst” */always @(posedge clk) begin:blk_1if (rst)

out1 = 0;else out1 = in ;endalways @(posedge clk) begin:blk_2if (rst)

out2 = 0;else out2 = in ;endendmodule

The generated logic is shown below. Notice that the reset control (rst signal) for theout1 flip-flop is connected directly to the synchronous reset pin, whereas the resetcontrol for theout2 flip-flop is connected through logic to the data input pin. This isbecause only therst signal inblk_1 was identified in the directive.

Figure 3.4 — Implementation of set-reset synchronous signals in a block log

DSENASARSSSRCLK

Q

Q_

DSENASARSSSRCLK

Q

Q_

in

clk

100

10000

out1

out2

rst0



used.

edg

nd,

statective.

Architecture Selection DirectiveThis directive is used to select different types of architectures for arithmetic andcomparator (relational) operators. At present, there are three choices available forarchitecture selection - Carry Look-ahead, Conditional Sum, and Ripple Carry.

This directive must be specified as follows, just before the operator to be selected is

// ambit synthesis architecture = cla, csum, or rippleFor example,module abc(…)…// ambit synthesis architecture = claassign x1 = a + b; // use Carry Lookahead adder

…// ambit synthesis architecture = csumassign x1 = a + b; // use Conditional Sum adder

…// ambit synthesis architecture = rippleassign x2 = d - e; // use Ripple Carry subtracter

Finite State Machine DirectivesWhen a finite state machine is described, much of the information related to it’s stateencoding is not written in the Verilog HDL model. Two synthesis directives are providto capture this information. These are the enum and the state_vector directives. Usinthese directives in your Verilog HDL description causes the FSM to be extracted andoptimized when the -extract_fsm option is specified with the do_build_generic commaas follows:

do_build_generic -extract_fsm

The directives are described in detail in the following section.

Enum Directive

Theenum synthesis directive is used to enumerate state assignments and to bind theassignments to the state vector. A name for the enumeration is defined using the direIt is bound to the state vector when the state vector (current state and next state) isdeclared.

The following is the syntax for the enum synthesis directive:

// ambit synthesis enum <enumeration_name>

Example 1.5 illustrates how to use this directive to specify a FSM.



as an

ofrom

Example1.5 - Using the enum synthesis directive to represent state vector values

module myfsm (clk, out, reset);input clk, reset;output [1:0] out;parameter [1:0] // ambit synthesis enum state_infoSTATE0 = 2’b00,STATE1 = 2’b01,STATE2 = 2’b10,reg [1:0] /* ambit synthesis enum state_info */ state;reg [1:0] /* ambit synthesis enum state_info */ next_state;reg [1:0] out;// ambit synthesis state_vector state -encoding one_hotalways @ (posedge clk) beginif (reset)

state = STATE0;else

state = next_state;endalways @ (state or reset) begincase (state)

STATE0 : beginnext_state = STATE1;out = 2’b01;

endSTATE1: beginnext_state = STATE2;out = 2’b10;

endSTATE2: beginnext_state = STATE0;out = 2’b10;

enddefault: begin //represents the unreachable (invalid) statesof the FSM //next_state = STATE0;out = 2’bxx;endendcaseendendmodule

Using the directive with parameter declarations results in each parameter being takenenumeration of the state. The directive is used to associate the state vector (state andnext_state above) with the state assignments enumerated by the parameterdeclaration. A warning is generated if the FSM is extracted with more states than theparameters specified as state enumeration.

If the enum synthesis directive is specified with the state vector declaration but has nenumeration of state encoding, the valid state assignments are derived automaticallythe model.



tois

e - -es,

thes.

e settM arent. Ifion

c-

from

ate

State_vector Directive

Thestate_vector synthesis directive enables you to specify the state vector and specify the method of encoding and optimizing the FSM. The syntax for the synthesdirective is:

// ambit synthesis state_vector sig state_vector_flag

wheresig is the name of the signal representing the state vector. Thestate_vector_flag may take one or more of the following options:

-encoding [binary|gray|one_hot|random|input|output|combined| area |timing]-minimize-reachable-preserve_state s1,s2,s3-initial_state s1,s2,s3)

FSM OptimizationsBuildGates only invokes the FSM optimization framework when the do_build_genericcommand is used with the -extract_fsm option i.e. do_build_generic -extract_fsm. Thextract_fsm option extracts the state transition table for the FSM. Use the report_fsmstate command to view the table and the associated information (e.g. equivalent statinitial states, state encodings).

The suite of FSM optimizations is listed below in order of importance and impact on quality of results. These optimizations are invoked using the Ambit synthesis pragma

1. Remove unreachable and invalid statesThis transformation instructs BuildGates to treat all unreachable states including thof invalid states represented by the default case as don’t cares. If this option is nospecified, the actions indicated by the default case statement representing the FShonored by BuildGates. The full_case pragma is ignored for such a case statemethe invalid states are to be treated as don’t cares then you must use this optimizatusing the following pragma:

//ambit synthesis state_vector state_reg -reachable

Option Description

encoding Allows you to set one of several different encoding styles for thestate vector. These encoding styles are discussed in the next setion.

reachable Removes all unreachable and invalid states from the statemachine. This allows the default case representing the invalidstates of the FSM to be treated as don’t care.

preserve_state Specifies the states to be preserved and prevents those statesbeing removed by the minimize or reachable options.

initial_states Specifies the states to be set as the initial states of the finite stmachine



the

ter

lityhe

ut

oughn aber

Note: This option reduces the run time as BuildGates treats special care to handleactions from invalid states (represented by the default case). For a sparselyencoded machine the number of unreachable (invalid) states could be largeleading to larger run-times. Thus this switch is recommended highly for shorrun-times as well as more effective optimization.

2. State assignment or re-encodingAlthough you can provide a default state assignment using the enum directive,BuildGates offers a wide choice of encoding schemes which often yield better quaresults for area and timing. The various encoding schemes can be invoked using tfollowing Ambit pragma.

// ambit synthesis state state_reg -encoding encoding_style

The following encoding styles are available using BuildGates:

In input and output encoding, adjacent refers to the positions of the output and inpstates in the Karnaugh Map.

Using the area or timing encoding options are highly recommended as they go thra set of good encodings and select the one with the best implementation based osuitable area or timing cost function. The timing cost function is based on the numof logic levels of the resulting netlist before technology mapping. The area costfunction is based on the number of gates in the resulting netlist before technologymapping.

Table 2 — Encoding styles for state vectors

Style Description

binary binary encoding of states

gray gray encoding of states

one_hot one hot encoding (exactly one bit is one for each state) of states

random random assignment of states

input maximize the adjacent states that are inputs of identical or sim-

ilar outputs.

output maximize the adjacent states that are outputs of identical or

similar (adjacent) inputs

combined A combination of input and output encoding

area A new scheme which goes through a lot of different encodings

(including input, output and combined schemes) and picks the

one with the best area implementation.

timing A new scheme which goes through a lot of different encodings

(including input, output and combined schemes) and picks the

one with the least number of logic levels in an optimized

implementation



n aug in

ente

. Afoundsing

3. State MinimizationEach state of an FSM usually corresponds to a unique behavior. In some cases,however, two or more equivalent states, having identical I/O behavior, may occur istate machine. This can be a result of performance reasons (by the designer) or a bthe design. Using the -minimize option in the state_vector directive instructsBuildGates to perform a minimization on the FSM. This optimization is run on theFSM to validate it. If equivalent states are found in the design it may mean that thedesign has a bug. If you are confident that your design does not have any equivalstates, then you can ignore this option and save on run time. The following directivinvokes state minimization:

//ambit synthesis state_vector state_reg -minimize

4. Terminal State Check is always performed on the extracted state machine.A terminal state is a state of the FSM from which there are no outgoing transitionswell designed state machine should never have a terminal state. If such a state is in the FSM it is recorded and included in the FSM report (which can be generated uthe report_fsm command).





DLter.

sistheels

ea),cts of

E

the

4VHDL Modeling Style

OverviewThis chapter describes the VHDL modeling style in BuildGates. Both VHDL'87 andVHDL'93 are supported in BuildGates and adhere to the ANSI/IEEE standards on VHlanguage definition. Prior knowledge and experience of VHDL is assumed in this chapA summary of supported constructs can be found in Appendix D.

This chapter describes the impact that different modeling styles have on logic syntheand netlist generation. Two functional models may simulate identically and describe same behavior (functionality) of a design. However, the implementation of the two modthrough the logic synthesis process may differ significantly in terms of gate count (arcritical paths, and physical characteristics. We also present some of the new construVHDL’93 and how they affect synthesis.

The synthesizable subset of VHDL is based on the IEEE P1076.6 Draft Standard forVHDL Register Transfer Level Synthesis. A preliminary draft of this document isavailable from the following location:

http://server.vhdl.org/siwg/

In addition to specific modeling styles and their impact on the netlist, a set of specialcomments, known assynthesis directives, are also described.

Associated DocumentsFor more detail on the VHDL syntax and semantics, please refer to the following IEEStandard VHDL Language Reference Manuals:

• ANSI/IEEE Std 1076-1987 (for VHDL’87)

• ANSI/IEEE Std 1076-1993 (for VHDL’93)

Combinational Logic InferencingBuildGates synthesizes combinational logic to implement a variable or signal under following conditions:

• The variable or signal is unconditionally assigned a value before it is used andwhenever any of the signals in the right-hand side expression change.



onsple,

ed

ent

For example, combinational logic is synthesized to generate signalz for themodel in the example shown below:

process (a, b, c)begin

z <= a+b+c;end process;

• The variable or signal is conditionally assigned a value under all possible conditiwhenever any of the signals in the right-hand side expression change. For examcombinational logic is synthesized to generate signalz for the model in the exam-ple shown below:

process (a, b, c)begin

if b= ‘1’ thenz <= a;

elsez <= c;

end if;end process;

Register InferencingA storage element is implemented for a signal or variable that is incompletely assignunder the control of an edge-triggered or level-sensitive signal condition.

Latch InferencingConsider the following example of inferring a latch:

process(data_in, enable)begin

if enable = '1' thendata_out <= data_in;

end if;end process;

data_out is modified when signalenable is high. The model does not specify whathappens whenenable is low (or unknown). The default behavior implied by VHDL isthat the signaldata_out retains its previous value. BuildGates infers a storage elemto implement the variabledata_out . As no clock edge (rising or falling) is involved, alatch is inferred whose data input isdata_in , enable input (sometimes called gate) isenable , and output isdata_out .

On running thedo_build_generic command inac_shell, the following report of alatch inference is provided:

ac_shell[1]> read_vhdl latch.vhdac_shell[2]> do_build_generic



l

nal

l is

al

.

In VHDL’93, the same latch could be inferred by using a concurrent conditional signaassignment:

data_out2 <= data_in when (enable = '1');

Such an incomplete assignment is not possible in VHDL’87 since the conditional sigassignment in VHDL’87 is required to have anelse clause.

Asynchronous set-reset on a latch

A latch with asynchronous set and reset connections is synthesized when the modewritten as follows:

process(data_in, enable, set_sig, reset_sig)begin

if set_sig = '1' thendata_out <= '1';

elsif reset_sig = '1' thendata_out <= '0';

elsif enable = '1' thendata_out <= data_in;

end if;end process;

The process is triggered whendata_in , enable , set_sig, or reset_sig change.The assignment todata_out is first controlled by theset_sig andreset_sigsignals. Only when both are inactive isdata_out assigned the value ofdata_in ifenable is active.


ac_shell[1]> read_vhdl latchsr.vhdac_shell[2]> do_build_generic

In VHDL’93, the same latch could be modeled by using a concurrent conditional signassignment:

data_out2 <='1' when (set_sig = '1') else‘0' when (reset_sig = '1') elsedata_in when (enable = '1');

If either theset_sig or thereset_sig is active low then the condition in theifstatement should be negated (i.e.set_sig = 0 ). If either a set or a reset control is notrequired, the corresponding condition must not be specified in the process.

Only single bit set and reset signals are supported. Refer to the section, “SynthesisDirectives” for information on how to control the set and reset connections for a latch



in,

nal

el is

fied in

Flip-Flop InferencingWhen a process is triggered by a rising edge or a falling edge transition on a signal(typically, a clock signal), the variable or signal on the left-hand side of a proceduralassignment is inferred as a flip-flop. This is shown in the following example:

process(clk)begin

if clk’event and clk = '1' thendata_out <= data_in;

end if;end process;

A rising edge D-type flip-flop will be inferred. Its data input will be connected to data_its clock input will be connected to clk, and its output will be connected to data_out.


ac_shell[1]> read_vhdl ff.vhdac_shell[2]> do_build_generic

In VHDL’93, the same flip-flop could be modeled by using a concurrent conditional sigassignment:

data_out2 <= data_in when rising_edge(clk);

Note that in this example we have used the standardrising_edge function (defined inpackagesIEEE.STD_LOGIC_1164 and IEEE.NUMERIC_BIT) to specify apositive edge on signalclk .

Synchronous set-reset on a flip-flop

A flip-flop with synchronous set and reset connections is synthesized when the modwritten as follows:

process(clk)begin

if clk'event and clk = '1' thenif set_sig = '1' then

data_out <= '1';elsif reset_sig = '1' then

data_out <= '0';else

data_out <= data_in;end if;

end if;end process;

The process is triggered only on the rising (or falling) edge ofclk , but the assignment todata_out is controlled byset_sig andreset_sig signals. Only when bothset_sig andreset_sig are not ‘1’ is data_out assigned the value ofdata_in . Ifeither a set or a reset is not required, the corresponding condition must not be specitheprocess .



e 4-8

del is

sing

flop.


ac_shell[1]> read_vhdl ffsr_sync.vhdac_shell[2]> do_build_generic

Only single bit set and reset signals are supported. See “Synthesis Directives” on pagfor more information on controlling the set and reset connections for a flip-flop.

Asynchronous set-reset on a flip-flop

A flip-flop with asynchronous set and reset connections is synthesized when the mowritten as follows:

process(clk, set_sig, reset_sig)begin

if set_sig = '1' thendata_out <= '1';

elsif reset_sig = '1' thendata_out <= '0';

elsif clk'event and clk = '1' thendata_out <= data_in;

end if;end process;

The process is triggered when a rising edge is detected onclk , or a change is detected onset_sig , or reset_sig . If either theset_sig or thereset_sig is active low, then thecondition in the if statement should be negated (i.e.set_sig=’0’ ). The report from thedo_build_generic command is shown below.

ac_shell[1]> read_vhdl ffsr_async.vhdac_shell[2]> do_build_generic

In VHDL’93, the same flip-flop with asynchronous sets/resets could be modeled by ua concurrentconditional signal assignment:

data_out2 <= '1' when (set_sig = '1') else'0' when (reset_sig = '1') else

data_in when (clk'event and clk = '1');

Only single bit controls are accepted for set and reset. See the section on synthesisdirectives for more information on controlling the set and reset connections for a flip-



Specifying Clock EdgesClock edges can be specified for flip flops in the context ofif, wait, andconditional signalassignment (VHDL’93 mode only) statements. The following three statements areequivalent:

• Using anif statementprocess (clk)begin

if (clk'event and clk = '1') thenq <= d;

end if;end process;

• Using await statementprocessbegin

wait until (clk'event and clk = '1');q <= d;

end process;

• Using aconditional signal assignment statement in VHDL’93q <= d when (clk'event and clk = '1');

For each of the cases above, clock signals can be ofbit , boolean , std_ulogic andstd_logic types. The clock edge expression for a signalclk can be specified in severalways. The rising edge of the clock signal can take the following forms:

For boolean clock signals:

clk'event and clk = TRUEnot clk'stable and clk = TRUE

For bit clock signals:

clk'event and clk = '1'not clk'stable and clk = '1'

For std_ulogic andstd_logic clock signals:

rising_edge(clk)clk'event and clk = '1'not clk'stable and clk = '1'

The falling edge of the clock signal can specified in one of the following ways:

For boolean clock signals:

clk'event and clk = FALSEnot clk'stable and clk = FALSE

For bit clock signals:

clk'event and clk = '0'not clk'stable and clk = '0'

For std_ulogic andstd_logic clock signals:

falling_edge(clk)clk'event and clk = '0'not clk'stable and clk = '0'

All of the forms of clock edge expressions can be used inif, wait, andconditional signalassignment statements.

In addition, the following expressions can be used inwait statements to specify rising andfalling edges respectively:

wait until (clk = '1'); -- rising clock edge



nriable,

r the

er

deled

wait until (clk = '0'); -- falling clock edge

The Case StatementA case statement represents multi-way branching in a functional description. Whea case statement is used as a decoder to assign one of several different values to a vathe logic can be implemented as combinational or sequential logic based on whethesignal or variable is assigned a value in branches of the case statement.

There are two specific uses of thecase statement, explained below, as it relates to registinferencing.

Incomplete Assignments in the Case StatementWhen acase statement specifies only some of the values that thecase expressioncan possibly have, a latch is inferred. For example, a state transition table may be moas follows.

signal curr_state, next_state, modifier:std_logic_vector(2 downto 0);

process(curr_state, modifier)begin

case curr_state iswhen "000" => next_state <= "100" or modifier;when "001" => next_state <= "110" or modifier;when "010" => next_state <= "001" and modifier;when "100" => next_state <= "101" and modifier;when "101" => next_state <= "010" or modifier;when "110" =>next_state <= "000" and modifier;when others => null;

end case;end process;

Thenext_state signal is assigned a new value ifcurr_state is any one of the sixvalues specified. For the other two possible states, thenext_state signal will retain itsprevious value. This behavior causes BuildGates to synthesize a 3-bit latch fornext_state .

Complete Assignments in the Case StatementIf you do not want BuildGates to infer a latch, thenext_state signal must be assigneda value under all situations.next_state should have a default value. There are twopossible ways we can assign a default value tonext_state .


next_state <= "000";case curr_state is

when "000" => next_state <= "100" or modifier;when "001" => next_state <= "110" or modifier;when "010" => next_state <= "001" and modifier;when "100" => next_state <= "101" and modifier;when "101" => next_state <= "010" or modifier;when "110" =>next_state <= "000" and modifier;when others => null;




ctor

eto the

Thenext_state signal is assigned a value unconditionally and then it is modifiedappropriately by thecase statement. An alternative approach is to use theothersclause in the case statement to capture all the remaining cases wherenext_state isassigned a value.

signal curr_state,next_state,modifier:std_logic_vector(2 downto 0);


case curr_state iswhen "000" => next_state <= "100" or modifier;when "001" => next_state <= "110" or modifier;when "010" => next_state <= "001" and modifier;when "100" => next_state <= "101" and modifier;when "101" => next_state <= "010" or modifier;when "110" =>next_state <= "000" and modifier;when others =>next_state <= "000";


Both solutions above will prevent BuildGates from inferring a latch.

The For LoopThefor loop is used to describe repetitive operations. For example, all the bits of a ve(in_sig ) can be stored reverse order using afor loop.

process(in_sig, out_sig)begin

for i in 0 to 7 loopout_sig(7-i) <= in_sig(i);

end loop;end process;

wherei is declared as integer, and out_sig andin_sig are 8-bit signals andi isimplicitly declared as an integer. Thefor loop is unrolled to repeat the operations over thrange of the index. Therefore, the example above is treated in an equivalent mannerfollowing operations:

out_sig(7) <= in_sig(0);out_sig(6) <= in_sig(2);out_sig(4) <= in_sig(3);out_sig(3) <= in_sig(4);out_sig(2) <= in_sig(5);out_sig(1) <= in_sig(6);out_sig(0) <= in_sig(7);

The following forms of thefor loop are supported:

for <index> in <start_val> to <end_val> loopfor <index> in <start_val> downto <end_val> loopfor <index> in <discrete_subtype_indication> loop



s

. set

the

ot.

de

An example of the last form of thefor loop range is given below where we reverse the bitof curr_state and assign them tonext_state .

signal curr_state: std_logic_vector(2 downto 0);signal next_state: std_logic_vector(2 downto 0);

process(curr_state)subtype INT02 is integer range 0 to 2;

beginfor I in INT02 loop

next_state(2-I) <= curr_state(I);end loop;

end process;

Synthesis DirectivesBuildGates provides a variety of synthesis directives to control the synthesis processExamples of such directives are those that perform code selection or specify how theand reset pins of a register are to be wired.

BuildGates supports two mechanisms for specifying synthesis directives:

• Attributes : These consist of VHDL attributes attached to appropriate objects insource VHDL.

• Meta-comments: These consist of VHDL comments embedded in the VHDLsource code. Such directives begin with the following keywords:

-- ambit synthesisWhen a comment is used for specifying a synthesis directive, that comment should ncontain any extra characters other than what is necessary for the synthesis directive

Code Selection DirectivesBy default, BuildGates parses and synthesizes all the VHDL code from a file. The coselection synthesis directives are used in pairs around VHDL code:

• synthesis on/off

• translate on/off

Synthesis on/off Directive

Thesynthesis on andsynthesis off code selection directives are used aroundVHDL code that should be parsed for syntactical correctness but should not besynthesized by BuildGates. All the code following the synthesis directive

-- ambit synthesis offup to and including the synthesis directive

-- ambit synthesis onis ignored by BuildGates for synthesis.



ot for

.

dzed

esetrhown

t and

igure

g

data

For example, a model may contain assertions to be used only for debug purposes, nsynthesis. If the assertions are surrounded by thesynthesis on/off directives,BuildGates ignores them for synthesis but verifies the syntax between the directives

function DIVIDE (L, R: integer) return integeris variable RESULT: integer;begin

-- ambit synthesis offassert (R /= 0)report "Attempt to Divide by Zero Unsupported !!!"severity ERROR;

-- ambit synthesis onRESULT:= L/R;return (RESULT);

end DIVIDE;

Translate on/off Directive

The translate on andtranslate off code selection directives are used arounVHDL code that should be completely ignored by the VHDL parser and not synthesiby BuildGates. All the code following the synthesis directive

--ambit translate off

up to and including the synthesis directive

--ambit translate on

is ignored by BuildGates even if it contains syntax errors.

Set_Reset Synthesis DirectivesWhen BuildGates infers a register from the VHDL description, it also infers set and rcontrols of the register and determines whether these controls will be synchronous oasynchronous. The examples with set and reset control on a flip-flop and a latch are sin the section “Register Inferencing” on page 4-2.

There are two ways to implement the synchronous set-reset logic for these inferredregisters.

One approach is to control the input to the data pin of a register component using sereset logic so that the data value is1 when set is active,0 when reset is active, and drivenby the data source when both set and reset are inactive. This is the default approach.F4-1 shows the default implementation of the set-reset control logic.

An alternative approach is to implement set and reset control of a register by selectinappropriate register component (cell) from the technology library and connecting theoutput of set and reset logic directly to the set and reset pins of the component. Thepin of the component is driven directly by the data source. Figure 4-2 shows theimplementation of the set-reset control logic.



level,

and the

de is

ing

allued

resete

Figure 4.1 — Default Implementation of set-reset control logic

Figure 4.2 — Implementation of set-reset control logic

There are six synthesis directives to support this selection at the process level, signalor a mix of the process and signal levels for each register inferred. These synthesisdirectives are advisory directives only. They do not force BuildGates to implement setreset logic with one approach; rather, they drive the selection of the component fromtechnology library to provide additional options for BuildGates.

These synthesis directives do not change the behavior of the code in any way. If the cowritten with synchronous control on a flip-flop, and the synthesis directive specifiesasynchronous selection, the resulting implementation will still be synchronous. A warnis issued if the synthesis directive conflicts with the model.

Process Directives

The process (or block) directives control the connection of set/reset control logic for the registers inferred within a specific process. They are specified using boolean-valattributes attached directly on the labels of the specific process as shown below:

attribute SYNC_SET_RESET_PROCESS: boolean;attribute SYNC_SET_RESET_PROCESS of P1: label is TRUE;

attribute ASYNC_SET_RESET_PROCESS: boolean;attribute ASYNC_SET_RESET_PROCESS of P2: label is TRUE;

P1 and P2 above refer to labels of processes. These directives indicate that the set/control logic for all the registers inferred within the process is directly connected to thsynchronous (forSYNC_SET_RESET_PROCESS) and asynchronous (forASYNC_SET_RESET_PROCESS) pins of the register component. The attributesSYNC_SET_RESET_PROCESSand ASYNC_SET_RESET_PROCESSare declared inthe packageambit.attributes .

set

reset

dataclock

data_out

data_out

clock

set

reset

data data_out

data_out



e thats for

eset

These process directives must be specified in the declarative region of the architecturcontains the process being attributed. It is an error to specify these process directivenon-existent processes.

Consider the following example that uses theSYNC_SET_RESET_PROCESSsynthesisdirective:

use ambit.attributes.all;....entity sync_block_dff is

port (clk, din, set, rst: in std_logic;out1, out2: out std_logic);

end entity sync_block_dff;

architecture A of sync_block_dff isattribute SYNC_SET_RESET_PROCESS of P1: label is TRUE;

beginP1: process (clk)begin

if (rising_edge(clk)) thenif (set = '1') then

out1 <= '1';elsif (rst = '1') then

out1 <= '0';else

out1 <= din;end if;

end if;end process;

P2: process (clk)begin

if (rising_edge(clk)) thenif (set = '1') then

out2 <= '1';elsif (rst = '1') then

out2 <='0';else

out2 <= din;end if;

end if;end process;

end architecture A;

out1 will be inferred as a D-type flip-flop with synchronous connections to set and rpins, butout2 will be inferred as a D-type flip-flop with synchronous reset and setoperations controlled through combinational logic feeding the data portDas shown below.



tr

theThe

os

eing error.

Figure 4.3 — Implementation of set-reset synchronous block logic

Signal Directive

When set and reset control logic is inferred for a register, you can selectively connecsome of the signals directly to the set or reset pin of the component and let the othesignals propagate through logic on to the data pin.

The signal directive dictates that the specified signal should be connected directly toset and reset pin of any inferred registers for which the signal causes a set or reset. signal directive is specified using boolean-valued attributes attached directly on theappropriate signals, as shown below:

attribute SYNC_SET_RESET: boolean;attribute SYNC_SET_RESET of S: signal is true;

attribute ASYNC_SET_RESET: boolean;attribute ASYNC_SET_RESET of R: signal is true;

The signals are taggedS andR with the attributeSYNC_SET_RESET andASYNC_SET_RESET, respectively, indicating that they should be connected directly tthe synchronous set and asynchronous reset pins of inferred registers. The attributeSYNC_SET_RESETand ASYNC_SET_RESETare declared in the packageambit.attributes .

The signal directive must be specified in the same declarative region as the signal battributed. Specifying these directives for a non-existent or unused signal causes an

DSENASARSSSRCLK

Q

Q_

DSENASARSSSRCLK

Q

Q_

set

din

rst

clk

100

10000

out1

out2



ent.

ew.

Consider the following example:

use ambit.attributes.all;....entity sync_sig_dff is

port (clk, din, set1, rst1, set2, rst2: in std_logic;out1, out2: out std_logic);attribute SYNC_SET_RESET of set1: signal is true;attribute SYNC_SET_RESET of rst1: signal is true;

end entity sync_sig_dff;architecture A of sync_sig_dff isbegin


if (rising_edge(clk)) thenif (set1 = '1') then

out1 <= '1';elsif (rst1 = '1') then

out1 <= '0';else

out1 <= din;end if;

end if;end process;


if (rising_edge(clk)) thenif (set2 = '1') then

out2 <= '1';elsif (rst2 = '1') then

out2 <= '0';else

out2 <= din;end if;

end if;end process;

end architecture A;

While the outcome is very similar to the example above, the reason, however, is differIn the earlier case with the process directive, the flip-flop inferred inprocess P wasconnected such that the set and reset signals connect directly to the synchronousset andreset pins. In this case, the signalsset1 andrst1 are required to be connected to thinferred flip-flop’s synchronous set and reset pins. The generated logic is shown belo



eesis

and

ocess

n

et andtively.ata

Figure 4.4 — Implementation of set-reset synchronous signal logic

If more than one flip-flop is controlled by the same set and reset signals (e.g.rst andsetin the process directives example), then each flip-flop will have set and reset signalsconnected directly to its synchronous pins respectively.

Signals in a Process Directive

Sometimes it is necessary to connect signals directly to the set and reset pins of somregisters, and through the data input of other registers. In such a situation, two synthdirectives that provide a combination of the synthesis directives discussed above areuseful. These combination synthesis directives allow you to specify both the processthe signal names as follows:

signal rst, set: std_logic;

attribute SYNC_SET_RESET_LOCAL: string;attribute SYNC_SET_RESET_LOCAL of P1: label is "rst";

attribute ASYNC_SET_RESET_LOCAL: string;attribute ASYNC_SET_RESET_LOCAL of P2: label is "set";

TheSYNC_SET_RESET_LOCAL attribute above is used to indicate that the signalrstshould be connected to the synchronous set/reset pin of the register(s) inferred in prP1. TheASYNC_SET_RESET_LOCAL attribute above indicates that the signalsetshould be connected to the asynchronous set or reset pin of the register(s) inferred iP2.The attributesSYNC_SET_RESET_LOCALand ASYNC_SET_RESET_LOCALaredeclared in the packageambit.attributes .

Only the listed signals in the process are inferred as synchronous or asynchronous sreset signals and will be connected to the synchronous or asynchronous pins respecFor registers inferred from other processes, these signals may be connected to the dinput as appropriate.

DSENASARSSSRCLK

Q

Q_

DSENASARSSSRCLK

Q

Q_

set2

din

rst2

clk

100

10000

out1

out2

set1

rst1



ol for

Consider the following example that uses thesync_set_reset_localsynthesis directive:

use ambit.attributes.all;....entity sync_block_dff is

port (clk, din, rst: in std_logic;out1, out2: out std_logic);

end entity sync_block_dff;

architecture A of sync_block_dff isattribute SYNC_SET_RESET_LOCAL of P1: label is "rst";

beginP1: process (clk, rst)begin

if (rising_edge(clk)) thenif (rst = '1') then

out1 <= '0';else

out1 <= din;end if;

end if;end process;

P2: process (clk, rst)begin

if (rising_edge(clk)) thenif (rst = '1') then

out2 <= '0';else

out2 <= din;end if;

end if;end process;

end architecture A;

The generated logic is shown below. Notice that the reset control (rst signal) for flip-flopfor out1 is connected directly to the synchronous reset pin, whereas the reset contrflip-flop for out2 is connected through logic to the input pin. This is because therstsignal was identified as synchronous in the directive for processP only.



ic

tely

For

Figure 4.5 — Implementation of set-reset synchronous signals in a block log

Architecture Selection DirectiveThe directive is used to select different types of architectures for arithmetic andcomparator (relational) operators. At present, there are two choices available forarchitecture selection: Carry Lookahead and Ripple Carry. By default, the CarryLookahead architecture is used.

The architecture selection directive must be specified immediately after the selectedoperator is used. For example,

-- use Carry Lookahead adderx1 <= a + b; -- ambit synthesis architecture = cla

-- use Ripple Carry subtracterx2 <= c - d; -- ambit synthesis architecture = ripple

--use Conditional Sum adderx3 <= p + q; -- ambit synthesis architecture = csum

If there are multiple operators in the expression, the directive must be placed immediafollowing the desired operator. For example:

-- implement subtractor with ripple-carry architecture

x1 <= a + b - c; -- ambit synthesis architecture = ripple

-- implement adder with ripple-carry architecture

x1 <= a + -- ambit synthesis architecture = ripple

b - c; -- ambit synthesis architecture = ripple

Enumeration Encoding DirectiveThis directive allows the user to override the default encoding of enumeration literals.example, the literals RED and YELLOW below would normally be encoded as00 and11respectively (corresponding to their position in the type COLOR, starting from0). Due totheENUM_ENCODING attribute below, RED and YELLOW will be encoded as10 and01 respectively. The attributeENUM_ENCODING is declared in the packageambit.attributes .

DSENASARSSSRCLK

Q

Q_

DSENASARSSSRCLK

Q

Q_

din

clk

100

10000

out1

out2

rst0



rals

type COLOR is (RED, BLUE, GREEN, YELLOW);attribute ENUM_ENCODING: string;attribute ENUM_ENCODING of COLOR: type is "10 00 11 01”;

TheENUM_ENCODING value string must contain as many encodings as there are litein the corresponding enumeration type. All encodings must contain only0s or1s andshould have an identical number of bits.



like

n the

the

Map.

Signed Type DirectiveThis directive allows the user to specify that the annotated vector type is to be treateda signed type for all arithmetic, logical, and relational operations. The attributeSIGNED_TYPE is a boolean valued attribute declared in the packageambit.attributes .

An example is theieee.numeric_std.signed type:

use ambit.attributes.all;....type SIGNED is array (NATURAL range <>) of STD_LOGIC;-- Attribute the type ’SIGNED’ for synthesisattribute SIGNED_TYPE of SIGNED : type is TRUE;

Mux implementation DirectiveIf a case statement is to be implemented as a multiplexor instead of random logic, theMUX directive should be specified for the case statement.

Example:

library ieee;use ieee.std_logic_1164.all;entity mux is

port(d : in std_logic_vector(7 downto 0);s : in std_logic_vector(2 downto 0);z : out std_logic

);end entity mux;

architecture mux_arch of mux isbegin

process( d, s )begin

case( s ) is -- ambit synthesis muxwhen "000" => z <= d(0);when "001" => z <= d(1);when "010" => z <= d(2);when "011" => z <= d(3);when "100" => z <= d(4);when "101" => z <= d(5);-- "110" not specified.when "111" => z <= d(7);when others => null;


end architecture mux_arch;

Finite State Machine DirectivesWhen a finite state machine is described, information pertaining to the encoding andoptimization of the state assignments can be included in the source as attributes on state signal or variable.

TheSTATE_VECTOR attribute is used to identify the state signal or variable.

TheENCODING attribute specifies encoding of the state vector to one of the encodingstyles summarized in Table 4-1. Note that for input andoutput encoding styles, theterm "adjacent" refers to the positions of the output and input states in the Karnaugh



hose

TheMINIMIZE attribute minimizes the finite state machine by merging equivalentstates.

TheREACHABLE attribute removes all unreachable states from the state machine.

ThePRESERVEattribute specifies the states that should be preserved and prevents tstates from being removed by theMINIMIZE andREACHABLE attributes.

TheINITIAL attribute specifies the initial state of the finite state machine.

Examplelibrary IEEE;use IEEE.std_logic_1164.all;library ambit;use ambit.attributes.all;

entity fsm isport (

clk, rst : in std_logic;data : out std_logic_vector(1 downto 0) );

end entity fsm;

architecture rtl of fsm istype COLOR is (red, blue, green, yellow);

signal STATE, NEXT_STATE : COLOR;

attribute STATE_VECTOR of STATE : signal is true;

attribute PRESERVE of STATE : signal is "red, blue";attribute INITIAL of STATE : signal is "red";attribute REACHABLE of STATE : signal is true;attribute MINIMIZE of STATE : signal is true;

begin

Table 4-1 — Encoding styles for state vectors

Style Description

binary binary encoding of states

gray gray encoding of states

one_hot one hot encoding (exactly one bit is one for each state) of states

random random assignment of states

input Maximize the number of adjacent states that are inputs of iden-

tical or similar outputs.

output Maximize the number of adjacent states that are outputs of

identical or similar (adjacent) inputs.

combined A combination of input and output encodings.

area Computes encoding with best area implementation.

timing Computes encoding with best timing implementation.



ser-

the

state_p: process (clk, rst)begin

if (rst = ’1’) thenSTATE <= red;

elsif (rising_edge(clk)) thenSTATE <= NEXT_STATE;

end if;end process state_p;

next_state_p: process(state)begin

case (STATE) iswhen red => data <= "01";

NEXT_STATE <= blue;when blue => data <= "10";

NEXT_STATE <= green;when green => data <= "11";

NEXT_STATE <= red;when yellow => data <= "00";

NEXT_STATE <= red;end case;

end process next_state_p;end architecture rtl;

Resolution Function DirectivesThe resolution function directives allow you to identify the intended behavior of any udefined resolution function in the design.

By specifying a string-valued attribute RESOLUTION on any user-defined resolutionfunction, the designer can control how a signal (with multiple drivers and resolved byattributed function) will be synthesized. The three directives below will cause awired-and , wired-or , or three-state behavior to be synthesized for any signal that isresolved by function MYRES.

attribute RESOLUTION: string;attribute RESOLUTION of MYRES: function is "WIRED_AND";attribute RESOLUTION of MYRES: function is "WIRED_OR";attribute RESOLUTION of MYRES: function is "WIRED_TRI";

In the example below, the function MYRES has been tagged as havingWIRED_ORbehavior using theRESOLUTIONattribute.Signal X with resolution function MYRESwill be synthesized to exhibit aWIRED_OR behavior.

Example:

function MYRES(bv: bit_vector) return ulogic_4 is variabletmp: bit:= '0';begin

for I in vtbr'range looptmp:= tmp or bv(I);

end loop;return tmp;

end;

attribute RESOLUTION of MYRES: function is "WIRED_OR";signal X: MYRES bit;

The attributeRESOLUTION is declared in the packageambit.attributes .



the

the

. Thentity

body:

7)).

with

Template DirectiveWhen an entity is written with generic declarations strictly for use as a template, onlyinstantiated, parameterized design needs to be synthesized. TheTEMPLATE directive onan entity indicates to BuildGates that the template entity is not to be synthesizedexceptinthe context of an instantiation. When theTEMPLATEdirective is used, it must be specifiedin the entity declaration as shown in the example below.

use ambit.attributes.all;entity FOO is

generic (Width : integer := 64);port (DIN : bit_vector (Width - 1 downto 0);

DOUT : bit_vector (Width - 1 downto 0));attribute TEMPLATE of FOO: entity is TRUE;

end FOO;

By designating such entities as templates,do_build_generic will complete fastersince it can eliminate synthesizing the template entities that are not actually used in hierarchical design as stand-alone modules.

The attributeTEMPLATE is declared in the packageambit.attributes .

Type Conversion DirectivesYou can have functions that in effect translate between unrelated user-defined typestype conversion directive indicates to BuildGates that the function behaves like an ideoperator and that the body of such a function need not be synthesized.

There are three types of type conversion directives that can be attached to a function

-- ambit synthesis BUILTIN_TYPE_CONVERSION-- ambit synthesis BUILTIN_ZERO_EXTEND-- ambit synthesis BUILTIN_SIGN_EXTEND

All three directives result in the function body being ignored for synthesis. TheBUILTIN_TYPE_CONVERSION directive should be used for converting betweenidentically sized types (such as between bit_vector(0 to 7) and std_logic_vector(0 to

TheBUILTIN_ZERO_EXTEND andBUILTIN_SIGN_EXTEND should be used forconversions where the size of the argument and returned value are different.

In the following example thetranslate function is treated as an identity operator:

function translate(b: bit) return integer is-- ambit synthesis BUILTIN_TYPE_CONVERSION

beginif (b = '0') then

return 0;else

return 1;end if;

end function;

Reading VHDL designs

Defining Logical LibrariesEach logical library used in a design with the exception of WORK must be associateda physical directory. Use theset_vhdl_library command to do this. The commandcan be used in the following two ways:



taged

d.

o

arda

, set

1. To define a new logical library, use the command as follows:set_vhdl_library <logical_library> <directory>

The directory name above must be a valid path to an existing directory. The advanof creating a library in this manner is that the contents of the library are preservefrom one synthesis run to another.

For example,

ac_shell[1]> set_vhdl_library MYLIB /home/me/vhdlibs/lib1ac_shell[2]> read_vhdl -library MYLIB design.vhd

will analyze the file design.vhd into library MYLIB

2. To map library WORK to an existing logical library:set_vhdl_library WORK <library>

The library name above must be the name of an existing logical library. Allsubsequent read_vhdl commands that do NOT have an explicit -library flag, willresult in the files being analyzed into the last library to which WORK was mappeFor example,

ac_shell[1]> set_vhdl_library MYLIB /home/me/vhdlibs/lib1ac_shell[2]> set_vhdl_library WORK MYLIB

then the following commands are identical and will causedesign.vhd to be analyzedinto libraryMYLIB:

ac_shell[3]> read_vhdl design.vhdac_shell[4]> read_vhdl -library MYLIB design.vhd

However,

ac_shell[5]> read_vhdl -library ADLIB design.vhd

would analyzedesign.vhd to library ADLIB.

By default, the library WORK is mapped to the logical library TEMP. Its is an error if twVHDL libraries are mapped to the same physical directory.

Thereport_vhdl_library command shows the mapping between VHDL logicallibraries and the corresponding physical directory.

It is an error if an attempt is made to analyze a VHDL design unit into one of the standlibraries (STD, AMBIT, IEEE, SYNERGY, SYNOPSYS) without mapping the library tonew directory using theset_vhdl_library command.

Predefined VHDL EnvironmentPrecompiled VHDL libraries and packages are available in thestandard (default),synopsys , andsynergy environments. Thestandard (default) setting provides only theIEEE approved packages. To access the precompiled VHDL libraries and packagesthe value of the global variable:hdl_vhdl_environment (see below).

set_global hdl_vhdl_environment {standard|synopsys|synergy}

Note: Theset_global command must be executed before executing aread_vhdl ordo_build_generic command and must not be changed during the designanalysis.



Table 4-2 lists the VHDL libraries and packages that are available with thestandard

(default) environment using the following command:

set_global hdl_vhdl_environment standard

Table 4-3 lists the VHDL libraries and packages that are available with thesynopsys

environment using the following command:

set_global hdl_vhdl_environment synopsys

Table 4-4 lists the VHDL libraries and packages that are available with thesynergy


set_global hdl_vhdl_environment synergy

Table 4-2 — BuildGates Predefined VHDL Libraries for the Standard Environment

Library Packages

AMBIT attributes

STD standard

textio

IEEE std_logic_1164

numeric_bit

numeric_std

Table 4-3 — BuildGates Predefined VHDL Libraries for the Synopsys Environment

Library Packages

AMBIT attributes

STD standard

textio

SYNOPSYS attributes

IEEE std_logic_1164

std_logic_arith

std_logic_misc

std_logic_signed

std_logic_textio

std_logic_unsigned

Table 4-4 — BuildGates Predefined VHDL Libraries for the Synergy Environment

Library Packages

AMBIT attributes

STD standard

textio

SYNERGY constraints

signed_arith

std_logic_misc

IEEE std_logic_1164

std_logic_arith

std_logic_textio



ser.

ated

iled

n

HDL

s

e

The VHDL source for these packages can be found in the following directory:

ac_shell[1]> ls $env(AMBIT_VHDL_LIBS)/<version>/<library>where<version> is either1987 or 1993 , and<library> is one of the following:ambit ,std , ieee_ambit (for hdl_vhdl_environment set tostandard ), ieee_synergy (forhdl_vhdl_environment set tosynergy ), andieee_synopsys (for hdl_vhdl_environment

set tosynopsys ), synergy , or synopsys .

All other VHDL packages referred to in the design must be explicitly analyzed by the u

Using Arithmetic Packages From Other Vendors

It is strongly recommended that the globalhdl_vhdl_environment be used to setup yourVHDL environment. This is especially important since the arithmetic packages associwith thestandard , synergy andsynopsys enviroments have been tagged with specialdirectives that enable BuildGates to implement them efficiently.

However, it may be possible that some of the VHDL designs may have references toarithmetic packages from other synthesis vendors that are also required to be compinto a library named IEEE.

To make use of these additional packages, execute the following steps:

• Redefine the library IEEE to a new directory:

ac_shell[1]> set_vhdl_library IEEE <dir_name>

• Analyze thestd_logic_1164 package before analyzing any vendor-specificpackages. The source for this package is available in the BuildGates installatiodirectory:

ac_shell[2]> read_vhdl -library IEEE \$env (AMBIT_VHDL_LIBS)/1993/ieee/std_logic_1164.vhdl

We now have a local version of the IEEE library with the basic packagestd_logic_1164

analyzed into it. Note that in this example we have assumed that we are using the V‘93 version of thestd_logic_1164 package. It must be pointed out that thestd_logic_1164 package shipped with BuildGates must be used in this step since it itagged with the appropriate synthesis directives.

• Read in the other vendor-specific packages that are required to be in the IEEElibrary:

ac_shell[5]> read_vhdl -library IEEE <package>After this step, read any VHDL entities that use these packages.

Since the local copy of the IEEE library was created using theset_vhdl_library

command, the corresponding directory is preserved on exiting fromac_shell . On asubsequent invocation ofac_shell , reuse the IEEE library created above by repeating thfirst step. The other steps are not required.



.

oth

ilizee

ting

le to

87t theseneric

ce,l

Switching between VHDL’87 / VHDL’93BuildGates supports both 1987 and 1993 versions of VHDL. It is possible to read inVHDL designs that are modeled using different versions.It is also possible to read inVHDL designs in one version and write out the synthesized netlist in another version

The globalhdl_vhdl_read_version can be used to specify the VHDL version offiles that will be analyzed using theread_vhdl command. For example:

ac_shell[1]> set_global hdl_vhdl_read_version 1987

will ensure that only VHDL files that conform to the VHDL ’87 standard are parsedsuccessfully. The default value for this global is1993 .

For all the packages that are part of the BuildGates predefined VHDL environment, bthe VHDL’87 and VHDL’93 versions are precompiled and shipped with BuildGates.

It should be pointed out that when the value of the globalhdl_vhdl_read_versionis changed, BuildGates will reset the libraries STD, IEEE, and AMBIT to the defaultvalues for the language setting. Thus, users will need to redefine the library IEEE to utother vendor-specific IEEE packages analyzed into the correct VHDL version. See thsection on arithmetic packages from other vendors for more information on incorporavendor-specific IEEE packages into the library IEEE.

It is advisable to use the same version of VHDL for reading in a given design. If yourproject requires a mix of VHDL versions to be read in, in most cases you should be abanalyze both the sets of VHDL files with the globalhdl_vhdl_read_version set to1993. If it is absolutely essential that the different sets of files be read in with theappropriate version-specific syntax checking, then read in the VHDL code for the 19version and elaborate it with do_build_generic and save out the generic adb. Repeasteps for the code using 1993 version. Then, in a new ac_shell session, read in the ge.adb files and run do_build_generic to link the designs together. Then proceed withconstraining and optimizing the design.

Reusing previously analyzed entitiesFor large designs, it is usually desirable to analyze all the VHDL files into a library onand then reuse the analyzed entities in subsequent BuildGates sessions. The globahdl_vhdl_reuse_units can be used to import VHDL entities that were analyzedpreviously into a library. When set totrue , do_build_generic will automaticallysynthesize all entities that reside in any VHDL library specified using theset_vhdl_library command. The default value ofhdl_vhdl_reuse_units istrue.

For example assume that a libraryMYSRChas entitiesTOPandBOTTOManalyzed into it.Since the default value ofhdl_vhdl_reuse_units is true ,do_build_generic automatically picks up these entities for synthesis.



s

s of

ed.ule

ng.

However, ifhdl_vhdl_reuse_units is set tofalse , then only entities that areexplicitly read in usingread_vhdl in the current session will be synthesized byBuildGates. In the example below, even though the libraryMYSRC has entities analyzedinto it from a previous BuildGates session, they are not synthesized as the variablehdl_vhdl_reuse_units is set tofalse .

ac_shell[1]>set_vhdl_library MYSRC ./libac_shell[2]>set_global hdl_vhdl_reuse_units falseac_shell[3]>do_build_generic Info: No designs to process. <CDFG-301>.

Modifying case of VHDL namesThe global variablehdl_vhdl_case can be used to control the case in which VHDL namewill be stored in BuildGates. For example:

ac_shell[1]> set_global hdl_vhdl_case lower

Possible values of the globalhdl_vhdl_case are:

• lower : convert all names to lower-case (Xpg is stored asxpg )

• upper : convert all names to upper-case (Xpg is stored asXPG)

• original : preserve case used in declaration of the object (Xpg is stored asXpg)

The case of VHDL names is only relevant for references to foreign modules. Exampleforeign references are Verilog modules and library cells.

If the globalhdl_vhdl_case is set tooriginal , it is recommended that the same case bused when referring to such foreign objects as was used when the object was defineTherefore, component and port names should be identical in case to the Verilog moddefinition.

Writing VHDL Netlists

Selecting bit-level representationThe VHDL netlister preserves the port types of the current entity’s ports during netlistiThis requires generation of conversion functions that transform potentially complexVHDL port types to a simpler bit-level representation. Such conversion functions areencapsulated in a package that is generated by the netlister.



en

f

d.

e

.g.

All descendant module ports are always written with the equivalent bit-levelrepresentation.

For a module that did not originate as a VHDL entity, the module’s port are also writtout with the equivalent bit-level representation.

The global variablehdl_vhdl_write_bit_type is used to determine the type ofthe bit-level representation used in VHDL netlists. The allowed values arestd_logi c orstd_ulogic. The default value is std_logic . For example,

ac_shell[1]> set_global hdl_vhdl_write_bit_type std_ulogic

will result inbit ports being mapped to internalstd_ulogic ports andintegerports being mapped to internalstd_ulogic_vector signals.

VHDL’87 / VHDL’93 netlistsThe globalhdl_vhdl_write_version can be used to specify the VHDL version othe netlists that will be written out using thewrite_vhdl command.

For example:

ac_shell[1]> set_global hdl_vhdl_write_version 1987

will ensure that the VHDL netlists that are written out conform to the VHDL’87 standarThe default value for this global is1993 .

If VHDL netlists will be written out in the VHDL’87 mode, care must be taken to avoidillegal names that might be generated by synthesis. When busses are bit-blasted, thindividual net names are formatted as specified by the globalbuscomp_generator .By default, names for the nets of a bus will be generated with the square brackets (eb[1] ). Such names are illegal in VHDL ’87 and can be avoided by setting:

ac_shell[2]> set_global buscomp_generator %s_%d

prior to anydo_build_generic command. This is not an issue in VHDL ’93 modenetlists, since a name such asb[1] can be written out as an escaped name \b[1]\.

Referring to VHDL packages in netlistsThe global variablehdl_vhdl_write_packages can be used to specify the set oflibrary and use clauses that must precedeevery module that is being written out. Forexample,

ac_shell[1]> set_global hdl_vhdl_write_packages\"ieee.std_logic_1164 atl.comps1 atl.comps2"

will result in the following clauses preceding every module that is written out:

library ieee;use ieee.std_logic_1164.all;library atl;use atl.comps1.all;use atl.comps2.all;

The default value of this global is "ieee.std_logic_1164 ".



e

Writing Component DeclarationsThe global variablehdl_vhdl_write_components can be used to specify whetherthe netlister should write out component declarations for the technology cells that arreferred to within the modules.

For example, if the component declarations for all the cells in the technology libraryclibare encapsulated in a package calledcomponents, writing of component declarationsfor individual modules can be disabled by settinghdl_vhdl_write_componentsto false, and making thecomponents package visible to all modules being writtenout:

ac_shell[1]> set_global hdl_vhdl_write_components falseac_shell[2]> set_global hdl_vhdl_write_packages\

"ieee.std_logic_1164 clib.components"

The default value of this global isfalse.

Hierarchical VHDL Designs

Component Instantiations and BindingsBuildGates supports several types of component instantiation in hierarchical VHDLdesigns. Consider an entityBOTTOM that has two architectures -A1 andA2. Thefollowing example illustrates the various ways in which entityBOTTOM can beinstantiated for BuildGates and bound to a specific entity architecture pair forimplementation:

entity BOTTOM is ...architecture A1 of BOTTOM is ...architecture A2 of BOTTOM is ...

configuration BOTTOM_CONF of BOTTOM is ...for A2end for;

end configuration BOTTOM_CONF;

entity TOP is .....architecture A of TOP is

component BOTTOM is ...component COMP is ...for I2 : COMP use entity work.BOTTOM;for I3 : COMP use entity work.BOTTOM (A1);for I4 : COMP use configuration work.BOTTOM_CONF;

begin-- instantiate component BOTTOM, default architectureI1 : BOTTOM ...

-- instantiate component COMP bound to entity BOTTOMI2 : COMP ...I3 : COMP ...I4 : COMP ...

- instantiate entity BOTTOM, default architectureI5 : entity work.BOTTOM ...

-- instantiate entity BOTTOM, architecture A1I6 : entity work.BOTTOM(A1) ...



d in

s. In

ortesates.that

-- instantiate entity/architecture in BOTTOM_CONFI7 : configuration work.BOTTOM_CONF ...

-- instantiate component,binding in configuration-- declarationI8 : COMP ...I9 : COMP ...

end architecture A;

configuration TOP_CONF of TOP isfor A

for I8 : COMP use entity work.BOTTOM(A1);for I9 : COMP use configuration work.BOTTOM_CONF;

end for;end configuration BOTTOM_CONF

InstancesI1, I2, I3 andI4 are examples of component instantiations that refer tocomponent declarations. InstanceI1 of componentBOTTOMrelies on a default binding toentityBOTTOM. Default architecture (i.e. the most recently analyzed)A2 will be selectedfor implementingI1 . The configuration specification forI2 binds the componentCOMPto entityBOTTOM, default architectureA2. The configuration specification for instanceI3bindsCOMP explicitly to entityBOTTOM and its architectureA1. The configurationspecification forI4 references the configurationBOTTOM_CONF, which bindsI4 toentityBOTTOM and architectureA2.

InstancesI5 andI6 are examples of entity instantiations, where the entity beinginstantiated is directly referred to in the instantiation. Since no architecture is specifieinstantiationI5 , default architectureA2 is used for implementing this componentinstance. InstanceI6 instantiates entityBOTTOM and implements with architecture A1.

InstanceI7 is an instantiation that uses a configuration to indicate the entity andarchitecture that will be used to implement the instance.

Finally, instancesI8 andI9 illustrate that the binding for component instances can bespecified as component configurations in a configuration declaration. InstanceI8 ofCOMP is bound to entityBOTTOM and architectureA1, while instanceI9 is bound to theentityBOTTOM and architectureA2 specified in configurationBOTTOM_CONF.

Block configurations in configuration declarations can only be used to configurearchitectures. Component configurations cannot have any generic maps or port mapother words, even though the component declarationCOMP may be bound to entityBOTTOM, the generics and ports of the component declaration must match that of theentity it is bound to.

Restrictions on Entities with Multiple ArchitecturesIn VHDL, an entity may have multiple architectures (e.g. one for synthesis and one fsimulation). While you can analyze an entity that has multiple architectures, BuildGarestricts a entity to be bound to exactly one architecture in a single session of BuildGIn other words, if once an entity is bound to a specific architecture, it must be bound tosame architecture everywhere in the design.



s

ill be

The design below is not synthesizable in BuildGates because instancesI1 andI2 bindcomponentCOMP to different architectures of entityBOTTOM.

entity TOP is .....architecture A of TOP is

component COMP is ...for I1 : COMP use entity work.BOTTOM (A1);for I2 : COMP use entity work.BOTTOM (A2);

beginI1 : COMP ...I2 : COMP ...

end architecture A;

Example:

entity BOTTOM is ...architecture A1 of BOTTOM is ...architecture A2 of BOTTOM is ...configuration BOTTOM_CONF of BOTTOM is

for A1end for;

end configuration BOTTOM_CONF;

entity TOP is ...architecture A of TOP isbegin

I1 : entity work.BOTTOM(A2);end architecture A;

For the design above, the following command

ac_shell[4]> do_build_generic -design TOP

will synthesize entityTOP and consequently entityBOTTOM while processing instanceI1 . The entityBOTTOM will be bound to architectureA2 specified in the entityinstantiation.

However, the following two commands:

ac_shell[4]> do_build_generic -design BOTTOMac_shell[5]> do_build_generic -design TOP

will result in an error since the first do_build_generic bindsBOTTOM to architectureA1specified in configurationBOTTOM_CONF, while the second do_build_generic encountera conflicting binding when processing the entity instantiationI1 (whereBOTTOM isbound toA2).

Precedence Rules for Architecture SelectionWhen an entity has multiple architectures, BuildGates selects the architecture that wused to synthesize the entity, by evaluating the following rules in order:

1. The global variablehdl_vhdl_preferred_architecture overrides anyVHDL entity-architecture binding rules. For example, if the global is set as in:ac_shell[1]>set_global hdl_vhdl_preferred_architecture synth

then if an entity,foo , has two architectures namedsim andsynth , BuildGates willbind foo to entitysynth . By default, hdl_vhdl_preferred_architectureis set to the null string ("").



oura-

era-

le,

nly

the

st of

2. If the entity is being synthesized in the context of an instantiation in a higher levelentity, then any explicit architecture binding specified for that instantiation is used tdetermine the architecture that will be used to implement the current entity. Configtion specifications and component configurations (e.g. instances I2 and I8 respec-tively on page 29) can be used explicitly specify the entity-architecture to which theinstance is bound.

3. If the entity has a corresponding configuration declaration, the entity is bound to tharchitecture specified in the top-level block configuration of the configuration declation. For example, the configurationBOTTOM_CONF in the example on page 30 bindsentityBOTTOM to architectureA1.

4. Finally, if none of the previous rules apply, BuildGates binds the entity to the mostrecently analyzed architecture (also known as the default architecture). For exampassume entityMRA has two architectures:A1 andA2. A1 is analyzed first followed byA2. The synthesis of entityMRA will use architectureA2.

It must be pointed out that once an entity has been synthesized in BuildGates, the oway to re-synthesize it with a different architecture (say by modifying a configurationdeclaration) is to reanalyze the entity and all its architectures. For the same reason, globalhdl_vhdl_preferred_architecture should only be set prior to anydo_build_generic command.

VHDL Related Commands and GlobalsThe following table is a summary of the VHDL relatedac_shell commands and globalvariables. Please see the BuildGates Command Reference manual for a complete licommands, their descriptions, and examples.

Table 4-5 — VHDL Global Variables

Command Description(Defaults)

hdl_vhdl_case Case of VHDL symbols when files are analyzed

using read_vhdl. (original)

hdl_vhdl_environment Specifies the selection of the predefined arith-

metic libraries. Choices are standard, synopsys,

and synergy.

hdl_vhdl_preferred_architecture Name of preferred architecture to use with an

entity when there are multiple architectures.

(““)

hdl_vhdl_read_version VHDL version when files are analyzed using

read_vhdl. (1993)

hdl_vhdl_reuse_units Specify whether pre-analyzed units in VHDL

libraries will be synthesized during

do_build_generic. (true)

hdl_vhdl_write_architecture_name Name of the architecture for each entity in the

netlist. ("netlist")

hdl_vhdl_write_bit_type Define the bit type in which VHDL netlists will

be written . (std_logic)

hdl_vhdl_write_components Specify whether component declarations for

technology cells are to be written in the VHDL

netlists. (true)



hdl_vhdl_write_entity_name Generator for entity names during netlist gener-

ation. If set to the empty string, “ “, then use

current module name as the entity name. When

writing out a hierarchical design, this variable

only applies to the current module and all

descendants use their own names. (“ “)

hdl_vhdl_write_packages Space separated list of package names for which

library/use clauses must precede each entity

during netlisting. For example, "lib1.pack1

lib2.pack2". ("ieee.std_logic_1164")

hdl_vhdl_write_version VHDL version in which netlists will be written.

(1993)

Table 4-6 — VHDL ac_shell Commands

Command Description

read_vhdl Analyze VHDL source files.

report_vhdl_library List mapping between VHDL libraries and corresponding

physical directories.

reset_vhdl_library Delete all analyzed units from library.

set_vhdl_library Define a new VHDL logical library. Also, associate WORK to

another VHDL logical library.

write_vhdl Write VHDL netlist.

get_hdl_type Returns the file type, either verilog or VHDL, for a given mod-

ule.

get_hdl_hierarchy Returns a hierarchical list of modules in the design and a list

of their paramterized and non-parameterized instances.

get_hdl_file Returns the file name corresponding to the module.

get_hdl_top_level Returns a list of top level module names.

Table 4-5 — VHDL Global Variables (Continued)

Command Description(Defaults)





used

ts on

ints.withothere

or

d toects

of

5Setting Constraints

OverviewThis chapter describes the implications of specifying constraints and the commandsin theac_shell environment to specify these constraints.The logic synthesis processrequires two user inputs, a functional (RTL) model of the design and a set of constrainthe design.

The constraints are divided into two groups - timing constraints and physical constraThere are no user specified constraints for the area of the design because a design smaller area (gate count) is always preferred over a design with larger area, when allcharacteristics (e.g. timing) are the same. AMBIT synthesis tools always strive for thsmallest possible design area given timing and physical constraints.

Only a few commands are described to explain how to set some of the constraints. Fcomplete description of all commands and options for each command please refer toCommand Reference Manual.

Setting a Hierarchical ContextConstraints are placed on various design objects such as ports, nets, etc. In order touniquely identify the design object used in the command, a module must be identifieprovide a context where the design objects can be found. In other words, design objare searched for in a given module context.

The syntax forset_current_module is as follows:

set_current_module modulename

wheremodulename refers to the name of the module that is being used as the currentcontext. For example,

set_current_module mycounter

wheremycounter is an example of a module design object. Assume the modulemycounter has four ports:ck , din , dout , andcntrl . We can apply constraints tothese ports by using the names of the ports. If we wish to apply constraints to ports another module, we must change the context usingset_current_module command.



teach

ools, are

eth as

le

k iseal

t alleir

es

toprefer

.

edng to

If a module has multiple instances in the design, and each instance requires differenconstraints to be applied to its design objects, a unique module must be generated forinstance. Seedo_uniquely_instantiate command.

Units in ConstraintsThe values used in constraints represent many different quantities. AMBIT synthesis tare “unitless” tools in the sense that when the quantities, whether constant or variablespecified in consistent units, there is no need to explicitly mention units.

The data in technology library is stored in appropriate units for delay, load, drive,capacitance, etc. The user supplied data must be consistent with these units for thecorresponding quantities.

Timing ConstraintsTiming constraints guide AMBIT synthesis tools to achieve certain performance in thresulting netlist. The performance generally refers to the maximum clock frequency awhich the design implementation (netlist) can operate. It also includes information succritical paths in the design.

Timing AnalysisTiming constraints can be thought of as timing specifications placed on certain moduports. The timing specification on an input port is referred to assignal arrival time; thetiming specification on an output port is referred to assignal required time. All timingconstraints are associated with an ideal clock. First, we will describe how an ideal clocdefined. Later, we will show how all other constraints are defined in relation to the idclock.

Timing analysis is an integral part of logic synthesis, and it is performed to ensure thatiming specifications are met. Cells are selected from technology library based on thfunctional, timing and technology characteristics to achieve the goals set up byconstraints. The timing analyzer is built-in as part of AMBIT synthesis program. It guidthe cell selection process to satisfy all the timing requirements.

Setting up Timing ContextTiming context is specified by identifying a module of the design hierarchy that is themodule for timing. Subsequent commands that assert constraints or perform analysisto this timing context.

Theset_top_timing_module command provides context for all timing constraintsThe syntax for the commandset_top_timing_module is as follows:

set_top_timing_module modulename

wheremodulename is the name of the module being set as the timing context.

All timing constraints are applied in the context of a top level module which is specifiby this command. The timing analyzer maintains the analysis and constraints pertainidifferent timing contexts. Thus, theset_top_timing_module command can beviewed as a selection mechanism for timing contexts.



the

k.

a

ck

as a

Ideal Clock DefinitionAn ideal clock must be defined as a global reference signal for all the data signals indesign. The command for defining an ideal clock isset_clock . The syntax for thiscommand is:

set_clock clock_name -period period -waveform {lead trail}where

clock_name is the name used for the ideal clockperiod is the period of the clocklead is the time at which first transition on the clock occurstrail is the time at which second transition on the clock occursperiod lead and trail are integer or real constants

For example,

set_clock master -period 10 -waveform {0 5}set_clock A -period 100 -waveform {30 90}

Figure 5.1 — Defining ideal, positive, and negative clocks

The first command defines an ideal clock calledmaster with a period of 10, with leadingtransition at 0 and trailing transition at 5. The second command defines an ideal cloccalledA with a period of 100, with leading transition at 30 and trailing transition at 90

The leading transition does not imply a rising edge, nor does trailing transition implyfalling edge on the clock signal. The leading transition only indicates first transition,which may be a rising edge or a falling edge transition. The trailing transition is theopposite transition to the leading transition. The figure above shows that an ideal clodefinition can be treated either as apositive clock (leading transition is a rising edgetransition) or as anegative clock (leading transition is a falling edge transition). Thepolarity of the clock gets defined when an input port is associated with the ideal clockclock port as explained later inset_clock_arrival_time command definition.

0 5 10 master

negative clock

positive clock

lead trail period

0 30 90 100A

negative clock

positive clock

lead trail period



or a) thetput

lockge of

lockge of

clocke of

ocke of

sary.

e

Each data signal arriving at a port is considered to be associated with either a leadingtrailing edge of the clock. That is, the signal change is associated with (was caused byleading or the trailing edge of the ideal clock. For example, the signal change in the ouport of a flip-flop is caused by one of the following four events:

1.A rising-edge triggered flip-flop causes a change at its output using a positive cas shown in (a). In this case, the signal change is associated with the leading edthe ideal clock.

2.A falling-edge triggered flip-flop causes a change at its output using a negative cas shown in (b). In this case, the signal change is associated with the leading edthe ideal clock - same as (a).

3.A rising-edge triggered flip-flop causes a change at its output using a negative as shown in (c). In this case, the signal change is associated with the trailing edgthe ideal clock.

4.A falling-edge triggered flip-flop causes a change at its output using a positive clas shown in (d). In this case, the signal change is associated with the trailing edgthe ideal clock - same as (c)

Figure 5.2 — Positive and negative clocks controlling a flip-flop

In a single clock design, only oneset_clock command will be used. In a multi-phaseclock system severalset_clock commands will be used to define each phase of theclock.

For purely combinational design, an ideal clock (or any clock) definition is not neces

Clock Arrival TimeOnce ideal clocks are defined, the actual clock signals arriving at the input port of thdesign can be defined. The association between the ideal clock and the clock signalarriving at a clock port is made using theset_clock_arrival_time command.

lead

rck

QD

fck

QD

fck

QD

rck

QD

(a) (b)

(c) (d)

lead

trailtrail



.1 the

he

The syntax of the command is as follows:

set_clock_arrival_time -rise rise -fall fall -clock clockportlist

where

rise is the time at which rising edge occursfall is the time at which falling edge occursclock is the name of the ideal clockportlist is the list of ports associated with this ideal clockrise and fall are integer or real constants

For example,

set_clock_arrival_time -rise 0.1 -fall 5.2 -clockmaster ckset_clock_arrival_time -rise 91 -fall 32 -clock A {c1 c2}

The first example associates a clock port calledck to the ideal clock calledmaster (asdefined earlier). The primary difference between the ideal clock and the clock signalarriving at the clock port is the skew, i.e. the shift in time. The rising edge occurs at 0and the falling edge occurs at 5.2. This indicates that the rising edge skew is 0.1 andfalling edge skew is 0.2. The timing relationship between the ideal clock (master ) andthe clock signal (ck ) is as follows

Figure 5.3 — Associating a positive clock signal to an ideal clock

The second example associates two clock portsc1 andc2 with the ideal clockA (asdefined earlier) which has its rising edge at 91 and its falling edge at 32. The timingrelationship between the ideal clock (A) and the two clock signals (c1 , c2 ) is as follows

Figure 5.4 — Associating a negative clock signal to an ideal clock

More than oneset_clock_arrival_time command may be used to associatedifferent clock ports with the same or other ideal clock(s). This may be useful when tsame ideal clock signal arrives at two different clock ports with different skews.

0.1 0.2

ck positive clock

1050

0.1

0 30 100

negative clockc1, c2

90

2 1



l of alock

ebelow

t

e

hes at

ort.

ort.

Data Arrival TimeSignal changes arrive at input ports of a design at certain times. In general, the arrivasignal change at an input port of a block is controlled by the output port of another bwhich is eventually driven by a register or primary input to the design. Therefore, thearrival time of a signal for an input port (also called a data port) is associated with thclock edge that causes the signal change. This is shown schematically in the figure

Figure 5.5 — Associating data arrival at input port with ideal clock

The commandset_data_arrival_time is used to specify the signal arrival time ainput port(s).

set_data_arrival_time ?-lead | -trail? ?-rise | -fall? ?-late | -early? ?-clock clock? time portlist

where

clock is the name of the ideal clock associated with the reg causing changetime is the arrival time, an integer or real constantportlist is the list of ports

Thelead andtrail options refer to the pertinent edge of the ideal clock with which thsignal arrival time is specified. If omitted, it defaults tolead .

Therise andfall options indicate whether the arrival time refers to a rising edge at tinput port or the falling edge. If omitted, the data arrival time applies to both the edgethe input port.

For example,

set_data_arrival_time -clock master -lead -fall 6.4 D

Here, the falling edge transition of the data signal arrives at input portD at 6.4 ns. It isassociated with the leading transition of the ideal clockmaster . Since the rising edgetransition is not specified, it is not considered in the timing analysis.

The clock specification is not necessary when the signal arriving at the output port isgenerated through purely combinational logic.

Early and Late Arrivals

Theearly andlate options refer to the changing of the signal at the input port. Theearly option indicates the earliest time the signal can arrive (change) at the input pThis implies that the signal at the input port will remain stable with its value in theprevious clock cycle at least as long as the specified time.

The late option indicates the latest time the signal can arrive (change) at the input p

clockQ

LogicD

Previous BlockCurrent Module

ck

Reg



ime.

ll as

inputat

t time

theeled

This implies that the signal at the input port will not have a change after the specified t

If this option is omitted, the specified arrival time is taken to be both early time as welate time.

The signal at the input port may change between the early and late times. When an port is driven from multiple paths, it is common to have a fast path and a slow path thcause the change in the signal at the input port. Using theearly andlate options, youcan specify the earliest time when the fast path can change the signal, and the latesthat the slow path can change the signal. The following figure helps explain this

Figure 5.6 — Early and late arrivals of a signal

In the example shown above, let us assume that the input port D has two paths, andsignal atD can change (rising or falling) as early as 5.3 ns due to change on path labpath1 and a falling edge as late as 6.4 ns due to change on path labeledpath2 . Let usalso assume that both paths are associated with the leading edge of the ideal clockmaster . We can describe the situation using twoset_data_arrival_timecommands as follows:

set_data_arrival_time -clock master -lead -early 5.3 Dset_data_arrival_time -clock master -lead -late -fall 6.4 D

Setting Arrival Time for All Inputs

The arrival time at all input ports can be specified usingfind command instead of listingindividual ports. As shown below, thefind command evaluates to a list of all the inputports of a given block.

set_data_arrival_time -clock master 1.6 [find -port -input*]

If an input port is already identified as a clock port usingset_clock_arrival_timecommand, then theset_data_arrival_time command for that port is ignored.

early time late time

Data changes here

data stable data stable

R1

R2

Dout

Logic

path1

path2

previous blockCurrentModule

D



t

sitions,

ed ise) of

put

es the

geh

ut

Conversely, ifset_data_arrival_time command was applied to set arrival time onan input port and later the same port was used to set clock signal arrival time usingset_clock_arrival_time command, the clock arrival time is ignored on the inpuport.

Data Required TimeThe timing information for an output port is described in terms of when the valid datasignal is required to be stable at the output port. This is known as therequired time. Thechange caused at the output port is associated with either a leading or a trailing tranof the master clock. The required time on an output port is specified in absolute timesimilar to the arrival time.

The required time specification applies only to the data signals arriving at the identifioutput ports, where each signal is associated with the specified clock, i.e. the signaldriven by a register that is clocked by the pertinent edge (leading edge or trailing edgthe specified clock.

The required time at the output ports and arrival time at the input ports constrain thedesign from the timing requirements viewpoint. As shown in the figure below, the outportOP can be driven through various paths.

Figure 5.7 — Associating data required time at an output port

The required time atOP is specified using theset_data_required_timecommand. The syntax for theset_data_required_time command is as follows:

set_data_required_time ?-lead | -trail? ?-rise | -fall?? late | -early? ? -clock clock? time portlist

where

clock is the name of the ideal clock that generated the data signaltime is the required time, an integer or real valueportlist is the list of ports

The lead andtrail options refer to the pertinent edge of the ideal clock to which thsignal required time is associated. This is the edge of the clock that eventually causeregister in the current module to change the data signal arriving at the output port. Ifomitted, it defaults tolead .

Therise andfall options indicate whether the required time refers to the rising edat the output port or the falling edge. If omitted, the data required time applies to botedges (transitions) at the output port.

Theearly option indicates that the time specified is the earliest time when the outpport can change, whereas thelate option indicates that the time specified is the latesttime when the output port is allowed to change.

Clock

Inputs OP

Current Module

r Logic



the

port.

e

For example, the command

set_data_required_time -clock master -lead 8.2 OP

requires output portOP of the design to complete its transitions (either rising edge orfalling edge) no later than 8.2 ns absolute time. This requirement is associated with leading edge of the ideal clockmaster .

The clock specification is not necessary when the signal arriving at the output port isgenerated through purely combinational logic.

Recovergence and multiple clock paths

In multi-phase clock designs, there can be different types of data signals arriving at aThese types may differ in the clock or the pertinent edge of the clock that feeds theupstream register that generated the data. The problem is simplified by writing onerequired time constraint for each clock phase.

For example, in the figure shown below, we can specify required times forQ using twoset_data_required_time commands

Figure 5.8 — Multiple clocks and multiple paths controlling data required tim

set_clock phase1 -period 10 -waveform {1 3}set_clock phase2 -period 10 -waveform {7 9}set_clock phase3 -period 10 -waveform {4 6}set_data_required_time -clock phase1 3.9 Qset_data_required_time -clock phase2 13.9 Q

phase1

phase2

Q

phase1, phase2 and phase3 are 10ns period clocks

r

r

phase1

phase3

phase2

phase3

0 10

r

Current Module DownstreamBlock

phase1r

Logic

path1

path2

path3



e to

dt

ingd to.

ing

he

ats at

isterrfortionock.

Here, the first command after the clock definition commands specifies the required timbe 3.9 ns, indicating that the transition atQ(either rising or falling edge) is associated withthe leading edge of the current cycle ofphase1 whereas the 13.9 ns delay in the seconcommand indicates that the transition atQ is associated with the leading edge of the nexcycle ofphase2 .

Note that theset_data_required_time command is used only once even thoughthere are two paths (path1 andpath2 ) from two different registers to output portQ,because both paths are associated with the same edge (lead ) of a clock (phase1 ). Thethird path,path3 , requires a separateset_data_required_time because that pathis associated with a different clock (phase2 ). In general, there is only oneset_data_required_time for all the paths to an output port associated with eachedge of a clock.

External DelayAn alternate way to specify data required time at the output port is to consider the timrequirement of the configuration of the downstream block the output port is connecteIf you know the critical path from the output port of your block to the register of thedownstream block, then you can describe the configuration and the required time usset_external_delay command.

Figure 5.9 — Specifying external delay at an output port

set_external_delay ?-rise | -fall? ?-late | -early? ?-lead | -trail? ?-clock clock? extdly portlist

where

clock is the name of the ideal clock controlling the external registerextdlyis the external delay (including setup), an integer or real constantportlist is the list of ports

The lead or trail options refer to the pertinent edge of the ideal clock controlling texternal register. If omitted, it defaults tolead .

Therise or fall options indicate whether the external delay refers to a rising edgethe output port or the falling edge. If omitted, the external delay applies to both edgethe output port.

The required time at the output port is computed as if the output port is driving a regexternal to the design. The data signal must arrive at the input of the external registe(including setup time) before the arrival of the clock. In other words, the required timedata signal at the output port of your design is calculated by subtracting the propagadelay through the logic from the clock arrival time at the register of the downstream bl

Current Downstream Block

pout Logic

clock

extdly

ExternalRegister

Module



athsthebe

ing

2

For example, the command

set_external_delay -lead clock 4.1 pout

sets external delay of4.1 on the output portpout which is driving the input to a registerthat is controlled by the leading edge of the ideal clockclk .

Note that ifset_data_required_time command andset_external_delaycommand are used on the same output port, onlyset_data_required_time isaccepted. Ifset_data_required_time command is not used, but multipleset_external_delay commands are used, then the worst case required time isestablished for timing analysis.

Multi-cycle PathsAll paths in a design, by default, are considered single cycle paths. However, certain pin the design are multi-cycle paths, i.e. the signal propagation from the start point to end point spans over multiple cycles. The timing information for multi-cycle paths canspecified usingset_cycle_addition command. The command has the followingsyntax:

set_cycle_addition ?-from from_pin? ?-to to_pin? ?-late | -early? ?-rise | -fall? cycle_valuewhere

from_pinis the (hierarchical) port name at the start of the pathto_pin is the (hierarchical) port name at the end of the pathcycle_valueis the number of cycles to add to this path

Thefrom option indicates the port name at the start of the multi-cycle path. All pathsoriginating from thefrom_pinget extra cycles as specified by thecycle_value. This can beviewed as decreasing the arrival time delay at thefrom_pin by the specified number ofcycles.

Theto option indicates the port name at the end of the multi-cycle path. All paths endin to_pin get extra cycles as specified by thecycle_value.

If from option is used without theto option, all paths originating from thefrom_pinwillbe considered as multi-cycle paths with thecycle_value. Thecycle_value is storedunconditionallyat thefrom_pinfor all paths originating at thefrom_pin. For example, thecommand

set_cycle_addition -from I1/Q 2

indicates that all paths from portQof instanceI1 should be considered as 3 cycle paths (additional cycles) as shown in the figure below. Each path may end at different cellinstances in the design. There is only one cycle_valuestored atI1/Q.

Figure 5.10 — Multiple paths starting from pin I1/Q

path1

path2

path3

Q

I1 22

2



1

nal

If to option is used without thefrom option, all paths ending into_pin will beconsidered as multi-cycle paths with thecycle_value. The cycle_value is storedunconditionally at the to_pinfor all paths terminating at theto_pin.For example, thecommand

set_cycle_addition -to I2/A 1

indicates that all paths ending in portA of instanceI2 should be treated as 2 cycle paths (additional cycle) as shown in the figure below. Each path may have originated fromdifferent ports and different module instances. There is only onecycle_value stored atI2/A.

Figure 5.11 — Multiple paths ending at pin I2/A

If both from andto options are used, all paths between thefrom_pin and theto_pin areconsidered as multi-cycle paths with thecycle_value. Thecycle_valueat to_pin is storedconditionallyfor each path originating at the specifiedfrom_pin.Thecycle_value for thepaths terminating at theto_pinthat were specified without thefrom_pin (seeto optionabove) remain stored at theto_pin unconditionally. For example, the command

set_cycle_addition -from I1/Q -to I2/A 2

indicates that bothpath1 andpath2 between portQ of instanceI1 and portA ofinstanceI2 are 2 cycle paths as shown in the figure below. This will decrease the sigarrival time at portA by 2 cycles.

Figure 5.12 — Multiple paths between pins I1/Q and I2/A

Note that if oneset_cycle_addition command is used with onlyto option, andanotherset_cycle_addition command is used with bothto andfrom options atthe sameto_pin (irrespective of the order in which they are executed), then the pathbetween thefrom_pin and theto_pin has two differentcycle_values. For this particularpath, thecycle_value specified in the command withfrom andto options will overridethecycle_value at stored at theto_pin specified in the command with onlyto option.When a path is defined either with onlyto option, or with bothfrom andto options, thecycle_value is stored at theto_pin; thefrom_pin is not affected.

During the timing analysis phase, thecycle_value stored atfrom_pins andto_pins areadded to the signal arrival times.

path1

path2

path3

A

I211

1

path1AQ

I1 I2path2



rts

.

Consider the block diagram shown below. Let us assume that all paths from portA ofinstanceI1 are two cycle paths (p3 , p4 , p5) and all paths ending in portB of instanceI2are also 2 cycle paths (p1 , p2 , p3). Let us further assume that all paths between the poA andB are single cycle paths (p3).

Figure 5.13 — Describing multi-cycle paths

We can describe these multi-cycle paths using threeset_cycle_additioncommands as follows:

set_cycle_addition -from I1/A 1 // affects p3, p4, p5set_cycle_addition -to I2/B 1 // affects p1, p2, p3set_cycle_addition -from I1/A -to I2/B -1

// overrides p3 at I2/B

The first command indicates that all paths starting at portI1/A are 2 cycle paths (p3,p4, p5 ), decreasing the arrival time at portI1/A for all paths by 1 cycle. Thecycle_value for these three paths is stored unconditionally at the portI1/A . The tablebelow describes thecycle_value stored at each port after the first command is executedThere is nocycle_valuestored at the portI1/A for pathsp1 andp2 . Thecycle_valueatthe portI2/B is not affected

Table 5.1 — cycle_value stored at from_pin (after first command).

The second command indicates that all paths ending in portI2/B are 2 cycle paths (p1,p2, p3 ), decreasing the arrival time at portI2/B for all paths by 1 cycle. Thecycle_value for these three paths is stored unconditionally at the portI2/B .This would

causeI1/A →I2/B path (p3) to have decreased the arrival times twice.

Path

Ports

I1/A I2/B

p1 - -

p2 - -

p3 1 -

p4 1 -

p5 1 -

- indicates no change (initialized to 0)

A

CB

D

I3I2

I4

I1

p1

p2

p3

p4

p5



is

e

e.

iver)

The table below describes thecycle_valuestored at each port after the second commandexecuted.

Table 5.2 — cycle_value stored at to_pin (after second command)

The third command overrides the unconditionalcycle_value specified at theto_pin for allthe specific paths ending at theto_pin. The paths not identified by the third command arnot affected. Therefore, thecycle_value at the portI2/B will now be replaced with -1 asspecified in the third command. The reason we chose -1 as cycle time is that after

overriding thecycle_valueat the portI2/B , we want the path fromI1/A →I2/B (p3) tobe a single cycle path, i.e. the sum of the two cycle values (atI1/A andI2/B ) should bezero. The table below describes thecycle_value stored at each port and the net effect onthe path after the third command is executed

Table 5.3 — cycle_value stored at from_pin and to_pin (after third command).

Setting Drive Cell for Input PortsIn order to accurately model the drive capability of an external driver connected to thinput port, you should identify the library cell that drives the input port of your designThis helps decide how many loads can be driven directly from the input port withoutcreating too large a load (and therefore an increased slew time). If the library cell (drhas multiple output ports, then the output port connection must be identified.

PathPorts

I1/A I2/B

p1 - 1

p2 - 1

p3 1 1

p4 1 -

p5 1 -

- indicates no change due to this command

Path

Ports

I1/A I2/Bnet effect(extra cycles)

p1 - 1 1

p2 - 1 1

p3 1 -1 0

p4 1 - 1

p5 1 - 1

- indicates no change due to this command



ed,lated

loth

utme

ne

put Ifs atll.

The driver cell information is known to you if the upstream block was already synthesizor a decision was already made to use certain drivers due to various circuit design reissues.

Figure 5.14 — Selecting a driver for input port

Theset_drive_cell command has the following syntax:

set_drive_cell ?-early|-late? ?-cell cellname??-cell_rise cellname? ?-cell_fall cellname??-library libname? ?-library_rise libname??-library_fall libname? ?-pin pinname? ?-pin_rise pinname??-pin_fall pinname? ?-from_pin fpinname??-from_pin_rise fpinname? ?-from_pin_fall fpinname??-source_edge_rise R|F? ?-source_edge_fall R|F? portlistwhere

cellname is the name of the driver celllibname is the library name of the driver cellpinname is the name of the output pin (port) of the driver cellfpinname is the name of the input pin (port) that has an arc to the output pinportlist is the list of ports driven by the driver

The late or early options specify whether the driver provides an early or late signaarrival at the input port of your design. If it is not specified, the driver is considered in bearly and late timing analysis.

Thecell options specify whether the driver specified by thecellname is providing arising transition driver (-cell_rise cellname), a falling transition driver (-cell_fall cellname), or both (-cell cellname). Thus, it is possible to distinguish thecells that provide drivers for specific transitions. One of the three (-cell , -cell_rise , -cell_fall ) options must be specified.

Thelibrary options specify the name of the library (libname) which contains the drivercell. If one driver cell is causing both the rising and falling edge transitions at the inpport, or different driver cells are causing the transitions but they both belong to the salibrary, only the-library option is needed. If the driver cells causing the rising andfalling edge transitions at the input port belong to different libraries,-library_riseand-library_fall options must be used to identify the specific libraries. If only olibrary is used in the design, the library name need not be specified.

Thepin option specifies the output port of the driver cell that drives the signal at the inport of your design. This option is required if the driver cell has multiple output ports.the output pin (port) of the driver cell causes both the rising and falling edge transitionthe input port, the-pin option should be used to identify the output port of the driver ce

Current ModuleExternalDrivers



heits

e.

er to

en at

hean

to

igh)l toned

If a port of the driver cell is causing only a rising edge or falling edge transition,-pin_rise or -pin_fall option should be used to identify the port namerespectively.

Thefrom_pin option specifies the input port of the driver cell that has a controllingtiming arc to the output port of the driver cell which is connected to the input port of tdesign. This option is required if there are multiple timing arcs in the driver cell from input ports to its output port(s). As with the other options,-from_pin_rise and-from_pin_fall options can be used to distinguish the controlling timing arc thatcauses a rising edge or a falling a edge transition at the input port.

Thesource_edge_rise option specifies whether the rising edge (R) or falling edg(F) at thefrompin is controlling the rising edge transition at the input port of the designThesource_edge_fall option specifies whether the rising edge (R) or fallingedge(F) at thefrompin is controlling the falling edge transition at the input port of thedesign.

Setting Drive ResistanceA simpler form of theset_drive_cell command calledset_drive_resistance can be used in many situations where the drive resistanccan be specified. The arrival time at the input port is modified by adding the RC factothe specified arrival time at the input port. The RC constant is the capacitance as sethe input port multiplied by the drive resistance.

The syntax for theset_drive_resistance command is

set_drive_resistance ?-rise | -fall? ?-early | -late? valueportlistwhere

value is the resistance valueportlist is the list of input ports for which drive resistance is specified

Therise or fall options indicate whether the drive resistance is applicable to only trising edge or falling edge transition at the input port. If this option is not specified ththe drive resistance is applied to both transitions at the input port.

Theearly or late options indicate whether the drive resistance should be applied the early arrival time or the late arrival time for timing analysis.

Slew Related CommandsSlew is a measure of the slope of an arriving signal. For a signal changing from low (hto high (low), slew time is represented by the time it takes to reach from low (high) levehigh (low) level. It is a common practice to consider the change between two predefithresholds around the two levels, e.g. 20% and 80%.



than

n by.

gl

ast

g

n is

Figure 5.15 — Rising and falling edges of a signal

There are two commands related to slew -set_slew_time_limit andset_slew_propagation_mode .

Setting Slew Limit

Design rules of a process requires that slew time at each input and output port be lesscertain predefined limit. This is set using theset_slew_time_limit command.

set_slew_time_limit slewlimit portlist

whereslewlimitindicates maximum slew allowed, an integer or real constantportlist is thelist of ports with specifiedslewlimit.

For example,

set_slew_time_limit 2.3 {bus1 bus2}

Here, the slew limit forbus1 andbus2 are set at2.3 , i.e. the slew of a signal atbus1 orbus2 cannot exceed2.3 . The slew limit is usually derived from the design ruleconstraints placed on the cells that the output port is driving or the input port is drive

Setting Slew Propagation Mode

Three slew propagation modes are available to perform static timing analysis. Thesemodes are:fast ; critical_slew ; andworst_slew . The slew propagation mode ischanged using the global variable:

set_global slew_propagation_mode {fast | critical_slew |worst_slew}

Theslew_propagation_mode is changed to fast when any transform that performs timinoptimization automatically is invoked. Fast mode timing, by default, does not use celinput slews to affect cell output slews. In contrast,critical_slew andworst_slew modespropagate output slew through all logic levels.

The effect of output slew on input slew can be increased up to three logic levels for fslew propagation mode. Path timing converges toworst_slew timing with increases inslew propagation depth for fast mode. The command to control this is:

set_global depth_for_fast_slew_prop {0 | 1 | 2 | 3}The default for this global variable is 0.

It is recommended that the default value for thedepth_for_fast_slew_prop globalvariable (0) be used during initial optimization of a design to correct the coarse timinproblems. This can be followed with an increase in thedepth_for_fast_slew_prop

number and a timing correction transform on the circuit. Two levels of slew propagationormally adequate to achieve good (1-2%) path timing correlation between fast andaccurate slew propagation mode.

20% 80% 20% 80%

Slew is the slope of the signal from 20% of target level to 80%

rising edge on a signal falling edge on a signal



thetion

but ishe

, thetivelyepth

w

fast

g

tedofived

Below is a partial tcl script outlining this flow:

... do_build_generic source top_constraints.tcl do_optimize-no_design_rule set_global depth_for_fast_slew_prop 2do_xform_timing_correction ...

Fast Slew Propagation Mode

Fast Slew Propagation Mode, by default, calculates the output slews independent ofinput slews. The output slews are based only on the drive strength of the cell in quesand on the loading conditions on the output pin. This mode has the fastest runtime, the least accurate in terms of results. To set the slew propagation mode to fast use tfollowing command:

set_global slew_propagation_mode fast

Figure 5.16 — Gate Delay Diagram

To make the cell output slews dependent on the input slews, in fast slew propagationmode, use the command:

set_global depth_for_fast_slew_prop <depth>

Set the value for depth to 1, 2, or 3. The default value is 0. Using depths of 1, 2, or 3input slew dependency on output slew is propagated 1, 2, or 3 levels of logic respecbut then assumed to have no affect on further levels. Timing accuracy increases as dincreases. Output slews are calculated in the same manner used to calculate theworst_slew slew propagation mode, where the worst input slew affects the output sleregardless of the critical path through the cell.

Timing optimization transforms automatically change the slew_propagation_mode tobut do not modify the depth_for_fast_slew_prop setting.

Worst Slew Propagation Mode

Two methods of accurate slew propagation are available in BuildGates. These are:

• Worst slew propagation mode

• Critical slew propagation mode

There is no limit on the number of logic levels an output slew can propagate for timincalculations for both of these modes, as with fast mode.

The worst slew propagation mode is set using the following command:

set_global slew_propagation_mode worst_slew

Using this mode, the effect of the input slew on the output slew for all arcs is calculaand then the worst slew effect is combined into the output slew along with the effect output loading. In this way if the worst slew effect is associated with an input that arrmuch earlier than the other inputs, that slew effect is still used.

(1, 10)

(2, 2)

(delay, slew)

delay: 1

delay: 1

a

b(3, fslew (output load))



st ofed the

des

ngther

. This,ant the

This algorithm is more pessimistic than the critical slew propagation mode describedbelow.

In the figure below, although the arrival time at inputa is earlier than atb, as the input slewis so much greater fora, the effect on the output slew from inputa will probably be worsethan the effect from inputb and thus the effect froma will be used.

Figure 5.17 — Accurate Slew Propagation Mode

Critical Slew Propagation Mode

In addition to the worst slew propagation mode described above, BuildGates containanother algorithm called critical_slew. Using critical slew propagation mode, the effecthe input slew from the latest arriving signal along with the effect of output loading is usto calculate the total output slew. In the figure below, the effect of the input slew fromlatest arriving signal, (2, 2), is used in the output slew calculation.

Figure 5.18 — Critical Slew Propagation Mode

Technology and Design Rule ConstraintsA technology library contains both functional and timing information. The functionalinformation is represented using operators and equations. The timing information incluspecification of propagation delays within each cell and wire delays. During the cellselection process in logic synthesis, these delays are used to ensure that all the timirequirements (constraints) are met. However, for accurate timing analysis, various oaspects must be accounted for their impact on delay calculations, e.g. variation inoperating condition, wire loads, fanout, etc. This section describesac_shell commandsthat allow the user to provide such information.

Operating ConditionThe technology library contains timing data about all the cells at nominal voltage,temperature and process. Any variation in these conditions must be reflected in howvarious factors such as resistance, capacitance, propagation delay, etc. are affectedin turn, affects the selection of the cells during synthesis process. Hence, it is importthat the operating condition be specified for a particular synthesis run to approximatereal circumstances under which the design will be used.

(1, 10)

(2, 2)

(arrival time, slew)

delay: 1

delay: 1

a

b

(3, fslew (output load) with

worst of [fslew(1, 10) & fslew(2,2)] )

(1, 10)

(2, 2)

(arrival time, slew)

delay: 1

delay: 1

a

b(3, fslew (output load) & fslew(2, 2) )



.

ates)

s,

of the

hese

ad andutedariessign.ign

i.e.ined

on

Each technology library contains one or more operating conditions. Theset_operating_condition command is used for setting the operating conditionEach operating condition is identified by name, which specifies process, voltage andtemperature as the operating condition. This information is used in calculating accurcell delays from the nominal cell delays and the k-factors (also called derating factorusing eitherlinear model ornon-linear model.

The syntax for the command is

set_operating_conditions ?-library libname? opercondname

where

libnameis the name of the libraryopercondnameis the name of the operating condition

If only one technology library is used, the library option need not be specified.

Estimating Capacitance and ResistanceThe delay information in the technology library applies to the cells themselves; that itiming arcs from input ports to output ports of each cell and the wire delays. The celldelays and the wire delays are expressed as a function of the physical characteristicsnets in the design such as wire capacitance and wire resistance. In order to performmeaningful analysis before physical design, these parameters must be estimated. Testimates are derived from the models called wire load models.

There are two commands available inac_shell that affect wire load model determination:set_wire_load andset_wire_load_mode .

set_wire_load command

The technology library contains information about different wire load models. A wire lomodel is a function that uses the fanout count of a net and estimates its capacitanceresistance. A technology library contains different wire load models that are pre-compbased on the analysis of several designs differing in area. Usually, the technology librhave an area lookup table that gives the wire load model for a given cell area of a deAdditionally, the floor planning tools may determine specific wire load model for a desbased on an initial physical design. These wire load models can be read in usingread_library_update command.

The wire load can be set on the current module using theset_wire_load command.The syntax of the command is as follows:

set_wire_load ?-library libname? wload

where

libnameis name of the librarywload is the name of the wire load table in the library

This command applies to the module that is set as the current module usingset_current_module command, and the wire load estimation is applied using thelookup table to all the nets in the current module. If wire load model is not specified (no lookup table), then the delays are estimated based on the a wire load model determfrom the area of the current module. See Appendix C for the wire load model selectialgorithm.



ire

pireable

put or

ectedtancell asce

ving this

set_wire_load_mode command

In the absence of user specified wire load model, theset_wire_load_mode commandcontrols the determination of the wire model. There are two ways of determining the wload model. The syntax for the command is

set_wire_load_mode modename

wheremodename is enclosed or top .

If enclosed mode is specified, the wire load model is selected using an area lookutable for the module at the lowest level in design hierarchy that contains the entire w(net). If top mode is specified, the wire load model is selected using the area lookup tof the top level module (as set byset_timing_top_module command). The defaultwire load selection mode istop .

Port CapacitanceThe port capacitance refers to the capacitance external to the design as seen by the inoutput port of the design.

The capacitance at any port is the sum of external port capacitances the port is connto (See figure below). For an input port (A), the port capacitance refers to the capaciof all the ports of the drivers on the net that connects to the input port (C1, C2) as wecapacitance of other loads on the net (C3). For an output port (Q), the port capacitanrefers to the capacitance of the all the input ports of the cells that the output port is dri(C5, C6), as well as the capacitance of the input port of any other external drivers onnet (C4)

Figure 5.19 — Distributed capacitance at input and output ports

Theset_port_capacitance command can be used for setting capacitance on aninput port or an output port. The syntax is as follows:

set_port_capacitance cap portlist

where

cap is the capacitance valueportlist is the list of ports with this capacitance

A Q

C1

C2

C5

C6Port_cap(A) = C1 + C2 + C3Port_cap(Q) = C4 + C5 + C6

Current Module

C3 C4



han a

y

istors port

the

e netally the

ay beand:

Capacitance LimitDue to design rule requirements, each cell can not drive nets with more capacitance tpredetermined limit. This information is available in the cell library. Theset_port_capacitance_limit command can be used to specify this limit on aninput or output port.

set_port_capacitance_limit cap_limit portlist

where

cap_limit is the capacitance limitportlist is the list of ports with this capacitance limit

FanoutThe input ports of each cell have fanout loads that are related to the number of transconnected to the port in the cell. Similar to setting port capacitance, fanout load of acan be set using theset_fanout_load command as follows:

set_fanout_load load portlistwhere

load is the total fanout load external to the designportlist is the list of ports with this load

While the port capacitance affects timing analysis, fanout loads are used to enforce design rule checks.

Fanout LimitDue to design rule requirements, a port may not have fanout load more than certainpredefined limit. Theset_fanout_load_limit command can be used to set thislimit on input and output ports as follows:

set_ f anout_load_limit load_limit portlistwhere

load_limit is the fanout load limitportlist is the list of ports with this fanout load limit

External Sources and SinksExternal sources and sinks at a port specifies the number of sources and sinks to thconnected to the port that are external to the design. If you set the number of externsources or sinks on a port, then the port capacitance for such a port should include onexternal port capacitances. This is because the total wire capacitance of a net will becorrectly computed using the asserted external sources and sinks. This command momitted if the port capacitance includes internal wire capacitances. Using this commresults in an accurate delay computation. The syntax for the commands is as follows

set_num_external_sources num portlistset_num_external_sinks num portlistwhere

numis the number of sources or sinksportlist is the list of ports with given number of sources or sinks



h netand

t afters

Wire CapacitanceAfter the physical design has been done, you can back-annotate capacitance on eacand re-analyze the netlist for timing The syntax for setting the wire capacitance commis as follows:

set_wire_capacitance cap netnameswhere

cap is the wire capacitance

netnames is a list of nets with this capacitance.

Figure 5.20 — Wire Capacitance

Wire ResistanceSimilar to the capacitance specification, you can also specify resistance for each nethe physical design is done. The syntax for setting the wire resistance command is afollows:

set_wire_resistance res netnames

where

res is resistancenetnames is a list of nets with this resistance

If accurate resistance information at the source and the sink is also available, theset_distributed_wire_resistance can be used as follows:

set_distributed_wire_resistance ?-source_resistance value??-sink_resistance value? netnameswhere

valuerefers to resistance value at source or sinknetname is is the list of nets

Source Sink

net capsource cap sink cap

source res sink res





to

suchndent

eost-ort

f

6Optimization

OverviewThis chapter describes the flow and the commands used with Ambit’s synthesis toolsinvoke and control various optimization stages to produce a desired netlist. Logicoptimization plays a key role in the synthesis process. It consists of several processesas boolean transformations, flattening, structuring, technology independent and depemapping, hierarchical optimization, context derivation, etc.

There are several methods used to synthesize large designs. These methods includhierarchical optimization, context-based optimization, incremental optimization, and pplacement (in-place optimize) optimization. Various commands are provided to suppthese methods based on design requirements, complexity, partitioning and designerpreferences.

We will use the following hierarchical block diagram of a design to illustrate the use ovarious commands in this chapter.

Figure 6.1 - Hierarchy of an example block

des_top

unit1 unit2

blk11 blk12 blk21 blk22 blk23



n thed forlly

les at. Thedtext

they

tions,ers,

Optimization ApproachesAmbit synthesis tools support four different optimization strategies and allows mixingthese strategies as necessary.

Hierarchical OptimizationIf a design is small, all constraints can be set up at the top level of the design and theentire design can be optimized at once. Internally, the design is flattened with no regarthe hierarchy, and the optimization is done for the top level module without individuaoptimizing any lower level modules.

The following optimization commands are useful:

do_build_genericdo_optimizeset_dont_modifydo_dissolvedo_uniquely_instantiate

Context Based OptimizationWhen a design is large, the synthesis process must be carried out iteratively on moduthe lower levels of design hierarchy and then top level synthesis must be carried outconstraints are still applied at the top level of the design, but each module is providerelevant constraints on its input and output ports by deriving constraints from the conof the module in the overall design hierarchy.


do_build_genericdo_derive_contextdo_uniquely_instantiateset_dont_modifydo_optimize

Incremental OptimizationIn full design optimization, the synthesis is started without any gate level structures; are built from scratch and mapped to the target technology. If the design has beensynthesized once, the quality of design can be improved using incremental optimizaapproach. Certain portions of the design (e.g. combinational logic, clock net, registeretc.) can be extracted from the netlist and specific transformations (e.g. resizing drivfixing hold time) can be applied to guide the tool for specific improvements.


do_extractdo_xform_timing_correctiondo_xform_optimize_slackdo_xform_fix_design_rule_violationsdo_xform_fix_holddo_xform_mapdo_xform_resizedo_xform_structure



can

ringcan

r

ofof

ogyens.rax is

ch areth the

Post-placement OptimizationOnce the netlist goes through placement and routing, accurate wire length informationbe extracted and translated to wire delay. In turn, this information, stored in StandardDelay Format (SDF) file, can be used to further optimize the design through restructuand altering cell selections. From floorplanning and placement tools, wire load modelsalso be extracted and fed into synthesis tool for better optimization.

Additionally, cells with higher drives may replace the cells with lower drives to meet oimprove on the timing constraints. This is also referred to as in-place optimization.


do_xform_footprintread_sdfread_library_update

Module SelectionThe commands described in this chapter operate on an individual instance, a group instances or module descriptions. When a command specifies an instance (or a list instances), the action only affects that instance. If an instance is not specified as anargument, the command is applied to the current module as set by theset_current_module command. For further information on this command, seeSetting a Hierarchical Context in the Setting Constraints chapter.

For example, we can setdes_top as current module using the following command:

set_current_module des_top

As needed, we can setunit1 or unit2 as the current module to apply specificconstraints or transformations to just that module.

set_current_module unit1…commands for unit1…set_current_module unit2…commands for unit2…

Building Technology Independent NetlistLogic synthesis process can be thought of in two steps - technology independentoptimization followed by technology dependent mapping and optimization.

After HDL modules are read, the functions (operations) are mapped to Ambit TechnolLibrary (ATL) cells and eXtended Ambit Technology Library (XATL) cells. Some of thcomplex operations (e.g. addition, subtraction, increment) are also mapped to cells iAmbit Component Library (ACL). All three libraries are technology independent librarieThe command generates a technology independent netlist and provides the basis foperforming technology independent optimizations on the designs. The command syntas follows:

do_build_generic -group_all_processes? ?-group_named_processes? ?-group_process name_list? ?-group_subprograms?

For all the modules read in,ac_shellwill create the netlist mapped to cells in ATL, XATLand ACL libraries. If a module description has not been read in but the instance of sumodules exist in other module descriptions that make up the design, such instancestreated as black boxes until the corresponding modules have been read and linked wirest of the design.



el to

ir

er

mand

t

etputnent.

hy

dtion

The four grouping options allow creation of a hierarchy at process or subprogram levmaintain logical partitions.

Dealing with HierarchyWhile synthesizing hierarchical designs, it is necessary to deal with modules and theinstances for best results. The following capabilities are provided inac_shellto selectivelyhandle optimization of hierarchical designs:

• Ability to preserve a moduleas is

• Ability to treat one, some, or all of the instances of a module in a unique mann

• Ability to collapse one or more levels of hierarchy at or below the top module

The following sections describeac_shell commands that provide these capabilities.

Preserving Module ContentsIf certain modules, instances or nets have been optimized in the design, use the comset_dont_modify to preserve the logic netlist. No further optimization or otherchanges will be done on the specified module, instance or net.

The command syntax is as follows:

set_dont_modify -network ?-hierarchical? portlistset_dont_modify ?-hierarchical? modulelistset_dont_modify instancelistwhere

portlist is the list of ports (of current module) to preserveas is.modulelist is the list of modules to preserveas is.instancelist is the list of instances to preserveas is.

In the first form of theset_dont_modify command, one or more ports of the currenmodule are specified. The ports must be eitherinput or inout ports. The networkconnected to each port is identified by traversing forward all the nets starting from thport, going through the combinational cells the nets connect to, and following the ounets of the combinational cells until reaching a sequential cell or a black-box compoAll the nets and components on the network are marked for preservation during theoptimization phase.

If hierarchical option is used, the traversal is continued at lower levels of hierarcin the current module to preserve the network. Ifhierarchical option is not used, thenetwork visible only at the current module is preserved, but the network inside thehierarchical instances in the current module may be modified.

Frequently, the clock network or reset network is designed manually (i.e. routing, loabalancing, etc.) due to its global nature and must be preserved through the optimizaprocess. For example, consider the block diagram shown below. The effect of thefollowing command is shown by the highlighted path in Figure 6-2:

set_dont_modify -network -hierarchical rst



the

dule

r no

le to

om

by

edach

Figure 6.2 - Example of preserving a net using set_dont_modify command

If hierarchical option was not used in the example above, the highlighted path ininstanceI4 (shown by the dotted line), and the netsn1 andn2 will not be marked forpreservation.

If we want to preserve the clock network (connected toclk port) indes_top and itssubmodules, we can use the following command:

set_dont_modify -network -hierarchical clk

In the second form of the command, instead of preserving the network, the entire mois marked for no modification during the optimization phase. Ifhierarchical optionis used, all the instances in the current module are traversed recursively and thecorresponding modules are marked for no modification. Once a module is marked fomodifications, you cannot applydo_uniquely_instantiate or do_dissolvecommands on such a module.

This form of the command is useful when you have designed and optimized a moduyour satisfaction and would not want any further changes in it. This command is alsohelpful when you have identified any cells (e.g. macros, mega-functions, RAM, etc.) frthe library that you want to instantiate and preserve without any modifications.

For example, if you do not want hand-built RAM module to be modified duringoptimization, you can use the command

set_dont_modify -hierarchical myRAM

In the third form of this command, one or more instances can be specified which aremarked for no modification. Only the instances are marked, the modules referencedthese instances are not marked.

For example, ifblk22 is an instance of a counter that you want to preserve in thehierarchy, you can use the command as follows:

set_dont_modify blk22

Treating Instances UniquelyWhen a module has more than one instance in the design, each instance may havedifferent environment around it. In such cases, one instance may have to be optimizdifferently from another by placing different constraints on each of them. Therefore, einstance must be uniquely associated with a module.

rst

I1 I2

I3

I4

n1

n2



ted on

e in

e

ar as

er

,

icthical the

ave

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

do_uniquely_instantiate ?-hierarchical | instancelist?

whereinstancelistis a list of instances that will be instantiated uniquely.

Each instance in theinstancelist is now referenced by a unique module, so that differenconstraints can be applied on each module, and different transforms may be performeach module.

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

If instancelist is not specified, unique modules will be generated for all instances of thcurrent module as set byset_current_module command. The modules that haveinstances of the current module will be modified to reflect the change in binding theinstances to their respective unique modules.

For example, ifblk11 andblk23 are instances of an adder (mod_adder ) that needdifferent constraints during optimization, we can use

do_uniquely_instantiate blk11 blk23

After the unique module names have been generated, the two instances would appefollows:

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

wheremod_adder_0 andmod_adder_1 are the names of the unique addermodules created frommod_adder .

All timing optimizations can be performed on an instance only if it is uniquelyinstantiated.

Collapsing HierarchyOnce each of the modules is synthesized and meets its respective constraints, furthoptimization may be possible at the next higher level in the hierarchy. Typicaloptimizations include merging of inverters at the boundary, using different driver cellsetc. Thedo_dissolve command unpreserves the module boundaries. The commandsyntax is as follows:

do_dissolve ?-hierarchical | instancelist?

whereinstancelistis a list of instances that will be dissolved to their respectiveparent modules.

Each instance in theinstancelist is expanded into its parent module such that all the login the instance is now in the parent module. The new names of the cells in the parenmodule are derived by appending a number to the original instance name. The hierarccomponents inside the modules referenced by the instances are now components incurrent module.

If hierarchical option is used, all hierarchical components will be recursivelyexpanded to flatten the current module. After expansion, the current module will only hinstances of the library cells and instances of the modules marked byset_dont_modify command.

If instancelist is not specified andhierarchical option is not specified, all instancesof the current module will be expanded in their respective parent modules.



les.

ce by

theuse

nds.ogy

re met.ic-10

he

For example, if we decide to dissolve unit2 in the design, we can use

do_dissolve [find -instance unit2]

The new design will appear as shown in the block diagram below:

Figure 6.3 - Design hierarchy after dissolving unit2

If des_top was set as current module,

do_dissolve -hierarchical

command would dissolveunit1 andunit2 instances and the leaf cellsblk11 ,blk12 , blk21 , blk22 , andblk23 will become direct children ofdes_top . Theinstance names of the new children will be derived from their respective parent moduIf blk11 , blk12 etc. were not leaf cells, then the process of dissolving will continueuntil the leaf cells become direct children ofdes_top module.

Once dissolved, constraints can not be placed on the instance since there is no instanthat name in the design.

Optimizing DesignAfter reading the RTL model of the design and the target technology file, and applyingconstraints, you are ready for design optimization. The straight forward approach is todo_optimize command. There are various other commands known asdo_xformcommands that allow you finer control of the optimization process.

The diagram below shows the steps carried out by thedo_optimize command. Thefirst step, technology independent optimizations, includes logic factoring, flattening arestructuring. It generates a technology independent netlist using ATL and XATL cellThe second step then maps this technology independent netlist to a specific technollibrary and performs technology specific optimization.

The constraints are checked against the netlist to ensure that all the requirements aIf some of the constraints are not met, transformations for timing corrections and logrestructuring are applied on the netlist. (See “Applying Timing Corrections” on page 6for further details on various transformations. Also see thedo_timing_correctioncommand). After these transformations are done, if any design rules are violated in tnetlist, they will be fixed.

des_top

unit1

blk11 blk12

unit2_blk21 unit2_blk22 unit2_blk23



e

s be

e

is as

Figure 6.4 - Steps carried out by do_optimize command

Thedo_optimize command applies to the current module downward as set by theset_current_module command. The result of the optimization step is stored in thdatabase, and must be retrieved usingreport andwrite group of commands.

Prior to starting optimization, you must set target technology library. Seeread_alf ,read_library_update , andset_target_technology commands.

The syntax of thedo_optimize command can be found in the BuildGates CommandReference Manual.:

Deriving Constraints from ContextContext based optimization approach requires that constraints for lower level modulederived from the higher level modules. This is one of the fundamental capabilities forperforming top-down, hierarchical synthesis. The constraints set at the top level of thdesign are pushed down the hierarchy so that each of the lower level modules areoptimized with the correct set of constraints. Later, as the higher level modules arestitched together, the optimized modules are all in agreement with their respectiveconnections.

The syntax for the command to derive constraints from each instance’s environmentfollows:

do_derive_context ? instancelist?

whereinstancelist is a list of instances for which the context is derived.

The context is derived by extracting three types of constraints - interface timingconstraints, electrical constraints, and logic value constraints - from the surroundingenvironment of the instances in theinstancelist.

Technology Independent

Optimizations

Technology DependentMapping & Optimizations

Constraintsmet?

Timing Corrections &Logic Restructuring

Fix Design Rule Violations

Yes

No



vald

, and

rivediated

es

f

raryker

This, or

tingting

s.

st thetimethan

es intal

The interface timing constraints include timing information about clock definitions, arritime on input ports, required time on output ports, and identification of multi-cycle anfalse paths.

The electrical constraints include port capacitance and resistance, number of driversload for every port of every instance.

The logic value constraints set attributes on ports that specify whether the port isconnected, unconnected, inverted, tied to logic0 or logic1.

If instancelist is not provided, context is derived for all the instances in the currentmodule.

The instance name may be a hierarchical path name, in which case the context is deonly for that instance in the hierarchy. The instance must have been uniquely instantusing thedo_uniquely_instantiate command if the module it references hasmore than one instances.

The derived context information is stored in the database. The commandwrite_assertions must be executed to store the constraints on individual instancfor later use.

Time BudgetingTime budgeting is a unique feature inac_shellthat allows the user to do time budgeting olarge blocks with considerable ease.

Time budgeting allows the user come up with initial time budgets better than an arbitstarting point. This allows the design to be synthesized with fewer iterations and quicconvergence to target performance.

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

do_time_budget list_of_instances

wherelist_of_instances is a list of instances that will be resynthesized after thetime budgeting has been done.

If some of the blocks in the design can not be changed, (therefore, will not beresynthesized), they should be left out from the list of instances to do time budget on.situation arises when certain blocks are treated as “Intellectual Property” (IP) blocksneed to be retained “as is” for various legacy or compatibility reasons.

The synthesis strategy with time budgeting is similar to characterizing the blocks, wriscripts and resynthesizing the blocks. The significant difference is that the time budgealgorithm automatically distributes the slack evenly on paths across multiple moduleThese new constraints are written out in a script form usingwrite_assertionscommand for next iteration of synthesis. The slack distribution strategy employed bydo_time_budget command reduces the number of synthesis iterations required toreach the target.

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

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



ts are

ritten

ngg of

mens.

ons.

dek of

It is possible to use theset_data_budget_time command to force arrival andrequired times on particular pins. Such situations arise when hard coded time budgerequired due to specific design requirements. When time budgeting is performed, theforced values will override the automatic slack allocation, thereby providing manualcontrol over the automatic time budgets.

For example, in the diagram below, ifpath1 has a positive slack of 3ns and the delaythroughI1 is twice as long as the delay throughI2 , the required time forI1/p1 will getpositive slack of 2ns andI2/p2 will get positive slack of 1ns.

Figure 6.5 - do_time_budget

If we forced delay atI2/p2 port to be 2ns (usingset_data_budget_timecommand), then the arrival time will have a slack of only 1ns atI1/p1 .

Thedo_time_budget command generates (derives) constraints for all ports of theinstances in the instance list and saves it in the database. These constraints must be wout usingwrite_assertions command. The new constraints files must be used toresynthesize the instancesI1 , I2 , I4 , andI5 .

The time budgeting is applied to the entire hierarchy below current top level.

Applying Timing CorrectionsOnce the design is synthesized, certain amount of fine tuning can be done by applyispecific transformations to the netlist. One such transformation is to improve on timinthe critical path usingdo_xform_timing_correction command. The timing correctionsfor improving and for fixing late slack are already applied as part of thedo_optimize

command. Additional transformation may only be necessary if you were to extract sologic and make changes on it or want to fix hold time violations or design rule violatioThis command supports incremental optimization strategy.

There are three basic transformations performed by thedo_timing_correction

command: resizing, buffering, and cloning. The default is to try all three transformatiThe transformations are applied to the cells on the critical path in the current moduledownwards as set byset_current_module command. The transformations are performeas long as the quality of the netlist improves in terms of improving timing slack on thpaths that violated timing the most or improving area without worsening the worst slacthe network.

positive slack path

negative slack path

I1 I2 I3

I4 I5

do_time_budget { I1 I2 I4 I5 } // I3 is an IP block

path1

path2

p1 p2



lack.

maylackueto thece

be as

minglay

,

e

the

e

Typically, each transformation adds or replaces cells to the network to improve the sAt the end of the transformation step, not all cells added or replaced for thetransformations may be necessary to improve the slack time. Hence, some of the cellsbe removed or replaced with smaller cells that do not affect the improvement in the stime, thereby reclaiming the area associated with these cells. These iterations continuntil no further changes can be made to the netlist or no improvement can be made worst slack. The command syntax can be found in the BuildGates Command referenManual.

Physical Tool Data

Reading SDF DataThe delay data extracted from a physical tool such as a floorplanner or a router can imported using the Standard Delay Format (SDF) file. The syntax of the command isfollows:

read_sdf filenamewherefilename is the name of the SDF file.

The design name in the SDF file must match the name of the current module. The tidata from SDF file is applied to the current module and its hierarchy. Both the cell dedata and the interconnect delay data are backannotated in the netlist. The minimumtypical and maximum delays are used from the SDF file. The backannotated delaysoverwrite the delays in the netlist database.

The name matching (of ports, nets, cells and instances) between the SDF file and thnetlist database is case sensitive.

Reading Library Updatesread_library_update filename ?-library libname? ?-wireloads? ?-operating_conditions? ?-cells?where

filename is the name of the ASCII library filelibname is the name of the library to be updated

This command allows updating of wire load, operating condition, and cell specificinformation from the filefilename.

The library option indicates the library identified bylibname needs updating. Iflibrary option is not used, the target technology library identified by theset_target_technology command is updated.

If wireloads option is used then the wireload models from the filefilenameare used forupdating the wireloads in the library. If a wireload model already exists in the library,wireload model from the file overwrites the existing wireload data.

If operating_conditions option is used, the operating conditions specified in thfile filename are used to update the library.

If cells option is used then the cells from the filefilenameare added to the library. If thecell in the file already exists in the library then an error is reported.





se

finaland

n

mberhed for

d toeader

of then beces

7Report Generation

This chapter describes the BuildGates™ report generation commands and how to uthem when generating customized reports.

As the synthesis process transforms the design from its original RTL description to atechnology mapped netlist that meets all the constraints, information must be capturedanalyzed to see if synthesis goals are being met. The information, when presented ihuman readable form, is called areport.

BuildGates provides a variety of reports to help improve the synthesis process. A nuof commands are provided to generate the most frequently used reports. However, tsoftware is designed to be flexible, allowing you to create and customize reports suiteyour specific application.

Report HeaderEach report prints certain common information at the start. This information is intendehelp correlate the reported data with specific run, version of the software, etc. The hcontains the following information:

• Command used to generate the report

• Options used with the command

• Date and time the command was executed

• Name of the program (ac_shell)

• Release and Version number

• Any other relevant information

Reporting ModesThe data from the report commands can be presented in many different forms. Somereports can be printed in a summary form and detailed form. Some of the reports caprinted for the current module or at lower levels of hierarchy by traversing the instanand submodules.

SummaryThe data is presented in a summary form. It is useful for quick view at the results.



ults.s

a

datat

ut.

in

the

e.

DetailThe data is presented in a detailed form. It is useful for the detailed analysis of the resThis is the default mode. For example, a detailed report of netlist area may appear ashown below:

report_areadetailed listing…

Current ModuleThe data is presented for the current module as selected using theset_current_module command. This is the default. For example, the detailed arereport shown above is for the current moduledart_0000 .

HierarchicalThe data is presented for the entire hierarchy below current module, in addition to thefor the current module. The optionhierarchical must be used to generate the reporby traversing the hierarchy. For example,

report_area -hierarchical -summary

AreaThe report for the area of the netlist can be generated using the following command:

report_area ?-summary? ?-hierarchical? ?-cells? ?filename?

wherefilename is the name of the generated report file. Iffilename is given, the report iswritten to the file. If thefilenameis omitted, the report is displayed on the standard outp

If hierarchical option is used, the report is created for all the hierarchical modulesthe current module, otherwise only the current module area is reported.

If summary option is used, the area report only contains the summary information forcurrent module. This is the default option. The summary report includes the followinginformation:

• current module

• wire load model

• cell area

• net area

• total area

If the cells option is used, area report is printed on every cell in the current modulThe cell report includes the following information:

• summary report for current block

• summary report cumulative for the current design hierarchy

• name and count of cells used

• type of cells used

• area for each cell

• total cell area

• net area

• total area



in the

ut.

is,

denport:

eferspath.

(N)

lling

neput the

HierarchyThe hierarchy report describes the structural hierarchy as it exists at various stages synthesis process. The following command is used:

report_hierarchy ?filename?

wherefilename is the name of the generated report file. Iffilename is given, the report iswritten to the file. If thefilenameis omitted, the report is displayed on the standard outp

If the hierarchy report is requested prior to any netlist generation, then RTL hierarchyshown. If the mapping has been done, the mapped hierarchy is shown. For exampleconsider the following hierarchy report:

ac_shell [6]> report_hierarchy|-a(m)| |-ACL_ADD_1_16_4(m)

The top level module (current module) isa, and has one hierarchical instance in it, nameACL_ADD_1_16. The codem in parentheses indicates that both the modules have bemapped. The following codes are used to indicate the state of the modules in this re

b — module is a blackbox (no subcomponents)g — module contains generic viewm — module contains a mapped viewo — module contains an optimized viewx — module is marked “don’t modify”

Timing ReportThe timing report provides timing information about various paths in the design. Thesyntax for thereport_timing command can be found in the Command ReferenceManual.

The Path Delay Table

Each path delay table shows delay through the entire path. The first row in the table rto the start node of the path and the last row in the table refers to the end node of theThe summary above the table lists:

• the name of the end node

• the slack time of the signal arrival at the end node

• the name of the clock signal associated with this end node

• whether the end node is a clock node or a data node

• whether the transitions are associated with the leading edge (P) or trailing edgeof the clock

• whether the transition at the end node is caused by the rising edge (R) or the faedge (F) of the clock

• the signal arrival time at the end node

• the signal required time at the end node

• whether there is a violation, and the cause of the violation

The table rows contain two types of information for each cell on the reported path. Orow reports the delay from the start node or the output port of the previous cell to the inport of the current cell. The next node reports the delay through the current cell frominput port (as reported in the previous row) to the output port.



d in

s, ter-

or any

ed.

ds are the

t

State MachineThe report for finite state machine (FSM) optimization can be generated using thefollowing command:

report_fsm ?-vector vecname? ?-state_table? ?-encoding? ?-hierarchical? ?filename?

wherevecnameis the state vector name andfilename is the name of the generated reportfile. A summary report with the following information is always printed:

• design (module) name, state vector name, file name and line number it was founRTL model

• number of states in this FSM, initial state, equivalent states, unreachable stateminal states, preserved states, and number of transitions (arcs)

• number and name of inputs to this FSM, unused inputs and hold signal

• number and name of outputs from this FSM

• clock signal and edge (rising or falling) that controls transitions in this FSM

• encoding used, encoding size, whether any unreachable states were removedstates were merged.

If vector option is used, a report about the FSM represented by the state vectorvecnameis displayed. If this option is not used, all FSMs in the current module are reported.

If state_table option is used, a state transition table is extracted in a report form.

If encoding option is used, all state assignments for each selected FSM are report

If none of the above options are used, only the summary report is printed.

If hierarchical option is used, all FSMs in any module in the downward path ofcurrent module are reported.

If filename is used, the report is written to the file. If thefilename is omitted, the report isdisplayed on the standard output.

Customizing Reports

Column WidthIt is possible to customize the width of each column in a tabular report usingreport_column_width attribute. The syntax of the command is as follows:

set_global report_column_width w1 w2 w3 …

wherew1, w2, w3 are integers representing character spaces for each column.

The column widths are specified from left to right. If more column widths are specifiethan the number of columns, the excess arguments are ignored. If fewer column widthspecified than the number of columns in a report, the last column width specified oncommand is used for the remaining columns.

Since different reports have different information in each column, it is important to secolumn widths appropriately before using a report generation command.



sed

ments.

are

ed of

AVerilog Support

This appendix identifies all of the Verilog HDL constructs and describes how they are uin the synthesis process. The constructs are divided into four categories:

• Fully supported

• Partially supported

• Ignored

• Not supported

Fully Supported ConstructsFully supported constructs can be used unconditionally in describing a model. Theseinclude the basic module declaration, instantiation, use ofreg and wire data types,continuous assignments, always procedural block, and many of the procedural state

• Declarations : The following module, task, function, and data type declarationsfully supported.

module and macromodule declarationsfunction, endfunctiontask, endtaskinput, output, inout port declarationwire, wand, wor, tri, triand, trior, supply0, supply1integer, regparameter

• Operators and expressions: The following operators (and expressions compristhese operators with legal operands) are fully supported.

Table A.1 — Operators and Expressions

+, - arithmetic Operators

==,!=,>,<, , ≤ comparison operators

!, &&, || logical operators

~, - 1’s complement/invert, 2’s complement

&, |, ^, ^~, ~^ binary Operators

&, |, ^, ~^, ^~, ~&, ~| reduction operators

>>, << shift operators

{}, {n{}} concatenation and replication operators

Cadence Design Systems Inc. A - 1 Cadence Confidential


tions

• The legal operands include:reg , integer andwire data types, parameters, bit-select and part-select onwire andreg , sized and unsized constants in b, o, d, h

bases.

Structural Statements

The following structural statements are fully supported.

assign — continuous assignments

module instantiation — named and ordered port connections

parameter override — on module instantiation

Procedural Statements

The following procedural statements are fully supported:

assign (p rocedural and procedural continuous assignments), begin,end, case, casex, casez, endcase, default, disable,named blocks, variable bit select on LHS of assignment, if, else, elseif.

Partially Supported ConstructsThe following constructs are supported under specific conditions. When those condiare not met, an error is indicated.

? : conditional operator

Construct Constraints

*, /, % when both operands are constants,or second operand power of 2.

posedge, negedge can only be found within thesensitivity list of an always @construct, such as:always @(posedge clk)

!, &&, ||, ~, &, |, ^,^~, ~^, ~&, ~|, +, - ,<, >, <=, >=, ==, !=

operators supported without ‘X’ or‘Z’ constructs

and, nand, or, nor,xor, xnor, buf, not,buif0, bufif1,notif0,notif1

gate types supportedwithout ‘X’ or ‘Z’ constructs

always only with @(…) triggered events.

blocking assignment limitations on usage with non-blocking assignment.

non-blocking assign-ment

limitations on usage with blockingassignment.

Table A.1 — Operators and Expressions

+, - arithmetic Operators

Cadence Confidential A - 2 Cadence Design Systems Inc.


uset

ust

Ignored ConstructsThe following constructs are ignored when a Verilog HDL model is read. This may caa mismatch in results between simulation of Verilog HDL model and synthesis outpunetlist.

• DeclarationsThe following declarations are ignored:scalar, vectorsmall, large, mediumweak1, weak0, highz0, highz1, pull0, pull1

• Structural StatementsThe following structural statements or some parts of structural statements areignored:instance delay specification on built-in primitivesdelay specification on continuous assignmentssignal strengths on built-in primitivessignal strengths in continuous assignments

• Procedural StatementsThe following procedural statements are ignored:intra-assignment timing controlsprocedural delayswait$keyword (system tasks and functions)specify, endspecify, specparam, path delays

Unsupported ConstructsThe following Verilog HDL constructs are not supported for synthesis. When theseconstructs are encountered in Verilog HDL model, an error is generated. Your model mnot contain any of these constructs.

• DeclarationsThe following data type declarations are not supported.triand, trior, tri1, tri0, trireg net typestime, real, event data types

• Operators and expressionsThe following operators are not supported.===, !== (identity operators)

• Structural StatementsThe following structural statements and built-in switches are not supported.cmos, nmos, rcmos, rnmos, pmos, rpmos (switch primitives)rtran, tran, tranif0, tranif1, rtranif0, rtranif1pullup, pulldown, hierarchically referenced identifiers

for bounded by static variables: onlyuse “+” or “-” to index.

Construct Constraints



ns

• Procedural StatementsThe following procedural statements are not supported.initial procedural blockdeassignforce, releasefork, joinforever, while, repeattable, endtable, primitive, endprimitive-> (event triggers)disable

Verilog ConstructsThe following table provides a quick cross-reference of level of support for all VerilogHDL constructs. The support is indicated as fully supported (Full), partially supported(Partial), ignored (Ignored), and not supported (No). Wherever possible, the restrictioare listed to describe the partial nature of the support for each language construct.

Group Construct Support

basic identifiers Full

escaped identifiers Full

sized constants (b,o,d,h) Full

unsized constants Full

string constants No

real constants No

use of z, ? in constants Full

use of x in constants Partial

module, endmodule Full

macromodule Full

hierarchical references No

// comments Full

/* */ Full

$tasks Ignored

$functions Ignored



data types wire, wand, wor, tri, triand, trior Full

tri0, tri1 No

supply0, supply1 Full

trireg, small, medium, large No

reg, integer Full

real No

time No

event No

parameter Full

scalared, vectored Ignored

input, output, inout Full

memory No

strengths supply0, supply1 Ignored

strong0, strong1 Ignored

pull0, pull1 Ignored

large0, large1 Ignored

weak0, weak1 Ignored

medium0, medium1 Ignored

small0, small1 Ignored

highz0, highz1 Ignored

module

instances

connect port by name, order Full

override parameter by order Full

defparam Full

constants connected to ports Full

unconnected ports Full

expressions connected to ports Full

delay on built-in gates Ignored




built-in primi-

tives

(No support for

X or Z connect)

and, or, nand, nor, xor, xnor Partial

not, notif0, notif1 Partial

buf, bufif0, bufif1 Partial

tran, tranif0, tranif1,

rtran, rtranif0, rtranif1

No

pmos, nmos, cmos,

rpmos, rnmos, rcmos

No

pullup, pulldown No

UDPs primitive, endprimitive No

table, endtable No

operators &

expressions

+, - Full

*, /, % Partial

unary +, - Full

~ Full

bitwise &, |, ^, ~^, ^~ Full

reduction &, |, ^, ~&, ~|, ~^, ^~ Full

!, &&, || Full

==, !=, <, <=, >, >= Full

===, !== No

<<, >> Full

{}, {n{}} Full

? : Full

@ Partial

or Full

function call Full

event

control

procedural delay (#) Ignored

@ Partial

posedge, negedge Partial

wait Ignored

intra-assignment delays Ignored

intra-assignment event control Ignored

event trigger (->) No




bit and part

selects

constant bit-select, part-select of vectors Full

variable bit-select on left-hand side of an

assignment

Full

continuous

assignments

net/wire declaration Full

using assign Full

use of delay Ignored

use of strengths Ignored

procedural

blocks

initial No

always (exactly one @ required) Partial

procedural

statements

; Full

begin-end Full

if, else Full

for (constant bounds, only + and - opera-

tion on index)

Partial

while Partial

repeat Full

forever No

case, casex, casez, endcase, default Full

disable Partial

fork-join No

task call Full

procedural

assignments

blocking (=) assignments Partial

non-blocking (<=) assignments Partial

procedural continuous assignments

(assign)

Full

deassign No

force, release No

Functions and

tasks

function, endfunction Full

task, endtask Partial

named blocks named block creation Full

local variable declaration Partial

specify block specify, endspecify Ignored

specparam Ignored

module path delays Ignored




compiler direc-

tives‘ define Full

‘ resetall Full

‘ ifdef, ‘ else, ‘ endif Full

‘ include Full

VPP

directives‘ if Full

‘ for Full

‘ eval Full

‘ {} Full




tives

ols.

, are

BThe Verilog Pre-Processor

This appendix describes the Verilog Pre-Processor (VPP) that supports compiler direcin addition to those defined in Verilog HDL. These extra directives add powerfulfunctionality for writing configurable and reusable HDL code using Ambit synthesis to

The following compiler directives are added through VPP:

• `for

• ìf

• èval

• `{}

VPP also supports and interprets the following Verilog HDL compiler directives.

• `define

• ìfdef, èlse, èndif

• ìnclude

The remaining Verilog HDL compiler directives, when encountered in the source codepassed on to the Verilog HDL parseras is, without any interpretation by VPP.

Compiler Directives

‘for

The`for compiler directive is a loop to define complex repetitive expressions andstatements. The syntax of this directive is as follows:

‘for var = constant1 to constant2 step ?up | down? constant3Verilog description‘endwherevar is the name of a variableconstant1, constant2 andconstant3 are integer constantsVerilog description is any legal Verilog syntax

The variablevar is visible only within the scope of this directive (between‘for and‘end ). It can be referenced using‘ var. It can not be modified within theVerilogdescription. The initial value ofvar is set toconstant1 for the first iteration andincremented (or decremented, if the keyworddown is used) byconstant3 on everyiteration.

Cadence Design Systems Inc. B - 1 Cadence Confidential


er

.

The iterations are terminated when the value ofvar is greater (less) thanconstant2. TheVerilog description embedded within this directive is repeated for each iteration,substituting the current iteration value for the variablevar if it is referenced within theVerilog description.

In combination with theif , andèval compiler directives (described below), thiscompiler directive can be very useful. For example,

`define BITS 5`for i = èval(`BITS-1) to 0 step down 1ìf (ì == 0)

halfadder Uì (a[ì],b[ì],s[ì],c[ì]);èlse

fulladder Uì (a[ì],b[ì],c[èval(ì-1)],s[ì],c[ì]);èndifèndproducesfulladder U4 (a[4], b[4], c[3], s[4], c[4]);fulladder U3 (a[3], b[3], c[2], s[3], c[3]);fulladder U2 (a[2], b[2], c[1], s[2], c[2]);fulladder U1 (a[1], b[1], c[0], s[1], c[1]);halfadder U0 (a[0], b[0], s[0], c[0]);This allows a VHDL typeif-generate andfor-generate capability to besupported in Verilog HDL.

The ‘for compiler directive may be nested in other compiler directives, including oth‘for compiler directives.

‘if

VPP expands the syntax ofìf compiler directive of Verilog HDL to allow constantexpressions using the following operators:

||&&==!=

The syntax of this compiler directive is as follows:

‘if ( expression)verilog description?‘elseverilog description?‘endifwhere

expression is a constant expression composed of the legal operators listed above.

For example,

ìf ((ì == 0) || (`j == 1))example iì (a[ì], b[`j], c);

èlseexample2 iì (a[èval(ì-1), b[`j], c);

èndif

‘eval

VPP uses the èval to evaluate expressions involving defined macros and constants

Cadence Confidential B - 2 Cadence Design Systems Inc.


tant

The syntax for the compiler directive is as follows:

‘eval( expression)

where

expression is an expression with constant operands.

The operand can be either a constant number or a reference to a macro with a consvalue.

Two examples above show the use of‘eval compiler directive.

‘{}

Since Verilog gives no particular way to handle building of complex macros using acombination of macros, VPP provides‘{ABC} to evaluate a previously defined macroABC.

For example, the following is not supported in Verilog HDL

`define XYZ AND`define BITS 8`define LIB TECHmodule `XYZ_`BITS_`LIB ();

To handle such usage, the following extension to the syntax is used by VPP.

module `{XYZ}_`{BITS}_`{LIB} ();

This evaluates the module name toAND_8_TECH.

Command Line OptionsVPP supports the following command line options:

-I …/ incl directories to be searched for include files

-I …/ incl UNIX cpp compatibility (no space between option, path)

-D abc=12 define abc to be 12, similar to +define in verilog-xl

-Dabc=12 UNIX cpp compatibility (no space between option, value)

-nolinenum do not generate `line in output

VPP Flag Attributeset_global vpp_arg = “-I …/include -DSYNTH”

Cadence Design Systems Inc. B - 3 Cadence Confidential


Cadence Confidential B - 4 Cadence Design Systems Inc.


CWire Load Model Selection

Cadence Design Systems Inc. C - 1 Cadence Confidential


net.
The flow chart below shows the algorithm used for selecting a wire load model for a
Figure C.1 —Finding Wire Load Model W for a net N

Find module m thatencloses net N

Find hierarchically lowest levelmodule M enclosing m with userspecified wire load model W

Wire load mode= enclosed?

use area of topmodule

use area ofmodule m

Lookup wire load modelW from module area

Net N

Wire Load Model W

Yes

No

YesNo

Found?

Cadence Confidential C - 2 Cadence Design Systems Inc.


f

In the figure below,T is the current top module,A is an instance insideT, andM1 andM2are two instances insideA. The netnet1 is fully contained insideA, but not fullycontained inside eitherM1 or M2.

Figure C.2 —Estimating the wireload for a net

The wire load fornet1 is estimated as follows:

• Identify the enclosing module for net1. In the figure above, moduleA is the enclos-ing module.

• ForA or its parent modules (modules in its upward hierarchical path), identify iwire load table is already set.

• If set, use it as the wire load table.

• If not set, check the global wire load mode (by default, this istop ).

• If the mode isenclosed , use the area of enclosing moduleA to identify the wireload table.

• If the mode istop , use the area of top moduleT to identify the wire load table.

• Look up the area table in the technology file to get wire load model name.

A

M1 M2

net1

T

enclosedtop

Cadence Design Systems Inc. C - 3 Cadence Confidential


Cadence Confidential C - 4 Cadence Design Systems Inc.


thes are

DVHDL Constructs

VHDL ConstructsThis appendix lists the VHDL constructs supported by BuildGates/VHDL and shows category to which each of them belong. The list is subject to change and modificationongoing. Both VHDL 1987 and VHDL 1993 style descriptions are supported. Theconstructs are classified by one of the following four categories:

• Synthesized fully (Full)

• Synthesized partially or in specific contexts (Partial)

• Construct is ignored and a warning is generated (Ignored)

• Construct is unsupported and an error message is generated (No)

Table D-1 — VHDL Constructs Supported in BuildGates

Construct Support

Design Entity &Configuration

Entity Declaration Entity header Full

Entity declarative part Full

Entity statement part Ignored

Architecture Body Architecture declarative part Full

Architecture statement part Full

Configuration Declaration Configuration declarative part Partial

Block configuration Full

Component configuration Full

Subprogram & Packages Subprogram Declaration Full

Subprogram Body Subprogram declarative part Full

Subprogram statement part Full

Subprogram Overloading Full

Resolution Function Partial

Package Declaration Package declarative part Full

Deferred constants Full

Package Body Full

Cadence Design Systems Inc. D - 1 Cadence Confidential


Types Scalar Type Definition Enumeration type Full

Integer Full

Physical Ignored

Floating Ignored

Composite Type Definition Array Full

Record Full

Access Type Definition Ignored

File Type Definition Ignored

Declarations Subprogram Declaration Full

Subprogram Body Full

Type Declaration Full

Subtype Declaration Full

Object Declaration Constant Full

Signal Full

Variable Full

Shared variable No

File No

Alias Declaration No

Attribute Declaration Full

Component Declaration Full

Group Template Declara-

tion

No

Group Declaration No

Specifications Attribute Specification Full

Configuration Specifica-

tion

Full

Disconnection Specifica-

tion

No

Table D-1 — VHDL Constructs Supported in BuildGates (Continued)

Construct Support

Cadence Confidential D - 2 Cadence Design Systems Inc.


Expressions Logical Operators and, or, nand, nor, xor, xnor Full

Relational Operators =, /=, >, <, >=, <= Full

Shift Operators sll, srl

sla, sra, ror, rol

Full

No

Arithmetic Operators +, -, & Full

Sign Operators +, - Full

Multiplying Operators *

/, mod, rem

Full

Partial

Miscellaneous Operators * *

abs

not

Partial

Full

Full

Operands Integer literal Full

Real Literal Ignore

Physical Literal Ignore

Enumeration Literal Full

String Literal Full

Bit String Literal Full

Null Literal No

Aggregates Record Aggregates Full

Array Aggregates Full

Function calls Qualified Expression Full

Type Conversion Full

Allocators No

Statements Sequential StatementsWait Sensitivity clause Partial

Condition clause Partial

Timeout clause Ignored

Assertion Ignored

Report Ignored

Signal Assignment Full

Variable Assignment Full

Procedure Call Full

If Full

Case Full

Loop Unconditional Loop No

While Loop Partial

For Loop Full

Next Full

Exit Full

Return Full

Null Full

Concurrent StatementsBlock Guard No

Block header No

Block declarative part Full

Block statement part Full

Timeout clause Ignored


Construct Support



d in

d for

.

clara-

Notes on Supported ConstructsThis section contains additional information pertaining to all of the constructs outlinethe above table. Please read the following section for more information.

Design Entities and Configurations

• Generics and ports in an entity header can be of any synthesizable type allowean interface object (e.g. bit , boolean , bit_vector , integer ). See the sec-tion on Types for more information.

• Generics must have a default value specified, unless the entity has aTEMPLATEattribute set toTRUE. See the section Synthesis Directives for more information

• Declarations in an entity or architecture declarative part must be supported detions. See the section on Declarations for more information.

Process Full

Concurrent Procedure Call Full

Concurrent Assertion Ignored

Concurrent Signal Assign-

ment

Conditional Signal Assign-

ment

Full

Selected Signal Assignment Full

Component Instantiation Full

Generate Statement If Generate Full

For Generate Full


Construct Support



the

ype

kageclara-

no-

a-

edesis as

ection

ters

• Configuration declarations and configuration specifications are supported withrestriction that only one unique architecture is bound to an entitythroughoutthedesign.

Subprograms and Packages

• Impure functions are unsupported.

• Recursive subprograms are supported.

• Formal parameters in a subprogram declaration can be of any synthesizable tallowed for an interface object (e.g.bit , boolean , bit_vector , integer ).See the section on Types for more information.

• Declarations in a subprogram declarative part, package declarative part, or pacbody declarative part must be a supported declaration. See the section on Detions for more information.

• Theresolved function defined in package IEEE.STD_LOGIC_1164 is theonly supported resolution function. User defined resolution functions can be antated with theRESOLUTION attribute to force aWIRED_AND, WIRED_OR, orWIRED_TRI behavior. See the section on Synthesis Directives for more informtion.

Types

• Objects (constants, signals, variables) declared with a subtype that is an ignortype or derived from an ignored type are unsupported. For example, the synthtool ignores floating type definitions, but a signal of that floating type is flaggedan error. For example:

type GET_REAL is 2.4 to 3.9; --Ignored type definitionsignal S: GET_REAL; --Error!

• The attributeENUM_ENCODING can be used to override the default mappingbetween an enumerated type and the corresponding encoding value. See the son Synthesis Directives for further information.

• Array type definitions are supported.

Examples

subtype BYTE is bit_vector(7 downto 0);type COLORS is (SAFFRON, WHITE, GREEN, BLUE);type BIT_2D is array (0 to 255, 0 to 7) of bit;type ANOTHER_BIT_2D is array (0 to 10) of BYTE;type BITVECTOR_1D is array (0 to 255) of BYTE;type INTEGER_1D is array (0 to 255) of integer;type ENUM_1D is array (0 to 255) of COLOR;type BOOL_1D is array (COLORS) of boolean;

-- a three dimensional bittype BIT_3D is array (0 to 10) of BIT_2D;-- a two dimensional integertype INTEGER_2D is array (0 TO 10, 0 TO 10) of integer;

• Interface Objects (i.e. formal ports of an entity or a component, formal parameof a subprogram) can be of any supported type.

• Null ranges are not supported.



ibed

is used

ge

hen

hen

ed.

asore

n

Declarations

• Initial values are supported for variables in a subprogram body.

• Deferred constants are supported.

• Signal kinds (i.e. bus and register) are unsupported.

• Modelinkage in interface objects is unsupported.

• All type declarations can be read in, but only objects of supported types descrin the types section are allowed to be declared.

• User-defined attribute declarations and specifications are supported.

Names

• Selected names that refer to elements of a record are supported.

• Selected names used as expanded names are supported. An expanded nameto denote a declaration from a library, package, or other named construct.

• The following pre-defined attributes are supported:base , left , right , high ,low , range , reverse_range , length.

• The following pre-defined attributes are only supported in the context of clock edspecifications:event , stable.

• Expressions in attribute names are unsupported.

• User defined attribute names are supported.

• Indexing and slicing of function return values is partially supported.

Expressions

• Signed arithmetic is supported.

• The following operators are only supported in the VHDL 1993 mode:xnor , sll ,srl.

• / , mod, andrem are only supported when both the operands are constants or wthe right operand is a static power of 2.

• The ** operator is only supported when both the operands are constants or wthe left operand is a power of 2.

• Real and physical literals may only exist in after clauses, where they are ignor

• TheTYPE_CONVERSION directives may be used to tag user-defined functions having a type conversion behavior. See the section on Synthesis Directives for minformation.

• Slices whose ranges cannot be determined statically are not supported.

• Slices of array objects are supported. Similarly, direct indexing of a bit within aarray is supported. For example:

subtype BYTE is bit_vector(3 downto 0);type MEMTYPE is array (255 downto 0) of BYTE;variable MEM: MEMTYPE;variable B1: bit;…MEM(3 downto 0):= X; -- supported multi-word sliceB1:= MEM(3)(0); -- supported reference to bit



ss.ityse.

rted.

re

ti-

poned

, set

Sequential Statements

• When an explicitwait statement is used, it must be the first statement of a proceThe condition clause must represent the clock edge specification. The sensitivclause, if any, must only contain the clock signal specified in the condition clau

• Multiple wait statements in a process (i.e. implicit state machines) are unsuppo

• Assignments that involve multiple “words” of 2-dimensional (or higher) objects asupported.

• The range in aFOR loop must be statically computable.

• Delay mechanisms in signal assignments are ignored.

• Multiple waveforms in signal assignments are unsupported.

• While loops are supported with the restriction that looping behavior can be stacally determined.

Concurrent Statements

• Postponed processes including postponed concurrent procedure calls and postconcurrent signal assignments are unsupported.

• Signal assignments that involve multiple “words” of 2-dimensional (or higher)objects are supported.

• Delay mechanisms in signal assignments are ignored.

• Multiple waveforms in signal assignments are unsupported.

• Guarded signal assignments are unsupported.

• The range in afor-generate statement must be statically computable.

• Declarations in a generate statement are only supported in VHDL 1993 mode.

Predefined VHDL EnvironmentPrecompiled VHDL libraries and packages are available in thestandard (default),synopsys , andsynergy environments. Thestandard (default) setting provides only theIEEE approved packages. To access the precompiled VHDL libraries and packagesthe value of the global variable:hdl_vhdl_environment (see below).

set_global hdl_vhdl_environment {standard|synopsys|synergy}

Note: Theset_global command must be executed before executing aread_vhdl ordo_build_generic command and must not be changed during the designanalysis.

Table D-2 lists the VHDL libraries and packages that are available with thestandard

(default) environment using the following command:

set_global hdl_vhdl_environment standard

Table D-2 — BuildGates Predefined VHDL Libraries for the Standard Environment

Library Packages

AMBIT attributes

STD standard

textio

IEEE std_logic_1164

numeric_bit

numeric_std



ry,

EEEthe

Table D-3 lists the VHDL libraries and packages that are available with thesynopsys


set_global hdl_vhdl_environment synopsys

Table D-4 lists the VHDL libraries and packages that are available with thesynergy


set_global hdl_vhdl_environment synergy

For information about how to add another IEEE arithmetic package to the IEEE librarefer to the section, “Arithmetic Packages”, in this manual. The STD_LOGIC_1164,NUMERIC_BIT, and NUMERIC_STD IEEE standard packages are shipped withBuildGates and have been tagged with the appropriate synthesis directives. If library Iis redefined (for example, to analyze arithmetic packages from other vendors), then user must use the three packages that are shipped with BuildGates.

The following programs and functions are NOT supported:

• All the subprograms of packageSTD.TEXTIO

• The functionnow

Table D-3 — BuildGates Predefined VHDL Libraries for the Synopsys Environment

Library Packages

AMBIT attributes

STD standard

textio

SYNOPSYS attributes

IEEE std_logic_1164

std_logic_arith

std_logic_misc

std_logic_signed

std_logic_textio

std_logic_unsigned

Table D-4 — BuildGates Predefined VHDL Libraries for the Synergy Environment

Library Packages

AMBIT attributes

STD standard

textio

SYNERGY constraints

signed_arith

std_logic_misc

IEEE std_logic_1164

std_logic_arith

std_logic_textio



e

tic

ge

VHDL Predefined AttributesTable D-5 lists the attributes for the pre-defined language environment and shows thcategory to which each belong (Full, Partial, Ignored, No).

Table D-5 — Attribute Set for the Pre-defined Language Environment

Notes on Pre-defined Attributes

• The following pre-defined attributes are supported only when the prefix is a statype mark:Base , Ascending , Pos, Val , Succ , Pred , Leftof , Rightof

• The following pre-defined attributes are supported only in the context of clock edspecifications:Event, Stable

• Expressions in attribute names are unsupported.

Pre-defined Attribute Support

‘Base Partial

‘Left Full

‘Right Full

‘High Full

‘Low Full

‘Ascending Partial

‘Image No

‘Value No

‘Pos Partial

‘Val Partial

‘Succ Partial

‘Pred Partial

‘Leftof Partial

‘Rightof Partial

‘Range Full

‘Reverse_range Full

‘Length Full

‘Delayed No

‘Stable Partial

‘Quiet No

‘Transaction No

‘Event Partial

‘Active No

‘Last_event No

‘Last_active No

‘Last_value No

‘Driving No

‘Driving_value No

‘Simple_name No

‘Instance_name No

‘Path_name No





ion.

sis

en

s,

s

gy

EMixed VHDL/Verilog Synthesis

This appendix describes how to synthesize VHDL/Verilog modules in the same sessAfter reading in the VHDL and Verilog designs (usingread_vhdl andread_verilog

respectively), a singledo_build_generic command will build the appropriate modulesand link VHDL/Verilog modules to their instantiations. No special attributes or synthedirectives are needed for mixed VHDL/Verilog synthesis.

Since VHDL is case-insensitive and Verilog is case-sensitive, care must be taken whusing BuildGates to synthesize mixed VHDL/Verilog designs in the same session.BuildGates sets various case-sensitivity constraints when performing the followingoperations:

• Reading in RTL modules

• Mixed VHDL/Verilog instantiations

• Generic build for a specified module

Reading in RTL ModulesWhen reading in RTL modules, the following BuildGates constraints apply:

• Verilog modules that have similar names in different cases (such as,FOO andfoo )are treated as two distinct modules.

• VHDL modules that have similar names are treated as identical modules. Forexample, if VHDL modulesFOO andfoo are read in sequentially,foo will replaceFOO in the BuildGates module pool.

• If there are both VHDL and Verilog modules with similar names in different casethey are considered identical modules. For example, if Verilog moduleFOO andVHDL modulefoo are read in sequentially, the last module read into BuildGatewill take precedence. In this case, VHDL modulefoo will replace Verilog moduleFOO in the BuildGates module pool.

Mixed VHDL/Verilog InstantiationsWhen using mixed VHDL/Verilog instantiations, the following BuildGates constraintsapply:

• Component instances in a Verilog module are resolved if a module or technolocell with the exact name is found. For example, an instance of a module namedfoo

can be resolved only with another VHDL or Verilog module namedfoo .

Cadence Design Systems Inc. E-1 Cadence Confidential


ner.

g

s

quertinge a

• Component instances in a VHDL module are resolved in a case-insensitive manFor example, an instance of a module namedfoo in a VHDL module may be linkedwith other VHDL/Verilog modules namedFOO, or Foo and so on. An error occurs ifthere are multiple modules whose names matchfoo in a case-insensitivemanner.

In the example below, when reading VHDL and Verilog modules, each of the followinmodules instantiateFOO.

VHDL: entity TOP_VHDL is...I1 : FOO port map(...); -- linked with "foo"end;

Verilog: module TOP_VERILOG (...);...FOO inst1 (...); // not linked with "foo"endmodule

Verilog: module foo (...);...endmodule

The instance,I1 of FOO, in entityTOP_VHDL is linked with the Verilog modulefoo (sincefoo andFOO are identical from a case-insensitive point-of-view). The instance,inst1 ofFOO, in moduleTOP_VERILOGis not linked tofoo (since a Verilog instantiation requires anexact name match).

Generic Build for a Specified ModuleWhen the-module switch is used with thedo_build_generic command, the subtree ofhierarchy rooted at the specified module is synthesized.

To determine the module that will serve as the starting point for synthesis, BuildGatelooks for an exact match of the specified module in the RTL module pool. If an exactmatch is not found, a case-insensitive match is executed in the module pool. If a unimatch is found that corresponds to a VHDL module, then that module is used as a stapoint fordo_build_generic . In other words, an exact name must be specified using th-module option for Verilog modules, while a case-insensitive search is used to locateVHDL module as a starting point fordo_build_generic . An error occurs if there are nomatches or multiple matches found for the module specified in the-module option.

Cadence Confidential E-2 Cadence Design Systems Inc.

BuildGates User Guide INDEX

Symbols‘{} directive B-3‘eval directive B-2‘for directive B-1‘if directive B-2

Aac_shell 1-1

command prompt 2-2invoking 2-2TCL 2-2

ACL 6-3ADB 2-9Ambit Technology Compiler 2-8AMBIT_SLIB_PATH 2-3area 2-11

detailed report 2-11summary report 2-11

arrival time 2-7clock 2-7, 5-4data 2-7, 5-6early 5-6late 5-6

Associated Documents 4-1asynchronous reset 3-2, 4-3asynchronous set 3-2, 4-3Asynchronous set-reset on a flip-flop 4-5ATL 2-4, 6-3AVL 2-10

Bbackannotation 6-11blackbox 2-11boolean transformations 6-1

Ccapacitance 5-20capacitance limit 5-22Case Statemen 4-7case statement 3-5, 4-7

casex 3-6casez 3-6default 3-6, 4-8incomplete 3-5, 4-7unconditional assignment 3-6

CDFG 2-4cell area 7-2characterization 6-8clock

arrival time 2-7, 5-4falling edge 5-3ideal 5-3lead 5-3multiple 5-9negative 5-3polarity 5-3positive 5-3rising edge 5-3skew 5-5trail 5-3

clock definition 2-7collapsing hierarchy 6-6command file 2-3, 2-14commands

do_build_generic 2-4, 6-3do_derive_context 6-8do_dissolve 6-6do_optimize 2-9, 6-8do_timing_correction 6-10do_uniquely_instantiate 6-6do_xform_ 6-7exit 2-14find 2-8get_hdl_file 4-33get_hdl_hierarchy 4-33get_hdl_toplevel 4-33get_hdl_type 4-33get_names 2-8glob 2-4hdl_vhdl_case 4-32hdl_vhdl_netlist_entity_generator 4-33hdl_vhdl_read_version 4-32hdl_vhdl_write_version 4-33quit 2-14read_alf 2-8read_library_update 5-20, 6-11read_sdf 6-11read_verilog 2-4read_vhdl 4-33report_area 2-11, 7-2report_column_width 7-4report_fsm 7-4report_hierarchy 2-10, 7-3report_timing 2-13report_vhdl_libraries 4-33reset_vhdl_library 4-33set_clock 2-7, 5-3set_clock_arrival_time 2-7, 5-4set_current_module 5-1set_cycle_addition 5-11set_data_arrival_time 2-7, 5-6set_data_required_time 2-8, 5-8set_distributed_wire_resistance 5-23

Cadence Design Systems Inc. I - 1 Cadence Confidential

INDEX BuildGates User Guide

set_dont_modify 6-4set_drive_cell 5-15set_drive_resistance 5-16set_external_delay 5-10set_fanout_load 5-22set_fanout_load_limit 5-22set_global 7-4set_num_external_sinks 5-22set_num_external_sources 5-22set_operating_condition 5-20set_port_capacitance 5-21set_port_capacitance_limit 5-22set_slew_limit 5-17set_top_timing_module 2-7, 5-2set_vhdl_library 4-33set_wire_capacitance 5-23set_wire_load 5-20set_wire_load_mode 5-21set_wire_resistance 5-23source 2-3UNIX shell 2-4write_adb 2-10write_assertions 6-9write_verilog 2-10write_vhdl 4-33

compiler directives 3-8, A-8Complete Assignments

Case Statement 4-7constraints 1-2, 5-1

area 5-1physical 5-1timing 5-1

ConstructVHDL D-1

contexthierarchical 5-1timing 5-2

context derivation 6-8

Ddata arrival time 5-6data required time 5-8Declarations D-5derating factors 5-20Design Entities and Configuration D-4design optimization 6-7detailed area report 2-11dissolving hierarchy 6-6do_build_generic 2-4, 6-3do_derive_context 6-8do_dissolve 6-6do_optimize 2-9do_uniquely_instantiate 5-2, 6-6

do_xform 6-7don’t modify hierarchy 6-4don’t modify network 6-4drive cell 5-14drive resistance 5-15, 5-16

Eearly arrival time 5-6early mode analysis 2-13enclosing module C-3Enumeration Encoding Directive 4-17external delay 5-10external driver 5-14external loads 5-14external sinks 5-22external sources 5-22

Ffanout 5-22fanout limit 5-22fast path 5-7find 2-8find command 2-5flattened netlist 2-10flattening 6-1Flip-Flop Inference 3-3, 4-4Flip-Flop Inferencing 4-4floorplanning tools 6-3for statement 3-8, 4-8Formal D-5FSM

report 7-4FSM encoding 3-19

binary 3-19gray 3-19one hot 3-19random 3-19

full case directive 3-10

Ggeneric cells 2-11get_names 2-8glob 2-4glob style pattern matching 2-6global attributes

target_technology 2-9global reference signal 5-3

Cadence Confidential I - 2 Cadence Design Systems Inc.


Hhierarchical context 5-1hierarchy 2-10, 6-4

collapsing 6-6preserving module boundary 6-4reports 7-2, 7-3unique instances 6-5

Iideal clock 2-7, 5-3Incomplete Assignments

Case Statement 4-7

Kk-factors 5-20

Llatch inference 3-1, 4-2late arrival time 5-6late mode analysis 2-13linear model 5-20logic optimization 6-1

Mmapping 2-9multi-cycle paths 5-11multiple clocks 5-9mux directive 3-11

Nnet area 7-2netlist 2-9non-linear model 5-20Notes

Supported Constructs D-4

OObjects D-5operating condition 5-19optimization 2-8, 6-1

context-based 6-2, 6-8critical path 6-10hierarchical 6-2incremental 6-2post-placement 6-3transformations 6-10

optimized view 2-11

Pparallel case directive 3-10pattern matching

glob style 2-6regexp style 2-6

placement tools 6-3port capacitance 5-21preserving hierarchy 6-4preserving network 6-4Process Directives 4-11

Rread_alf 2-8, 6-8read_library_update 5-20, 6-8, 6-11read_sdf 6-11read_verilog 2-4recovergence 5-9regexp style pattern matching 2-6Register Inferencing 4-2report_area 7-2report_column_width 7-4report_fsm 7-4report_hierarchy 2-10, 7-3reports 7-1

area 7-2cell area 7-2column width 7-4customizing 7-4detail 7-2header information 7-1hierarchical 7-2hierarchy 7-3modes 7-1net area 7-2state machine 7-4timing 7-3ummary 7-1wire load model 7-2

required time 2-8, 5-8data 5-8

resistance 5-20Resolution Function Directives 4-21RTL 1-2

SSDF 6-3, 6-11search order 2-3set_clock 2-7, 5-3



set_clock_arrival_time 2-7, 5-5set_current_module 5-1set_cycle_addition 5-11set_data_arrival_time 2-7, 5-6set_data_required_time 2-8, 5-8set_distributed_wire_resistance 5-23set_dont_modify 6-4set_drive_cell 5-15set_drive_resistance 5-16set_external_delay 5-10set_fanout_load 5-22set_fanout_load_limit 5-22set_global 2-9, 7-4set_num_external_sinks 5-22set_num_external_sources 5-22set_operating_conditions 5-20set_port_capacitance 5-21set_port_capacitance_limit 5-22set_reset directives 3-11, 4-10set_slew_limit 5-17set_target_technology 6-8set_top_timing_module 2-7, 5-2set_wire_capacitance 5-23set_wire_load 5-20set_wire_load_mode 5-21set_wire_resistance 5-23set-reset

asynchronous 3-2, 4-3synchronous 3-3, 4-4

signal arrival time 5-2Signal Directive 4-13signal required time 5-2Signals in a Process Directive 4-15slew 5-16slow path 5-7source 2-3standard delay format 6-11structuring 6-1Subprograms and Packages D-5Supported Constructs

Notes D-4synchronous reset 3-3, 4-4synchronous set 3-3, 4-4Synthesis Directives 4-9synthesis directives 3-1, 3-8, 4-1, 4-9

architecture selection 3-17blocks 3-12case statement 3-9code selection 3-9, 4-9enum 3-17FSM 3-17set_reset 3-11, 4-10signals 3-14, 4-13state_vector 3-19

Synthesis Packages 4-28

Ttarget_technology 2-9TCL 2-2technology constraints 5-19Technology library 2-8technology library 1-2

ATL 2-4xatl 2-8

technology mapping 2-9technology specific cells 2-11The Case Statement 4-7timing analysis 5-2timing context 5-2timing corrections 6-10timing report 2-13top level module 5-2top module 2-7Type Conversion Directive 4-22

Uunique instances 6-5Using VHDL 1987/1993 4-22

Vvendors

Arithmetic Packages 4-25Verilog constructs

basic A-4bit and part selects A-7built-in primitives A-6compiler directives A-8continuous assignments A-7data types A-5event control A-6expressions A-6fuly supported A-1functions A-7ignored A-3module instances A-5named blocks A-7operators A-6partially supported A-2procedural assignments A-7procedural blocks A-7procedural statements A-7specify block A-7strengths A-5table A-4



tasks A-7UDPs A-6unsupported A-3VPP directives A-8

VHDLCommands 4-32Declarations D-6Expressions D-6Language Environment D-7modeling style 1-2, 4-1Sequential Statement D-7Types D-5

VHDL Concurrent Statements D-7VHDL Construct D-1, E-1VHDL Packages D-7view

blackbox 2-11VPP directives A-8, B-1

Wwait D-7wire capacitance 5-23wire delays 5-20wire load 5-20wire load model 5-20, 7-2wire load model selection C-2wire load table C-3wire resistance 5-23write_adb 2-10write_assertions 6-9write_verilog 2-10Writing VHDL netlists 4-27

XXATL 6-3xatl 2-8




Date post:	14-Nov-2021
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times