Cadence Synthesis Rapid Adoption Kit · 2018-02-08 · Cadence Synthesis Rapid Adoption Kit May...

Cadence® Synthesis Rapid Adoption Kit

Product Version 5.0.10May 2003

2002-2003 Cadence Design Systems, Inc. All rights reserved.Printed in the United States of America.

Cadence Design Systems, Inc., 555 River Oaks Parkway, San Jose, CA 95134, USA

Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in thisdocument are attributed to Cadence with the appropriate symbol. For queries regarding Cadence’s trademarks,contact the corporate legal department at the address shown above or call 1-800-862-4522.

All other trademarks are the property of their respective holders.

Restricted Print Permission: This publication is protected by copyright and any unauthorized use of thispublication may violate copyright, trademark, and other laws. Except as specified in this permission statement,this publication may not be copied, reproduced, modified, published, uploaded, posted, transmitted, ordistributed in any way, without prior written permission from Cadence. This statement grants you permission toprint one (1) hard copy of this publication subject to the following conditions:

1. The publication may be used solely for personal, informational, and noncommercial purposes;2. The publication may not be modified in any way;3. Any copy of the publication or portion thereof must include all original copyright, trademark, and other

proprietary notices and this permission statement; and4. Cadence reserves the right to revoke this authorization at any time, and any such use shall be

discontinued immediately upon written notice from Cadence.

Disclaimer: Information in this publication is subject to change without notice and does not represent acommitment on the part of Cadence. The information contained herein is the proprietary and confidentialinformation of Cadence or its licensors, and is supplied subject to, and may be used only by Cadence’s customerin accordance with, a written agreement between Cadence and its customer. Except as may be explicitly setforth in such agreement, Cadence does not make, and expressly disclaims, any representations or warrantiesas to the completeness, accuracy or usefulness of the information contained in this document. Cadence doesnot warrant that use of such information will not infringe any third party rights, nor does Cadence assume anyliability for damages or costs of any kind that may result from use of such information.

Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth inFAR52.227-14 and DFAR252.227-7013 et seq. or its successor.

Cadence Synthesis Rapid Adoption Kit

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Other Information Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Text Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Using Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Using Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Invoking BuildGates Synthesis or BuildGates Extreme Synthesis . . . . . . . . . . . . . . . . . . 11Command Language Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Set up your UNIX Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Download the Tutorial Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Install the Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Regarding the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2Getting Started with BuildGates Synthesis . . . . . . . . . . . . . . . . . . . . 15

Introduction to BuildGates Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Example Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Setting Up to Run the Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Required License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Required Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Basic BuildGates Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Setting Up Your Design Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Setting Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Reading the Technology Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

May 2003 1 Product Version 5.0.10


Reading the HDL Models for the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Creating a Generic Gate-Level Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Setting Test Synthesis Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Setting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Checking Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Setting Path Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Optimizing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Generating Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Writing Netlist and Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Setting Scan Chain Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Incremental Timing Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Interfacing with Physical Design Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Using BuildGates Synthesis Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Migrating to BuildGates from Design Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Constraint Translation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Distributed Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Where to Go from Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3Getting Started with Design For Test. . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Introduction to BuildGates Test Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Example Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Setting Up to Run the Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Required License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Required Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

BuildGates Top-Down Test Synthesis Configuration Flow . . . . . . . . . . . . . . . . . . . . . . . . 78Setting up the Design Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Read Libraries and the HDL Models for the Design . . . . . . . . . . . . . . . . . . . . . . . . . . 81Setting Test Synthesis Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Checking DFT Assertions and Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Fixing DFT Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Setting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Optimizing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89



Setting Scan Chain Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Connecting the Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Checking the Timing of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Viewing the Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Writing Netlist and Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Writing Interface Files to Third Party ATPG Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4Getting Started with Datapath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Introduction to BGX Datapath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Example Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Setting Up to Run the Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Required License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Required Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Traditional Synthesis Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103BGX Datapath Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Setting up the Design Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Setting up Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Reading the Synthesis Technology Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Reading the HDL Models for the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Creating a Generic Gate-Level Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Setting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Operator Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Optimizing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Generating Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Writing Netlist, Database Files and Report File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Examining Traditional Synthesis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Comparing BGX and Traditional Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

5Getting Started with Low Power Synthesis . . . . . . . . . . . . . . . . . . . 117

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118



Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Example Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Setting Up for This Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Required License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Ensure Access to a Verilog Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Link to the Simulation Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Required Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Regular BGX Flow with Power Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122BGX LPS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Setting up Design Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Reading the Synthesis Technology Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Reading the HDL Models for the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Creating Generic Gate-level Netlist and Exploring Sleep-mode Options at the RTL Level

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Setting Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Setting Sleep-Mode and Clock-Gating Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Optimizing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Simulating and Reading the Toggle Count File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Optimizing the Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Analyzing the Results and Generating Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Power Analysis in BuildGates Extreme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Generating Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Writing Netlist and Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Gate-Level Only Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Sample Script Starting from a Gate-Level Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Sample Script Starting from a Timing-Optimized Netlist . . . . . . . . . . . . . . . . . . . . . 149

LPS-DFT flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

AMore about BuildGates Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

More about Optimizing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Top-Down Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Bottom-Up Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154More on do_optimize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154



More about Timing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

BMore about Datapath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

More about Operator Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158More about Automatic Architecture Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161More about the AmbitWare Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Inference Verses Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165More about Extended Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

CMore about Low Power Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

More about LPS Clock Gating Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170More about TCF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173More about Gate-Level Power Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Gate Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Pin Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Buffer Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Gate Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Slew Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Logic Restructuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179



Preface

This preface contains the following sections:

■ About This Manual on page 7

■ Other Information Sources on page 7

■ Documentation Conventions on page 8

About This Manual

This manual describes how to use the BuildGates® Synthesis tool and the BuildGates®Extreme Synthesis tool.

Other Information Sources

For more information about BuildGates Extreme and other related products, you can consultthe sources listed here.

■ BuildGates Synthesis User Guide

■ Command Reference for BuildGates® Synthesis and Cadence® PKS

■ Datapath for BuildGates Synthesis and Cadence PKS

■ Design for Test (DFT) Using BuildGates Synthesis and Cadence PKS

■ Distributed Processing of BuildGates® Synthesis

■ HDL Modeling for BuildGates® Synthesis

■ Low Power for BuildGates® Synthesis and Cadence® PKS

■ SDC Constraints Support Guide

■ Common Timing Engine (CTE) User Guide.


Cadence Synthesis Rapid Adoption KitPreface

The following books are helpful references.

■ IEEE 1364 Verilog HDL LRM

■ Tcl Reference, Tcl and the Tk Toolkit, John K. Ousterhout, Addison-Wesley PublishingCompany

Documentation Conventions

Text Command Syntax

The list below describes the syntax conventions used for the BuildGates Synthesis textinterface commands.

literal Non-italic words indicate keywords that you must enter literally.These keywords represent command or option names.

argument Words in italics indicate user-defined arguments or informationfor which you must substitute a name or a value.

| Vertical bars (OR-bars) separate possible choices for a singleargument.

[ ] Brackets denote optional arguments. When used with OR-bars,they enclose a list of choices from which you can choose one.

{ } Braces are used to indicate that a choice is required from the listof arguments separated by OR-bars. You must choose one fromthe list.

{ argument1 | argument2 | argument3 }

... Three dots (...) indicate that you can repeat the previousargument. If the three dots are used with brackets (that is,[argument]...), you can specify zero or more arguments. Ifthe three dots are used without brackets (argument...), youmust specify at least one argument, but can specify more.

# The pound sign precedes comments in command files.



Using Menus

GUI commands can take one of three forms.

CommandName A command name with no dots or arrow executes immediately.

CommandName… A command name with three dots displays a form for choosingoptions.

CommandName -> A command name with a right arrow displays an additional menuwith more commands. Multiple layers of menus and commandsare presented in what are called command sequences, forexample: File – Import – LEF. In this example, you go to the Filemenu, then the Import submenu, and, finally, the LEF command.

Using Forms

… A menu button that contains only three dots provides browsingcapability. When you select the browse button, a list of choicesappears.

OK The OK button executes the command and closes the form.

Cancel The Cancel button cancels the command and closes the form.

Apply The Apply button executes the command but does not close theform.



1Before You Begin

This Rapid Adoption Kit (RAK) consists of the following modules:

■ Getting Started with BuildGates Synthesis

■ Getting Started with Design For Test

■ Getting Started with Datapath

■ Getting Started with Low Power Synthesis

Each module highlights a specific feature for BuildGates® Synthesis.

Invoking BuildGates Synthesis or BuildGates ExtremeSynthesis

For the first two modules you can use BuildGates® Synthesis. For the remaining modules youneed to use BuildGates® Extreme Synthesis.

➤ To invoke BuildGates Synthesis in a text-based, Tcl shell, enter the following commandat the UNIX prompt:

bg_shell

➤ To invoke BuildGates Synthesis in graphical user interface (GUI) mode, enter thefollowing command at the UNIX prompt:

bg_shell -gui

Note: To invoke BuildGates® Extreme Synthesis, replace bg_shell with bgx_shell.

For help with your BuildGates Synthesis installation, see the BuildGates Synthesis UserGuide.


Cadence Synthesis Rapid Adoption KitBefore You Begin

Command Language Interface

BuildGates Synthesis is one of the first EDA tools to use Tcl as its command language. Tclwas developed for EDA tools at UC Berkeley and has quickly become a command interfacestandard for EDA tools. Tcl is a simple language with very few rules, so it is easy to learn. Formore details on the Tcl language, see either of these references:

■ Tcl and Tk Toolkit, John Ousterhout, Addison-Wesley Publishing Company

■ Practical Programming in Tcl and Tk, Brent B. Welch

Interactive commands entered into bg_shell (or bgx_shell) are saved in a command filecalled ac_shell.cmd. Commands and console messages are saved in a fileac_shell.log. You can use ac_shell.cmd input to bg_shell using the sourcecommand to recreate the previous execution of bg_shell. A setup file is saved in yourdirectory under .ambit/ambit.state which saves your GUI color settings, defaultvariables, and so on.

Getting Started

Set up your UNIX Environment

Make sure that your .cshrc file specifies the path to the directory in which the software isinstalled.

Download the Tutorial Data

1. Download the tutorial data to a new directory of your choice. For example,

cp -rf your_install_path/doc/syntut/RAK/RAK.tar.gzmy_tutorial/.

2. Extract the data from the tar file:

cd my_tutorial

gzip -dc RAK.tar.gz|tar -xvf -

This command creates the RAK directory in the current directory.



Install the Libraries

All modules share the same Artisan libraries.

To install the library, do the following:

1. Change directory to the RAK directory.

2. Enter the following command at the UNIX prompt:

INSTALL_LIB

The library installation process starts and you are asked whether or not you accept theArtisan license agreement.

Important

Read the agreement on terms of use. The agreement is also available inLIB_LICENSE.TXT (in the my_tutorial/RAK directory) for your review. Byinstalling and using the library with this tutorial, you are agreeing to the terms of theagreement. If you do not agree to the terms as specified, we advise that you do notproceed with this tutorial.

Note: If you do not have perl installed on your system, you can unzip the library.zipfile manually. Doing so indicates acceptance of the Artisan library license agreement asdescribed in LIB_LICENSE.TXT file. For more information, read the FAQ.txt file.

Regarding the Results

Important

Your results might differ from the results shown in the different modules due to thedifference in runs and release versions.



2Getting Started with BuildGatesSynthesis

■ Introduction to BuildGates Synthesis on page 16

■ Objectives on page 16

■ Example Design on page 16

■ Setting Up to Run the Tutorial on page 18

■ Basic BuildGates Flow on page 19

❑ Setting Up Your Design Environment on page 20

❑ Setting Global Variables on page 20

❑ Reading the Technology Library on page 21

❑ Reading the HDL Models for the Design on page 23

❑ Creating a Generic Gate-Level Netlist on page 24

❑ Setting Test Synthesis Assertions on page 26

❑ Setting Constraints on page 30

❑ Checking Constraints on page 39

❑ Setting Path Groups on page 42

❑ Optimizing the Design on page 43

❑ Generating Reports on page 45

❑ Writing Netlist and Database Files on page 51

❑ Setting Scan Chain Assertions on page 52

❑ Incremental Timing Optimization on page 55

■ Interfacing with Physical Design Tools on page 59

■ Using BuildGates Synthesis Graphical User Interface on page 61

■ Migrating to BuildGates from Design Compiler on page 66


Cadence Synthesis Rapid Adoption KitGetting Started with BuildGates Synthesis

■ Distributed Synthesis on page 71

■ Summary on page 72

Introduction to BuildGates Synthesis

BuildGates® Synthesis is a high-capacity and high-performance chip-level synthesis tool withbuilt in signoff-quality, fast, full-chip timing engine. Fast and flexible, BuildGates Synthesissupports a wide variety of design styles such as multiple clocks, including both edge triggeredand level sensitive with cycle stealing.

BuildGates Synthesis has a high capacity database that allows you to synthesize more of thedesign at once. Its fast runtime assures rapid turnaround, making chip-level synthesispractical. In addition, high-capacity enables productivity gains by eliminating the need forexcessive resources and time required for elaborate bottom-up script development.

BuildGates Synthesis also offers automatic time budgeting, integration with physical designtools, VHDL and Verilog support, support of both reads and writes of netlist EDIF 2.0, Tclcommand line interface for shell level control, transforms for performing focusedoptimizations, schematic and textual report capabilities, and integrated DFT analysis andscan insertion.

Capable of running in both command line mode and in graphical user interface (GUI) mode,the BuildGates Synthesis tool delivers dramatic performance and productivity benefits overconventional synthesis tools.

Objectives

In this brief self-teaching tutorial, you will become familiar with the BuildGates synthesis flowby running the tool on the test design. At the end of this module, you will have anunderstanding of BuildGates Synthesis methods, timing analysis, optimization methods, andtest support.

Note: This module takes about an hour to run.

Example Design

The example design provided with this module is a Verilog description of a Dual ToneMulti-Frequency (DTMF) receiver. In a telephone network, DTMF is a common in-bandsignaling technique used for transmitting information between network entities. DTMF signalsare commonly generated by touch-tone telephones.

Figure 2-1 on page 17 shows a block diagram of the DTMF receiver.



Figure 2-1 DTMF Block Diagram

SPI ULAW_CONVERTER

DATA SAMPLE

DATA SAMPLE RAM

DMA CONTROLLER

BUS ARBITER

SCRATCH

TDSPTDSP_CS_DS

ROMASCII DIGIT

RCC

REGISTER

TDSP MUX

MUX

DATA RAM

Note: This is a high-level diagram.spi_clk

spi_fs

spi_data

dout(7:0)

clk reset

dflag read

upcm(7:0)

lpcm(15:0)

dout[15:0]

t_data[15:0]

t_data_in[15:0]

clk reset

bus_grant

top_buf_flag

reset

t_write_rcc

bus_request_out

bus_grant_in

Scan flops previously added(block attributed with

Not all connections are shown.

set_dont_modify property).



Setting Up to Run the TutorialNote: We assume that you already copied the data. If not, see Getting Started on page 12.

Required License

You need a BuildGates (BG) license to run this module.

Required Files

You need the following files to run this tutorial:

■ Synthesis library

■ Verilog or VHDL netlist, preferably at RTL level.

■ Constraints

The your_install_path/doc/syntut/RAK/tutorial_buildgates directorycontains the files needed to run this module. It has the following directory structure:

tutorial_buildgates Root directory

tcl Scripts to run this module

rtl Verilog and VHDL design modules

lib Synthesis libraries

rpt Timing, area, hierarchy and other report files

adb Database files

run_dir Running directory



Basic BuildGates Flow

Set Constraints

Generate Reports

Optimize Design

Check Constraints

Do Incremental Timing Optimization

Set Scan Chain Assertions

Read Libraries

Write Netlist and Database Files

Read HLD Model for Design

Set Test Synthesis Assertions

Create Generic Gate-Level Netlist

Set Path Groups

Modify Constraints

Backannotate Parasitics from Place and Route



Setting Up Your Design Environment

1. Change to the run_dir directory in the tutorial_buildgates directory.

2. For this tutorial, invoke BuildGates Synthesis in shell mode:

unix_shell> bg_shell

Note: You will explore the graphical user interface later on.

3. Set up your design environment by running the following script in bg_shell:

bg_shell> source ../tcl/setup.tcl

The setup.tcl file defines Tcl variables for the rtl, library, report, database, and Tcldirectories. This file contains the following commands:

set rak_dir ..set tcl_dir $rak_dir/tclset rtl_dir $rak_dir/rtlset lib_dir $rak_dir/libset rep_dir $rak_dir/rptset adb_dir $rak_dir/adb

The variable rak_dir is set to the parent directory and other variables are set to theirrespective directories under the current directory.

Setting Global Variables

BuildGates Synthesis provides many global variables to control the overall run procedure andpolicies independent of the design. All global variables have default values when you startbg_shell. For more information on global variables, see the Global Commands forBuildGates Synthesis and Cadence PKS.

You can set the value of any global variable by issuing the following command:

bg_shell> set_global var_name value

You can obtain the value of any global variable by issuing the following command:

bg_shell> get_global var_name

➤ Set some globals by running the following script:

bg_shell>source $tcl_dir/set_globals.tcl

The set_globals.tcl script sets three variables:

set_global message_verbosity_level 8set_global echo_commands trueset_global report_precision 5set_global fix_multiport_nets trueset_global sdc_write_unambiguous_names falseset_global line_length 1000



■ The message_verbosity_level variable controls the level of verbosity of themessages generated by bg_shell in reporting information, warnings, and errors.

■ The echo_commands variable causes each command to be echoed in the standardoutput prior to its execution.

■ The report_precision variable controls the number of digits appearing after thedecimal point in timing reports, report_timing andreport_cell_instance_timing. The default is 2.

■ The fix_multiport_nets variable is considered during the do_optimizestage.When set to true, the do_xform_fix_multiport_nets command is runautomatically and any output signal driving multiple output ports is split into different netsby inserting buffers in the paths.

■ The sdc_write_unambiguous_names variable suppresses the output ofunambiguous hierarchical names in sdc constraint.

■ The line_length variable controls the line length in the console window.

Reading the Technology Library

A technology library containing timing and power models is required for successful mappingof RTL operations into technology-specific cells. In this tutorial, you will use the “ArtisanTSMC 0.18u” libraries to optimize the design.

1. Read in the synthesis technology libraries by running the following script:

bg_shell> source $tcl_dir/read_lib.tcl

The read_lib.tcl script contains the following commands:

read_tlf $lib_dir/slow_4.3.tlfread_tlf $lib_dir/pllclk_slow_4.3.tlfread_tlf $lib_dir/ram_128x16A_slow_4.3.tlfread_tlf $lib_dir/ram_256x16A_slow_4.3.tlfread_tlf $lib_dir/rom_512x16A_slow_4.3.tlfread_library_update $lib_dir/tpz973gwc-lite_4.3.tlf

set_global target_technology slow

❑ The first five commands read in .tlf libraries. Although BuildGates currentlysupports TLF version 4.4, version 4.3 is used for this design.

You can load multiple .alf, and .tlf libraries in BuildGates with separateread_alf and read_tlf commands for each library.

❍ Files with the .tlf extension are in Cadence Timing Library Format.

❍ Files with the .alf extension are in Ambit Library Format.



Both .alf and .tlf formats are compatible with the Synopsys .lib format.Usually the ASIC or library vendors provide libraries in .alf and/or .tlf format.

If the vendor only provides a .lib file, you can compile the .lib file into a .tlffile using the syn2tlf utility (installed in the your_install_dir/tools.platform/tlfUtil/bin directory):

unix_prompt> syn2tlf my_cells.lib my_cells.tlf

In addition to the .lib, .alf, and .tlf formats, BuildGates Synthesis alsosupports Synopsys Stamp Models, IEEE 1481 Delay and Power Calculation system(DCL) libraries, Open Library API (OLA) libraries, and the GrayBox model forreusable megacells or IP cores.

For more information on supported library formats (and the syn2tlf utility), see theUsing Timing Libraries chapter of the Common Timing Engine (CTE) UserGuide..

❑ The read_library_update command merges pad cells from thetpz973gwc-lite_4.3.tlf pad library into the target technology library,slow.alf.

You can set the target technology with the set_global target_technologycommand. By default, the first library you read becomes the target technology. Inaddition to merging cells from another library, the read_library_updatecommand can also be used for merging wireload models and operating conditionsinto the target library.

The previous example shows a complex use of the read_library command.However, in most cases, you can read the library with a single line:

read_tlf my.tlf

❑ The set_global target_technology slow command is used to specify thetarget library slow.alf. During optimization, BuildGates Synthesis maps a genericnetlist to the cells from the target library slow.alf. You can set multiple targetlibraries by providing a list of libraries with the set_global command.

2. View the contents of the slow technology library by entering the following command:

bg_shell>report_library

The report_library command reports on the cells in the library, the wireload models,and the operating conditions.



Reading the HDL Models for the Design

BuildGates Synthesis supports Verilog, VHDL, and EDIF hardware description language(HDL) models. You can describe your design in the Verilog, VHDL, or EDIF language.

BuildGates Synthesis is compatible with the Synopsys synthesis tool. You can read the sameRTL that you enter into the Synopsys tool into BuildGates Synthesis without making anychanges. BuildGates even supports most of the Synopsys pragmas, such astranslate_off, translate_on, and synthesis directives such as full_case,parallel_case, infer_mux. For more details on supported pragmas and synthesisdirectives, see Supported Synopsys Directives in the HDL Modeling for BuildGatesSynthesis.

➤ Read in the HDL model for the design by entering the following command:

bg_shell>source $tcl_dir/read_rtl.tcl

The read_rtl.tcl script contains the following commands:

set_global hdl_verilog_vpp_arg -I$rtl_dir

read_verilog $rtl_dir/accum_stat.vread_verilog $rtl_dir/alu_32.vread_verilog $rtl_dir/arb.vread_verilog $rtl_dir/data_bus_mach.vread_verilog $rtl_dir/data_sample_mux.vread_verilog $rtl_dir/decode_i.vread_verilog $rtl_dir/digit_reg.vread_verilog $rtl_dir/dma.vread_verilog $rtl_dir/dtmf_recvr_core.vread_verilog $rtl_dir/execute_i.vread_verilog $rtl_dir/mult_32_dp.vread_verilog $rtl_dir/m16x16.vread_verilog $rtl_dir/port_bus_mach.vread_verilog $rtl_dir/prog_bus_mach.vread_verilog $rtl_dir/ram_128x16_test.vread_verilog $rtl_dir/ram_256x16_test.vread_verilog $rtl_dir/results_conv.vread_verilog $rtl_dir/spi.vread_verilog $rtl_dir/tdsp_core.vread_verilog $rtl_dir/tdsp_core_glue.vread_verilog $rtl_dir/tdsp_core_mach.vread_verilog $rtl_dir/tdsp_data_mux.vread_verilog $rtl_dir/tdsp_ds_cs.vread_verilog $rtl_dir/test_control.vread_verilog $rtl_dir/ulaw_lin_conv.vread_verilog $rtl_dir/iopads.vread_verilog $rtl_dir/dtmf_chip.v

The set_global hdl_verilog_vpp_arg -I$rtl_dir command enables the Verilogpre-processor to search Verilog files in the $rtl_dir directory.

You can see that you can read multiple Verilog files using the read_verilog command foreach file. The read_verilog $rtl_dir/accum_stat.v command reads theaccum_stat.v file from the rtl_dir directory.



To read a VHDL file, you can use the read_vhdl command. You can use theset_vhdl_library logical_library_name directory command to associatethe logical library with a physical directory. You can set the hdl_vhdl_environmentvariable to synopsys to select the arithmetic package supported by the Synopsys VHDLcompiler. By default, this variable is set to standard which is the IEEE standard package.

While parsing the design modules, the read_verilog and read_vhdl commands willreport syntax errors, warnings, and other problems. For example, one of the warnings you seewhile parsing the accum_stat.v file is:

--> WARNING: ’delay’ statement is not supported for synthesizable modules (File ./rtl/accum_stat.v, Line 68) <VLOGPT-035>.

assign #1 acc_v = accum[‘S_ACC] ;

#1 specifies a one-unit delay in Verilog. The # construct is typically used for simulation, but itis not a synthesizable construct. You can turn off the above warning message by using thecommand, set_message_verbosity VLOGPT-035 off.

Creating a Generic Gate-Level Netlist

➤ Transform the design into a hierarchical, gate-level netlist by entering the followingcommand:

bg_shell>do_build_generic

The do_build_generic command transforms the design into a hierarchical, gate-levelnetlist consisting of technology-independent logic gates using:

■ Components from the Ambit Synthesis Technology Library (ATL)

■ Arithmetic and logical operators from the AmbitWare Components Library (AWACL)

The command performs constant propagation, loop unrolling, lifetime analysis, registerinferences, and logic mapping. You must execute this command before any optimizationcommands (such as do_optimize or do_xform_*) can be applied.

Note: If you are reading a gate-level netlist mapped to cells from the library, you still need torun the do_build_generic command.

For more information about the generic synthesis step, see the BuildGates Synthesis UserGuide. By default, the do_build_generic command uses timing sensitive implementationfor all the operators. BuildGates Synthesis also provides an architecture selection directive toselect different types of architectures for arithmetic operators. In BuildGates ExtremeSynthesis, architectures are automatically selected based on timing and context. For moreinformation, see Chapter 4, “Getting Started with Datapath.”



The following is one of the messages generated by the do_build_generic command:

Info: Processing design ’spi’ <CDFG-303>.Statistics for case statements in module ’spi’ (File ./rtl/spi.v)<CDFG-800>.+----------------------------------------+| Case Statistics Table ||----------------------------------------|| Line | Type | Full | Parallel ||---------+---------+---------+----------|| 97 | case | AUTO | AUTO |+----------------------------------------+

This message provides information on a case statement at line 97 in the spi module. Thecase statement type can be case, casex, or casez. It tells you whether the case statementcan be implemented with the full case (priority encoding logic) or parallel case (parallelencoding logic) synthesis directive. With the AUTO option, the tool will decide to implementthe case statement using either full case or parallel case depending on the constraints. If thesynthesis directives in the RTL include either full or parallel, the Full and Paralleloptions in the case statistics table will be set to YES. If the full case synthesis directive isincorrectly used, the do_build_generic command generates warnings for possible RTLand gate-level simulation mismatches.

Each sequential device that is inferred by the do_build_generic command is reported ina sequential element table as shown below.+----------------------------------------------------------------------------------------+| Sequential Elements ||----------------------------------------------------------------------------------------|| Module | File | Line | Name | Type | Width | AS | AR | SS | SR |+------------+--------------------+------+-------------+------+-------+----+---+----+----+| tdsp_ds_cs | ./rtl/tdsp_ds_cs.v | 128 | t_sel_7_reg | FF | 1 | N | Y | N | N || tdsp_ds_cs | ./rtl/tdsp_ds_cs.v | 141 | t_bit_7_reg | FF | 1 | N | Y | N | N |+----------------------------------------------------------------------------------------+

Finished processing module: ’tdsp_ds_cs’ <MODGEN-110>.

The first line of data in this table indicates that line 128 in the tdsp_ds_cs.v file infers aregister named t_sel_7_reg. It is of type D_FF and has 1 bit width. This register has no (N)asynch set control (AS), synch set control (SS), synch reset control (SR), but does have (Y)asynch reset control (AR).

For more information on case statements and RTL coding styles for synthesis, see the HDLModeling for BuildGates Synthesis.

Checking the Netlist

After you create a generic netlist using the do_build_generic command, Cadencerecommends that you check the structural connectivity of the netlist.

1. To check the structural connectivity of the netlist, enter the following command:

bg_shell>check_netlist



The check_netlist command performs a number of checks on the structuralconnectivity of the netlist, including checks for recursively defined modules,combinational feedback, undriven nets and pins, multiply driven nets and pins, andundriven ports. You can run the check_netlist command on a mapped netlist as well.

The check_netlist command generates the following report:

Current module: dtmf_chipThe number of recursively defined modules(at least): 0The number of combinational feedbacks: 0The total number of undriven nets/pins: 1The total number of multiply driven nets: 0The total number of potential multiply driven nets: 0The total number of undriven ports: 0The total number of common inputs between data and enable: 0

You should justify all warnings before proceeding further.

2. To see the details of the undriven nets and pins, use the -verbose option:

bg_shell>check_netlist -verbose

This command displays warnings like this:

--> WARNING: Undriven instance pin ’DTMF_INST/int’ found in module ’dtmf_chip’<FNP-533>.

In this example, you can ignore the warning because the int pin in instance DTMF_INSTis not used.

Setting Test Synthesis Assertions

As ASICs become more complex, it has become a standard practice to use test synthesisduring logic synthesis to integrate design-for-test (DFT) logic into designs. The foundry'stester uses these DFT logic structures to check the chip for manufacturing defects. The logicstructures produced by test synthesis do not affect the function of the chip.

The test synthesis capabilities of BuildGates Synthesis perform a single-pass, automatic,full-scan insertion prior to and during logic optimization. The test synthesis capability allowsyou to trade off timing and area during optimization. Currently, it does not perform automatictest pattern generation (ATPG), boundary scan/JTAG, and BIST. BuildGates Synthesis isdesigned to work well with the FastScan® tool from Mentor Graphics and the Turboscan® toolfrom Syntest, and it is compatible with most other vendors as well. For more information aboutBuildGates test features, refer to Chapter 3, “Getting Started with Design For Test.”

Finding Objects

To set assertions and constraints, you must be able to find various objects such as ports, netnames, instance names and module names in your design database.



The find command finds design objects and prepares a list for other bg_shell commands.Unless you specify the -regexp option, BuildGates uses glob-style pattern matching to finddesign objects in the design database. Multiple wildcard matching in a name is permitted.

BuildGates Synthesis assigns a unique identifier (ID) to each object type (cell, component,module, instance, net, pin, port, and so on). The find command returns the object ID, whichis an integer number. To get more information on an object, use the get_info command.

Typically, the output of the find command (a list of objects found by this command) is anargument to another command that accepts a list of objects and performs some task.

For example, the following command sets all input ports of a module to the same input delay:

set_input_delay 0.2 [find -ports -input *] -clock master_ck

Setting Assertions

1. Set assertions for test modes and connection preferences by running the following script:

bg_shell>source $tcl_dir/scan_assert.tcl

The scan_assert.tcl script contains the following commands:

issue_message -type info "Mapping test_control module"

set_current_module test_controldo_xform_mapset_dont_modify [find -hier -module test_control]set_current_module [find -module dtmf_chip]

issue_message -type info "Setting up for scan synthesis in tieback mode"

set_scan_style muxscanset_global dft_scan_path_connect tiebackset_global dft_scan_avoid_control_buffering trueset_scan_mode IOPADS_INST/Pscanenip/C 1

check_dft_rules

The script contains two sections.

2. Examine the commands in the first section of the scan_assert.tcl file.

This section applies to the test_control module only. This module consists of a scanclock muxed with all the clocks used in the dtmf_chip module and is controlled by thetest_mode signal. For this tutorial, you do not want to optimize this module.

❑ The set_current_module command sets test_control as the design contextfor DFT, then sets the context back to the DTMF design for optimization. You will lookat this command in more detail in Setting Constraints on page 30.



❑ The do_xform_map transform maps the test_control module to targettechnology slow. In this case, all you are doing is mapping the test control logic tothe target technology, and then telling the tool not to modify it. Since this is testcontrol logic, it is not speed sensitive. Optimizing the Design on page 43 describesthe transform commands in more detail.

❑ The set_dont_modify command keeps the instances, nets, or submodules in thetest_control module from being modified by the optimization tool.

❑ The second set_current_module command sets the timing and optimizationcontext to the dtmf_chip module for optimization.

3. Examine the commands in the second section of the scan_assert.tcl file.

❑ The set_scan_style command sets the scan style to muxscan (muxed-D scanflops) for the current module and all child modules. BuildGates also supports scanflops of type clocked_scan, clocked_lssd, and aux_clocked_lssd.

❑ The set_global dft_scan_path_connect tieback variable sets the scanmode to tieback for later connection. The tiebackmode connects the scan-dataoutput pin of the scan cell back to its own scan-data input pin. Cadencerecommends that you set the scan mode to tieback before optimization. After thescan chain is created and connected, you can set the value of this global variable tochain.

❑ The set_global dft_scan_avoid_control_buffering true command isoptional. It prevents buffering of the high fanout scan mode control signal after it isinserted. By default, high fanout signals are buffered by timing optimization anddesign rule fixing. This command overrides the default behavior for the scan modesignal only.

❑ The set_scan_mode IOPADS_INST_Pscanenip/C 1 command specifies thatinput port IOPADS_INST_Pscanenip/C activates shifting of scan data through thescan chain when the port is active high (1). When you use the set_scan_modecommand to define the input port of a scan chain, you must specify whether the scanchain is active-high (1) or active-low (0). There is no default for this argument. If youdo not use the set_scan_mode command, the test synthesis tool creates an activehigh top-level port with the default name BG_scan_enable.

❑ The check_dft_rules command checks your design for selected DFT ruleviolations such as uncontrollable clocks and uncontrollable asynchronous signals.

The tool does not insert scannable elements where DFT violations occur. It displaysa message if it detects any violations. You should fix all reported problems either bymodifying your RTL or by using the auto-DFT fix capabilities described in ImprovingTestability of Your Design in Design For Test (DFT) Using BuildGates Synthesisand Cadence PKS. Otherwise, your fault coverage is reduced.



The following error message is one of the messages reported bycheck_dft_rules:

==> ERROR: DFT Violation 6: Internally driven Clock net ’DTMF_INST/m_digit_clk’ in module ’dtmf_recvr_core’ (File ./rtl/dtmf_recvr_core.v, Line79) <DFT-316>. Traced its effective fanin cone to: :test_mode scan_clk DTMF_INST/RESULTS_CONV_INSTdigit_clk_reg:Q

In the DTMF design, all clocks are derived from the primary clock refclk using aPhase Lock Loop (PLL), which causes a DFT violation. In muxed scan style, allclocks must be controllable from a primary input to allow the tester to control theregisters during the test process. Figure 2-2 shows some examples of DFTviolations.

Figure 2-2 Examples of DFT Violations

Fixing DFT Violations

You can fix DFT violations by fixing the RTL or using the auto-fix DFT capabilities in the tool.Additionally, if test mode activated logic has been added to the RTL, DFT violations specificto this test mode logic, can be safely bypassed by using the set_test_mode_setupassertion. You can fix the previous DFT violation by using the test_mode signal to bypassthe clock gating logic or internal clocks during test mode.

➤ Fix the violations by running the following script:

bg_shell>source $tcl_dir/fix_dft_rules.tcl

The fix_dft_rules.tcl script contains the following commands:

set_test_mode_setup test_mode 1set_test_mode_setup reset 0check_dft_rules

clock

DFT Violation: Gated Clock

DFT Violation: Derived Clock

derivedclock

int_clk



■ The set_test_mode_setup test_mode 1 command sets the test_mode input portto 1 during the entire test session. The second set_test_mode_setup command setsthe reset port to 0 for the entire test session.

■ The check_dft_rules command displays a summary of the DFT clock domains, anyinternal clock domain points (specified using the set_dft_internal_clock_domainassertion), and the number of registers associated with those domains that have passedthe DFT rules checks:

Info: Partitioning registers for scan based on clock domain. <DFT-325>.Clock Domain 0 from pin ’scan_clk’ (Neg Edge) <Internal Pin: ’None’> has 129 f/fClock Domain 1 from pin ’scan_clk’ (Pos Edge) <Internal Pin: ’None’> has 411 f/fTotal Clock domains: 2 for 540 f/f

Info: Total Scannable register count: 540 <DFT-340>.

In addition to uncontrollable clocks, internally generated clocks, and uncontrollableasynchronous signals, you can check your design for combinational loops and flip-flops withpotential race-conditions between the data and clock signals by setting the following variablesbefore you run check_dft_rules.

set_global dft_enable_combinational_loop_check trueset_global dft_enable_race_condition_check true

If you set dft_enable_race_condition_check for the DTMF design you will get thefollowing warning message when you run check_dft_rules:

Info: Checking for registers with clock/data race condition. <DFT-326>.--> WARNING: Input ’test_mode’ fans out to both data and enable pins of sequential element ’DTMF_INST/SPI_INST/dflag_reg’ of module ’spi.’ This may create potential race conditions. Try ’-flatten on’ on this module <FNP-543>.

For more information about BuildGates Synthesis test features, such as ATPG, boundaryscan, and scan chain re-ordering refer to Chapter 3, “Getting Started with Design For Test.”

Setting Constraints

In addition to libraries and a functional RTL model of the design, the logic synthesis processrequires a set of constraints on the design. By default, BuildGates Synthesis meets yourtiming constraints first, then tries to achieve the smallest area. For more information onchanging the area and timing priority or making area a priority, see the Common TimingEngine (CTE) User Guide.

The performance generally refers to the maximum clock frequency at which the designimplementation (netlist) can operate. You do not need to specify any area constraints for thedesign because BuildGates always strives for the smallest possible design area for the giventiming and physical constraints.



Important

BuildGates Synthesis always tries to meet the specified timing constraints. Do notsynthesize your design without basic I/O and clock constraints because BuildGatesis a performance, timing-driven synthesis engine. Do not over-constrain the designto meet the desired timing constraints. For example, you do not need to set an 8 nsclock to meet a 10 ns clock constraint, which is a common practice in other synthesistools. Do not set your I/O arrival times at 95% of the clock period, as is common inother synthesis tools. If you over constrain the design, you will likely experience verylong run times while the tool works very hard to meet these constraints.

Note: If you already have Synopsys Design Compiler (DC) or Prime Time (PT) timingconstraints, use the BuildGates Synthesis Constraint Translator to translate these constraintsto a BuildGates Synthesis constraints file. For more information, refer to Migrating toBuildGates from Design Compiler on page 66.

➤ Set the commonly used constraints by running the following script:

bg_shell>source $tcl_dir/constraints.tcl

The following sections discuss the different sections of the constraint file in detail:

■ Setting Up Hierarchical and Timing Context on page 31

■ Setting Clock Constraints on page 32

■ Setting Constraints on Primary I/O Ports on page 36

■ Setting Multicycle and False Paths on page 37

■ Setting Design Rule Constraints on page 37

■ Setting Wire Load Models on page 38

Setting Up Hierarchical and Timing Context

The Setting up Hierarchical and Timing Context section of the constraints.tcl filecontains the following commands:

# Setting up Hierarchical and Timing Context"issue_message -type info "--> Setting up Hierarchical and Timing Context ..."

set_current_module dtmf_chipset_top_timing_module dtmf_chip

■ The first command issues the message “Setting up Hierarchical and Timing Context.”This message is written in the log file.



■ The set_current_module command makes dtmf_chip the current module. Designobjects such as nets and ports, referenced by subsequent commands, must be specifiedrelative to this module. All searches for design objects start in the dtmf_chip module.Hierarchical design objects are referenced with dtmf_chip as the root (top) of thehierarchy.

Note: If a module has multiple instances and each instance requires a separate set ofconstraints, you can use the set_current_instance command.

■ The set_top_timing_module command identifies the module to be used bysubsequent commands as a context for setting timing constraints. All constraints are setwith reference to the dtmf_chip module. The optimization commands will operate onthe dtmf_chip module and its hierarchy.

This is a unique and very powerful feature of BuildGates Synthesis. If you set a new toptiming module, you change the context for the subsequent timing constraints and theoptimization steps. The constraints applied to the previous top timing module arepreserved but do not affect the steps carried out in the new top timing module.

Setting Clock Constraints

The DTMF design has a primary clock port, refclk, which goes through a phase locked loopcircuit and internally generates a clock, clk, with a 6 ns period and several divided clocksrcc_clk, spi_clk, dsram_clk, ram_clk, and digit_clk, each with 12 ns periods. Allthese clocks are muxed with the scan clock in the test_control module. You will set theclock definition for these internal clocks at the output of the test_control module.

BuildGates uses the concept of ideal and applied clocks. An ideal clock is a perfectrepresentation of the clock, while the applied clock is a clock applied to the system. Forexample, on a lab bench the ideal clock is the clock source (for example, waveform generator)and the applied clock is the connection to the chip under test. The advantage of using an idealclock and applied clocks is that a common ideal clock can drive any number of applied clocks,all with different insertion delays while still maintaining the fundamental timing relationship.The split between ideal and applied makes it simple to construct complicated interrelatedclock systems.

Clock constraints are required to set the timing constraints on combinational logic betweenregisters.

1. Examine the commands defined in the Setting Ideal Clocks section of theconstraints.tcl file.

issue_message -type info "--> Setting Ideal Clocks ..."set_clock vclk1 -period 6.0 -waveform { 0 3.0 }set_clock vclk2 -period 12.0 -waveform { 0 6.0 }



❑ The first set_clock command defines the ideal clock vclk1with period 6, leadingtransition at 0, and trailing transition at 3: Since the leading transition is a rising edge,vclk1 is treated as a positive clock.

❑ The second command defines another positive ideal clock, vclk2, with period 12,leading transition at 0, and trailing transition at 6:

These two ideal clocks will be used as a global reference signal for all the data signalsin the DTMF design. In a single clock design, you will need only one ideal clock. However,in a multi-phase clock design, you will need several ideal clocks.

Once the ideal clocks are defined, you can define actual clock signals arriving at input/internal ports of the DTMF design.

2. Examine the commands defined in the Setting Primary Clocks section.

issue_message -type info "--> Setting Primary Clocks ..."set_clock_root -clock vclk1 [find -port refclk ]

The set_clock_root command assigns positive polarity to ideal clock vclk1 andassociates primary input pin refclk (system clock) with ideal clock vclk1.

3. Examine the commands defined in the Setting Internally Generated Clocks section.

issue_message -type info "--> Setting Internal Clocks ..."

set_generated_clock -name vclk1_int1 -from \DTMF_INST/TDSP_CORE_INST/DATA_BUS_MACH_INST/clk \-divide_by 2 DTMF_INST/TDSP_CORE_INST/DATA_BUS_MACH_INST/write_reg/Qset_generated_clock -name vclk1_int2 -from DTMF_INST/DMA_INST/clk \-divide_by 2 DTMF_INST/DMA_INST/write_reg/Q

The set_generated_clock commands create two generated clocks vclk1_int1and vclk1_int2, which are derived from the clock source vclk1. This commandcreates a new clock signal from the clock waveform of a given pin in the design, or anexisting virtual (ideal) clock signal, and binds it with the targeted pins (listed at the endof the command). Whenever the source clock changes, the derived clock(s) changeautomatically. You can generate the new clock waveform by

❑ Multiplying the frequency of the source clock

❑ Dividing the frequency of the source clock

❑ Selecting the edges of the source clock to be mapped on to the edges of the newclock

For examples about assertions on generated clocks, see Specifying Generated Clocksin the Common Timing Engine (CTE) User Guide..

4. Examine the commands defined in the Setting Muxed Clocks section.

issue_message -type info "--> Setting Muxed Clocks ..."set clock_pin [find -hier -pin DTMF_INST/TEST_CONTROL_INST/m_clk]



set drive_pin [get_drive_pin -hier [get_info $clock_pin net] ]set_clock_info_change -clock vclk1 -pos $drive_pinset_clock_insertion_delay -pin $drive_pin 2.0

foreach clock {m_rcc_clk m_spi_clk m_dsram_clk m_ram_clk m_digit_clk} { set clock_pin [find -hier -pin DTMF_INST/TEST_CONTROL_INST/$clock] set drive_pin [get_drive_pin -hier [get_info $clock_pin net] ] set_clock_info_change -clock vclk2 -pos $drive_pinset_clock_insertion_delay -pin $drive_pin 2.0

}

set_clock_uncertainty 0.25

❑ The set clock_pin command defines the clock_pin Tcl variable and assignsit a value of DTMF_INST/TEST_CONTROL_INST/m_clk, which is a clock pin.

❑ The set drive_pin command defines the drive_pin Tcl variable and assignsit a value of the pin driving the DTMF_INST/TEST_CONTROL_INST/m_clk net.

❑ The set_clock_info_change command assigns the positive polarity (-pos,which is the default) to ideal clock vclk1 and associates the instance pin driving theDTMF_INST/TEST_CONTROL_INST/m_clk net (actual clock) with the ideal clock.

As you can see, you can associate pins with more than one ideal clock.

You can use set_clock_info_change to change the clock to data, data to clock,and clock to clock for paths going through the specified pins for the downstreamlogic. This command is useful for modeling frequency dividers and clock-shapingcircuits.

Note: In version 5.0 and beyond, BuildGates Synthesis automatically changes aclock network to a data network, so you do not need to use theset_clock_info_change command to change a clock signal to a data signal, butyou still need to use it if you want to change a data signal to a clock signal.

❑ The set_clock_insertion_delay command inserts a 2-unit delay as clocknetwork latency. This means it will take a 2-unit delay for the clock signal topropagate from the clock definition point (instance pin driving DTMF_INST/TEST_CONTROL_INST/m_clk net) to the clock pin of a register. “Clock networklatency delay” is commonly referred to as “clock tree delay.”

The set_clock_insertion_delay command can also be used to add clocksource latency, the time a clock signal takes to propagate from its ideal waveformorigin point to the clock definition point (clock port) in the design. You need to usethe -source option to add clock source latency. In this design, you could use theset_clock_insertion_delay -source command to model the delay througha PLL circuit.

You can specify clock network latency and clock source latency on the clockwaveform as well as the clock port or clock pin. Clock tree delay is used during ideal



clock propagation mode, which is a default mode. Clock tree delays set by theset_clock_insertion_delay command are ignored during clock propagationmode. Actual clock tree delays are used during propagated mode. Theset_clock_propagation command tells the timing analyzer to treat all the clocksignals associated with the current timing top module as either ideal or propagated.

❑ The foreach Tcl loop associates clock pins m_rcc_clk, m_spi_clk,m_dsram_clk, m_ram_clk and m_digit_clk on DTMF_INST/TEST_CONTROL_INST instance with ideal clock, vclk2. For this tutorial, you willnot assign clock_insertion_delay for these clocks.

Clock pins, m_rcc_clk, m_dsram_clk, and m_ram_clk are internally derivedfrom frequency divider logic implemented inside the DTMF_INST/TDSP_CORE_INST/DATA_BUS_MACH_INST and DTMF_INST/DMA_INSTmodules. These clock signals are connected to Q pin write_reg registers. Hence,they will be treated as data signals. The two set_clock_info_changecommands in the Setting Internally Generated Clocks section, are used to changedata signals to clock signals for the paths going through the write_reg/Q pin forthe downstream logic.

❑ The set_clock_uncertainty command specifies a 0.25 unit delay as a clockskew for the vclk1 and vclk2 clock domains. It can also be used to specifyinter-clock skew for different clock domains. Clock uncertainty can also be used asa general method to add pessimism and/or optimism. A positive uncertaintycontributes to pessimism. A negative uncertainty has no meaning physically, but itmakes all slack numbers optimistic. Negative uncertainty can be used to adjustconservative constraints into more realistic ones. Figure 2-3 shows the skewbetween the clocks, clk1 and clk2.

Figure 2-3 Clock Skew

For more information on clock commands or methods, refer to the Common Timing Engine(CTE) User Guide..



Setting Constraints on Primary I/O Ports

You need to constrain the signal changes arriving at primary input ports of the DTMF design.These signal changes are controlled by an external block driving the DTMF block. Toconstrain the output ports, you need to consider the timing requirement of downstreammodules to which output ports of the DTMF block are connected.

➤ Examine the commands defined in the Setting Input/Output ports constraints section ofthe constraints.tcl file.

issue_message -type info "--> Setting Input/Output ports constraints..."set_input_delay -clock vclk1 0.5 [ get_names [ find -inputs -no_clocks] ]set_external_delay -clock vclk1 0.5 [ get_names [ find -outputs port*] ]set_external_delay -clock vclk1 0.5 [ get_names [ find -outputs tdigit*] ]

■ The set_input_delay command (see Figure 2-4) sets a 0.5 unit delay for the signalsto arrive at all input ports of the DTMF block.

The rising and falling edge transitions of data signals arrive at all input ports at a 0.5 unitdelay after the leading edge of the vclk1 clock. Since you have not set the -early or-late option, the input delay is applied for both late (max) and early (min) signals.

■ The set_external_delay commands (see Figure 2-4) set external delays of 0.5 unitson output ports whose names begin with port and tdigit. These ports are driven byregisters clocked by vclk1.

The required time at the output port is computed as if the output port is driving a registerexternal to the design. The data signal must arrive at the input of the external register(including setup time) before the arrival of the clock. In other words, the required time forthe data signal at the output port of your design is calculated by subtracting thepropagation delay through the logic from the clock arrival time at the register of thedownstream block.

Figure 2-4 Input and External Delays

set_input_delay set_external_delay

DTMFModule



Setting Multicycle and False Paths

By default, all paths in a design are considered to be single-cycle paths. However, in theDTMF design, signal propagation for paths going through multipliers spans over multiplecycles. You need to relax the timing constraints on these paths.

➤ Examine the commands in the Setting Multicycle and False Paths section of theconstraints.tcl file:

issue_message -type info "--> Setting Multicycle and False Paths ..."set_cycle_addition -to DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/acc_reg* 1set_cycle_addition -to DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/p_reg* 1set_cycle_addition -to DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/ov_flag_reg* 1

set_false_path -from reset

set_constant_for_timing 0 test_modeset_constant_for_timing 0 scan_en

■ The set_cycle_addition commands indicate that all paths ending in pinsacc_reg*, p_reg* and ov_flag_reg* registers in the DTMF_INST/TDSP_CORE_INST/EXECUTE_INST hierarchy should be treated as two-cycle paths—one cycle addition to the clock driving these registers.

The corresponding Synopsys command is set_multicycle_path 2. One of the mostpowerful and unique features of the set_cycle_addition command is that the cycleaddition number can be a real number. For example, you could use the command,set_cycle_addition -0.2, to constrain paths for 80% of the clock period.

■ The set_false_path command sets paths starting from the reset pin as false path.The timing analyzer ignores these paths, and the paths are optimized for area and nottiming.

■ The set_constant_for_timing commands set the value of the primary portstest_mode and scan_en to 0.

Logic 0 will be propagated through corresponding combinational logic cones and disablesections of the logic for timing analysis.

Setting Design Rule Constraints

In order for a circuit to function correctly, it needs to meet design rule constraints as well. Youcan set all the necessary design rule constraints such as fanout, port capacitance, slew time,wire loads, and operating conditions in BuildGates Synthesis.

➤ Examine the commands in the Setting Design Rules section of the constraints.tclfile.

issue_message -type info "--> Setting Desgin Rules ..."set_slew_time_limit 2.3 [ find -ports -noclocks * ]



set_global fanout_load_limit 15

set_drive_cell -cell PDO04CDG [find -input -noclocks * ]set_port_capacitance [expr [get_cell_pin_load -cell PDIDGZ -pin PAD]*2.0]\

[find -output * ]

■ The set_slew_time_limit command specifies the limit for slew time (transition time)at the input and output ports of the DTMF module.

You can also set global values for the slew time using the global variablesmax_slew_time_limit and min_slew_time_limit, and you can use theset_slew_time_limit command to override these global values.

■ The set_global fanout_load_limit command specifies the maximum value forfanout load limit (number of transistors to be connected) on the ports of a cell and is usedto enforce design rule checks.

■ The set_drive_cell command models the drive strength of external driversconnected to input ports of the DTMF block.

This command identifies output pin PAD of the PDO04CDG library cell driving input portsof the DTMF block. You can also use the set_drive_resistance command to set thedrive resistance.

■ The set_port_capacitance command sets output loads by specifying the outputport capacitance external to the DTMF block.

Setting Wire Load Models

For deep sub-micron designs, using wire load models for synthesizing is becoming lessattractive because the margin of error in these designs is disappearing. Thus, wire load baseddesign, or “design by guard band” is becoming less and less valid with each new technologygeneration. Designers are using tools like BuildGates Physically Knowledgeable Synthesis(PKS) to accurately predict interconnect RCs rather than to use wire load models. This nextgeneration of tools does “design by accuracy.”

However, you can use BuildGates Synthesis to synthesize designs using wire load models.

➤ Examine the commands in the Setting wire load models section of theconstraints.tcl file.

set_wire_load TSMC18_Conservativeset_wire_load_mode enclosedset_wire_load_selection_table WireAreaCon

■ The set_wire_load command sets the wire load model for the current module, DTMF.If you run the report_library -wireload command, you seeTSMC8k_Conservative as the default. The set_wire_load command overrides thisdefault.



■ The set_wire_load_mode command specifies that the wire load model must beselected using an area lookup table for the module at the lowest level in the designhierarchy that contains the entire wire (net). If topmode is specified, the wire load modelis selected using the area lookup table of the top-level module, which is the default.

■ The set_wire_load_selection_table selects wire load models based on the wireload model selection table WireAreaConwhich is defined in the tpz973gwc_4.3.tlflibrary.

Checking Constraints

Cadence recommends that you check all constraints before you execute the do_optimizecommand or any timing analysis commands, such as report_timing. This helps you verifythat the timing environment is complete and self-consistent.

1. Check the constraints by entering the following command:

bg_shell>check_timing

The check_timing command performs a variety of consistency and completenesschecks on the timing constraints specified for a design. Running this command can saveyou a lot of wasted time. This command can be used on generic and mapped netlists.

The check_timing command displays the report shown in Figure 2-5.

Figure 2-5 check_timing Report+--------------------------------+| Report | check_timing ||---------+----------------------|| Options | |+---------+----------------------+| Date | 20030522.105735 || Tool | bg_shell || Release | v5.10-s058 || Version | May 20 2003 13:14:56 |+--------------------------------++---------------------------------------------------------------------------------------------------+| TIMING CHECK SUMMARY ||-------------------------------------------------------------------------------------------------- || Warning | Warning Description | Number || | | of || | | Warnings !|--------------+-------------------------------------------------------------------------+----------|| clock_but_data | Clock signal found where data is expected | 1 || clock_clipping_freq | Clock clipping possible due to incompatible clock signal & data | 11 || | signal frequencies | || data_gating_clock | Data gating clock | 6 || multiple_signal | Multiple signals arriving at end point | 67 || no_drive | No drive assertion | 1 || no_ext | No external delay or required time assertion | 2 |+---------------------------------------------------------------------------------------------------+

1. Use the –verbose option with the check_timing command to look at the details ofthe warnings:

bg_shell>check_timing -verbose



The -verbose option displays a detailed report in addition to the report shown inFigure 2-5 on page 39. An extract of the detailed report is shown in Figure 2-6 onpage 40.

The TIMING CHECK SUMMARY shown in Figure 2-5 on page 39 includes a summary ofwarnings, a brief description, and the number of warnings.

The TIMING CHECK DETAIL shown in Figure 2-6 on page 40 gives the hierarchical pinnames and a description of the warnings.

Figure 2-6 Extract of the Detailed Warning Information

Tip

You can use the set_table_style command to change the column widths of thetable. For example, to change the column widths of the TIMING CHECK DETAILtable use:

set_table_style -name report_timing_prologue -max_widths 40

TIMING CHECK DETAIL

Pin Warning

DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/I1 Clock signal (vclk1_int1 neg ) found where data is expected

DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/I1 Multiple signals (vclk1_int1 pos vclk1_int1 neg ) arriving

DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/O0 Clock clipping possible due to incompatible clock signal

’DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/I0’ and data signals

’DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/S’ frequencies







DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/O0 Data gating clock

DTMF_INST/RAM_256x16_TEST_INST/RAM_256x16_INST/A[7]

Multiple signals (vclk1_int1 lead vclk1 lead ) arriving

DTMF_INST/RESULTS_CONV_INST/clear_flag_reg/D

Multiple signals (vclk1 lead vclk2 trail ) arriving

DTMF_INST/RESULTS_CONV_INST/gt_reg/D Multiple signals (vclk1 lead vclk2 trail ) arriving

.... ...



All the warnings should be checked, and each warning should be justified or fixed by addingnew constraints or modifying existing constraints.

■ The following warning indicates that a clock signal is being gated (MUX), where theexpected input signal on the combinational gate is data, rather than a clock:

DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/I1 ---- Clock signal (vclk1_int1 neg )found where data is expected

Since clock gating logic is present in the design, you can ignore this warning.

■ The following warning indicates that the data signal at pin I1 of the instanceDTMF_INST/DATA_SAMPLE_MUX_INST/i_5 is triggered by the positive edge andnegative edge clocks of vclk1_int1:

DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/I1 ---- Multiple signals (vclk1_int1 posvclk1_int1 neg ) arriving

■ The following message indicates that the logic value of the clock input before the activeclock transition may not be controlling theDTMF_INST/DATA_SAMPLE_MUX_INST/i_5gate, resulting in clock clipping:

DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/O0 ---- Clock clipping possible due toincompatible clock signal 'DTMF_INST/DATA_SAMPLE_ MUX_INST/i_5/I0' and datasignals 'DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/S' frequencies

If the clock input is not dominant or controlling before and after it makes its transitions,then the output signal could be distorted by the data input. This distortion is calledclipping or shaping.

■ The following warning message indicates that a single data signal at pin D of instanceDTMF_INST/RESULTS_CONV_INST/high_mag_reg_0/D is triggered by the vclk1and vclk2 clocks:

DTMF_INST/RESULTS_CONV_INST/high_mag_reg_0/D ---- Multiple signals (vclk1 leadvclk2 trail ) arriving

■ The following warning indicates that the clock signal at DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/00 is being gated:

DTMF_INST/DATA_SAMPLE_MUX_INST/i_5/O0 --- Data gating clock

Important

As a general strategy, you should either fix or understand and dismiss allcheck_timing errors before moving on to optimization.

Note: check_timing -old will give you <TA-XXX> warnings.



Setting Path Groups

You can use path groups to group paths for the purpose of timing optimization or timinganalysis. When you have overconstrained paths or when I/Os are overconstrained becauseof uncertainties, each group can be optimized separately. This enables the tool to work onother paths that have more realistic constraints when attempts to find improvements on theoverconstrained paths fail. You can also group the timing paths which have some violations,to do incremental timing optimization.

➤ Set the path groups for this design, by running the following script:

bg_shell> source $tcl_dir/path_groups.tcl

The path_groups.tcl script contains the following commands

set_path_group -name IN -from [ find -input -noclocks * ]set_path_group_options IN -target_slack 0.2 -all_end_points

set_path_group -name OUT -to [ find -output * ]set_path_group_options OUT -target_slack 0.5 -all_end_points

set_path_group -name vclk2_group -clock_from vclk2set_path_group_options vclk2_group -target_slack 0.0 -all_end_points

set_path_group -name vclk1_group -clock_from vclk1set_path_group_options vclk1_group -target_slack -1.0 -all_end_points

The set_path_group command groups the critical paths in the design to be optimized.You can use this command in conjunction with the set_path_group_optionscommand to potentially specify a different set of optimizations for the grouped paths. Allgrouped and ungrouped paths are optimized according to the options specified in thedo_optimize command, unless the grouped paths have different optimization optionsspecified using the set_path_group_options command.

In this design you use the set_path_group command to create four path groups: IN,OUT, vclk2_group, and vclk1_group. Each group has its own optimizationrequirements which are specified with the set_path_group_options command. Thetarget slack for the vclk1_group group is set to –1.0 to show some negative slack afteroptimization.

Initially, there is only the default group. You cannot create any other groups with thatname. Each group created with set_path_group is separated from the defaultgroup.



Optimizing the Design

Logic optimization plays a key role in the synthesis process and consists of severalprocesses, including: Boolean transformations, flattening, structuring,technology-independent and technology-dependent mapping, hierarchical optimization, andcontext derivation. Depending on the design size, the two most commonly used optimizationtechniques are top-down and bottom-up optimization.

➤ Optimize the DTMF design using the top-down synthesis methodology by entering thefollowing command:

bg_shell>do_optimize

Note: Depending on the performance of your machine, the optimization runs for about 30minutes. You can take this time to read more about the difference between top-down andbottom-up optimization in More about Optimizing the Design on page 154.

do_optimize Info Messages

The do_optimize command displays several informational messages. Examples of thesemessages are explained below.

■ Message 605 indicates that AmbitWare components (ACL and AWL cells) created ashierarchical instances during the do_build_generic step are dissolved in the parentmodule.

Info: Dissolving AmbitWare instance ’i_5377’ (cellref ’AWMUX_2_2’) in module’arb’ ... <TCLNL-605>.

■ The following message indicates that the optimizer is creating a unique instance i_3282for the multiple instantiated module AWACL_SUB_UNS_162. This allows the optimizer tooptimize one instance module differently from another by placing different constraints onthem. The transform to uniquely instantiate multiple instances isdo_uniquely_instantiate.

Info: Duplicated module ’AWMUX_8_3’ as ’AWMUX_8_3_1’ and bound to instance’i_3094’ in module ’spi’ <FNP-700>.

■ The following message indicates that the optimizer is applying Boolean and algebraicalgorithms and transformations to achieve logic optimization and logic structuring. Youwill get this message for all the modules in the DTMF design. The transform to performstructuring is do_xform_structure.

Info: Structuring module 'spi' ... <TCLNL-500>.

■ The following message indicates that the optimizer is propagating logic levels (0 or 1)throughout the design crossing hierarchical boundaries. The transform to performpropagation of constants is do_xform_propagate_constants.

Info: Propagating constants ... <TCLNL-505>.



■ The following message indicates that the optimizer is removing redundancies from thenetlist. The transform to remove redundancy is do_xform_remove_redundancy.

Info: Removing redundancies ... <TCLNL-504>.

■ The following message indicates that the optimizer is mapping a generic netlist for thespi module to the target technology library. You will get similar messages for all themodules in the DTMF design. The transform to perform mapping is do_xform_map.

Info: Mapping module 'spi' ... <TCLNL-501>.

■ The following report is the Path Group Options report generated during the optimizationprocess. It shows five path groups with their respective effort level, target slack, criticalendpoints and worst slack. Incremental reports will be generated as the optimizationprocess continues.+---------------------------------------------------------------------------+| Path Group Options Report ||---------------------------------------------------------------------------|| PathGroup | Effort | All | Target | Critical | Worst | TEFS || | | Pts | Slack | Endpoints | Slack | ||-------------+--------+-----+----------+-----------+----------+------------|| default | medium | - | 0.00000 | 0/5 | 9.55629 | 0.00000 || IN | medium | + | 0.20000 | 0/23 | 2.63263 | 0.00000 || OUT | medium | + | 0.50000 | 16/25 | -2.40688 | 27.60275 || vclk1_group | medium | + | -1.00000 | 326/1124 | -5.40008 | 856.17926 || vclk2_group | medium | + | 0.00000 | 16/378 | -1.37748 | 22.03970 |+---------------------------------------------------------------------------+

Stopping and Restarting Optimization

BuildGates Synthesis provides several features that allow you to stop and restartoptimization.

During optimization, you can always issue the control-c command to stop the optimizationrun.

Use the -checkpoint option with the do_optimize command to periodically save theentire database (checkpoint.adb). In the event of a network crash, you can resumebg_shell by loading the checkpoint.db file.

Use the command, dump_adb bg_shell_process_id, with the process ID of abg_shell process, to dump the.adb (Ambit Synthesis Database) file at the next mostsuitable time that will allow the process to be restarted.



Generating Reports

At this point, the synthesis process has transformed your design from RTL to a finaltechnology-mapped netlist that meets all the constraints. Now, you need to capture theinformation and analyze the reports to see if the synthesis goals are met. You need to runvarious timing reports to determine:

■ Whether the design has any problems

■ Whether the design passes or fails timing analysis and where the violations are

■ The constraints and exceptions for timing analysis

■ How the delays are calculated

BuildGates Synthesis provides a number of report categories such as timing, area, hierarchy,library, design rule violations, end point slack and path histograms, fanin and fanout, finitestate machine to analyze various steps in synthesis process.

In this module, you will only use a subset of all the possible report options.

Note: One of the key advantages of BuildGates Synthesis is that it has a built-in, full-chip,sign-off quality, static timing analysis capability. You do not need to use a separate standaloneSTA tool to perform timing analysis. This makes BuildGates more efficient and accurate andeliminates the need to buy another tool to signoff your design.

Generating Summary and Detailed Reports

1. Generate a summary report for all timing checks.

bg_shell>report_analysis_coverage > $rep_dir/report_analysis_coverage.rpt

Figure 2-7 on page 46 shows an excerpt of the generated report.

❑ TIMING CHECK COVERAGE SUMMARY has a summary of all timing checks. Foreach timing check, the report indicates whether the timing condition was met,violated, or untested.

❑ TIMING CHECK COVERAGE DETAILS gives details of each pin and reference pin.The report shows that untested setup checks are due to “No data signal” on the scanpins. You can ignore these checks, since scan pins are in tieback mode at this stage.

The Pin and Reference Pin columns represent hierarchical pins DTMF_INST/ARB_INST/dma_grant_reg/*, and DTMF_INST/ARB_INST/dma_grant_reg/*, respectively. The report_analysis_coverage.rpt filehas the complete pin names.



Figure 2-7 Excerpt of the Summary Report

The report_analysis_coverage command allows you to generate detailed reportsfor any type of checks shown above.

+-------------------------------------------------+| Report | report_analysis_coverage ||---------+---------------------------------------|| Options | > ../rpt/report_analysis_coverage.rpt |+---------+---------------------------------------+| Date | 20030522.115114 || Tool | bg_shell || Release | v5.10-s058 || Version | May 20 2003 13:14:56 |+-------------------------------------------------+ +----------------------------------------------------------------------+ | TIMING CHECK COVERAGE SUMMARY | |----------------------------------------------------------------------| | Check Type | No. of | Met | Violated | Untested | | | Checks | | | | |-----------------------+--------+------------+-----------+------------| | ClockGatingHold | 24 | 0 (0%) | 24 (100%) | 0 (0%) | | ClockGatingSetup | 24 | 24 (100%) | 0 (0%) | 0 (0%) | | ClockPeriod | 6 | 6 (100%) | 0 (0%) | 0 (0%) | | ExternalDelay (Early) | 50 | 50 (100%) | 0 (0%) | 0 (0%) | | ExternalDelay (Late) | 50 | 50 (100%) | 0 (0%) | 0 (0%) | | Hold | 3632 | 1442 (39%) | 18 (0%) | 2172 (59%) | | PulseWidth | 1618 | 1092 (67%) | 0 (0%) | 526 (32%) | | Recovery | 269 | 6 (2%) | 0 (0%) | 263 (97%) | | Setup | 3632 | 1318 (36%) | 142 (3%) | 2172 (59%) | +----------------------------------------------------------------------+

TIMING CHECK COVERAGE DETAILS

Pin Reference Pin Check Type Slack Reason

dma_grant_reg/CK ^ dma_grant_reg/CK v PulseWidth 2.36

dma_grant_reg/CK v dma_grant_reg/CK ^ PulseWidth 2.11

dma_grant_reg/D ^ dma_grant_reg/CK ^ Setup 0.35

dma_grant_reg/D ^ dma_grant_reg/CK ^ Hold 1.23

dma_grant_reg/D v dma_grant_reg/CK ^ Setup -0.00

dma_grant_reg/D v dma_grant_reg/CK ^ Hold 1.38

dma_grant_reg/RN dma_grant_reg/RN PulseWidth UNTESTED No reference signal

dma_grant_reg/RN ^ dma_grant_reg/CK ^ Recovery UNTESTED No data signal

dma_grant_reg/SE dma_grant_reg/CK ^ Hold UNTESTED No data signal

dma_grant_reg/SE dma_grant_reg/CK ^ Setup UNTESTED No data signal

dma_grant_reg/SI dma_grant_reg/CK ^ Setup UNTESTED No data signal

... ... ... ... ...



2. Generate a detailed report on the setup timing check:

bg_shell>report_analysis_coverage -check_type setup -sort slack \> $rep_dir/setup.rpt

An excerpt of the detailed report on the setup timing check is shown in Figure 2-8.

Figure 2-8 Summary of Setup Timing Check+------------------------------------------------------------+| Report | report_analysis_coverage ||---------+--------------------------------------------------|| Options | -check_type setup -sort slack > ../rpt/setup.rpt |+---------+--------------------------------------------------+| Date | 20030522.123427 || Tool | bg_shell || Release | v5.10-s058 || Version | May 20 2003 13:14:56 |+------------------------------------------------------------+

+-----------------------------------------------------+ | TIMING CHECK COVERAGE SUMMARY | |-----------------------------------------------------| | Check | No. of | Met | Violated | Untested | | Type | Checks | | | | |-------+--------+------------+----------+------------| | Setup | 3632 | 1318 (36%) | 142 (3%) | 2172 (59%) |

+-----------------------------------------------------+

Note: The Pin and Reference Pin columns represent hierarchical pins DTMF_INST/RESULTS_CONV_INST.

The last table shows that the report sorted all the setup checks in increasing order by slack.At this time, the design has some setup violations.

TIMING CHECK COVERAGE DETAILS

Pin Reference Pin Check Type Slack Reason

... ...

r1200_reg_10/D v r1200_reg_10/CKN v Setup -0.02




r770_reg_11/D ^ r770_reg_11/CKN v Setup -0.02


... ... ... ...



Checking Setup Violations

➤ Generate a timing report to find out if the design works at the specified frequency or tosee the worst timing path in the design:

bg_shell>report_timing > $rep_dir/setup_timing.rpt

The timing report contains the start and end nodes of the path and the delay through theentire path. The report_timing command has a number of options, such as -from,-through, and -to, to specify the begin, through, and end points (respectively) of the path,-max_points, and max_slacks nworst.

Figure 2-9 on page 49 shows a typical timing report:.

■ The first section lists the options used with report_timing, tool version, process,voltage, temperature, operating conditions, top timing module (DTMF_chip), and so on.

■ The second section describes the beginning and ending points of the path, launchingand capturing edge of the clock, whether timing on the path is met or violated. Fordetailed cell-to-cell delays, see the setup_timing.rpt file.

Note: As mentioned before, your results might differ from what is shown here due todifference in runs and release versions.

For setup check calculation, the tool uses the worst case delays of the library cells. Bydefault, report_timing without any options checks the setup using worst case delays.

■ The third section of the timing report is a table describing all the instances on the path—timing arc, cell name, delay through timing-arc, the signal required times, and the actualsignal arrival times at the output of each instance.



Figure 2-9 Excerpt of the Setup Time Report+-------------------------------------------------+| Report | report_timing ||---------------------+---------------------------|| Options | > ../rpt/setup_timing.rpt |+---------------------+---------------------------+| Date | 20030522.125015 || Tool | bg_shell || Release | v5.10-s058 || Version | May 20 2003 13:14:56 |+---------------------+---------------------------+| Module | dtmf_chip || Timing | LATE || Slew Propagation | WORST || Operating Condition | slow || PVT Mode | max || Tree Type | balanced || Process | 1.00000 || Voltage | 1.62000 || Temperature | 125.00000 || time unit | 1.00000 ns || capacitance unit | 1.00000 pF || resistance unit | 1.00000 kOhm |+-------------------------------------------------+Path 1: VIOLATED Setup Check with Pin DTMF_INST/TDSP_CORE_INST/DATA_BUS_MACH_INSTdata_out_reg_0/CKEndpoint: DTMF_INST/TDSP_CORE_INST/DATA_BUS_MACH_INST/data_out_reg_0/D (v)checked with leading edge of ’vclk1’Beginpoint: DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/arp_reg/Q (^)triggered by leading edge of ’vclk1’Path Groups: {vclk1_group}Other End Arrival Time 0.00000- Setup 0.69730+ Phase Shift 6.00000- Uncertainty 0.25000= Required Time 5.05270- Arrival Time 5.75437= Slack Time -0.70167 Clock Rise Edge 0.00000 = Beginpoint Arrival Time 0.00000

You can use the -format option to customize the reports to your needs by requesting theexact fields in which you have an interest. Using a combination of the -format and

Instance Arc Cell Delay ArrivalTime

RequiredTime

refclk ^ 0.00000 -0.70167

IOPADS_INST refclk ^ iopads 0.00000 -0.70167

IOPADS_INST/Prefclkip PAD ^ -> C ^ PDIDGZ 0.00000 0.00000 -0.70167

IOPADS_INST refclkI ^ iopads 0.00000 -0.70167

... ... ... ... ... ...



-tcl_list options lets you integrate the timing reports into your Tcl scripts. You can writethe report to a file by specifying the filename. You can also set the global variablereport_timing_format to specify the format for the report_timing command.

BuildGates Synthesis comes with a host of sign-off quality, full-chip, static-timing-analysisfeatures such as:

■ Clock reconvergence pessimism removal

■ Pulse width and recovery and removal checks

■ Full path and end point histograms

■ Simultaneous bc/wc analysis

■ Full support for all major back annotation formats (sdf, dspf, spef, rspf)

■ Path group capability

■ Support for common exceptions such as false_path, multicycle_path, and so on

■ STAMP modeling and so on.

See the Common Timing Engine (CTE) User Guide. for more information.

Generating Area Reports

➤ Generate an area report.

bg_shell>report_area > $rep_dir/area.rpt

The area report will look similar to:

+--------------------------------+| Report | report_area ||---------+----------------------|| Options | > ../rpt/area.rpt |+---------+----------------------+| Date | 20030522.125511 || Tool | bg_shell || Release | v5.10-s058 || Version | May 20 2003 13:14:56 |+---------+----------------------+| Module | dtmf_chip |+--------------------------------+

Summary Area ReportSource of Area : Timing Library-------------------



The table shows that the total area of the top module (dtmf_chip) is 1.393.684 squaremicrons, as shown in the first row of the table.

The area report table contains all the modules in the design—the wireload model namebased on wire load section table, the total cell area, the net area and the total area for eachmodule. You can use the -cells option to get more details on cell names and counts usedin the current module, area for each cell, and total cell area.

Writing Netlist and Database Files

At this stage, optimization is complete and you find the report results satisfactory. Next, youneed to save the technology-dependent, optimized netlist and BuildGates Synthesisdatabase file.

1. Save the optimized netlist.

bg_shell>write_verilog -hierarchical $adb_dir/dtmf_chip_opt.vs

The write_verilog command writes out a hierarchical, mapped netlist(dtmf_chip.v) that is stored in the database in Verilog format. If you write a netlist afterthe do_build_generic command, it saves a generic-level netlist which containsinstances of ATL and XATL cells.

Note: You can use the write_vhdl command to write out a netlist in VHDL format andthe write_edif command to write out a netlist in edif format. If you get assignstatements in the Verilog netlist, you can use the transform,do_xform_fix_multiport_nets, or the global variable, set_globalfix_multiport_nets, to avoid assign statements.

2. Save the database file.

bg_shell>write_adb $adb_dir/dtmf_chip_opt.adb

Module Wireload Cell Area Net Area Total Area

dtmf_chip TSMC18_Conservative 1392217.23010 0.00 1392217.23010

dtmf_recvr_core TSMC64K_Conservative 579117.23010 0.00 579117.23010

iopads TSMC64K_Conservative 813100.00000 0.00 813100.00000

arb TSMC8K_Conservative 671.93282 0.00 671.93282

data_sample_mux TSMC8K_Conservative 678.58561 0.00 678.58561

digit_reg TSMC8K_Conservative 725.15523 0.00 725.15523

dma TSMC8K_Conservative 2022.45128 0.00 2022.45128

ram_128x16_test TSMC8K_Conservative 100791.69418 0.00 100791.69418

ram_256x16_test TSMC16K_Conservative 113656.55447 0.00 113656.55447

results_conv TSMC16K_Conservative 42464.82314 0.00 42464.82314

spi TSMC8K_Conservative 2461.53600 0.00 2461.53600

... ... ... ... ...



The write_adb command writes the design data for the dtmf_chip design inBuildGates Synthesis database (ADB) file format. By default, the ADB netlist is ahierarchical netlist of the current module and all instances inside it.

You can use the read_adb command to quickly load design data in bg_shell for furtheranalysis or synthesis. The write_adb command has several useful options such as the-no_assertions option to write out the database without timing constraints, the -no_rcoption to write out the database without any wire resistances or capacitances, and so on.

Setting Scan Chain Assertions

So far, you ran test-synthesis in tieback mode. In this mode, the test synthesis toolconnects the scan-data output pin of the scan register to its own scan-data input pin. Thetieback mode speeds up synthesis due to the fact that chain path connections are not beingconsidered. Hence, Cadence recommends that you perform your initial synthesis in tiebackmode using BuildGates Synthesis. Now that optimization is completed, you can set scanchain assertions and connect the scan chain.

To connect the scan chain, you need to set the following assertions:

■ The number of scan chains and/or the maximum length of the scan chains

■ The compatible clock domains for data lockup latch analysis and/or insertion

■ The scan-data input/output pairs

1. Set the scan chain assertions using the following script:

bg_shell>source $tcl_dir/connect_scan_chain.tcl

The connect_scan_chain.tcl script contains the following commands:

set_number_of_scan_chains 3

set_scan_data {IOPADS_INST/Ptdspip00/C} {IOPADS_INST/Ptdspop00/I} -shared_outset_scan_data {IOPADS_INST/Ptdspip01/C} {IOPADS_INST/Ptdspop01/I} -shared_outset_scan_data {IOPADS_INST/Ptdspip02/C} {IOPADS_INST/Ptdspop02/I} -shared_out

set_dft_compatible_clock_domain -same_clockset_global dft_scan_path_connect chain

do_xform_connect_scan

❑ The set_number_of_scan_chains command specifies the number of scanchains (3) to create for the current module (DTMF). Use theset_max_scan_chain_length assertion to specify a maximum scan chainlength. Meeting the specified number of scan chains takes priority over meeting aspecified maximum chain length, unless the later assertion is specified with the-priority option. By default, the tool creates one chain for each clock domain.



❑ Each scan chain needs its own input and output port. The set_scan_dataassertion specifies the names for the input (IOPADS_INST/ptdspip0*/I) andoutput (IOPADS_INST/ptdspip0*/C) scan data ports. In addition, the -clockoption associates the input and output names with a specific DFT clock domain. The-shared_out option enables the scan data output port to be shared with afunctional port using a MUX.

❑ By default, the test synthesis tool creates one scan chain for each DFT clockdomain. The set_dft_compatible_clock_domain assertion specifies domainand phase compatibility between the DFT clock domains. You must specify thiscommand prior to running the scan connection engine in chain mode. It instructs thescan connection engine to create a scan chain in which a data lockup element (latchor flip-flop) can be optionally inserted between the scan chain segments belongingto the different DFT clock domains. The -same_clock option specifies that bothedges of each clock are compatible.

❑ The set_global dft_scan_path_connect assertion sets the connectionmode. Before optimization, you set this global variable to tiebackmode.) In chainmode, the test synthesis tool connects the scan-data output pin from one register tothe scan-data input pin of the next register, thus creating the top-level scan chains.

❑ The do_xform_connect_scan command configures and connects scan flip-flopsinto scan chains. The command applies to the current module and all lowerhierarchies referred to in the current module. The design must be mapped beforeconnecting scan chains in a design. All flip-flops that pass DFT rule check (throughthe check_dft_rules command) are converted to scan flip-flops and areconnected into scan chains. The flip-flops that do not pass DFT rule checks areautomatically excluded from scan chains. The flip-flops in the lower modulehierarchies are also automatically reconfigured and connected, unless the lowermodule is tagged with dont_modify or dont_touch_scan.

2. Examine the messages you get while running this script.

❑ By specifying the set_dft_compatible_clock_domains -same_clockassertion, domains can be merged for this design. When the top-level scan chainsare created, the negative edge-triggered flops, belonging the DFT clock domain 0,will proceed the positive edge-triggered flops, belonging to DFT clock domain 1.Test synthesis will not insert a data lockup element between the domain transitionsof the chain segments triggered by the alternative phases of scan_clk whenconstructing the top level chain.

For scan flops belonging to different root clock domains, if domain merging wasspecified, test synthesis would insert a data lockup element between the domaintransitions of the scan flops belonging to the different DFT domains or betweengated-clock branches of the same top-level logical clock source, refclk. In thissituation, the following Info message would be reported:



Info: Inserting lockup latch (f/f) instance ’<path_to lockup_element>’to connect scan flip-flops ’<path_to_flip_flop>’ and ’<path_to_flip_flop>’in a single chain <DFT-344>.

Insertion of data lockup elements is only supported for the multiplexed scan(muxscan) style of test insertion. Insertion of data lockup elements allows you toreduce the number of scan chains configured in a multi-clock domain design.Additionally, insertion of data lockup elements between different gated-clockbranches, derived from the same logical clock source, can prevent capture problemsduring the scan-shift cycle of the test mode due to clock skew variances betweenthe different gated-clock branches. Without this capability, test synthesis creates asingle scan chain for each DFT clock domain.

❑ The following message indicates that the test synthesis tool created a flat scanreport file called dtmf_chip.scan.flat.

DFT - creating flat scan order file 'dtmf_chip.scan.flat'

The flat scan chain report file is organized by scan chain, listing all the bits on eachscan chain in the order of connection.

Note: You can also create a hierarchical scan report file using thewrite_scan_order_file command with the -hier option.

DFT - creating hierarchical scan order file 'dtmf_chip.scan'

The hierarchical scan chain report file is organized by module, listing the chainconnections visible at each level of hierarchy.

At this stage the scan chain is hooked-up.

3. Report the timing to check the impact of the scan insertion.

bg_shell>report_timing -late > $rep_dir/setup_scan_timing.rpt

You will notice that, after hooking up scan, the timing becomes worse, which is due to thescan chain order. By default, the test synthesis tool orders the scan chain alphabetically,which is not optimal.

Path 1: VIOLATED Setup Check with Pin DTMF_INST/TDSP_CORE_INST/DATA_BUS_MACH_INST/data_out_reg_0/CKEndpoint: DTMF_INST/TDSP_CORE_INST/DATA_BUS_MACH_INST/data_out_reg_0/D (v)checked with leading edge of ’vclk1’Beginpoint: DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/arp_reg/Q (^)triggered by leading edge of ’vclk1’Path Groups: {vclk1_group}Other End Arrival Time 0.00000- Setup 0.69730+ Phase Shift 6.00000- Uncertainty 0.25000= Required Time 5.05270- Arrival Time 5.80546= Slack Time -0.75276 Clock Rise Edge 0.00000 = Beginpoint Arrival Time 0.00000



Incremental Timing Optimization

Before doing an incremental timing optimization to fix the negative slack, change the targetslack of the path group, vclk1_group to 0.0 from –1.0 set earlier.

1. Change the target slack.

bg_shell>set_path_group_options vclk1_group -target_slack 0.0 -all_end_points

2. Do an incremental optimization of the slack.

bg_shell> do_optimize -incremental -dont_reclaim_area

The -incremental option indicates that the design is already well-optimized and thatthe design rule violations have been fixed. The optimizer works incrementally on thepaths which have timing violations.

The -dont_reclaim_area option prevents downsizing and the removal of buffers orclone instances to reduce area. By default, area reclamation is done when slack fixingceases to find improvement. This option is useful when you want prevent areareclamation in parts of the design that are not timing critical.

For more information on scan, see Design for Test (DFT) Using BuildGatesSynthesis and Cadence PKS.

3. Check the timing again.bg_shell> report_timing -late -nworst 5 > \$rep_dir/setup_scan_incr_opt_timing.rpt

This command generates five worst timing paths between the flip flops in the design.

The report is shown in Figure 2-10 on page 56.

As you can see, the timing constraints are now met.

4. Find out if there are any hold violations in the design.

bg_shell> report_timing -early > $rep_dir/time_hold.rpt

For hold time calculation you specify the –early option to ensure that the tool uses thebest case delays of the library cells.

Figure 2-11 on page 57 shows a typical timing report.



Figure 2-10 Timing Report after Reoptimization

+------------------------------------------------------------------------------+| Report | report_timing ||---------------------+---------------------------------------------------------| Options | -late -nworst 5 > ../rpt/setup_scan_incr_opt_timing.rpt |+---------------------+--------------------------------------------------------+| Date | 20030522.132637 || Tool | bg_shell || Release | v5.10-s058 || Version | May 20 2003 13:14:56 |+---------------------+--------------------------------------------------------+| Module | dtmf_chip || Timing | LATE || Slew Propagation | WORST || Operating Condition | slow || PVT Mode | max || Tree Type | balanced || Process | 1.00000 || Voltage | 1.62000 || Temperature | 125.00000 || time unit | 1.00000 ns || capacitance unit | 1.00000 pF || resistance unit | 1.00000 kOhm |+-------------------------------------------------------------------------------Path 1: MET Setup Check with Pin DTMF_INST/TDSP_CORE_INST/EXECUTE_INSTsel_op_a_reg_2/CKEndpoint: DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/sel_op_a_reg_2/E (^) checkedwith leading edge of ’vclk1’Beginpoint: DTMF_INST/TDSP_CORE_INST/DECODE_INST/ir_reg_15/Q (v) triggeredby leading edge of ’vclk1’Path Groups: {vclk1_group}Other End Arrival Time 0.00000- Setup 1.03155+ Phase Shift 6.00000- Uncertainty 0.25000= Required Time 4.71845- Arrival Time 4.71031= Slack Time 0.00814 Clock Rise Edge 0.00000 = Beginpoint Arrival Time 0.00000


RequiredTime

refclk ^ 0.00000 0.00814

IOPADS_INST refclk ^ iopads 0.00000 0.00814

IOPADS_INST/Prefclkip PAD ^ -> C ^ PDIDGZ 0.00000 0.00000 0.00814

IOPADS_INST refclkI ^ iopads 0.00000 0.00814

DTMF_INST refclk ^ dtmf_recvr_core 0.00000 0.00814

DTMF_INST/PLLCLK_INST refclk ^ -> clk2x ^ pllclk 0.00000 0.00000 0.00814

... ... ... ... ... ...



Figure 2-11 Excerpt of the Hold Time Report+-------------------------------------------------------+| Report | report_timing ||---------------------+---------------------------------|| Options | -early > ../rpt/hold_timing.rpt |+---------------------+---------------------------------+| Date | 20030522.133440 || Tool | bg_shell || Release | v5.10-s058 || Version | May 20 2003 13:14:56 |+---------------------+---------------------------------+| Module | dtmf_chip || Timing | EARLY || Slew Propagation | WORST || Operating Condition | slow || PVT Mode | max || Tree Type | balanced || Process | 1.00000 || Voltage | 1.62000 || Temperature | 125.00000 || time unit | 1.00000 ns || capacitance unit | 1.00000 pF || resistance unit | 1.00000 kOhm |+-------------------------------------------------------+

Path 1: VIOLATED Clock Gating Hold Check with Pin DTMF_INST/TDSP_DS_CS_INST/i_10/DEndpoint: DTMF_INST/TDSP_DS_CS_INST/i_10/AN (v) checked withtrailing edge of ’vclk1_int1’Beginpoint: DTMF_INST/TDSP_CORE_INST/PORT_BUS_MACH_INST/as_reg/Q (v) triggered byleading edge of ’vclk1’Path Groups: {vclk1_group}Other End Arrival Time 6.00000+ Clock Gating Hold 0.00000+ Phase Shift 0.00000+ Uncertainty 0.25000= Required Time 6.25000 Arrival Time 0.37220 Slack Time -5.87780 Clock Rise Edge 0.00000 = Beginpoint Arrival Time 0.00000


RequiredTime

refclk ^ 0.00000 5.87780

IOPADS_INST refclk ^ iopads 0.00000 5.87780

IOPADS_INST/Prefclkip PAD ^ -> C ^ PDIDGZ 0.00000 0.00000 5.87780

IOPADS_INST refclkI ^ iopads 0.00000 5.87780

DTMF_INST refclk ^ dtmf_recvr_core 0.00000 5.87780

DTMF_INST/PLLCLK_INST refclk ^ -> clk2x ^ pllclk 0.00000 0.00000 5.87780

DTMF_INST/TEST_CONTROL_INST

clk ^ test_control 0.00000 5.87780

DTMF_INST/TEST_CONTROL_INST/i_198

A ^ -> Y ^ MX2X1 0.00000 0.00000 5.87780

DTMF_INST/TEST_CONTROL_INST

m_clk ^ test_control 0.00000 5.87780

... ... ... ... ... ...



The report shows that the design has some hold violations between the clock domainsvclk1 and vclk2. You can fix these hold violations with the do_xform_fix_holdtransform.

You can read More about Timing Reports on page 156.

5. Write out the Verilog netlist.

bg_shell> write_verilog -hierarchical $adb_dir/dtmf_chip_scan.vs

6. Save the database file to use when you try the graphical interface (Using BuildGatesSynthesis Graphical User Interface on page 61).

bg_shell>write_adb $adb_dir/dtmf_chip_scan.adb

7. End this BuildGates session.

bg_shell>exit



Interfacing with Physical Design Tools

So far, you have been optimizing your design using wire-loads provided with the libraries. Fordeep sub-micron designs, wireloads are a source of timing closure issues. Addressing timingclosure issues requires a coordinated effort in synthesis and place-and-route. BuildGatesSynthesis provides all the standard interfaces to floorplanning and place and route tools.Supported interfaces are SDF (2.0 or 3.0 format), PDEF (2.0 IEEE version), CadenceGeneral Constraint Format (GCF, version 1.3 or 1.4), and wire resistance and capacitancefiles (SPEF, RSPF and DSPF).

Figure 2-12 on page 60 shows the physical design tool interfaces. Because of the highcapacity of BuildGates Synthesis, you can perform in-place and post-layout optimization atchip-level for multi-million gate designs. The transform to perform in-place optimization isdo_xform_ipo. Important options for this command are -change_limit to limit thenumber of changes and -change_file to write out all the changes in a file. To find out moreinformation on interfacing with physical design tools, refer to Optimization WithBackannotation in the BuildGates Synthesis User Guide.

Figure 2-12 shows that with the traditional timing closure flow, you have to go through severaliterations between synthesis and place-route tools. To solve this problem, you can use theCadence Physically Knowledgeable Synthesis (PKS) tool. It produces perfect timingcorrelation between the synthesis and place-and-route domains by providing concurrentlogical, physical, and timing optimization, thus eliminating iterations between synthesis andplace-and-route. PKS provides optimization, placement, global routing, and clock-treesynthesis, all using the same sign-off quality static timing analysis engine.



Figure 2-12 Physical Design Tool Interfaces



Using BuildGates Synthesis Graphical User Interface

BuildGates Synthesis has an integrated, easy-to-use, graphical user interface (GUI) orientedtowards design analysis. Unlike traditional GUIs oriented towards menu-driven tool control,this GUI uniquely combines linked graphical and textual views to speed access to designinformation, making for more productive design analysis. This GUI also contains constraintspecification menus, schematic generation, a slack and area histogram; and linked graphical,schematic, and textual reports.

1. Invoke BuildGates Synthesis in graphical mode.

bg_shell -gui &

The BuildGates Synthesis window is displayed as shown below:

The GUI has three basic panes.

❑ The browser window is used to browse the logical hierarchy of your design orvariables set in your synthesis run.

❑ The design area window is primarily used to view schematics and highlighting timing

Browserwindow

Designareawindow

Console



paths. You can also use it to edit Tcl, hdl, constraints, and so on.

❑ The console is the command line interface that you have been working with. Allcommands that you can click on are echoed in this pane to make it easier to learnthe tool.

Any pane can be selected by clicking in the pane, and <CTRL-M> can be used tomaximize or minimize the selected pane.

2. Enter the following commands in the console:

source ../tcl/setup.tclsource $tcl_dir/set_globals.tclsource $tcl_dir/read_lib.tclread_adb $adb_dir/dtmf_chip_scan.adb

The following appears in your Logical browser:

3. Click left on dtmf_chip to select it.

4. Click right in the browser window to bring up the popup menu.



5. Select Open Schematic – Main Window.

The schematic of the DTMF chip is displayed in the Schematic window.

The colored paths correspond to the three scan chains that you configured earlier.

With the left mouse you can zoom out, go up in the hierarchy, zoom in, or zoom to fit. Adouble click will dig deeper in the hierarchy. The middle mouse button is used to pan



around the schematic. The right mouse button is used to first select what is under themouse (general schematic, net, port, pin, or module), then to provide special functionsfor that item.

For more information on the GUI, see GUI Guide for BuildGates Synthesis andCadence PKS

6. To generate the end point slack histogram for the100 worst paths, select Reports – EndPoint Histogram. The End Point Slack Histogram window shown in Figure 2-13appears.

Figure 2-13 End Point Slack Histogram

a. Keep Late mode selected.

b. Select the Compute Histogram icon shown in Figure 2-13 on page 64.

Compute histogram icon



The generated End Point Slack Histogram shows100 paths falling in different slackwindows.You will see something similar to:

You can also write the results into a file.

c. Click on the Close window icon (red x) to close the histogram window.

1. To generate the End Point histogram for 100 the best/early paths, select Reports – EndPoint Histogram and select Early mode on the window. The results can also be writtento a file.

Similarly, you can generate Path Histogram Reports. For a complete description of Pathhistograms, refer to GUI Guide for BuildGates Synthesis and Cadence PKS.

2. To end the session, select File – Exit or type exit in the console.



Migrating to BuildGates from Design Compiler

You are now ready to try out BuildGates Synthesis on your own design following these steps.If you already have Synopsys Design Compiler (DC) or Prime Time (PT) timing constraints,you can use the BuildGates Synthesis Constraint Translator to translate DC or PT output toa BuildGates Synthesis constraints file.

1. Locate your library in .alf or .tlf format. If you do not have a .alf library, ask yourvendor or convert a .lib to .alf or .tlf. For more information, see the Using TimingLibraries chapter of the Common Timing Engine (CTE) User Guide..

2. Determine which product you need:

a. BuildGates Synthesis is suitable for most synthesis needs

b. BuildGates Synthesis Extreme includes everything that BuildGates Synthesis has,as well as advanced engines for Low Power and Datapath optimization. Datapathincludes the basic arithmetic functions (+,-,*) as well as the comparison functions(==, <=, and so on).

c. PKS is an advanced physically knowledgeable synthesis tool that can be used if youcannot meet timing with traditional tools.

3. Convert your Synopsys Design Compiler (DC) constraints to BuildGates synthesisconstraints.

a. BuildGates Synthesis only needs top-level constraints, so you can remove most ofyour lower, block-level I/O constraints. You will need to retain any other lower levelconstraints, such as false_path and multi_cycle_paths.

b. Use the write_script command in DC or PT to create an output file (in dcsh orTcl format).

c. Use the read_dc_script in BuildGates Synthesis to read your constraints.

Note: You can only run the read_dc_script command after thedo_build_generic step.

See Constraint Translation Example on page 67 for an example.

Most designs can be easily constrained with only a few commands which set up theclocks, I/O constraints, and special path settings.

The following table shows Synopsys DC Compiler commands and the correspondingBuildGatesBuildGates Synthesis constraint commands. A complete mapping of



Synopsys commands to BuildGates Synthesis commands is available in SDCConstraints Support Guide

4. Check your HDL for any Synopsys proprietary DesignWare elements. In most cases, youcan replace these with inferences. For example, DW01_add can be replaced with a+b.

There are more tips for converting to BuildGates Synthesis in SDC ConstraintsSupport Guide

Constraint Translation Example

In this section, you will translate Synopsys constraints to BuildGates constraints. Although wehave no Synopsys constraints for this design that are generated with write_script, theycan be generated using the write_sdc command in BuildGates.

Using the read_dc_script command, you can read in these Synopsys constraints into theBuildGates environment.

The BuildGates Synthesis read_dc_script command is capable of translating output fromDC or PT write_script (in dcsh and Tcl formats) or write_sdc (available fromSynopsys in Tcl format) into a BuildGates Synthesis format constraints file.

Synopsys Command BuildGates Synthesis Command

Create_clock Set_clockSet_clock_root

Set_input_delay Set_input_delay

Set_output_delay Set_external_delay

Set_multicycle_path Set_cycle_addition

Set_false_path Set_false_path

Set_propogated_clock Set_clock_propagation

Max_transition Slew_time_limit

Max_capacitance Port_capacitance_limit

Max_fanout Fanout_load_limit

Set_don’t_touch Set_don’t_modify

Set_clock_uncertainity Set_clock_uncertainity

Set_don’t_touch_network Set_don’t_modify -network

Set_don’t_use Set_cell_property –don’t_use true

Set_disable_timing Set_disable_timing

Set_clock_latency Set_clock_insertion_delay



The read_dc_script command automatically detects the format of the original constraintsfile (dcsh or Tcl) and issues detailed error and warning messages if problems areencountered during translation.

Figure 2-14 shows the translation flow.

Figure 2-14 Synopsys-to-BuildGates Synthesis Translation Flow

1. Write the constraints in Synopsys format:

bg_shell > write_sdc sdc_out.tcl

The write_sdc command writes the constraints in Synopsys constraints format, for useby First Encounter, PrimeTime, and so on. Part of the sdc_out.tcl file is shown below.

set sdc_version 1.4current_design dtmf_chipcreate_clock [get_ports {refclk}] -name vclk1 -period 6 -waveform {0 3}create_clock -name vclk2 -period 12 -waveform {0 6}

create_generated_clock -name vclk1_int1 -from [get_pins{DTMF_INST/TDSP_CORE_INST/DATA_BUS_MACH_INST/clk}] -divide_by 2 \[get_pins {DTMF_INST/TDSP_CORE_INST/DATA_BUS_MACH_INST/write_reg/Q}]

Design Compiler

PrimeTime

(Tcl)cmd file

BuildGates Synthesis

BuildGatesconstraints

read_dc_script

DC

filescript

write_script-format dctcl

write_script-format dcsh write_sdc

PrimeTime

write_script-format dcsh

write_script-format ptsh write_sdc



create_generated_clock -name vclk1_int2 -from [get_pins \{DTMF_INST/DMA_INST/clk}] -divide_by 2 \[get_pins {DTMF_INST/DMA_INST/write_reg/Q}]

set_driving_cell -lib_cell PDO04CDG -library slow -no_design_rule -pin PAD\ -from_pin I [get_ports {ibias}]

set_driving_cell -lib_cell PDO04CDG -library slow -no_design_rule -pin PAD\ -from_pin I [get_ports {port_pad_data_in[5]}]

set_driving_cell -lib_cell PDO04CDG -library slow -no_design_rule -pin PAD\ -from_pin I [get_ports {port_pad_data_in[10]}]

set_driving_cell -lib_cell PDO04CDG -library slow -no_design_rule -pin PAD\ -from_pin I [get_ports {reset}]...

Since you do not get any warning or error messages, you can assume that all constraintsare translated properly.

Tip

The translator gives warning messages if any constraints are not translated properly.You need to check all the warning messages, before using the constraints. Alwaysreview the translated output file quickly. If a constraint is not translated properly, thetool will print the original command with a comment.

2. Read the Synopsys constraints:

bg_shell > read_dc_script -ambit bg_constraints.tcl -write_only \-tcl sdc_out.tcl

This command reads a Synopsys constraints file, sdc_out.tcl,and writes a file,bg_constraints.tcl, in BuildGates constraints format. In this case, you write out theconstraints without applying them. You can also apply the constraints on the designloaded in bg_shellwith the -apply_only option. In the latter case, the constraints arenot written.

From the log file below, you can see that all synopsys constraints are translated correctlyinto BuildGates constraint format without any errors or warnings.

Below you find an extract from the log file:

Info: Following commands are not supported and will be suppressed:<S2A-404>. Info: set_local_link_library <S2A-405>. Info: converting sdc_out.tcl to tcl format ... <S2A-406>. Info: initializing pbc constraints ... <S2A-407>. Info: translating constraints ... <S2A-409>.

...



Below you find an extract from the bg_constraints.tcl file:

### ac_shell version: v5.10-s058 (May 20 2003 13:32:50)#WARNING: PLEASE DO NOT REMOVE/CHANGE THE FOLLOWING COMMAND - IT SETS THE TIMINGENGINE IN PT COMPATIBLE MODE#Removing/Changing this will lead to different interpretation of false path andmulticycle path constraints.set_flow_compatible_mode onset_current_module dtmf_chipset_clock vclk1 -waveform {0 3} -period 6set_clock_root -clock vclk1 -pos {refclk}set_clock vclk2 -waveform {0 6} -period 12...set_drive_cell -cell {PDO04CDG} -library {slow} -pin {PAD} -from_pin {I}\-no_design_rule ibias....set_constant_for_timing 0 scan_enset_constant_for_timing 0 test_modeset_wire_load_mode enclosedset_wire_load -library slow -pvt max TSMC18_Conservative...set_port_capacitance 6.14228 vcopset_port_capacitance 6.14228 {{port_pad_data_out[6]}}...set_slew_time_limit -max 2.3 {{port_pad_data_out[3]}}set_slew_time_limit -max 2.3 {{port_pad_data_in[12]}}...set_input_delay -clock vclk1 -add_delay 0.5 {{port_pad_data_in[6]}}set_input_delay -clock vclk1 -add_delay 0.5 {{port_pad_data_in[11]}}...set_external_delay -clock vclk1 -add_delay 0.5 {{port_pad_data_out[1]}}set_external_delay -clock vclk1 -add_delay 0.5 {{port_pad_data_out[15]}}

...




Distributed Synthesis

Distributed Synthesis is a built-in automated parallel processing technology that lets you takeadvantage of multiple processors working on a single synthesis design, thus achievingsignificant speedups in run times. This highly automated system, requiring very little directionfrom you, is a robust system with a built-in recovery mechanism for networking and computerfailure. Distributed synthesis also has built-in controls to work seamless in an environmentmanaged by the Platform Computing LSF batch management product.

For more information, refer to Distributed Processing for BuildGates Synthesis.



Summary

Congratulations, you have just finished the introductory module for BuildGates Extreme.

In this session, you learned:

■ How BuildGates Synthesis works including test synthesis, timing analysis, translation,mapping and optimization.

■ Which commands to use to execute the basic steps in the BuildGates Synthesis flow.

■ To use BuildGates Synthesis in both text mode and graphical mode.

■ How to migrate from Design Compiler to BuildGates Synthesis.

Where to Go from Here

At this time, you may be interested in completing one of the following tutorials that go intodetail on some of the advanced features of BuildGates Extreme:

■ Getting Started with Design For Test

■ Getting Started with Datapath (advanced arithmetic)

■ Getting Started with Low Power Synthesis



3Getting Started with Design For Test

This tutorial contains the following sections:

■ Introduction to BuildGates Test Synthesis on page 74




■ BuildGates Top-Down Test Synthesis Configuration Flow on page 78

❑ Setting up the Design Environment on page 80

❑ Read Libraries and the HDL Models for the Design on page 81

❑ Setting Test Synthesis Assertions on page 82

❑ Checking DFT Assertions and Rule Violations on page 84

❑ Fixing DFT Rule Violations on page 87



❑ Setting Scan Chain Assertions on page 90

❑ Connecting the Scan Chains on page 92

❑ Checking the Timing of the Design on page 94

❑ Viewing the Scan Chains on page 95


■ Writing Interface Files to Third Party ATPG Tools on page 97


Cadence Synthesis Rapid Adoption KitGetting Started with Design For Test

Introduction to BuildGates Test Synthesis

Design For Test (DFT) using BuildGates Test Synthesis refers to the set of capabilities ofBuildGates® Synthesis to perform test synthesis. Test synthesis consists of a set ofautomated techniques used to integrate DFT logic into your design.

In BuildGates Synthesis this includes capabilities to automatically map all flip-flops that passDFT rule checks to their scan-equivalent flip-flops from the target technology library, andconfigure those flip-flops into scan chains (scan chain configuration) given the presence ofclock domain information (output from check_dft_rules command). These functions canbe applied to designs at the RTL, gate, or mixed level.

Capabilities

■ Supports Verilog/VHDL (RTL and/or gate level netlists) formats

■ Multiplexed flip flop, clocked-scan, clocked-LSSD, aux-clocked LSSD scan insertionstyles

■ Module or instance specific set_dont_scan attributes

■ DFT Rule Checking

■ Multiple clock domains

■ Multiple balanced scan chains

■ Data lockup latch insertion and analysis between compatible clock domains

■ Data lockup flip-flop insertion between compatible clock domains

■ Configuration of data lockup latches or flops at the end of the scan chains

■ Auto-fix of DFT rule violations associated with async set/reset and internal clock nets

■ Full-scan test insertion

■ Top-down and bottom-up scan insertion

■ Test insertion to tieback, chain or floating modes

■ Scan chain inversion based on net loading

■ Fixed segment handling through set_dont_touch_scan attribute

■ Shared scan-data input and scan-data output signals

■ User-defined scan chain ordering through read_scan_order_file command

■ Automatic creation of top-level scan-data input and output, and scan mode ports



Objectives

This tutorial is an introduction to performing test synthesis of an RTL design in the top-downflow (shown in Figure 3-2 on page 79) using BuildGates Synthesis.

Upon completion of this tutorial, you will have learned the following:

■ Full scan test insertion

■ Single-pass test synthesis

■ DFT rule checking

■ Top-down scan insertion

■ Test insertion to tieback and chain mode

■ Data lockup latch insertion and analysis between compatible clock domains

■ Using existing functional ports for scan-data signals

■ Writing ATPG interface files for third-party ATPG tools

■ Displaying module level scan chains

■ Using set_dont_modify and set_dont_touch_scan on precompiled lower levelmodules

For further information on the BuildGates test synthesis features, see the Design for Test(DFT) Using BuildGates Synthesis and Cadence PKS.

Note: This module assumes that you completed Chapter 2, “Getting Started with BuildGatesSynthesis” and that you are familiar with Design for Test (DFT).

Example Design

The design in this tutorial is a Verilog description of a Dual Tone Multi-Frequency (DTMF)receiver. In a telephone network, DTMF is a common form of in-band signaling techniqueused for transmitting information between network entities. DTMF signals are commonlygenerated by touch tone telephones. Figure 3-1 on page 76 shows the block diagram ofDTMF receiver.

The DTMF controller is comprised of RTL modules with the exception of the DMA Controller.This module has previously undergone test synthesis to scan flops. The logic in this modulewill be preserved during optimization by attributing this block with a set_dont_modifyproperty. All other blocks, unless attributed with a set_dont_scan property, will undergotest synthesis.



Figure 3-1 DTMF Block Diagram

SPI ULAW_CONVERTER

DATA SAMPLE

DATA SAMPLE RAM

DMA CONTROLLER

BUS ARBITER

SCRATCH

TDSPTDSP_CS_DS

ROMASCII DIGIT

RCC

REGISTER

TDSP MUX

MUX

DATA RAM

Note: This is a high-level diagram.spi_clk

spi_fs

spi_data

dout(7:0)

clk reset

dflag read

upcm(7:0)

lpcm(15:0)

dout[15:0]

t_data[15:0]

t_data_in[15:0]

clk reset

bus_grant

top_buf_flag

reset

t_write_rcc

bus_request_out

bus_grant_in

Scan flops previously added(block attributed with

Not all connections are shown.

set_dont_modify property).



Setting Up to Run the TutorialNote: We assume that you already copied the data. If not, see Getting Started on page 12.

Required License

You need a BuildGates (BG) license to run this module.

Required Files

You need the following files to run this tutorial:

tutorial_dft Root directory

tcl Scripts to run this module

rtl Verilog design modules

lib Synthesis libraries

rpt Timing, area, hierarchy, dft registers (scan and non-scan), scan orderfile

adb Design netlists and database files




BuildGates Top-Down Test Synthesis Configuration Flow

The top-down test synthesis configuration flow maps all flip-flops which pass the DFT rulechecks and which are not attributed with a set_dont_modify or set_dont_scanproperty, to their scan equivalent flops and creates scan chains in a single optimization pass.

By default, the number of scan chains configured in the design is a single scan chain for eachDFT clock domain identified by the check_dft_rules command. You can also createadditional scan chains by specifying the set_number_of_scan_chains orset_max_scan_chain_length assertions, or create merged scan chains using theset_dft_compatible_clock_domain assertion.

The selection of test synthesis assertions and commands depends on whether you areperforming test synthesis in tieback mode or creating the scan chain configuration afteroptimization.

The flow outlined in Figure 3-2 on page 79 is used to synthesize the DTMF controller to scanflops and create the top-level scan chains. Figure 3-2 shows the order in which you specifythe test synthesis assertions and commands when the scan flops are being placed intieback mode (see Setting Test Synthesis Assertions on page 82). After optimizationcompletes, the top-level scan chains are configured by specifying the top-level chainassertions and then running the scan connection engine in chain mode using thedo_xform_connect_scan command (see Connecting the Scan Chains on page 92).



Figure 3-2 DFT Top-Down Configuration Flow

Note: Colored steps are either DFT-specific or are affected by DFT.

Set Scan Chain Assertions

Check DFT Assertions andDFT Rule Violations

report_dft_registers

do_xform_connect_scan

Design completely synthesized

Read Libraries, Design Data

Set Test Synthesis Assertions

Fix DFT Violations

set_global dft_scan_path_connect tieback

set_global dft_scan_avoid_control_buffering true

set_scan_style

set_scan_mode

set_test_mode_setup

report_dft_assertions

check_dft_rules

Set Constraints

Optimize Design

set_global dft_scan_path_connect chain

set_scan_data

set_number_of_scan_chains

set_dft_compatible_clock_domain

Connect Scan Chains

Fix Timing Violations

Write Netlist and DatabaseFiles



Setting up the Design Environment

Start the Tool

1. Change to the run_dir directory in the tutorial_dft directory.

2. Invoke BuildGates in Graphical User Interface (GUI) mode.

bg_shell -gui &

3. Set up your design environment by running the following script in bg_shell:

bg_shell> source ../tcl/setup.tcl

The setup.tcl file defines Tcl variables for the rtl, library, report, database, and Tcldirectories. This file contains the following commands:

set run_dir ./set rak_dir ../set tcl_dir $rak_dir/tclset rtl_dir $rak_dir/rtlset lib_dir $rak_dir/libset rep_dir $rak_dir/rptset adb_dir $rak_dir/adb

Set Global Variables

➤ Set some globals by running the following script:

bg_shell>source $tcl_dir/set_globals.tcl

The set_globals.tcl script sets two variables:

set_global message_verbosity_level 3set_global echo_commands true

■ The message_verbosity_level variable controls the level of verbosity of themessages generated by bg_shell in reporting information, warnings, and errors.

■ The echo_commands variable causes each command to be echoed in the standardoutput prior to its execution.



Read Libraries and the HDL Models for the Design


bg_shell> source $tcl_dir/read_lib.tcl

The read_lib.tcl script contains the following statements:

read_tlf $lib_dir/slow_4.3.tlfread_tlf $lib_dir/pllclk_slow_4.3.tlfread_tlf $lib_dir/ram_128x16A_slow_4.3.tlfread_tlf $lib_dir/ram_256x16A_slow_4.3.tlfread_tlf $lib_dir/rom_512x16A_slow_4.3.tlfread_library_update $lib_dir/tpz973gwc-lite_4.3.tlf

set_global target_technology slow

This script will set the technology libraries and wireload model for this design.

2. View the contents of the technology library with the following command:

bgx_shell>report_library

3. Read the RTL code for the design by running the following script:

bg_shell> source $tcl_dir/read_rtl.tcl

The read_rtl.tcl script contains the following statements:

set_global hdl_verilog_vpp_arg -I$rtl_dir

read_verilog $rtl_dir/accum_stat.vread_verilog $rtl_dir/alu_32.vread_verilog $rtl_dir/arb.vread_verilog $rtl_dir/data_bus_mach.vread_verilog $rtl_dir/data_sample_mux.vread_verilog $rtl_dir/decode_i.vread_verilog $rtl_dir/digit_reg.vread_verilog $rtl_dir/dma.vread_verilog $rtl_dir/dtmf_recvr_core.vread_verilog $rtl_dir/execute_i.vread_verilog $rtl_dir/mult_32_dp.vread_verilog $rtl_dir/m16x16.vread_verilog $rtl_dir/port_bus_mach.vread_verilog $rtl_dir/prog_bus_mach.vread_verilog $rtl_dir/ram_128x16_test.vread_verilog $rtl_dir/ram_256x16_test.vread_verilog $rtl_dir/results_conv.vread_verilog $rtl_dir/spi.vread_verilog $rtl_dir/tdsp_core.vread_verilog $rtl_dir/tdsp_core_glue.vread_verilog $rtl_dir/tdsp_core_mach.vread_verilog $rtl_dir/tdsp_data_mux.vread_verilog $rtl_dir/tdsp_ds_cs.vread_verilog $rtl_dir/test_control.vread_verilog $rtl_dir/ulaw_lin_conv.vread_verilog $rtl_dir/iopads.vread_verilog $rtl_dir/dtmf_chip.v



4. Transform the design into a hierarchical, gate-level netlist by entering the followingcommand:

bg_shell> do_build_generic

The do_build_generic command transforms the design into a hierarchical, gate-levelnetlist consisting of technology-independent logic gates. It also performs constantpropagation, loop unrolling, lifetime analysis, and register inferencing. You see thefollowing messages:

Info: Setting 'dtmf_chip' as the top of the design hierarchy <FNP-704>.Info: Setting 'dtmf_chip' as the default top timing module <FNP-705>.

These messages indicate that the top module is set to dtmf_chip for logic optimizationand scan chain configuration. The top timing module is set to dtmf_chip for timingassertions and DFT rule checking. These modules can also be specified by theset_current_module and set_top_timing_module commands, respectively.

Setting Test Synthesis Assertions

Assertions can be thought of as requirements or guidelines that govern how test synthesiswill process the design. Assertions are used by test synthesis commands, such ascheck_dft_rules, do_xform_connect_scan, and write_scan_order_file.

1. Set test synthesis assertions by running the following script:

bg_shell> source $tcl_dir/scan_assert.tcl

The script contains two sections.

2. Examine the commands in the first section of the scan_assert.tcl file.

The “Mapping test_control module” section of scan_assert.tcl file contains thefollowing commands:

set_current_module test_controldo_xform_mapset_dont_modify [find -hier -module test_control]set_current_module [find -module dtmf_chip]

The test_control module consists of combinational gates which multiplex betweenthe functional clocks (system mode), and the test clock (test mode). The select enablesignal to the mux is controlled by the test_mode signal.

❑ The set_current_module command sets test_control as the design context.

❑ The do_xform_map transform maps the test_control module to targettechnology slow.



❑ The set_dont_modify command keeps the instances, nets, or submodules in thetest_control module from being modified by the optimization and test synthesistool.

❑ The second set_current_module sets the timing and optimization context to thedtmf_chip module.

3. Examine the commands in the second section of the scan_assert.tcl file.

The “Setting Test Synthesis Assertions” section of the scan_assert.tcl file containsthe following commands:

set_scan_style muxscanset_global dft_scan_path_connect tiebackset_global dft_scan_avoid_control_buffering true

set_scan_mode IOPADS_INST/Pscanenip/C 1

set_dont_modify [find -instance DTMF_INST/DMA_INST]set_dont_touch_scan dma

❑ The set_scan_style command sets the scan style to muxscan. The multiplexedscan style (muxscan) is the most commonly used scan style. Test synthesissupports four scan styles: muxscan, clocked_scan, clocked_LSSD, andaux_clocked_LSSD. When no style is selected, the default is muxscan.

❑ The set_global dft_scan_path_connect tieback command sets the scanconnection mode to tieback by test synthesis during optimization. The tiebackmode connects the scan flop's scan-data output pin to its own scan-data input pin.Cadence recommends that you set this variable to tieback before optimizationand set the variable to chain after optimization, when the scan chain is created andconnected.

❑ The set_global dft_scan_avoid_control_buffering true command isoptional. It prevents buffering of the high fanout scan mode control signal after it isglobally routed by test synthesis during optimization. By default, high fanout signalsare buffered by timing optimization and design rule fixing. This command overridesthe default behavior for the scan mode signal only.

❑ In the muxscan style, the set_scan_mode IOPADS_INST_Pscanenip/C 1command specifies an internal pin, IOPADS_INST/Pscanenip/C, and its activevalue (1)which is the scan mode signal, used for shifting scan-data into scan flops.If you do not specify this assertion, test synthesis will create a top-level input portnamed BG_scan_enable, with an active high polarity. Additionally, you can specifythe dft_scan_port_name_prefix global to specify a different default namingconvention.

❑ The set_dont_modify [find -instance DTMF_INST/DMA_INST]command keeps the instances, nets, or modules in DMA_INST module from beingmodified by the optimization tool. The command is needed as the DMA_INST



module is a precompiled module from a previous synthesis run. This attribute alsoprevents the scan chains and scan chain order from being modified by the testsynthesis tool. If optimization were allowed in the module, but the scan chainconfiguration was to be preserved, then use the set_dont_touch_scan assertioninstead. You should specify this assertion prior to creating the top-level scan chains.

Checking DFT Assertions and Rule Violations

The following procedure verifies the test synthesis assertions applied to the database andchecks the generic database for DFT rule violations.

1. Display the current test synthesis assertions (optional):

bg_shell> report_dft_assertions

The report_dft_assertions command displays the following test synthesisassertions that are in effect.

Info: Scan mode for module 'dtmf_chip' set to 'IOPADS_INST./Pscanenip/C = 1'.Info: Default Scan mode for module ’dtmf_chip’ set to ’IOPADS_INST/Pscanenip/C = 1’.Info: Scan style for module 'dtmf_chip' set to 'mux_scan'.Info: module 'dma' set to DONT_TOUCH_SCAN mode.

Note: Check for combinational loops and race conditions in your design (optional):

set_global dft_enable_combinational_loop_check trueset_global dft_enable_race_condition_check true

Setting the above global variables to true forces a subsequent execution ofcheck_dft_rules to check for and report any combinational feedback loops and anyflip-flops with potential race conditions between the data and clock signals.

2. Check for DFT rules violations.

bg_shell> check_dft_rules

The check_dft_rules command checks for DFT rules violations, such asuncontrollable clocks and uncontrollable asynchronous signals. It also checks to makesure clock pins to the flip-flops are directly controllable from a primary input, and that anyasynchronous control pins (set/reset) to the flip-flops can be held to their inactive stateduring the scan shift-cycle of test mode.

The tool does not insert scannable flip-flops where DFT violations occur. Only those flopswhich pass the DFT rule checks will be mapped onto their scan equivalent flop andplaced on the scan chain. The check_dft_rules command displays a message if itdetects any violations. You should fix all reported problems either by modifying your RTLor by using the auto-DFT fix capabilities described in Improving Testability of Your Designin Design For Test (DFT) Using BuildGates Synthesis and Cadence PKS.Otherwise, your fault coverage is reduced.



The check_dft_rules command lists the DFT clock domains, any internal clockdomains specified with the set_dft_internal_clock_domain assertion, thenumber of flip-flops associated with those domains that have passed the DFT ruleschecks, and the number of flip-flops which failed the DFT rule checks.Part of the TDRC output is shown below.

...Info: Checking for registers with uncontrollable clock ports. <DFT-315>.==> ERROR: DFT Violation 1: Internally driven Clock net ’DTMF_INST/TDSP_DS_CS_INST/m_sel_ds_address’ in module ’tdsp_ds_cs’ (File ../rtl/tdsp_ds_cs.v, Line 125) <DFT-316>.

Traced its effective fanin cone to::test_modeDTMF_INST/TDSP_CORE_INST/DATA_BUS_MACH_INSTwrite_reg:QDTMF_INST/TDSP_CORE_INST/PORT_BUS_MACH_INST/as_reg:QDTMF_INST/TDSP_CORE_INST/DECODE_INST/ir_reg_9:QDTMF_INST/TDSP_CORE_INST/DECODE_INST/ir_reg_10:Q:scan_clkrefclkibiaspllrst

. . . . . . . . . . . .==> ERROR: DFT Violation 3: Internally driven Clock net ’DTMF_INST/m_clk’ inmodule ’dtmf_recvr_core’ (File ../rtl/dtmf_recvr_core.v, Line 84) <DFT-316>.

Traced its effective fanin cone to::test_modescan_clkrefclkibiaspllrst

. . . . . . . . . . . .Clock pins for dft_top_module dtmf_chip are:Info: Checking for registers with uncontrollable Async. Set/Reset ports.<DFT310>.Info: Partitioning registers for scan based on clock domain. <DFT-325>.Total Clock domains: 0 for 0 f/fInfo: Total Scannable register count: 0 <DFT-340>.--> WARNING: Scan mapped register 'DTMF_INST/DMA_INST/breq_reg' in module'netlist' has a TDRC violation:internal clock signal <DFT-334>.--> WARNING: Scan mapped register 'DTMF_INST/DMA_INST/as_reg' in module'netlist' has a TDRC violation: internal clock signal <DFT-334>.. . . . . .. . . . . . .--> WARNING: Scan mapped register 'DTMF_INST/DMA_INST/a_reg_1' in module'netlist' has a TDRC violation: internal clock signal <DFT-334>.--> WARNING: Scan mapped register 'DTMF_INST/DMA_INST/a_reg_0' in module'netlist' has a TDRC violation: internal clock signal <DFT-334>.Info: Checking for available scan cells in Library. <DFT-330>.--> WARNING: Design has 6 TDRC violations <DFT-342>.

If a flip-flop fails the DFT rule checks, a fanin trace from the source of the violation to thetop-level ports will be automatically performed. The fanin trace attempts to identify alltop-level primary input ports associated with the cone of logic originating from the failure.

The goal is to identify a primary input port which when placed in test mode, will bypassthe DFT rule violation. Of course, this presumes that the bypass logic has already beencoded in the RTL.



Following is one of the errors reported by the check_dft_rules command.

==> ERROR: DFT Violation 6: Internally driven Clock net ’DTMF_INST/m_digit_clk’ in module ’dtmf_recvr_core’ (File ../rtl/dtmf_recvr_core.v, Line84) <DFT-316>.

Traced its effective fanin cone to::test_modescan_clkDTMF_INST/RESULTS_CONV_INST/digit_clk_reg:Q

The above fanin trace indicates that the DFT rule violation maybe possibly bypassed bysetting the top-level signal, test mode, to an appropriate logic value using theset_test_mode_setup assertion. The value of the assertion is propagated throughthe circuit on the next invocation of check_dft_rules command.



Fixing DFT Rule Violations

1. Fix the DFT rule violations by running the following script:

bg_shell> source $tcl_dir/fix_dft_rules.tcl

The fix_dft_rules.tcl script has the following commands:

set_test_mode_setup test_mode 1set_test_mode_setup spi_fs 0

These assertions set the test_mode signal to a logic 1, and set the asynchronous setor reset signal spi_fs to a logic 0 for the duration of test mode session. When specified,the following Info messages are displayed:

set_test_mode_setup test_mode 1

Info: Test mode for module ’dtmf_chip’ set to ’test_mode = 1’ during entiretest session.

set_test_mode_setup spi_fs 0

Info: Test mode for module ’dtmf_chip’ set to ’spi_fs = 0’ during entire testsession.

Additionally, if an asynchronous set or reset signal had been directly controllable from aprimary input port, such that this signal fanned out directly (or through buffers orinverters) to the asynchronous set/reset pins of the flip-flops, the check_dft_rulescommand would have automatically asserted the test mode setup for this signal. Thevalue asserted for the signal is specified to maximize the number of flip-flops which passthe DFT rule checks. When the assertion is automatically specified, thecheck_dft_rules command displays the following message:

TDRC identified the following PI ports as active set/reset control pins to beheld constant during scan-shift operation:

Set PI port reset to logic 0 during scan-shift

Note: This assertion can be manually specified as follows:

bg_shell> set_test_mode_setup reset 0 -scan_shift

2. Having specified the test mode setup signals, re-run the DFT rule checks to propagatethe logic values of these signals through the circuit.

bg_shell> check_dft_rules

The output from check_dft_rules, also known as DFT rule check data, is used by thetest synthesis tool to configure the scan chains during optimization. The final output fromthe check_dft_rules command is shown below:

Info: Checking for registers with uncontrollable clock ports. <DFT-315>.Clock pins for dft_top_module dtmf_chip are: scan_clk

Info: Checking for registers with uncontrollable Async. Set/Reset ports.<DFT-310>....

Info: Partitioning registers for scan based on clock domain. <DFT-325>.Clock Domain 0 from pin ’scan_clk’ (Neg Edge) <Internal Pin: ’None’> has 129 f/fClock Domain 1 from pin ’scan_clk’ (Pos Edge) <Internal Pin: ’None’> has 411 f/f



Total Clock domains: 2 for 540 f/fInfo: Total Scannable register count: 540 <DFT-340>.Info: Checking for available scan cells in Library. <DFT-330>.Info: Design has no TDRC violation <DFT-343>.

At this stage, there are no DFT rule check violations. The DFT rule check report indicatesthe top-level clock pins, their DFT clock domains, and the number of flip-flops in eachdomain which pass the DFT rule checks. You can see that both edges of the scan_clkare used in the design for a total flip-flop count of 540.

In specific:

❑ DFT Clock domain 0 is associated with 129 flip-flops, which are negative edgetriggered.

❑ DFT Clock domain 1 is associated with 411 flip-flops, which are positive edgetriggered.

In the absence of specifying configuration assertions such asset_number_of_scan_chains, set_max_scan_chain_length, orset_dft_compatible_clock_domains, test synthesis would use the DFT rulecheck data to create a default configuration. The default configuration creates a singlescan chain for each DFT Clock domain. In this design, test synthesis would create twoscan chains, one of length 411 comprising the positive edge-triggered flops and one oflength 129, comprising the negative edge-triggered flops.

3. Generate a report for the list of scannable flops.

bg_shell> report_dft_registers -scan > $rep_dir/dft_registers.scan

The report_dft_registers -scan command writes scan flops identified bycheck_dft_rules to the file ../rpt/dft_registers.scan. The tool reports thefollowing message:

Info: Total Scannable register count: 540 <DFT-340>.

4. Generate a report for the list of non-scannable flops.

bg_shell> report_dft_registers -non_scan > $rep_dir/dft_registers.nonscan

The report_dft_registers -non_scan command writes nonscan flops identifiedby check_dft_rules to the file ../rpt/dft_registers.nonscan. The toolreports the following message:

Info: Total Non-Scannable register count: 0 <DFT-341>.

Flip-flops, which will be placed in the non-scan list, are those flip-flops that fail the DFTrule checks, or are attributed with a user-specified set_dont_scan property.

Since there are no DFT rule check violations, you can now proceed with specifying thetiming assertions prior to performing test synthesis (mapping the flip-flops to their scanequivalent flops) and optimization on the design.



Setting Constraints

➤ Set the constraints by running the following script:

bg_shell>source $tcl_dir/constraints.tcl

The constraints.tcl file sets up timing constraints for the dtmf_chip design. Fora detailed description of the constraints, see Setting Constraints on page 30.


➤ Optimize the DTMF design using the top-down synthesis methodology by entering thefollowing command:

bg_shell>do_optimize

The do_optimize command does the following:

❑ Generic optimization

❑ Technology mapping to scan flops (for all flip-flops which pass the DFT rule checks)

❑ Globally routes the scan mode control signal, as per thedft_scan_enable_connect global

❑ Connects the scan flops as per the dft_scan_path_connect global

❑ Logic optimization

Using the DFT rules check data, the test synthesis tool determines the scan status offlip-flops and to which DFT clock domain the flip-flops belong. In addition, the tool addsa scan mode port (tieback and chain mode), and it adds pairs of scan-data in andscan-data out ports (chain mode only), if required.

The test synthesis tool maps the design's flip-flops to scan flops and connects the scanchains as specified by the dft_scan_path_connect global variable. Because you setdft_scan_path_connect to tieback, the tool connects the scan-data output pin ofeach scan flop back to its own scan-data input pin.

Note: Depending on the performance of your machine, the optimization runs for a while.



Setting Scan Chain Assertions

The test synthesis tool was run in tieback mode, which connects the scan flop’s scan-dataoutput pin to its own scan-data input pin. Tieback mode speeds up synthesis because chainpath connections are not being considered during optimization.

➤ Now that optimization is completed, set the scan chain assertions and connect(configure) the scan chain in the current module (dtmf_chip).

bg_shell> source $tcl_dir/scan_chain_assert.tcl

The scan_chain_assert.tcl script contains the following commands:

set_number_of_scan_chains 8set_dft_compatible_clock_domain -same_clock

set_scan_data {IOPADS_INST/Ptdspip00/C} {IOPADS_INST/Ptdspop00/I} -shared_outset_scan_data {IOPADS_INST/Ptdspip01/C} {IOPADS_INST/Ptdspop01/I} -shared_outset_scan_data {IOPADS_INST/Ptdspip02/C} {IOPADS_INST/Ptdspop02/I} -shared_outset_scan_data {IOPADS_INST/Ptdspip03/C} {IOPADS_INST/Ptdspop03/I} -shared_outset_scan_data {IOPADS_INST/Ptdspip04/C} {IOPADS_INST/Ptdspop04/I} -shared_outset_scan_data {IOPADS_INST/Ptdspip05/C} {IOPADS_INST/Ptdspop05/I} -shared_outset_scan_data {IOPADS_INST/Ptdspip06/C} {IOPADS_INST/Ptdspop06/I} -shared_outset_scan_data {IOPADS_INST/Ptdspip07/C} {IOPADS_INST/Ptdspop07/I} -shared_out

■ The set_number_of_scan_chains 8 assertion specifies the total number oftop-level scan chains which are to be configured across all DFT clock domains identifiedby the check_dft_rules command. This assertion will create balanced scan chains.

Note: In addition to the above assertions, you can specify the scan chain length usingthe set_max_scan_chain_length assertion. This assertion will pack the scan chainsup to the limit specified, with any residual scan flops placed on a new chain. Both theset_number_of_scan_chains and set_max_scan_chain_length assertionscan be optionally specified with -clock (-rise and -fall options) which allows forclock domain-specific and clock edge-specific configuration of the scan flops which passthe DFT rule checks.

■ The set_dft_compatible_clock_domain assertion specifies the domain andphase compatibility between the DFT clock domains. This assertion optionally instructstest synthesis to insert a data lockup element between flip-flops belonging to the scanchain segments from the different DFT clock domains.

The -same_clock option instructs test synthesis to combine alternate edges of thesame root clock in a single scan chain. If the DFT clock waveform is set to Return-to-Zero(RTZ), the negative edge-triggered segments proceed the positive edge-triggeredsegments in the same scan chain avoiding the need to insert a data lockup elementbetween the domain transitions. If however, the set_dft_clock_waveform is set toReturn-to-One (RT1), the positive edge-triggered segments proceed the negativeedge-triggered segments in the same scan chain avoiding the insertion of a data lockupelement between the domain transitions. The set_dft_clock_waveform assertion



must be specified prior to running the check_dft_rules command. The default valuefor this assertion is RTZ. For this example, the root clock domain is scan_clk. Themessage from this assertion is excerpted below:

Info: Compatible clock mode set to ’DOMAINS THAT ARE PHASES OF SAME CLOCK CANBE MERGED’.

■ The set_scan_data assertion specifies the names for the scan-data input andscan-data output signals which are used to shift data into and out of the scan chains,respectively. The scan-data signals may be specified to top-level ports or hierarchicalpins. The scan-data input signal can be a dedicated port for scan in purposes only, or itcan be a shared functional input port. The scan-data output port can be a dedicated portfor scan out purposes only, or it can be a shared functional output port. Use the-shared_out option if the scan-data output signal is also a shared output. This optioninstructs test synthesis to insert a multiplexer to select between the internal scan-dataoutput (from the last scan flop in the scan chain), and the internal functional outputsignal. The select control to the multiplexer is the scan mode signal, declared using theset_scan_mode assertion.

For the eight sets of scan-data assertions above, the scan-data signals have beenspecified to existing hierarchical pins. When the scan chains are configured in thedesign, the connection engine uses these pins to create the connections from thescan-data input signals to the scan-data input pin of the first scan flop in each scan chain,and from the last scan flop output pin in each scan chain, multiplexed with the internalfunctional output signal to the scan-data output signal. The multiplexer is inserted justbefore the scan-data output signal, in the iopads module.

When specified, the following Info messages are displayed:

Info: Existing scan input port 'IOPADS_INST/Ptdspip00/C' will be used for scaninsertion.Info: Existing scan output port 'IOPADS_INST/Ptdspop00/I' will be used for scaninsertion.Info: Scan data I/O for module 'dtmf_chip' set to:<no clock domain>: {IOPADS_INST/Ptdspip00/C IOPADS_INST/Ptdspop00/I }.

where

IOPADS_INST/Ptdspip00/C is the output pin of input pad, port_pad_data_inIOPADS_INST/Ptdspop00/I is the input pin of the output pad, port_pad_data_out



Connecting the Scan Chains

Before optimization, the global variable dft_scan_path_connect was set to tiebackmode. You will now set this variable to chain mode to create the scan chains in the design.

1. Specify to connect the scan chain in chain mode:

bg_shell> set_global dft_scan_path_connect chain

When the scan chain connection engine is run, test synthesis creates the scan chainconfiguration by connecting the scan-data output pin from one scan flop to the scan-datainput pin of the next scan flop in the scan chain.

In chain mode, the following two additional DFT globals control how the chains areconnected.

❑ dft_scan_output_pref controls whether to use normal or inverted output (Q orQ-bar) of scan flip-flop for scan connection

The possible settings are:

❍ non_inv: use non-inverted (Q) output

❍ min_load: use the output with least load (DEFAULT)

❑ dft_allow_scan_path_inv controls if inverters should be inserted in scan pathto compensate for logic inversion when connecting from inverted output or toinverted scan-input.

The possible settings are:

❍ on: inversion in scan path is allowed. (DEFAULT)

❍ off: inversion in scan path is not allowed. When connecting from invertedoutput (Q-bar) or to inverted scan-input, an inverter will be inserted tocompensate for logic inversion in the scan data path.

2. Run the scan chain connection engine.

bg_shell> do_xform_connect_scan -scan_file dtmf_chip.scan.flat

The do_xform_connect_scan uses the clock domain information generated by thecheck_dft_rules command (shown below) to connect the scan flops into scan chainsand creates a scan chain order file in flat format in the run directory, nameddtmf_chip.scan.flat.

Clock Domain 0 from pin ’scan_clk’ (Neg Edge) <Internal Pin: ’None’> has 129 f/fClock Domain 1 from pin ’scan_clk’ (Pos Edge) <Internal Pin: ’None’> has 411 f/f

If you do not specify a name for the scan chain order file, it will be named the same asthe top-level module (set_current_module) with an extension of.scan.flat.



Due to the setting of set_number_of_scan_chains in this design, eight scan chainshave been created for scan flops clocked by scan_clk. Test synthesis will createbalanced (equal length) scan chains as follows:

❑ One scan chain of length 68 is created in Clock Domain 0 for a total scan flop countof 68.

❑ Six scan chains of length 68 are created in Clock Domain 1 for a total scan flop countof 408.

Due to the setting of the set_dft_compatible_clock_domain to -same_clock,one scan chain of length 64 is created between two scan chain segments clocked by thescan_clk negedge and scan_clk posedge respectively. Using this order no datalockup element is needed between the domain transitions. The scan chain segment inthe scan_clk negedge domain has three scan flops and the scan chain segment in thescan_clk posedge domain has 61 scan flops.

Note: If a data lockup latch would be inserted, it would be denoted using llatchnotation in the scan chain order file.

When the connection engine is run, it first analyzes the lower level modules in order toidentify existing scan chain segments. These segments are then incorporated into thetop-level scan chains. Note that the scan chain analysis routine analyzed a 17-scan flopscan chain segment in precompiled module dma. Since this module was attributed withset_dont_modify and set_dont_touch_scan properties, the order of the scanflops in the scan chain segment will remain intact when incorporated into the top-levelscan chains.

do_xform_connect_scan generates the following messages while running:

Collecting scan chains for module ram_128x16_test <DFT-501>.Collecting scan chains for module spi <DFT-501>.Collecting scan chains for module arb <DFT-501>.Collecting scan chains for module dma <DFT-501>.Analyzed chain # 1 (total 17 regs; BG_scan_in -> BG_scan_out)connected in module 'dma'. <DFT-025>.

When the top-level scan chains are being created by the connection engine, it will alsogenerate an Info message to indicate the insertion of data lockup latches.

Top-level chain 1 (IOPADS_INST/Ptdspip00/C -> IOPADS_INST/Ptdspop00/I) has 68registers. <DFT-024>.Top-level chain 2 (IOPADS_INST/Ptdspip01/C -> IOPADS_INST/Ptdspop01/I) has 68registers. <DFT-024>.Top-level chain 3 (IOPADS_INST/Ptdspip02/C -> IOPADS_INST/Ptdspop02/I) has 68registers. <DFT-024>.Top-level chain 4 (IOPADS_INST/Ptdspip03/C -> IOPADS_INST/Ptdspop03/I) has 68registers. <DFT-024>.Top-level chain 5 (IOPADS_INST/Ptdspip04/C -> IOPADS_INST/Ptdspop04/I) has 68registers. <DFT-024>.Top-level chain 6 (IOPADS_INST/Ptdspip05/C -> IOPADS_INST/Ptdspop05/I) has 68registers. <DFT-024>.



Top-level chain 7 (IOPADS_INST/Ptdspip06/C -> IOPADS_INST/Ptdspop06/I) has 68registers. <DFT-024>.Top-level chain 8 (IOPADS_INST/Ptdspip07/C -> IOPADS_INST/Ptdspop07/I) has 64registers. <DFT-024>.

Finally, test synthesis will report the top-level scan chains which have been configured inthe design.

Collecting scan chains for module dtmf_chip <DFT-501>.Analyzed chain # 1 (total 68 regs; IOPADS_INST/Ptdspip00/C ->IOPADS_INST/Ptdspop00/I) connected in module 'dtmf_chip'.<DFT-025>.Analyzed chain # 2 (total 68 regs; IOPADS_INST/Ptdspip01/C ->IOPADS_INST/Ptdspop01/I) connected in module 'dtmf_chip'.<DFT-025>....Analyzed chain # 7 (total 68 regs; IOPADS_INST/Ptdspip06/C -> IOPADS_INST/Ptdspop06/I) connected in module ’dtmf_chip’. <DFT-025>.Analyzed chain # 8 (total 64 regs; IOPADS_INST/Ptdspip07/C -> IOPADS_INST/Ptdspop07/I) connected in module ’dtmf_chip’. <DFT-025>.Finished scan connection <DFT-400>.

This report shows how the scan chains are evenly balanced with equal scan chainlengths using BuildGates Synthesis.

Checking the Timing of the Design

➤ Check the timing.

bg_shell> report_timing > $rep_dir/time_scan.rpt

The time_scan.rpt shows that timing is met for this design.

Important

If there are any timing violations after scan chain connection, you need to performincremental timing optimization.



Viewing the Scan Chains

The design contains eight scan chains since the set_number_of_scan_chains assertionis set to 8. You can examine the scan chains in a text file or in the schematic viewer.

1. Examine the flat scan chain report file.

more dtmf_chip.scan.flat

The flat scan chain report file is organized by scan chain, listing all the bits on each scanchain in the order of connection.

A sample of the dtmf_chip.scan.flat file is shown below:

module dtmf_chipbegin_chain 1 port IOPADS_INST/Ptdspip00/Cbit 1 DTMF_INST/DIGIT_REG_INST/flag_out_reg/Qbit 2 DTMF_INST/DIGIT_REG_INST/digit_out_reg_7/Qbit 3 DTMF_INST/DIGIT_REG_INST/digit_out_reg_6/Q

. . . . . .

. . . . . .bit 66 DTMF_INST/SPI_INST/bit_cnt_reg_2/Qbit 67 DTMF_INST/SPI_INST/bit_cnt_reg_1/Qbit 68 DTMF_INST/SPI_INST/bit_cnt_reg_0/Qend_chain 1 port IOPADS_INST/Ptdspop00/I <shared_or_complex_out>

2. Display the scan chains with the schematic viewer.

a. Select Edit – Preferences – Schematic.

The Schematic Preferences form appears.

b. Enable Display scan chain.

c. Click OK.

d. Double-click on the top module.

The GUI highlights the scan chains in the design as shown in Figure 3-3 on page 96.

Note: You can also view the scan chains as follows:

e. Double-click on the top module to display the schematic in the Schematic window.

f. Display the scan chains for the top module:

display_scan_chains [get_names [get_current_module]]



Figure 3-3 Scan Chains Displayed in Schematic Viewer


Optimization is complete and the scan chains are connected.

➤ Write the netlist and database:

bg_shell> write_verilog -hierarchical $adb_dir/dtmf_chip_scan.vsbg_shell> write_adb $adb_dir/dtmf_chip_scan.adb



Writing Interface Files to Third Party ATPG Tools

BuildGates generates interface files containing scan chain information in the IEEE StandardTest Interface Language (STIL) format or in a format readable by third party ATPG tools likeMentor FastScan®, Syntest Turboscan®, and LogicVision® ATPG tools.

1. Remove scan_mode and scan_dataDFT assertions, which are set on the internal padpins and set them with top-level ports.

bg_shell> source $tcl_dir/remove_dft_assertions.tcl

The remove_dft_assertions.tcl script contains the following commands:

remove_dft_assertions -scan_mode -scan_data_io

#set top level scan port assertions

set_scan_mode scan_en 1

set_scan_data {port_pad_data_in[7]} {port_pad_data_out[7]} -shared_outset_scan_data {port_pad_data_in[6]} {port_pad_data_out[6]} -shared_outset_scan_data {port_pad_data_in[5]} {port_pad_data_out[5]} -shared_outset_scan_data {port_pad_data_in[4]} {port_pad_data_out[4]} -shared_outset_scan_data {port_pad_data_in[3]} {port_pad_data_out[3]} -shared_outset_scan_data {port_pad_data_in[2]} {port_pad_data_out[2]} -shared_outset_scan_data {port_pad_data_in[1]} {port_pad_data_out[1]} -shared_outset_scan_data {port_pad_data_in[0]} {port_pad_data_out[0]} -shared_out

The remove_dft_assertions command removes DFT assertions that were set usingset_scan_mode and set_scan_data assertions. Since the assertions were specifiedto internal pins (pads), for ATPG purpose these are removed and re-specified usingtop-level ports.

The eight set_scan_data commands are used to specify the top-level ports to be usedfor generation of ATPG vectors. Now the platform is set for generation of ATPG interfacefiles for the third-party ATPG tools.

2. Write ATPG interface files.

❑ For FastScan, enter

bg_shell> write_atpg_info -mentor

This command writes dtmf_chip.dofile (command file) anddtmf_chip.testproc (test procedure) files into the run directory.

❑ For Syntest, enter:

write_atpg_info -syntest

❑ For LogicVision, enter:

write_atpg_info -logicvision



❑ For an interface file in the IEEE Standard Test Interface Language (STIL) format,enter:

write_atpg_info -stil


Summary

In this session, you

■ Became familiar with the DFT top-down flow which performs test synthesis of an RTLdesign.

■ Learned that DFT automatically maps all flip-flops that pass DFT rule checks to theirscan-equivalent flip-flops from the target technology library, and configures thoseflip-flops into scan chains given the presence of clock domain information

■ Learned how to display the scan chains

■ Learned how to write ATPG interface files for third-party ATPG tools



4Getting Started with Datapath

■ Introduction to BGX Datapath on page 100




■ Traditional Synthesis Run on page 103

■ BGX Datapath Flow on page 104

❑ Setting up the Design Environment on page 105

❑ Setting up Global Variables on page 105

❑ Reading the Synthesis Technology Libraries on page 106


❑ Creating a Generic Gate-Level Netlist on page 106


❑ Operator Merging on page 108



❑ Writing Netlist, Database Files and Report File on page 114

■ Examining Traditional Synthesis Results on page 115

■ Comparing BGX and Traditional Results on page 115


Cadence Synthesis Rapid Adoption KitGetting Started with Datapath

Introduction to BGX Datapath

Datapaths are multi-bit bus structures consisting of arithmetic components such as adders,multipliers, decoders, counters, Multiply-Accumulators (MAC), and so on. Traditionally,computing and multimedia designs had some datapath contents, but recently with theintegration of computing devices and telecom devices, the usage of datapaths has increased.Telecom designs implement filters with many datapath components. In addition, as a resultof the market convergence of consumer, communication, computing, and multimediaapplications. most IC designs have complex datapath contents.

Traditional logic synthesis tools optimize datapath contents by providing a library consistingof commonly used datapath components. Very often designers have to overwrite theseinstances by using pragmas or global variables to produce better results. If these componentsend up on a critical path, each one must be individually optimized to improve timing. Indesigns that have many datapath components, there are opportunities for improvement byeliminating redundancies in multiply connected components. Many times designers handcraftcustom datapath components to eliminate these redundancies and to achieve the desiredperformance.

Another approach designers use to synthesize high performance datapath designs involvesmanually partitioning the datapath portion of the design, writing datapath description in non-standard, proprietary language (such as MCL), and optimizing it in a specialized, standalonetool. The following are some disadvantages to these techniques:

■ Handcrafted datapath components often require datapath expertise that is not available.

■ Specialized datapath solutions are difficult to implement and use.

■ Stand-alone datapath synthesis solutions require learning a new language to describethe datapath logic, which results in a loss of portability across tools and limits your abilityto reuse designs.

■ Timing closure requires manual effort when you use point tools.

■ Designs must be manually partitioned.

■ You have to manually explore various implementations and choose the best one.

■ Quality of Results (QOR) leaves much to be desired.

BuildGates Extreme (BGX) addresses all of these issues. As you will see in this tutorial, BGXdelivers hand-crafted quality results. It automatically takes advantage of redundancies tobuild optimal components and automatically selects architectures for you based on thecontext of the component. (For more information on the library see More about theAmbitWare Library on page 163). BGX eliminates the need for a separate point tool orspecialized datapath or language knowledge. For more information about BGX datapathfeatures see Datapath for BuildGates Synthesis and Cadence PKS.



Objectives

In this tutorial, you will work on a Finite Input Response (FIR) filter design using the datapathfeature of the BuildGates Extreme (BGX) flow, and compare the results to those from atraditional flow.

■ Learn about BuildGates Extreme (BGX) datapath features.

■ Compare the quality of results from BuildGates Extreme with the results from traditionalsynthesis.

Note: This tutorial assumes that you have already gone through the Getting Started withBuildGates Synthesis (the basic module of the Rapid Adoption Kit) and are familiar with basicsynthesis.

Example Design

You will use an FIR filter (shown in Figure 4-1) with the following specifications:

32-TAP16-bit coefficient16-bit I/O data

Figure 4-1 FIR Filter Architecture

x(n)

16-tap Tapped Delay Line 16-tap Tapped Delay Line

+

x

+

+

+

x

+

+

x x

+

+ y(n)

Accumulator

FilterCoefficients



Setting Up to Run the Tutorial

Note: We assume that you already copied the data. If not, see Getting Started on page 12.

Required License

You need a BuildGates Extreme (BGX) license to run this tutorial. The BGX adds Datapath(DP) and Low Power Synthesis (LPS) capabilities to BuildGates Synthesis.

To save running time, you can run bg_shell in parallel with bgx_shell, one for the regularflow and the other for DP flow. This requires either two BGX licenses (one for runningbg_shell) or one BG and one BGX license. Call your sales representative to get demolicenses if needed.

Required Files

To run datapath you need the following:

■ Datapath content in your design. Specifically, you need to have some of the four basicarithmetic functions (+, -, *, /) or some of the comparison operators (<, >, >=,and so forth). The FIR filter that you will be working with has four multipliers and nineadders.

■ Basic synthesis pre-requisites: a properly constrained design and a synthesis library.

■ Verilog or VHDL code for the design, preferably at the RTL level. Datapath must be eitherinferred or instantiated. (Gate-level netlists offer little improvement opportunity). Formore information on the supported languages, see More about Extended Languages onpage 166.

The your_install_path/doc/syntut/RAK/tutorial_dp directory contains thefiles needed to run this module and has the following directory structure::tutorial_dp Root directory

tcl Scripts to run the RAK DP module


lib Synthesis library

rpt Design outputs, including timing, area, hierarchy, and other report files

adb Design outputs, including netlist and database files

run_dir Run directory



Traditional Synthesis Run

For comparison purposes, you will try a traditional synthesis run of the FIR filter. On thesurface, the only difference between the traditional synthesis run and the BGX run is that youinvoke a different shell. The two runs use the same design and the same constraints.

The script for the baseline run is in the tcl directory and is called run_no_dp.tcl. The onlydifference between this script and the equivalent datapath script is the output filenames. Oneof the strengths of this solution is that you do not need to make any changes to your scriptsor code to take advantage of datapath.

1. Change to the run_dir directory in the tutorial_buildgates directory.

2. Start the traditional synthesis run by entering the following in a UNIX shell:

unix_shell>bg_shell -gui -f ../tcl/run_no_dp.tcl -logfile no_dp.log-cmdfile no_dp.cmd &

Important

Make sure you run bg_shell and not bgx_shell at this stage. The goal is to seea non-datapath run. This synthesis run will take a relatively long time to finishdepending on the speed of your machine.You can let it run in the background andmove on to the BGX run.



BGX Datapath Flow

Note: Colored steps are affected by Datapath.


Read Libraries


Set Constraints

Check Constraints

Optimize Design

Generate Reports




Setting up the Design Environment

1. In the run_dir directory of the tutorial_dp directory, start BuildGates Extreme byentering the following:

unix_shell>bgx_shell -gui &

2. Set up the design environment by entering the following command in the console:

bgx_shell>source ../tcl/setup.tcl

The setup.tcl file defines all the path variables. If you prefer, you can enter thesecommands manually in the console.

The content to of the setup.tcl file is as follows:

set rak_dir ..set tcl_dir $rak_dir/tclset rtl_dir $rak_dir/rtlset lib_dir $rak_dir/libset rep_dir $rak_dir/rptset adb_dir $rak_dir/adb

Setting up Global Variables

➤ Set up the design globals:

bgx_shell>source $tcl_dir/set_global.tcl

The set_global.tcl script has the following content:

set_global aware_adder_architecture ripple

This command sets the initial adder architecture to a ripple adder (see the CommandReference for BuildGates Synthesis and Cadence PKS for details about thisglobal). Based on the design and timing constraints, the final adder architecture might bedifferent. Even for the same design, different initial adder selection may end up withdifferent final architecture. For this design, you will start with a slow but small adder fordemonstration purpose. By default BGX starts with FCLA (fast carry look-ahead adder).



Reading the Synthesis Technology Libraries

1. Read the synthesis technology libraries:

bgx_shell>source $tcl_dir/read_lib.tcl

This command sets the technology libraries and wireload model for this design.

2. View the contents of the library:


The report_library command can report on the cells in the library, the wireloadmodels, the operating conditions, and more.

Reading the HDL Models for the Designbgx_shell>source $tcl_dir/read_design.tcl

The content of the script is as follows:

read_verilog $rtl/filt4.v

Creating a Generic Gate-Level Netlist

➤ Generate the generic build of the netlist:

bgx_shell>do_build_generic

The do_build_generic command transforms the design into a hierarchical, gate-levelnetlist. The Logical browser and console change as the tool builds the netlist.



Setting Constraints

1. Constrain the design:

bgx_shell>source $tcl_dir/constraints.tcl

This command sets up the ideal clock, binds the clock root to the clock pin, and sets inputand external delay for the primary input and output ports.

The constraints.tcl file contains the following commands:

set_current_module filt4set_top_timing_module filt4

set cyc 10.00set_clock CLK -period $cyc -waveform "0 [expr $cyc /2]"set_clock_root -clock CLK [find -port SYS_CLK]set_clock_insertion_delay 0.3 -pin {SYS_CLK}

proc all_inputs {} {find -port -inputs -no_clocks *}proc all_outputs {} {find -port -outputs *}set_input_delay -clock CLK 0.4 [all_inputs]set_external_delay -clock CLK 0.5 [all_outputs]

set_drive_cell -cell DFFX4 -from_pin CP -pin Q [all_inputs]set_drive_cell –cell CLKBUFX20 SYS_CLKset_port_capacitance [expr [get_cell_pin_load -cell DFFX4 –pin D]*4.0] \[all_outputs]

set_false_path -from [find -port -input reset]

See the Command Reference for BuildGates Synthesis and Cadence PKS formore details on these commands.

The last command tells the tool not to spend time optimizing any timing path starting fromthe input signal reset.

Note: The clock frequency is 10ns, which means that if timing is met, the design will runat 100 MHz.

2. After applying the timing constraints, check the constraints:

bgx_shell>check_timing -verbose

The check_timing command performs a variety of consistency and completenesschecks on the timing constraints specified for a design. As you can see, there is nowarning.

3. At this point, check the netlist to make sure there are no problems:

bgx_shell>check_netlist -verbose

The check_netlist command performs a number of checks on the structuralconnectivity of the netlist. All checks come up clean.



Operator Merging

One of the techniques that BGX uses to improve the speed and decrease the area of a designis operator merging. For more details on this technique, see More about Operator Merging.Figure 4-2 shows how operator merging is applied to the FIR design used in this tutorial.

Figure 4-2 Critical Path for FIR Filter

You can see eight adders and four multipliers in the diagram. There is also one more adder(not shown) in the block right before the final output y(n). The critical path in this design goesfrom the input through the datapath and to the input of the accumulator, including threeadders and one multiplier. The operator-merged result combines the four multipliers andthree downstream adders into one big component. You may wonder why all the four upstreamadders were not merged into that big component as well. Technically, it is feasible, but the toolchooses not to do so because this would lead to a big area penalty with little timing benefit.

To see the pre-optimized merged component, follow these steps:

1. In the Logical browser, expand the logical hierarchy of module filt4 by clicking on the+ icon left of filt4.

2. Double click on module AWDP_partition_2 using the left mouse button.

x(n)


+

x

+

+

+

x

+

+

x x

+

+ y(n)

Accumulator

FilterCoefficients

Critical Path



3. Highlight the worst path:

a. Bring up the pop-up menu by clicking the right mouse button in your Schematicwindow.

b. Select Worst Path.

The result shown in Figure 4-3 on page 109 shows the pre-optimized version of themerged operators. It contains four multipliers and three adders in one module.

Note: If you cannot reproduce this figure, select Edit – Preferences – Schematic, thenclick the Paging tab and set Page Size to None. Then double click on moduleAWDP_partition_2 (in the Logical browser) to refresh the schematics. Then reselectWorst Path.

Figure 4-3 Pre-optimized Critical Path in Merged Component



To see which architectures are embedded in this merged operator:

1. Doubleclick the filt4 module in the Logical browser (this will set filt4 as the currentmodule).

2. Report the datapath resources in the design with the report_resources command:

bgx_shell> report_resources -hier

Your report will be similar to the report shown in Figure 4-4 on page 110.

Figure 4-4 Resource Report

This report shows the architectures, the bit widths of the datapath functions, the name of thepartition they are in, the magnitude of the component, and whether it is signed or unsigned.

+-----------------------------------------------------------------------------+| Arithmetic Resources ||-----------------------------------------------------------------------------+| Module | File | C | Arch | Op | Line | Out | In |+-------------+------------------+---+------------+----+------+-----+---------+| AWDP_EQ_1 | ..//rtl/filt4.v | 1 | cla | == | 10 | 1u | 1ux1u |+-------------+------------------+---+------------+----+------+-----+---------+| AWDP_EQ_0 | ..//rtl/filt4.v | 1 | cla | == | 16 | 1u | 1ux1u |+-------------+------------------+---+------------+----+------+-----+---------+| AWDP_EQ_10 | ..//rtl/filt4.v | 1 | cla | == | 31 | 1u | 1ux1u |+-------------+------------------+---+------------+----+------+-----+---------+| AWDP_EQ_00 | ..//rtl/filt4.v | 1 | cla | == | 37 | 1u | 1ux1u |+-------------+------------------+---+------------+----+------+-----+---------+| AWDP_ADD_0 | ..//rtl/filt4.v | 1 | ripple | + | 55 | 16u | 16ux1u |+-------------+------------------+---+------------+----+------+-----+---------+| AWDP_ADD_3 | ..//rtl/filt4.v | 1 | ripple | + | 191 | 17s | 16sx16s |+-------------+------------------+---+------------+----+------+-----+---------+| AWDP_ADD_4 | ..//rtl/filt4.v | 1 | ripple | + | 192 | 17s | 16sx16s |+-------------+------------------+---+------------+----+------+-----+---------+| AWDP_ADD_00 | ..//rtl/filt4.v | 1 | ripple | + | 193 | 17s | 16sx16s |+-------------+------------------+---+------------+----+------+-----+---------+| AWDP_ADD_1 | ..//rtl/filt4.v | 1 | ripple | + | 194 | 17s | 16sx16s |+-------------+------------------+---+------------+----+------+-----+---------+| AWDP_partiti| ..//rtl/filt4.v | 1 | ripple | + | 199 | 35s | 34sx34s || on_2 | | | | | | | || | | | | + | 199 | 34s | 33sx33s || | | | | + | 199 | 34s | 33sx33s || | | | non_booth | * | 195 | 33s | 17sx16s || | | | non-booth | * | 196 | 33s | 17sx16s || | | | non-booth | * | 197 | 33s | 17sx16s || | | | non-booth | * | 198 | 33s | 17sx16s |+-------------+------------------+---+------------+----+------+------+--------+| AWDP_ADD_5 | ..//rtl/filt4.v | 1 | ripple | + | 206 | 35s | 35sx35s |+-------------+------------------+---+------------+----+------+-----+---------+

partition bit width and sign




➤ Optimize the design using the do_optimize command:

bgx_shell>do_optimize

The optimization can take a while to finish depending on the speed of your machine.When complete, you will compare it to the traditional synthesis run to show the QORimprovement.

Generating Reports

When the BGX run finishes, you can examine the results.

1. Report the area and speed of the design:

bgx_shell>set_current_module filt4bgx_shell>report_timingbgx_shell>get_area

See the Command Reference for BuildGates Synthesis and Cadence PKS formore information on these commands.

Figure 4-5 on page 112 shows an example of the timing report.

From these reports, it is evident that the design has the following specifications:

❑ Speed: 100 MHz

❑ Area:185423.52 um2

❑ Run Time: approximately 30 minutes (depending on the speed of your machine)



Figure 4-5 Timing Report after Optimization+-------------------------------------------------------------------------------+| Instance | Arc | Cell | Delay | Arrival | Required || | | | | Time | Time ||--------------+----------------+------------------+-------+---------+----------|| | cycle[1] ^ | | | 0.47 | 0.47 || i_177 | A ^ -> Y ^ | BUFX12 | 0.13 | 0.60 | 0.60 || i_166 | B ^ -> Y v | NOR2BX4 | 0.07 | 0.67 | 0.67 || i_5548 | A v -> Y v | BUFX20 | 0.14 | 0.81 | 0.81 || i_4914 | A v -> Y v | BUFX3 | 0.14 | 0.95 | 0.95 || i_837 | A1 v -> Y ^ | AOI22XL | 0.28 | 1.24 | 1.24 || i_85 | A ^ -> Y v | NAND2X2 | 0.15 | 1.39 | 1.39 || i_510 | data_H1[1] v | AWDP_ADD_4 | | 1.39 | 1.39 || i_510/i_3 | A v -> Y ^ | XNOR2X4 | 0.29 | 1.68 | 1.68 || i_510/i_37 | A0 ^ -> Y v | OAI21X4 | 0.08 | 1.76 | 1.76 || i_510/i_5842 | A v -> Y v | BUFX2 | 0.20 | 1.96 | 1.95 || i_510/i_53 | A0 v -> Y ^ | AOI21X4 | 0.20 | 2.15 | 2.15 || i_510/i_112 | A ^ -> Y ^ | XOR2X1 | 0.40 | 2.55 | 2.55 || i_510 | s1[4] ^ | AWDP_ADD_4 | | 2.55 | 2.55 || i_507 | s1[4] ^ | AWDP_partition_2 | | 2.55 | 2.55 || i_507/i_317 | A ^ -> Y v | INVX1 | 0.16 | 2.71 | 2.71 || i_507/i_4595 | A v -> Y v | BUFX8 | 0.19 | 2.90 | 2.90 || i_507/i_399 | B v -> Y ^ | NOR2X1 | 0.19 | 3.09 | 3.09 || i_507/i_1638 | B ^ -> CO ^ | ADDFX1 | 0.57 | 3.66 | 3.66 || i_507/i_1698 | A ^ -> CO ^ | AFHCINX2 | 0.45 | 4.11 | 4.11 || i_507/i_3530 | B ^ -> Y ^ | XOR2X2 | 0.31 | 4.43 | 4.43 || i_507/i_3531 | A ^ -> Y ^ | XOR2X1 | 0.29 | 4.72 | 4.72 || i_507/i_1776 | CI ^ -> CO ^ | ADDFX2 | 0.30 | 5.03 | 5.03 || i_507/i_1851 | A ^ -> S ^ | AFHCONX2 | 0.50 | 5.53 | 5.53 || i_507/i_1861 | B ^ -> CO ^ | ADDFHX1 | 0.38 | 5.91 | 5.91 || i_507/i_1924 | A ^ -> S v | ADDFHX4 | 0.49 | 6.40 | 6.39 || i_507/i_1928 | B v -> CON ^ | AFHCONX2 | 0.34 | 6.74 | 6.74 || i_507/i_1985 | CIN ^ -> S v | AFHCINX2 | 0.34 | 7.08 | 7.08 || i_507/i_1987 | A v -> CO v | AFHCINX2 | 0.39 | 7.47 | 7.47 || i_507/i_2038 | CI v -> CO v | ADDFHX2 | 0.25 | 7.72 | 7.72 || i_507/i_2085 | A v -> S v | AFHCINX2 | 0.52 | 8.24 | 8.24 || i_507/i_2344 | A v -> Y ^ | NOR2X2 | 0.19 | 8.43 | 8.42 || i_507/i_2521 | A ^ -> Y v | NOR2XL | 0.13 | 8.55 | 8.55 || i_507/i_1388 | A v -> Y v | BUFX4 | 0.17 | 8.72 | 8.72 || i_507/i_2555 | A1 v -> Y ^ | AOI21X1 | 0.26 | 8.98 | 8.98 || i_507/i_2624 | B0 ^ -> Y v | OAI21X1 | 0.21 | 9.20 | 9.19 || i_507/i_2701 | A0 v -> Y ^ | AOI21X2 | 0.18 | 9.38 | 9.38 || i_507/i_2770 | B0 ^ -> Y v | OAI21X2 | 0.11 | 9.48 | 9.48 || i_507/i_2839 | B0 v -> Y ^ | AOI21X2 | 0.15 | 9.63 | 9.63 || i_507/i_3799 | S0 ^ -> Y v | MXI2X1 | 0.20 | 9.83 | 9.83 || i_507 | mult_out[32] v | AWDP_partition_2 | | 9.83 | 9.83 || u3 | d[32] v | reg_35_0 | | 9.83 | 9.83 || u3/q_reg_32 | D v | SDFFRHQXL | 0.00 | 9.83 | 9.83 |+-------------------------------------------------------------------------------+

2. In the Logical browser double click on module AWDP_partition_2 using the left mousebutton.



3. Highlight the worst path:

a. Bring up the pop-up menu clicking and holding the right mouse button in yourSchematic window.

b. Select Worst Path.

The result is shown below:



Note: The automatic architecture selection chose a faster adder to meet timing. (Seealso More about Automatic Architecture Selection.)

4. Check which adder was used:

bgx_shell> set_current_module filt4

bgx_shell> report_resources -hier

Figure 4-6 on page 114 shows the resulting resource report.

The tool upsized the adders from RIPPLE to CLA or FCLA on the critical path inAWDP_partition_2.

Figure 4-6 Resource Report After Optimization+-------------------------------------------------------------------------+| Arithmetic Resources ||-------------------------------------------------------------------------|| Module | File | C | Arch | Op | Line | Out | In |+--------------+-----------------+---+--------+----+------+-----+---------+| AWDP_ADD_0 | ..//rtl/filt4.v | 1 | ripple | + | 55 | 16u | 16ux1u |+--------------+-----------------+---+--------+----+------+-----+---------+| AWDP_ADD_3 | ..//rtl/filt4.v | 1 | cla | + | 191 | 17s | 16sx16s |+--------------+-----------------+---+--------+----+------+-----+---------+| AWDP_ADD_4 | ..//rtl/filt4.v | 1 | cla | + | 192 | 17s | 16sx16s |+--------------+-----------------+---+--------+----+------+-----+---------+| AWDP_ADD_00 | ..//rtl/filt4.v | 1 | cla | + | 193 | 17s | 16sx16s |+--------------+-----------------+---+--------+----+------+-----+---------+| AWDP_ADD_1 | ..//rtl/filt4.v | 1 | cla | + | 194 | 17s | 16sx16s |+--------------+-----------------+---+--------+----+------+-----+---------+| AWDP_partiti | ..//rtl/filt4.v | 1 | fcla | + | 199 | 35s | 34sx34s || on_2 | | | | | | | || | | | | + | 199 | 34s | 33sx33s || | | | | + | 199 | 34s | 33sx33s || | | | booth | * | 195 | 33s | 17sx16s || | | | booth | * | 196 | 33s | 17sx16s || | | | booth | * | 197 | 33s | 17sx16s || | | | booth | * | 198 | 33s | 17sx16s |+--------------+-----------------+---+--------+----+------+-----+---------+| AWDP_ADD_5 | ..//rtl/filt4.v | 1 | ripple | + | 206 | 35s | 35sx35s |+-------------------------------------------------------------------------+

Writing Netlist, Database Files and Report File

1. Write out the Verilog netlist and database.

bg_shell> write_verilog -hierarchical $adb_dir/filter_dp.vbg_shell> write_adb $adb_dir/filter_dp.adb

2. Write out the results to a report file:

report_timing > $rep_dir/filter_dp.rptreport_area >> $rep_dir/filter_dp.rptreport_resources -hier >> $rep_dir/filter_dp.rpt

3. Select File – Exit or type exit in the console to end this BGX session.



Examining Traditional Synthesis Results

To examine the results of traditional synthesis, turn to the bg_shell run you started at thebeginning of the tutorial. If it is still running, you either let it go to completion, or you caninterrupt it by clicking on the Stop icon under menu bar.

1. To get the area and speed of the design, enter the following:

bg_shell> report_timing

bg_shell> get_area

From these reports, it is evident that the design has the following specifications:

❑ Speed: 94 MHz

❑ Area: 230393.12 um2

❑ Run Time: approximately 90 minutes (depending on the speed of your machine)

Note: The reported slack is -0.69 ns. Since the design was compiled for 100 MHz, thistranslates into a maximum frequency of approximately 94 MHz.

2. Select File – Exit or type exit in the console to end the traditional synthesis session.

Comparing BGX and Traditional Results

Figure 4-7 on page 115 compares the speed and area of these two results.

Figure 4-7 Comparing Results

Comparing these two results, notice that both tools start with the same design and with thesame constraints, and use the same script. By using BuildGates Extreme, you achievedsubstantial area, timing, and run-time savings.

These results come to you without the difficulty of manual partitioning, without specializeddatapath knowledge, and without manual intervention in your synthesis process. Afterautomatically partitioning your design, the BGX tool works to close timing automaticallybetween datapath and control logic, while applying several highly specialized datapathoptimizations: automatic architecture selection, automatic operator merging, and Wallacetree optimizations.

Area (um2) Speed

Normal flow 230393.12 94 MHz

DP 185423.52 100 MHz



Summary


■ Learned about BuildGates Extreme (BGX) datapath features.

■ Compared the quality of results from BuildGates Extreme with the results from atraditional synthesis run.



5Getting Started with Low PowerSynthesis

■ Introduction on page 118



■ Setting Up for This Module on page 119

■ Regular BGX Flow with Power Estimation on page 122

■ BGX LPS Flow on page 123

❑ Setting up Design Environment on page 124

❑ Reading the Synthesis Technology Libraries on page 124


❑ Creating Generic Gate-level Netlist and Exploring Sleep-mode Options at the RTLLevel on page 125


❑ Setting Sleep-Mode and Clock-Gating Options on page 130


❑ Simulating and Reading the Toggle Count File on page 135

❑ Optimizing the Power on page 137

❑ Analyzing the Results and Generating Reports on page 137

❑ Power Analysis in BuildGates Extreme on page 141



■ Gate-Level Only Flow on page 149

■ LPS-DFT flow on page 149


Cadence Synthesis Rapid Adoption KitGetting Started with Low Power Synthesis

■ Summary on page 151

Introduction

Today, low power is emerging as a critical issue in ASIC design. The primary driving factorsare the remarkable success and growth of personal computing devices (portable desktops,audio- and video-based multimedia products) and wireless communications systems(personal digital assistants, pagers, and cellular phones). These technologies demand high-speed computation and complex functionalities, which means low-power consumption is acrucial design concern.

Another development that emphasizes the need for low-power solutions is the growingnumber of large, high-performance designs. Millions of transistors switching at high clockspeeds lead to power consumption problems that can be difficult to solve late in the designcycle. The high cost associated with packaging and cooling strategies is yet another factorthat makes it imperative to have a seamless low-power methodology.

Because power dissipation is becoming just as important as performance and area, poweranalysis and optimization needs to be an integral part of the design methodology. TheCadence approach with Low-Power Synthesis (LPS) is to address low-power issues early inthe design cycle and fix them automatically during the optimization flow. LPS explores optionsfor lowering power at the RTL level, but does not make any commitments until the gate level.Also, all gate-level transformations take into account power, delay, and placementinformation. This option lets engineers determine a design’s power dissipation early in thedesign process which is a key benefit for chip designers targeting power-sensitiveapplications.

Objectives

In this module, you will run the regular BGX flow and the BGX-LPS flow in parallel on thesame design. You will learn more about the

■ LPS features while running the BGX-LPS flow

■ LPS automatic power saving capability when comparing the results of both flows

At the end of this module, the gate-level only LPS flow and LPS DFT flow are brieflyaddressed.

Note: This module assumes that you completed Chapter 2, “Getting Started with BuildGatesSynthesis.”



Example Design

You will use an FIR filter (shown in Figure 5-1) with the following specifications:

32-Tap16-bit coefficient16-bit I/O data

Figure 5-1 FIR Filter Architecture

Setting Up for This ModuleNote: We assume that you already copied the data. If not, see Getting Started on page 12.

Required License

You need a BuildGates Extreme (BGX) license to run this module. To save running time youcan run two copies of bgx_shell in parallel, one for the regular flow and one for the LPSflow. This implies that you need to check out two BGX licenses. You can still complete thewhole flow with only one license, but it will take longer as you need to run two flows one afterthe other. Call your sales representative to get demo licenses if needed.

x(n)


+

x

+

+

+

x

+

+

x x

+

+ y(n)

Accumulator

FilterCoefficients



Ensure Access to a Verilog Simulator

To do any meaningful power optimization, you need to simulate the design. LPS supports allsimulators. You can either use a Cadence® simulator (Cadence® NC-Verilog® simulator, orVerilog®-XL simulator) or another vendor’s Verilog simulator. In this tutorial, we use theVerilog-XL simulator.

Note: If you want to use the Verilog-XL simulator, you need to use version 2.7 or higher.

Locate the path to your simulator, type the following command in a UNIX window:

which verilog

If “no verilog” is returned, contact your system administrator to give you the installationdirectory to the Verilog simulator and set up the environment accordingly.

Link to the Simulation Library

While running the simulation you need to link to the LPS PLI shared library to capture thedesign switching activity during the simulation.

Note: You can skip this step if you call the simulator within the bgx_shell environment.

■ SunOS/Solaris:

setenv LD_LIBRARY_PATHyour_install_path/version/lib/archives/sunos7/sparc:$LD_LIBRARY_PATH

■ HPUX:

setenv SHLIB_PATHyour_install_path/version/lib/archives/hpux11/hppa32:$SHLIB_PATH

■ IBM:

setenv LD_LIBRARY_PATHyour_install_path/version/lib/archives/aix43/ppc32:$LD_LIBRARY_PATH

Required Files

You need the following files when you start the BuildGates-LPS flow:

■ Simulation library

A complete set of Verilog files for the library cells.

■ Synthesis library

A .tlf or .alf file containing either cell-based or arc-based power tables. BGXsupports both the traditional 2-D look-up table and the 3-D look-up table. In case of the3-D table, the internal power is not only a function of the input slew and output loadcapacitance, but also of the sum of the capacitances on the other output pins.



■ Verilog or VHDL netlist, preferably at RTL level.

■ Testbench

Unlike your traditional testbench, which is designed for coverage, you need a testbenchthat simulates how the design works in real life. To emphasize power savings, considerexercising the parts of the design that are used most during power sensitive application.For example, if you were designing a digital camera, consider emphasizing the phototaking process and de-emphasizing the save to hard drive process.

■ Constraints

The your_install_path/version/tutorial/RAK/tutorial_lps directorycontains the files needed to run this module and has the following directory structure:

tutorial_lps Root directory

tcl Scripts to run the RAK LPS module


lib Synthesis libraries and simulation libraries

rpt Design outputs including timing, area, hierarchy and otherreport files

adb Design outputs including netlist and database files

simulation Simulating files and test benches




Regular BGX Flow with Power Estimation

You will start a traditional synthesis run with power estimation. Later, you will compare itsresults with those of the LPS flow to see the automatic power saving capability of LPS. Aregular BGX flow with power estimation contains these steps:

read_alf # or read_tlf

read_verilog # or read_vhdl

do_build_generic# Set timing constraints

do_optimize write_verilog -hier

# Simulate # generates toggle count format (TCF) file# Write netlist and database files# Generate reports and analyze the design

The TCF file recording the switching activities of the circuit will be used by LPS to estimatethe power consumption of the design. For more information about TCF file, refer to Simulatingand Reading the Toggle Count File on page 135.

To execute this flow, follow these steps:

1. Change the current directory to tutorial_lps/run_dir in the directory you created.

2. Start BGX by entering the following command:

unix_shell>bgx_shell -gui -f ../tcl/run_no_lps.tcl -logfile run_no_lps.log-cmdfile run_no_lps.cmd &

While this process runs in the background, you can start the BGX LPS flow. The samplescript, run_no_lps.tcl, is provided in the tcl directory.



BGX LPS Flow

Note: Colored steps are either LPS-specific or have specific LPS options.

The following sections explain these steps in detail. The Tcl script for this flow,run_lps.tcl, is provided in the tcl directory.



Set Constraints

do_build_generic -sleep_mode

Explore Sleep Mode

do_optimize -power -stop_for_power_simulation

Explore/Insert Clock GatingOptimize Design

Write Verilog Netlist

Simulate Design

Read TCF

Optimize Powerdo_optimize -power

Decommit Clock-gating, Commit Sleep Mode, Optimize Gate-level Netlist

Generate Reports


Read Libraries

Set Sleep-Mode and Clock-GatingOptions



Setting up Design Environment

1. From the run_dir directory, invoke BuildGates Extreme in graphical user interface(GUI) mode:

unix_shell>bgx_shell -gui &

2. Set up your design environment by running the following script in the console of theBuildGates Synthesis window:

bgx_shell>source ../tcl/setup.tcl

The setup.tcl file defines all path variables and has the following content:

set rak_dir ..set tcl_dir $rak_dir/tclset rtl_dir $rak_dir/rtlset lib_dir $rak_dir/libset rep_dir $rak_dir/rptset adb_dir $rak_dir/adbset sim_dir $rak_dir/simulation

Reading the Synthesis Technology Libraries


bgx_shell>source $tcl_dir/read_lib.tcl

The read_lib.tcl script contains the following statements:

read_tlf $lib_dir/slow_4.3.tlfread_symbol $lib_dir/slow.sym

2. View the contents of the technology library with the following command:


The report_library command reports on the cells in the library, the wireload models,the operating conditions, and more. Since you only read one library, you do not need tospecify the library name here.

3. Ensure that the design does not map to cells without power characterization with thefollowing command:

bgx_shell>check_library -power library_pwr.rpt

The check_library command generates a file containing all the cells without powercharacterization.

4. Prevent the design from mapping into those cells with the following command:

bgx_shell>foreach i [exec cat library_pwr.rpt] \{set_cell_property dont_utilize true $i}

This command sets some cell properties on the cells without power characterization.



Or you can run the following script which executes steps 3 and 4:

bgx_shell>source $tcl_dir/check_lib.tcl

Reading the HDL Models for the Design

➤ After loading the libraries, read the RTL code for this design:

bgx_shell>source $tcl_dir/read_design.tcl

The read_design.tcl script has the following content:read_verilog $rtl_dir/filt4.v

Creating Generic Gate-level Netlist and Exploring Sleep-mode Options atthe RTL Level

1. Transform the RTL netlist you just read into a hierarchical, gate-level netlist consisting oftechnology- independent logic gates.

bgx_shell>do_build_generic -sleep_mode

The -sleep_mode option of the do_build_generic command tells LPS to exploreareas of the design where power could be saved using the sleep-mode technique.

Note: The sleep-mode logic is only committed during gate-level power optimizationbased on timing, area and power.

2. Using the left mouse, click on the + icon next to filt4 to see the hierarchy beneath.

3. Display the schematic generated by do_build_generic by double clicking on topmodule filt4 in the Logical browser using the left mouse button.

The schematic viewer window is activated. The schematic is displayed (See Figure 5-2).



Figure 5-2 Schematic of Top Module filt4

Note: If you get a zoomed out view of the schematic, use the Zoom Fit icon on the toolbar under the Schematic tab to fit the schematic in the Schematic window.

4. Select Reports – Sleep Mode Logic Info to list the functional blocks that were markedas sleep-mode candidates.

The Sleep Mode Information window is displayed.

Zoom Fit Icon



a. Select Hierarchical.

b. Click the Search button to populate the window.

The result is shown in Figure 5-3 on page 127. One sleep-mode candidateLPS_SleepModeModule_16 was found.

Figure 5-3 Sleep Mode Information Window

c. Click the left mouse button on the sleep-mode candidate in the Sleep ModeInformation window.

The sleep mode module is highlighted in the schematic.



d. Click the right mouse button on the sleep-mode candidate in the Sleep ModeInformation window.

A window with the components of the sleep-mode logic pops up.

e. Click Cancel to close the Sleep Mode Information window.

5. List all instance IDs of candidates for sleep-mode information in the current module.

bgx_shell>get_sleep_mode_instance_list -hier

The result consists of one triplet, where the first number identifies the sleep-modemodule. The second number identifies the data bus. The third number identifies theenable signal.

If the current module is not filt4 (or round_clip), you will not be able to see theLPS_SleepModeModule_16. In that case, type set_current_module filt4 andtry again.

Examining RTL Code of the round_clip Module

Examining the output in the console, shows that the sleep mode candidate was added to theround_clipmodule. Look at the RTL code for the round_clipmodule which is excerptedfrom filt4.v under the rtl directory:

module round_clip (clipped, data_out, data_in);input [34:0] data_in; // <35,4,t>output [15:0] data_out; // <16,0,t>output clipped;wire carry;wire [14:0] lower;wire [15:0] upper, cap, rnd;assign upper = {data_in[34], data_in[29:15]};assign lower = {data_in[15], data_in[13:0]};assign carry = (| lower) & data_in[14];assign rnd = upper + carry;assign cap = {data_in[34], {15{~data_in[34]}}};assign clipped = data_in[34] ? (~ (& data_in[33:30])) : (| data_in[33:30]);assign data_out = clipped ? cap : rnd;

endmodule // round_clip

Look at the last assign statement:

assign data_out = clipped ? cap : rnd;



The output of this module, data_out, is controlled by signal clipped. If clipped is high,data_out equals cap, otherwise if clipped is low, data_out equals rnd, which is theoutput of an adder, as indicated by

assign rnd = upper + carry;

That is a 16 plus 1 bit addition: inputs to the adder are bus upper and wire carry. Wheneverthe value of upper or carry changes, the adder calculates the value for signal rnd.However, the signal rnd is only needed when the signal clipped is low. So LPS sees apower saving opportunity here and inserts AND gates in front of the adder inputs as shownin Figure 5-4. The number of additions could potentially drop depending on how often theinput signals toggle and what the probability is that signal clipped is high.

Figure 5-4 LPS power saving opportunity

At this point, LPS has only identified this sleep-mode candidate as an opportunity for sleepmode. LPS dynamically computes power savings for each opportunity as well as the cost ofimplementation—one array of AND gates and two inverters in this example. This dynamiccomputation is done considering the simulation-based switching information, the capacitanceof the nets or gates and the constraints in the design. (You will apply constraints in the nextstep.) After optimization, only opportunities that actually save power and that do not violatetiming paths are kept.



Setting Constraints

1. Set the timing constraints by running the following script.

bgx_shell>source $tcl_dir/constraints.tcl

The constraints.tcl file sets up the ideal clock, binds the clock root to the clock pin,and sets input and external delays for primary input and output ports. This script has thefollowing content:

set_current_module filt4set_top_timing_module filt4

set cyc 10.00set_clock CLK -period $cyc -waveform "0 [expr $cyc /2]"set_clock_root -clock CLK [find -port SYS_CLK]set_clock_insertion_delay 0.3 -pin {SYS_CLK}

proc all_inputs {} {find -port -inputs -no_clocks *}proc all_outputs {} {find -port -outputs *}set_input_delay -clock CLK 0.4 [all_inputs]set_external_delay -clock CLK 0.5 [all_outputs]

set_drive_cell -cell DFFX4 -from_pin CK -pin Q [all_inputs]set_drive_cell -cell CLKBUFX4 SYS_CLKset_port_capacitance [expr [get_cell_pin_load -cell DFFX4 -pin D]*4.0] \

[all_outputs]set_false_path -from [find -port -input reset]

The last command instructs the tool not to optimize any timing path starting from theinput signal reset.

2. Check the validity of the constraints.

bgx_shell>check_timing -detail

No warnings are issued.

3. Check the netlist to make sure there are no problems.

bgx_shell>check_netlist -verbose

All checks come up clean.

Setting Sleep-Mode and Clock-Gating Options

Next, you will check the sleep-mode and clock-gating options.

1. Check the default values of the sleep-mode options.

bgx_shell>get_sleep_mode_options

The get_sleep_mode_options command returns the table shown in Figure 5-5 onpage 131. Only options that are set or for which the tool has defined a default arereported.



Figure 5-5 Default Sleep-mode Options+-----------------------------+| Sleep Mode Options ||-----------------------------|| Options | Value ||----------------+------------|| -no_dissolve | true || -timing_driven | full |+-----------------------------+

By default, LPS does not dissolve the hierarchy of a sleep-mode module when it iscommitted and it commits each sleep mode module only if it does not violate timing.

2. Check the default values of the clock-gating options.

bgx_shell>get_clock_gating_options

The get_clock_gating_options command returns the table shown in Figure 5-6.

Figure 5-6 Default Clock-Gating Options +---------------------------------+ | Clock-Gating Options | |---------------------------------| | Options | Value | |-----------------+---------------| | -auto_test_port | false | | -control | none | | -control_mode | use_test_mode | | -control_port | NOT_SET | | -domain | all | | -force | NOT SET | | -gating_style | latch | | -ignore | NOT SET | | -max_fanout | NOT SET | | -minsize | 3 | | -no_timing | false | | -observe | false | | -obs_style | port | | -remove_all | false | | -rg_dissolve | false | | -rg_force | NOT SET | | -rg_ignore | NOT SET | | -rg_max | 10 | | -same_polarity | false | | -xor_depth | 5 | | -reset | false | | -exclude_cells | NOT SET | +---------------------------------+

Most options are related to Design for Test (DFT). For more information on how to set someof these options, refer to Getting Started with Design For Test on page 73. For this module,you can use default values.




1. Map the design to the target technology and insert clock-gating elements.

bgx_shell>do_optimize -power -stop_for_power_simulation

The do_optimize command maps a generic cell netlist to a technology-specific cellnetlist and optimizes the netlist for timing according to the constraints. Logic optimizationincludes uniquification, constant propagation, structuring, redundancy removal,technology mapping, timing-driven optimization, component swapping, buffering of multi-port nets, and design-rule fixing.

Since you specified stop_for_power_simulation, the tool stops post-mappingoptimization just before power optimization is performed. Up till then LPS only exploresthe power saving opportunities. After this point you can run a simulation and read in thetoggle count information. Based on the toggle count information LPS can perform alltypes of gate-level transformations to simultaneously optimize power, delay, and area.

Note: Depending on the performance of your machine, the synthesis can run for a while.You can take this time to read more about the clock-gating techniques used by LPS.Refer to More about LPS Clock Gating Technique on page 170.

2. Scroll the console back to see what the tool has done so far.

The information shows that BuildGates was working on dissolving instances, duplicatingand structuring modules, propagating constants, removing redundancies, exploringclock-gating, inserting clock-gating logic, mapping modules, optimizing modules to meetconstraints, fixing design rules, and swapping datapath components.

During clock-gating exploration, LPS identifies all the clock-gating candidates andcreates one gating logic per register bank with the same enable signal.

LPS also creates a dummy module that has only one input port connected to the enablesignal for the clock gating. LPS needs this dummy module to identify the clock-gatingcandidates and their corresponding enable functions during decommitment. After gate-level timing optimization, LPS performs decommitment of the clock-gating logic based ontiming and power information.

3. Examine one register in the schematic viewer to better understand how clock-gatinglogic works.

a. In the Logical browser, first click on the + icon in front of filt4, then click on the +iconin front of instance u1 (module name cf_reg) to expand its hierarchy.

You see a list of 32 register banks.

b. Click on instance r00 (module name reg_16_1) to highlight it.

c. Bring up the pop-up menu by clicking the right mouse button in the Logical browser.



d. Select Open Schematic – New Window from the pop-up menu and release theright button.

A new Schematic window pops up for the selected instance.

In Figure 5-7, three components were manually highlighted: a latch, a gating cell(AND gate) and a dummy module, LPS_CG_EN_34_0. The dummy module allowsLPS to mark the design. You can remove it after the final optimization using thedo_remove_cg_dummy_hierarchy command, but once you issue thiscommand, LPS no longer keeps track of gating instances. Do not issue thiscommand now!

Figure 5-7 Clock-Gating Logic

Note: The output signal from the gating cell drives all 16 registers in this register bank.

e. Close the Schematic window by clicking on the Close Window icon (red cross).

4. Check how many gating logic circuits exist in this stage.

a. Double click on filt4 in the Logical browser to make it the current module.



b. Select Reports – Clock Gating Logic Info.

The Clock Gating Information window is displayed.

c. Select Hierarchical.

d. Click the Search button to populate the window.

The result is shown in Figure 5-8.

Figure 5-8 Clock-Gating Information Window

e. Click left on any of the gating instance or component of the gating instance.

The instance is highlighted on the schematic.

f. Click right on the same gating instance or component of the gating instance.

The hierarchical path is displayed in the clock-gating information window.

g. Click Cancel to close the Clock Gating Information window.



5. List the information on the clock-gating candidates in the console.

bgx_shell>set_current_module filt4bgx_shell>get_gating_instance_list -hier

To make the output a little bit easier to read, you can enter:

bgx_shell>foreach i [get_gating_instance_list -hier] \{puts [get_names $i]}

This returns a number of lines similar to the following one:

SYS_CLK LPS_CG_EN_1__0 lock i_2_LPS_CG_GATING_1

The first entry identifies the clock domain. The second one identifies the dummy module,the third one identifies the enable signal and the last entry identifies the gating instance.

Simulating and Reading the Toggle Count File

To do any meaningful power optimization, you need toggle count (or gate-level switchingactivity) information and to create this information in a Toggle Count Format (TCF), you mustsimulate the gate-level netlist.

1. Modify the testbench to create a TCF file.

Note: For this module, a modified testbench called test_bench_0.v is provided in thesimulation directory, just for demonstration purpose. The test vectors are randomlygenerated.

You need to modify your testbench to use LPS Program Language Interface (PLI) tasks.The PLI tasks are provided in a shared library (which works fine with most Verilogsimulators):

your_install_path/version/lib/archives/os/platform/lps_pli.so

a. At the beginning of the time slot you want to start the capturing, insert:

$toggle_count(instance1, instance2 & );

b. To stop recording the TCF file and specify the TCF file name, enter the followingcommand to create a flat TCF file:

$toggle_count_report_flat(tcf_file_name, hier_top);

For a hierarchical TCF file, use the next routine which requires a hierarchical netlist:

$toggle_count_report_hier(tcf_file_name, hier_top);

After the simulation, a TCF file tcf_file_name is created with the toggle countinformation of the netlist.

The closer the testing vectors in the testbench represent the input vectors in a realsituation, the more accurate the LPS results will be.



Note: If you are a VHDL user, refer to “Generating TCF Files from a VHDL-BasedDesign” in Low Power Synthesis for BuildGates Synthesis and Cadence PKS.

2. Create the gate-level Verilog netlist needed for simulation.

bgx_shell>set_current_module filt4bgx_shell>write_verilog -hier $sim_dir/filt4_lps.v

You see a warning message “Verilog continuous assignment written.” This is caused byassign statements dumped in the netlist. You can safely ignore that warning.

3. Start the simulation.

bgx_shell>verilog -f $sim_dir/sim_lps.opt

The sim_lps.opt file has the following content:

-v ../lib/tsmc18.v+loadpli1=lps_pli:lps_bootstrap+toggle+libext+.v+notimingchecks../simulation/test_bench_lps.v../simulation/filt4_lps.v

The second line loads the LPS PLI shared library.

The notimingchecks switch turns off setup and hold time checks by the simulator. Atthis stage, the netlist is not fully timing-optimized yet and might contain some setup orhold time violations. If the Verilog simulator catches those violations, the simulationresults might not be reliable, so you want to turn off the setup and hold time checks.

You see some warnings about too few port connections on gating latches, which you canignore. The reason is that the latches have inverted outputs, which the dumped netlistdid not characterize.

Note: While the simulation is running, you can read More about TCF Files on page 173.

4. Read the TCF file.

bgx_shell>read_tcf power_lps.tcf -scale 0.01

The command contains a scale factor. In the gate-level simulation you actually simulatewith a clock 100 times slower to get a reliable result, which is a commonly used techniquein gate-level circuit simulation. So when you read the TCF file in, you need to add a scaleto adjust the toggle rate back.

Note: You can also read a TCF file from the GUI by selecting File – Open.



Optimizing the Power

Start the power optimization.

bgx_shell>do_optimize -power

In this final step of the basic LPS flow, BGX performs three tasks with one command:

■ Decommitting clock-gating logic

Note: LPS only decommits clock-gating instances if the proposed clock-gating logicdoes not save power or if it causes a timing violation.

■ Committing sleep-mode logic

Note: LPS only commits sleep-mode logic if the sleep-mode logic saves power and doesnot cause a timing violation.

■ Performing gate-level power transformations

During gate-level power optimization, LPS performs the following transformations tominimize the power dissipation in the design:

❑ Gate Sizing

❑ Pin Swapping

❑ Buffer Removal

❑ Gate Merging

❑ Slew Optimization

❑ Logic Restructuring

All these transformations are done automatically, so you cannot call any transformationindividually.

Note: Depending on the performance of your machine, the optimization can run for a while.You can take this time to read More about Gate-Level Power Optimization on page 174.

Analyzing the Results and Generating Reports

1. Check the overall power dissipated in the current module.

bgx_shell>get_power

2. Get a further break down on the power dissipation.

bgx_shell>report_power

The result is shown in Figure 5-9 on page 138.



Figure 5-9 Power Report+---------------------------------------------------+| Report | report_power ||----------------------------+----------------------|| Options | |+----------------------------+----------------------+| Date | 20030527.161700 || Tool | bgx_shell || Release | v5.10-s061 || Version | May 23 2003 12:12:42 |+----------------------------+----------------------+| Module | filt4 || Timing Operating Condition | slow || Power Operating Library | Typical || Process | 1.000000 || Voltage | 1.620000 || Temperature | 125.000000 || time unit | 1.00 ns || capacitance unit | 1.00 pF || power unit | 1.00mW |+---------------------------------------------------++---------------------------------------------------------------------------------------+| filt4 ||---------------------------------------------------------------------------------------+| | | Library | Internal | Leakage | Net | Total || | | | Cell | | | ||--------------------+----------+---------+----------+------------+----------+----------|| Module | Instance | Cell | Power(mW)| Power(mW) | Power(mW)| Power(mW)||--------------------+----------+---------+----------+------------+----------+----------|| filt4 | | | 209.3068 | 7.607e-03 | 24.8811 | 234.1955+---------------------------------------------------------------------------------------+

where

❑ Internal Cell Power is the total internal cell power for the current module (inmW).

❑ Leakage Power is the total leakage power for the current module (in mW).

❑ Net Power is the net power (in mW) of all nets in the current module.

❑ Total Power is the total power dissipated by the current module (in mW).

Note: To report the power usage on a none hierarchical instance, use thereport_cell_instance -power command.

3. Scroll back the console to see what the tool has done to reduce power.

LPS first tried to meet the timing, then worked on clock gating committing ordecommitting, then sleep mode commitment. Finally, LPS worked on gate-leveloptimization with the various techniques discussed in More about Gate-Level PowerOptimization on page 174.

...Info: Commiting clock gating of flip-flops < q_reg_0 q_reg_1 q_reg_10

q_reg_11 q_reg_12 q_reg_13 q_reg_14 q_reg_15 q_reg_2 q_reg_3q_reg_4 q_reg_5 q_reg_6 q_reg_7 q_reg_8 q_reg_9 > in modulefilt4/u4. The estimated power savings is 12.44%. <POPT-229>.



This message indicates that clock-gating logic in register bank u4 got committed.

To report power on a selected object (net in this example), follow these steps:

1. In the Logical browser, double-click on instance u4 to display its schematic in theSchematic window.

2. Click on the search icon (similar to a camera) in the Schematic window.

A Search Objects window pops up as shown in Figure 5-10 on page 139.

3. Select Net under Object Type and type lock in the Search Text.

4. Click Search in the Search Objects window.

You can see the net lock in the Found Objects window.

Figure 5-10 Search for signal in Schematic Window



5. Double-click on lock.

The net lock is now highlighted in red in the Schematic window.

6. Click right on the net lock in the Schematic window to bring up the Net pop-up menu.

7. Select Power in the pop up menu.

You get the following line in the console.

Net power (lock): prob(0.06250*), toggle rate(0.02500*), cap(0.25276),power(8.290000 uW) <NAVIGATES-106>.

The power report for the selected net lists the signal probability, the toggle rate (a ratioof toggle count over the total simulation time), the loading capacitance, and the totalpower dissipated on this net. The asterisk (*) indicates that the value comes from theTCF file, while a non * value would indicate that the value was computed.

You can get similar information by entering the following commands:

bgx_shell>set_current_module filt4bgx_shell>report_power -net u4/lock

Figure 5-11 shows the result. It reports the same information except that instead of reportingtoggle rate, it uses the term transition density, which is the same as the toggle rate.

Figure 5-11 Report Power on a Net+---------------------------------------------------------------------------------------+| filt4 ||---------------------------------------------------------------------------------------+| Module | Net | Probability | Trans. Den. | Capacitance | Power(mW) ||---------------------------------------------------------------------------------------+| u4 | lock | *0.0625 | 0.0250 | 0.2527 | 8.292e-03 |+---------------------------------------------------------------------------------------+

From the output of the do_optimize -power command, you can also see that one sleepmode logic got committed. If you report_power -net on signal clipped in instance u6,you will see the signal probability is about 0.29. As explained earlier in Examining RTL Codeof the round_clip Module on page 128, the adder is shut off whenever the signal clipped ishigh, based on the following RTL code:

Assign data_out = clipped ? cap: rnd;

In this case, 29 percent of the time the signal clipped is high and LPS figured that the powerconsumption would be smaller if the sleep mode module got committed.



Power Analysis in BuildGates Extreme

You will use the following power analysis features offered by LPS.

■ Getting Statistical Reports on page 141

■ Viewing The Power Level Legend on page 143

■ Annotating Power on page 144

■ Adding Color on page 145

■ Displaying an Instance or Net Power Pie Chart on page 146

Getting Statistical Reports

To get the statistical report on the probability (prod), enter the following command:

bgx_shell> report_tc_stats -prob

To get the statistical report on the transition density (td), enter the following command:

bgx_shell> report_tc_stats -td

Figure 5-12 shows the report for the transition density. The one for signal probability is similar.

Figure 5-12 Statistical Report on Transition Density+--------------------------------+| Transition Density (td) || Statistics For Nets ||--------------------------------|| td | #nets ||-------------------+------------|| 0.000000-0.000050 | 41 |+-------------------+------------+| 0.000050-0.000100 | 0 |+-------------------+------------+| 0.000100-0.000500 | 4 |+-------------------+------------+| 0.000500-0.001000 | 2 |+-------------------+------------+| 0.001000-0.005000 | 4 |+-------------------+------------+| 0.005000-0.010000 | 9 |+-------------------+------------+| 0.010000-0.050000 | 1349 |+-------------------+------------+| 0.050000-0.100000 | 1605 |+-------------------+------------+| 0.100000-0.500000 | 2762 |+-------------------+------------+| 0.500000-> | 625 |+--------------------------------+



You can also get a graphical statistical report that contains the switching activity on individualnets, as well as the overall distribution of the switching activity for a particular instance.

The toggle count histogram lets you view the probability distribution or toggle countinformation on a per net basis.

To display a toggle rate histogram, follow these steps:

1. Make sure the current module is set to filt4.

2. Select Reports – Power Toggle Rate Histogram.

The Toggle Rate Histogram window appears.

3. In the Toggle Rate Histogram window, select the Compute Histogram icon as shown inFigure 5-13.

The Histogram shown in Figure 5-13 appears.

Figure 5-13 Toggle Rate Histogram

4. Close the Toggle Rate Histogram window by clicking on the Close Window icon.

Compute Histogram icon



Viewing The Power Level Legend

The Power Level Legend displays the colors used for the different power levels whenannotating the power in the Schematic window or the Logical browser.

To display the Power Level Legend, select View – Power Level Legend. You see a windowsimilar to the one shown in Figure 5-14.

Figure 5-14 Power Level Legend

The Power Level Legend has three columns:

■ Level displays the ten power levels from 0 (the lowest) to 9 (the highest).

■ Color displays the colors assigned to each level.

■ Value displays the values assigned to each power level. By default, level 0 is 00.00% andlevel 9 is 20.00%.

To change the power level values and colors, select Edit – Preferences – Colors, andselect the Power Levels tab.



Annotating Power

To annotate the power next to the instance or names in the schematic, follow these steps:

1. Select Edit – Preferences – Schematic.

The Schematic Preferences window appears.

2. Select the Highlighting tab.

3. Select Power under Power Properties.

4. Click OK.

5. Bring up the pop-up menu by clicking the right mouse button in the Schematic window.

6. Select Annotate Power – Instance or select Worst Power.

❑ Annotate Instance Power displays the power value below each instance in theschematic view. If you have a flat netlist, instance power is the sum of internal powerand leakage power. For a hierarchical netlist, instance power is the sum of internaland leakage power of primitive cells in the hierarchy and power consumed by thenets driven by the cells.

Figure 5-15 on page 145 shows the power consumption annotated for theinstances. (You should zoom in several times to see this.)



❑ Worst Power highlights (in the Schematic window) the specified number of objectsthat contain the worst power values for the current module.

Figure 5-15 Annotated Power in Schematic

Adding Color

You can use color to display the power characteristics in the Logical browser and schematic.

To easier see the colorization, make sure to display the schematic on one page.

1. Select Edit – Preferences – Schematic.

The Schematic Preferences window appears

2. Select the Paging tab.

3. Set Page Size to None.

4. Click OK.

power numbers for instances



To add color to your schematic, follow these steps:

1. Bring up the pop-up menu by clicking the right mouse button in the Schematic window.

2. Select Colorize Power Levels.

The schematic is annotated with different colors. Figure 5-16 shows a zoomed -in part ofthe schematic. For the meaning of the colors, see Viewing The Power Level Legend.

Figure 5-16 Colorize Power levels

Displaying an Instance or Net Power Pie Chart

To display an instance or net power pie chart, follow these steps:

1. Bring up the Commands pop-up menu by clicking the right mouse button in theSchematic window.

2. Select Power Piecharts – Instance (or Net).

The Instance Power Usage window shown in Figure 5-17 on page 147 appears. Thiswindow displays a pie chart of up to ten instances that consume the most power and theremainder. The Net Power Usage window shown in Figure 5-18 on page 147 displays apie chart of up to ten nets that dissipate the most power and the remainder.



Figure 5-17 Instance Power Pie Chart

Figure 5-18 Net Power Pie Chart

3. Select Close on the Instance Power Usage and the Net Power Usage windows.



Generating Reports

1. Write out the design and the reports for timing, area, resources as well as power.

bgx_shell>write_adb -hier $adb_dir/filter_lps.adbbgx_shell>write_verilog -hier $adb_dir/filter_lps.vbgx_shell>report_timing > $rep_dir/filter_lps.rptbgx_shell>report_area >> $rep_dir/filter_lps.rptbgx_shell>report_resources -hier >> $rep_dir/filter_lps.rptbgx_shell>report_power >> $rep_dir/filter_lps.rpt

2. Compare the numbers you see in the filter_lps.rpt file to the ones in thefilter_no_lps.rpt file.

Figure 5-19 Results Comparison with Normal Flow

Note: Your results may differ from the ones shown here because of the randomlygenerated test vectors in the testbench used for the power simulation.


1. Write out the Verilog netlist and database.

bg_shell> write_adb -hierarchical $adb_dir/filter_lps.adbbg_shell> write_verilog -hierarchical $adb_dir/filter_lps.v

2. Select File – Exit or type exit in the console to end this session.

That concludes the regular LPS flow.

Tip

For maximum power accuracy, you should resimulate your design after the finaldo_optimize -power command.

The same applies to the sleep-mode only flow, clock-gating only flow and gate-level onlyflow, which are described in the next sections. For this tutorial, we did not rerun thesimulation to save on run time.

Area (um2) Worst slack (ns) Power (mW)

Normal flow 179449.31 +0.01 343.1023

LPS 165904.20 -0.00 234.1955



Gate-Level Only Flow

Although LPS works best when starting from RTL, sometimes you might want to apply LPSto gate-level netlists only.

Sample Script Starting from a Gate-Level Netlistread_alf # or read_tlfread_verilog # or read_vhdldo_build_generic# Simulateread_tcf# Set timing constraintsdo_optimize -power

Sample Script Starting from a Timing-Optimized Netlistset_global depth_for_fast_slew_prop 2read_alf # or read_tlfread_verilog # or read_vhdldo_build_generic# Simulateread_tcf# Set timing constraintsdo_xform_optimize_power -gate_level

Note: The value for the global depth_for_fast_slew_prop is set to 2 to prevent slackfrom getting worse.

The run_gate.tcl script (which is provided in the tcl directory) starts with a timing-optimized netlist for this filter design and allows you to run this flow.

LPS-DFT flow

The following is a sample DFT-LPS observability flow script:

read_alf # or read_tlfread_verilog # or read_vhdlset_global dft_scan_path_connect tiebackdo_build_generic -sleep_mode# set timing constraintscheck_dft_rulesset_sleep_mode_optionsset_clock_gating_optionsdo_optimize -power -stop_before mappingcheck_dft_rulesdo_optimize -power -stop_for_power_simulation# simulateread_tcfdo_optimize -powerset_global dft_scan_path_connect chaindo_xform_connect_scan



The run_lps_dft.tcl script (which is included in the tcl directory) allows you to run thisflow on the filt4 design. LPS can add controllability and observability to the design and isfully compatible with DFT. BuildGates actually allows you to make a design with multiple clockdomains observable. For more information about using DFT, see Design for Test (DFT)Using BuildGates Synthesis and Cadence PKS.

Figure 5-20 illustrates how LPS adds a control port and observability circuit to a register.

Figure 5-20 LPS Observability Circuitry

You can add a control port and observability circuit to a register, using the following singlecommand:

bgx_shell>set_clock_gating_options -control post_seq_element \-auto_test_port true \-observe true \-domain clock_net \-obs_style port

control post_seq_element adds the controllability logic after the sequential element. In thecircuit in Figure 5-20, the OR gate is inserted after the latch.

-auto_test_port creates a test port in the top module. If you do not want an additionalport in your design, you can either include the observability register in a scan chain or sharethe test ports with functional input/output port.



-observe makes all gated signals observable. Each of the gating signals is added to anXOR tree and the output of the XOR tree is connected to either a port or observability register.In this case, a port will be used since you specified -obs_style port.

-domain groups gating signals driven by the same clock signal under DFT settings.

-obs_style creates a port in the top module for each observability domain and its logic isconnected to this port through an XOR tree.

Summary


■ Became familiar with the LPS design flow which provides power estimation, andoptimization techniques that consider timing constraints.

■ Learned that LPS makes all power decisions based on actual power computations ratherthan rule based decisions.

■ Learned that LPS minimizes the power by committing the RTL transformations andperforming gate-level power optimizations while satisfying the timing constraints

■ Learned various techniques to analyze the power saving results.

■ Received an introduction to the DFT-LPS flow



AMore about BuildGates Synthesis

■ More about Optimizing the Design on page 154

■ More about Timing Reports on page 156


Cadence Synthesis Rapid Adoption KitMore about BuildGates Synthesis

More about Optimizing the Design

Top-Down Optimization

In top-down design flow, the designer sets the constraints at the top level, and optimization isperformed from the top level without first individually optimizing lower-level modules. Top-down flow is traditionally used to optimize smaller designs. However, BuildGates Synthesishas much higher capacity. Compared to other tools, it can handle much larger designs topdown. You can easily do top-down optimization on one million gate designs. BuildGatesSynthesis top-down flow is very easy to use, and it doesn't require complicated scripting andtypically produces a better quality of results (QOR).

Bottom-Up Optimization

In the bottom-up optimization approach, lower-level modules are first optimized individuallywith constraints derived from top-level constraints. These optimized lower-level modules arethen “stitched together” and marked dont_modify. Then, the next level of the hierarchy isoptimized until all levels including the top level are optimized. The process of deriving lower-level constraints from top-level constraints is commonly referred to as time-budgeting. Thedo_time_budget command in BuildGates appropriately splits combinational delayrequirements across module boundaries based on the number of levels of logic andcompressibility of the logic. Compared to other tools, the BuildGates Synthesis timebudgeting process involves fewer iterations and requires less scripting time from the user.

More on do_optimize

The do_optimize command is the simplest way to optimize the design. It applies to thehierarchy in and under the current module, as set by the set_current_module command.Depending upon the state of the design database, logic optimization will include some or allof these steps: uniquification, constant propagation, structuring, redundancy removal,technology mapping, timing-driven optimization, buffering of multiport nets, and design-rulefixing. All of these steps can be run individually or as a subset using a unique concept calledtransforms. These transforms have a prefix of do_xform_. Transforms are a very powerfulmeans of customizing your optimization flow. Figure A-1 on page 154 shows thedo_optimize flow.

Figure A-1 do_optimize Flow



Return to do_optimize Info Messages on page 43 for more information on the messagesgenerated by do_optimize.



More about Timing Reports

Analyzing Simultaneous Best Case and Worst Case Analysis

Setup checks are performed using worst case PVT corner(s) while hold checks areperformed using best case operating corner(s). In the simplest of the cases, you specify twoPVT corners (best and worst) and setup, hold checks are done as mentioned.

There are several ways to set up BuildGates for simultaneous best case, worst caseanalyses.

Example for Best Case-Worst Case Analysis Using One Library and Two Operating Conditions

set_operating_condition -pvt min bccombestset_operating_condition -pvt max wccomworst

set_global pvt_early_path minset_global pvt_late_path maxset_global timing_analysis_type bc_wc

In this case, setup checks are performed using the worst case operating condition and thehold checks are performed using the best case operating condition.

Example for Best Case-Worst Case Analysis Using Two Libraries and Two Operating Conditions

read_alf -min min_lib -max max_lib -name merged_library_name

set_operating_condition -library min_lib -pvt min bccomset_operating_condition -library max_lib -pvt max wccom

set_global pvt_early_path minset_global pvt_late_path maxset_global timing_analysis_type bc_wc

Setup checks are performed using the worst-case operating condition. The worst-case delaysare picked from max_lib and scaled appropriately for the worst operating condition.Similarly, the hold checks are performed using the best-case operating condition. The best-case delays are picked from the min_lib library and scaled appropriately for the bestoperating condition.

Return to Generating Area Reports on page 50.



BMore about Datapath

■ More about Operator Merging on page 158

■ More about Automatic Architecture Selection on page 161

■ More about the AmbitWare Library on page 163

■ More about Extended Languages on page 166


Cadence Synthesis Rapid Adoption KitMore about Datapath

More about Operator Merging

The goal of the BGX datapath feature is to provide powerful optimization of datapath streamsand components, but in a standard, easy to use synthesis flow, and with automatic timingclosure between datapath and control logic. After automatically partitioning the datapath andcontrol logic, several powerful datapath techniques are applied to produce a handcrafted-quality result. These include operator merging, automatic architecture selection, andarchitecture refinement techniques. For details on how each of these features work, refer toDatapath for BuildGates Synthesis and Cadence PKS.

Operator merging is a powerful technique that eliminates redundancies that naturally existbetween sequentially connected discrete datapath components. It will improve both speedand area QOR. In general terms, what operator merging does is first locate a datapathcomponent (one of 13 functions including arithmetic and comparisons).

Next, it reads upstream and downstream from that component and locates other sequentiallyconnected components. Sequentially connected datapath components have naturallyoccurring redundancies and lend themselves well to optimization.

Finally, operator merging groups these components, determines their function, and replacesthem with a custom build component with the same function. This custom built componenthas several key features that make it smaller and faster than the previous discretecomponents.

For instance, in this example, each discrete component in the original design has a carrypropagate adder (CPA): See Figure B-1.

Figure B-1 Carry Propagate Adder (Ripple Adder)

The most basic CPA is a ripple adder (shown). The ripple adder has the disadvantage thatthe critical path is dependent on the bit width because it follows the ripple action from theleast significant bit (LSB) to the most significant bit (MSB). Thus, a 128-bit graphics controller,whose library has full adders with 0.5 ns of delay would be limited to a speed of 64 ns or



15.6 MHz if a ripple adder was used. The disadvantage of having CPAs is that, if they are ina timing critical path it is very expensive (in terms of area) to speed them up. Off the criticalpath, it is no problem to go with a ripple adder because it is small.

Operator merging solves this problem by converting each of the intermediate CPA adders toa format known as 3:2 compression illustrated by Figure B-2.

Figure B-2 Compression

The top adder is in 3:2 compression and the one below is a traditional CPA adder. Notice thatthe primary inputs of the first adder have been used, including the carry bit for addition. Alsonotice that the carry bit was passed to a downstream adder. 3:2 compression has the samenumber of components and does the same amount of computation—it just does it in adifferent order. By changing the order of the computation, the 3:2 compression improves thespeed of the path.

After converting over each of the intermediate adders to 3:2 format, operator merging addsthese 3:2 adders to a Wallace Tree. The second technique that operator merging applies is aWallace Tree optimization. Through this optimization, the tool orders the inputs to the WallaceTree according to the arrival times. This also includes streamlining the critical path to theoutput of the Wallace Tree. Effectively, this means that the critical path can almost bypassthe adders that were previously in its path. Once again, this substantially improves the speedof the path. Figure B-3 on page 160 shows an example diagram of a Wallace Tree:



Figure B-3 Wallace Tree

The last step in the operator merging technique is to select a final adder for this custom-builtmodule that is just large enough to meet the speed requirement of the design. Quite often, somuch improvement is made with 3:2 compression and Wallace Tree optimization that smalleradders can be used. This feature, in conjunction with the elimination of slow CPA adders fromthe critical path, results in area savings for the design as well as increased speed.

Note: Operator merging works best if you do not include a lot of hierarchy between datapathcomponents, because the tool defaults to preserving a user-defined hierarchy. Therefore, donot place each multiplier in your design in a module by itself. Operator merging only appliesto inferred components, not to gate level netlists or to instantiated components.

Return to Operator Merging on page 108.



More about Automatic Architecture Selection

Automatic Architecture Selection (AAS) is a technique that automatically selects the correctarchitectures for your adders and multipliers in your design.

First it looks at the timing context of the module. For example, off the critical path, area-optimized adders are selected. On the critical path, adder size and speed is experimentallyincreased until timing is met or the largest adder is used.

Next, AAS looks at the bit-width context and library availability when selecting architectures.For example, for multipliers, BGX considers the bit-width of the operands to determine if itmakes sense to build a booth-encoded or non-booth multiplier. Also, it tries to use specializedcells in the library, such as booth cells or 4:2 compression cells. If those are not available, thetool builds the cells it needs. In another example, the tool uses a square instead of a multiplierif it finds that the multiplier and multiplicand are the same vector.

The AAS technique is applied to every datapath operator in your design, including the inferredand instantiated operators, as well as the customized operator-merged components. Formore on AAS, refer to the Datapath for BuildGates Synthesis and Cadence PKS.

The tool also does automatic timing-driven implementation refinement. For example, if allinputs have the same arrive time, the tool may implement what is shown in Figure B-4. Thisreduces the levels of logic from input to output and should lead to the best timing. However,if the input arrival time is skewed, as show in Figure B-5, the software adjusts the order ofaddition accordingly, from iteration to iteration, to achieve the best timing.

Figure B-4 Timing-Driven Implementation Refinement with Uniform Arrival Time



Figure B-5 Timing-driven Implementation Refinement with Skewed Arrival Time

If this adder tree is part of a bigger design and the input skew must be derived from thesurrounding logic, it is hard to manually predict the skew and decide the configuration andorder of the adder tree. An adder tree like this can be found as part of the carrysave reductiontree inside of a multiplier, where timing from the surrounding logic is very difficult to calculatemanually. The software is better equipped for the job because it can calculate the timinginformation dynamically.

Return to Generating Reports on page 111.



More about the AmbitWare Library

Another feature of the BGX datapath offering is the free AmbitWare component library. Thislibrary contains many of the popular datapath components that are used in complexnetworking, multi-media, DSP, and processor designs today.

BuildGates Synthesis comes with three pre-defined AmbitWare libraries that provide bothsynthesis and simulation models of all of the components:

■ AmbitWare Complex Arithmetic Library (AWARITH)—Defines complex arithmeticfunctions in RTL that can be instantiated in the source RTL. For example, a combinedincrementer and decrementer, multiply accumulators, pipelined multipliers, and vectoradders.

■ AmbitWare Complex Logical Library (AWLOGIC)—Defines complex logic functions thatcan be instantiated in the source RTL, for example, arithmetic and logical shifters,rotaters, encoders and decoders.

■ AmbitWare Sequential Logic Library (AWSEQ)—Defines complex sequential logicfunctions that can be instantiated in the source RTL. For example, a reset-enable flip-flop, and a n-tap shift register.

The three AmbitWare libraries use the IP model by containing the encrypted models ofcomponents. The synthesis models of the components are defined in Verilog or VHDL RTL,the simulation models of the components are defined in Verilog and VHDL. The componentsare then decrypted, synthesized and optimized in the context of the design.

Below are some examples:

■ Pipelined Multiplier

■ Multiply-Accumulate (MAC)

■ Vector Add

■ Comparator

■ Square

■ Combinational Divider with Remainder

■ Barrel Shifter

■ Programmable Incrementer/Decrementer

■ Programmable Adder/Subtractor

■ Absolute Value



■ Priority Encoder/Decoder

■ Rotate Left/Right

■ Generalized Sum of Products

■ Saturator

■ Rounder

■ Overflow Detector

■ Blender

■ Universal Multiplexer

■ Register with Reset and Enable

The way to access these components is through instantiation, which involves specifying thecomponent parameters and mapping the ports. Figure B-6 shows an example.

Figure B-6 Instantiation of a Pipeline Multiplier

The port map is shown for a pipeline multiplier. Each of the components comes with asimulation model as well several examples of how to use these components (see theAmbitWare Component Reference).

Each component used from the library is custom built for the particular usage. Theconstruction is similar to the optimizations done on operator-merged components. Forexample, the final adders in the pipeline multiplier above are selected based on the timingcontext of the design. It is important to note, however, that instantiated components are noteligible for operator merging.

module fun (A, B, TC, CLK, Y);

input [8:0] A;

input [6:0] B;

input TC; // 0 if unsigned, 1 if signed

input CLK;

output [15:0] Y;

// 9x7, 1 pipeline stage added

AWARITH_PIPEMULT # (9,7,1) U0

(.A(A), .B(B), .TC(TC), .CLK(CLK), .Z(Y));

endmodule



Inference Verses Instantiation

For several datapath components, you have the option to infer them or instantiate them fromthe library (see Figure B-7). This is similar to Synopsys. You could use y = a+b; or you couldinstantiate an adder DW01_ADD (.A (A)...) and so on.

Figure B-7 Difference between Instantiation and Inference

For the most part, with BGX, the result will be the same for inference as with instantiate, withthe exception that instantiated components are not eligible for operator merging. Becauseoperator merging offers improved QOR, you should probably use inference wheneverpossible. See the Datapath for BuildGates Synthesis and Cadence PKS for details.

Return to Introduction to BGX Datapath on page 100.

// The following is an inference to an adder:

y = a + 1;

// This is an instantiation of an incrementer:

AWARITH_INCDEC #(width,0) U0(.A(a), .DEC(1’b0), .Z(y));



More about Extended Languages

The following is the relationship between various Verilog languages:

■ Verilog-2001 (originally named Verilog-2000) is a superset of Verilog-1995.

■ Verilog-DP is a superset of Verilog-2001.

■ Verilog-1995 and Verilog-2001 are both IEEE standards.

BGX supports all three versions. Verilog 2001 and Verilog-DP are purely additive extensionsof Verilog-95. This means that you do not have to convert your design over to take advantageof the new features. Verilog-2001 contains several enhancements to the Verilog-95, whichmakes designing with Verilog easier. Of particular interest are the generate function and thesigned data type.

Previously, in Verilog-95, sign extension was a manual effort. It was fairly laborious andsomewhat cryptic. The truncation and part-select involved in this created some limitations foradvanced datapath engines. By supporting the signed data type, these limitations are liftedand the code becomes much cleaner. Moreover, if your design uses only the unsigned datatype, BGX can accomplish the same quality of results as using signed data type, because itunderstands the signed nature behind the RTL coding.

Verilog-DP contains several datapath specific enhancements to Verilog-2001. Unlike MCL, aproprietary language from Synopsys, Cadence has asked the IEEE to approve Verilog-DP asa standard. Also there is another salient difference: Verilog-DP is purely additive—you do nothave to re-code your design to take advantage of the features it offers. Simply use your designas it exists today and change only the parts where you want to take advantage of the newfeatures.

Here is a list of some of the compelling features of Verilog-DP:

■ New signal attributes and querying functions:

❑ Signed (Verilog 2001)

❑ carrysave (via pragma)

❑ Signal attribute querying functions ($size, $is_signed, $low, $high)

■ Attribute inheritance

❑ Signal attributes can be deferred and inherited from the parent module via signalconnection

❑ Allows highly parameterized designs without explicit parameters



■ Explicit replication and conditional compilation

❑ for, if and case (compatible with Verilog 2001)

■ Array Signals and Operations

❑ Array signals and I/O ports

❑ Array operations: vector inner-product, vector-matrix product and other linearalgebra operations

❑ Array initialization, flattening and unflattening functions

■ New Datapath Primitives

❑ Succinct representation and improved QOR

❑ $blend (linear interpolation), $abs, $sgnmult, $lead0, $lead1, $sat,$rotatel, $rotater, $iroundmult, $itruncmult

Return to Required Files on page 102.



CMore about Low Power Synthesis

■ More about LPS Clock Gating Technique on page 170

■ More about TCF Files on page 173

■ More about Gate-Level Power Optimization on page 174


Cadence Synthesis Rapid Adoption KitMore about Low Power Synthesis

More about LPS Clock Gating Technique

Depending on the performance of your machine, the synthesis can run for a while. You cantake this time to read more about the clock-gating techniques used by LPS.

In LPS, clock-gating consists of the following two steps:

1. Exploration and insertion:

LPS starts with identifying the set of registers for clock gating and the periods of inactivityin those registers.

Next, LPS inserts gating logic for clocks in the inactive periods identified during theexploration phase.

2. Commitment

During this phase, LPS commits gating logic based on power savings, performs timingchecks for the setup and hold times of the gated clocks, and removes gating logic wheretiming constraints are violated or if there is no possible power savings.

Even though data is loaded into registers very infrequently in many designs, the clock signalcontinues to toggle at every clock cycle. Often, the clock signal also drives a large capacitiveload, making clock signals a major source of dynamic power dissipation.

Gating a group of flip-flops that are enabled by the same control signal reduces unnecessaryclock toggles.

By using clock gating, power is not consumed during the idle period when the register is shutoff by the gating function. Also, the logic of the enable circuitry on the data pin in the originaldesign is removed which saves power.

For example, consider the following Verilog module excerpted from the filt4.v file.

module reg_16 (clk, lock, set, d, q);input clk, lock, set;input [15:0] d;output [15:0] q;reg [15:0] q;always @ (posedge clk or posedge set)begin

if (set == 1’b1)begin

q <= 16’b0;endelsebegin

if (lock == 1’b0)begin

q <= d;end



endend

endmodule

reg_16 is register bank with an enable signal ~lock. Figure C-1 illustrates how clock gatingworks to reduce power.

Figure C-1 Clock-Gating Example

Instead of adding a MUX in front of each data input of every register, LPS gates the clock withan AND gate to drive the entire register bank. You can control the number of fanouts that theclock-gating cell output can drive using the set_clock_gating_options -max_fanoutcommand. If -max_fanout is set to 3 and 6 fanouts are required, LPS clones the gating cell.

Figure C-1 on page 171 also shows that a latch is inserted before the AND. This latch is usedto eliminate any possible clipping on the gated clock signal. Without the latch, a spike onsignal lock can propagate through the AND gate and induce clock clipping, which is bad. Ifyou are sure the enabling signal is glitch free you can eliminate the latch usingset_clock_gating_options -gating_style none.

Figure C-2 on page 172 illustrates how latches can eliminate spikes on an enabling signal.

D QData

En

clk

D QData

En

clk



Figure C-2 Eliminating Spikes with Latch

Here is how timing check is done on gated logic. The data input of the gating cell must bestable:

■ Before the clock input makes a transition from the controlling value to the non-controllingvalue (setup time).

■ After the clock input returns to a controlling value (hold time)

You can change the setup and hold times using the set_clock_gating_check command.

With a Physically Knowledgeable Synthesis (PKS) license, LPS can save even more powerwith the root gating technique. In this case, LPS inserts gating logic at the root of the clock tosave the power consumed by the clock-tree network.This is in addition to gating the registerbanks. For more details, see Root Gating in Low-power for BuildGates® Synthesis andCadence® PKS.

Return to Optimizing the Design on page 132, step 2.

GatedClock

QEn

clk

D Q

clk

clk

En

QEn

gclk

En



More about TCF Files

A Toggle Count Format (TCF) file contains net or pin switching activities, as well as signalprobabilities. TCF is not an industry standard format, but a pure Cadence format. The TCFfile can be flat or hierarchical. The switching activity equals to the toggle counts on the net orpin during the entire simulation. The signal probability means the probability for this signal tostay at 1 in the total recorded toggle counts.

If none of the logic nodes in the fanin cone contain assertion values, LPS assumes defaultvalues on the primary inputs and outputs of the sequential elements. The default value ofsignal probability is 0.5, and the default value of the toggle count is half of the clock togglecount. If there is no clock in the design, the transition will be simply 0. For internal nets, LPSuses probabilistic technique to the switch activities. New nets might be inserted inoptimization, and if there is a request for the switch activities on any of those newly creatednets, LPS uses probabilistic technique to calculate the switch activity for those nets uponrequest.

Return to Simulating and Reading the Toggle Count File on page 135, step 4.



More about Gate-Level Power Optimization

■ Gate Sizing on page 174

■ Pin Swapping on page 176

■ Buffer Removal on page 176

■ Gate Merging on page 177

■ Slew Optimization on page 178

■ Logic Restructuring on page 179

These LPS optimization techniques work with the timing engine to identify trade-off points inthe power delay curve. When combined with the various effort levels, you can choosebetween faster run time or a better quality result in terms of power dissipation.

Gate Sizing

Gate sizing makes the CMOS gate size smaller or larger to minimize the total powerdissipation without violating timing constraints.

In general, reducing the size of a gate leads to a decrease in power dissipation but to anincrease in delay.

The overall internal cell power dissipation of a gate consists of:

■ Leakage power

■ Short-circuit power

■ Power dissipated by parasitic capacitance

Sizing the gate reduces the short-circuit power dissipation and power dissipated by parasiticcapacitance. Gate sizing can, however, increase the short-circuit power dissipation of thefanout logic because the slew rate of the output signal can increase when this transformationis performed. LPS makes tradeoffs between the gate sizing and the increase of powerdissipated due to slew rate in order to optimally reduce the power dissipation of the design.

Figure C-3 demonstrates the importance of gate selection for gate sizing to maximize powerdissipation savings. The power of the circuit in Figure C-3 (A) can be reduced by downsizingeither gate I or gate II, but not by both due to the timing constraints. Downsizing gate I resultsin a circuit with less power because both inputs of gate I are heavily toggled.



Figure C-3 Gate Sizing

AND2C

Power: 1.2 uWSlack: 0.3 ns

AND2C

AND2A

Power: 0.7 uW

Slack: 0.0 ns

AND2APower: 1.1 uWSlack: 0.0 ns

(A)

(B)

(C)

AND2CAND2C

I

II



Pin Swapping

Pin swapping matches nets connected to logically equivalent pins so power dissipation canbe minimized. LPS matches pins with higher capacitance to nets that have lower switchingactivity. Figure C-4 shows how pin swapping works.

Pin swapping can actually increase the delay of the design if not done carefully. LPS finds theoptimal configuration that reduces power dissipation without affecting timing.

Figure C-4 Pin Swapping

Buffer Removal

Sometimes during timing optimization buffers are added to shield the critical path from a highcapacitive load. However, during timing optimization, the critical path itself can shift resultingin unnecessary buffers on non-critical paths.

While these unnecessary buffers are removed in a postprocessing step, only a limitednumber can be removed without violating timing. To maximize power savings, the poweroptimizer removes unnecessary buffers that drive highly active nets.

Note: In a normal timing optimization flow, regular buffer removal can increase power. Thereason is that the power saved by removing a buffer can be significantly offset by the powerincrease at the buffer’s fanout due to the increased slew. LPS performs a detailed analysis toensure that the removal of each buffer indeed saves power.

Power = 1.0 mW Power = 0.7 mW

higher pin capacity



Gate Merging

A major portion of dynamic power dissipation consists of driving the capacitive load of a net.A significant amount of dissipated power can be saved by dissolving the net because thedynamic power dissipation of a net is proportional to the switching activity of the net. Thesesavings are achieved by merging the gates on either side of the net. See Figure C-5 to seean example of gate merging.

Note: Although gate merging eliminates the power loss on the net, it can increase the internalpower dissipation of the new gate. LPS makes the correct tradeoffs.

Figure C-5 Gate Merging

a

b

c

Power = 0.95mW

c

a

b

Power = 0.85mW



Slew Optimization

The internal power of a cell largely depends on the slew of the input signals. The larger theinput slew, the larger the power dissipated by this gate. If a signal has a large slew, drivingthe signal through a buffer improves the signal’s slew and reduces the overall power of thecells driven by the signal.

Figure C-6 shows an example of how slew optimization works during timing-constrainedpower optimization. LPS reduces slew by adding buffers. The challenge for LPS is to choosethe set of gates that it needs to buffer. LPS performs a detailed analysis to identify the optimalpartition that will reduce power as much as possible without violating timing and adds a bufferof optimal size to that cluster.

Figure C-6 Slew Optimization

Power = 2.0mW Power = 1.8mW

Buffer toreduce slew



Logic Restructuring

Logic restructuring is different from other transformations performed during poweroptimization. Unlike gate merging, buffer removal, and other small local transformations thatdo not make significant changes to the circuit structure, logic restructuring actually changesthe topological structure and internal functions of a circuit without compromising the circuit’sfunctional integrity.

Figure C-7 on page 179 shows a circuit before logic restructuring. Signal A has the lowestswitching activity among all inputs. Although the final output of the circuit has a low switchingactivity, the two internal nodes are highly active, causing the bulk of switching powerdissipation.

Figure C-7 Circuit Before Logic Restructuring

Figure C-8 on page 179 shows how logic restructuring can find a more efficient circuitimplementation that cannot be done by other power optimization transformations. The newcircuit dissipates much less power than the original circuit shown in Figure 3-9 because thelogic functions at the two internal nodes are now less active.

Figure C-8 Circuit After Logic Restructuring

B

A

D

C

A

B

DC



Return to Analyzing the Results and Generating Reports on page 137.


Cadence Synthesis Rapid Adoption Kit · 2018-02-08 · Cadence Synthesis Rapid Adoption Kit May...

Documents

Transcript of Cadence Synthesis Rapid Adoption Kit · 2018-02-08 · Cadence Synthesis Rapid Adoption Kit May...