0% found this document useful (0 votes)

179 views144 pages

Cdboa

Uploaded by

tomyyy2

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

179 views144 pages

Cdboa

Uploaded by

tomyyy2

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 144

CDB to OpenAccess Translator User Guide

Product Version IC6.1.7

February 2018
© 2003-2018 Cadence Design Systems, Inc. All rights reserved.
Printed in the United States of America.
Cadence Design Systems, Inc. (Cadence), 2655 Seely Ave., San Jose, CA 95134, USA.
Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are trademarks or
registered trademarks of Open SystemC Initiative, Inc. in the United States and other countries and are
used with permission.
Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. contained in this document
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 800.862.4522. All other
trademarks are the property of their respective holders.
Restricted Permission: This publication is protected by copyright law and international treaties and
contains trade secrets and proprietary information owned by Cadence. Unauthorized reproduction or
distribution of this publication, or any portion of it, may result in civil and criminal penalties. Except as
specified in this permission statement, this publication may not be copied, reproduced, modified, published,
uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence.
Unless otherwise agreed to by Cadence in writing, this statement grants Cadence customers permission to
print one (1) hard copy of this publication subject to the following conditions:
1. The publication may be used only in accordance with a written agreement between Cadence and its
customer.
2. The publication may not be modified in any way.
3. Any authorized copy of the publication or portion thereof must include all original copyright,
trademark, and other proprietary notices and this permission statement.
4. The information contained in this document cannot be used in the development of like products or
software, whether for internal or external use, and shall not be used for the benefit of any other party,
whether or not for consideration.
Disclaimer: Information in this publication is subject to change without notice and does not represent a
commitment on the part of Cadence. Except as may be explicitly set forth in such agreement, Cadence does
not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or
usefulness of the information contained in this document. Cadence does not warrant that use of such
information will not infringe any third party rights, nor does Cadence assume any liability 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
in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.
CDB to OpenAccess Translator User Guide

Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
What’s New and KPNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Installation, Environment, and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Technology Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Additional Learning Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Video Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Virtuoso Videos Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Rapid Adoption Kits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Help and Support Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Feedback about Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Typographic and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1
Getting Started with CDB to OpenAccess Translation . . . . . . . 17
Database Versions and Design Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Text Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Running the Translator in 64-bit Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
CDB to OpenAccess Translator Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Command Line Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Library Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Library Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Reporting Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Using the CDB to OpenAccess Translator in the Virtuoso Design Environment . . . . . . . 25

February 2018 3 Product Version IC6.1.7

Environment Variables Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Name Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Multimedia Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2
How CDB Data is Converted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Application Infrastructure Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Library Definitions File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
System Information File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Technology Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Technology File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Attached Technology Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Setting Units Values in the OpenAccess Technology File . . . . . . . . . . . . . . . . . . . . . 34
Validating Technology Information in OpenAccess . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Display Resource File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Symbolic Device Masters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Via Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Cellviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Master Cellviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Illegal Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Empty Cellviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Directories in Cellviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Parent-Child Database File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
View Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Mosaics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Parameterized Cellviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Referencing SKILL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Instance Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
keepCDBInstParams Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Magnification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Bounding Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Text Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Visibility Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

February 2018 4 Product Version IC6.1.7

Bounding Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Property Bags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Filename Type Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Net, Pin, and Terminal Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Net Criticality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Unplaced Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Timestamps and Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Virtuoso XL Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Pins and Pin Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
CDB Pin Subnet Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
OpenAccess Pin Group Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Mapping Connectivity Status from CDB to OpenAccess . . . . . . . . . . . . . . . . . . . . . . 55
Instance Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Paths with Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Rows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
CDBOA SKILL Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3
Using the CDB to OpenAccess Translator from the Command
Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Before You Start with CDB to OpenAccess Translation . . . . . . . . . . . . . . . . . . . . . . . . . 63
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
UNIX Environment Variables in cdboa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Converting a Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Converting into the Current Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Converting into a Specified Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Converting a Cellview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Converting a Single Cellview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Converting a Hierarchical Cellview within a Single Library . . . . . . . . . . . . . . . . . . . . 82
Converting a Hierarchical Cellview over Multiple Libraries . . . . . . . . . . . . . . . . . . . . 84
Converting Multiple Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Setting up the Structure for the OpenAccess Version of the Library . . . . . . . . . . . . . 86
Determining the Sequence of Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

February 2018 5 Product Version IC6.1.7

Resolving Circular Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4
Using the CDB to OpenAccess Translator GUI . . . . . . . . . . . . . . . 91
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Choosing a Run Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Starting the Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Running the Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Converting a Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Converting into the Current Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Converting into a Specified Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Converting a Cellview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Converting a Single Cellview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Converting an Hierarchical Cellview within a Single Library . . . . . . . . . . . . . . . . . . 100
Converting an Hierarchical Cellview over Multiple Libraries . . . . . . . . . . . . . . . . . . 103
Converting Multiple Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Setting up the Structure for the OpenAccess Version of the Library . . . . . . . . . . . . 105
Converting Multiple Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Resolving Circular Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Customizing the Translation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Copying the cdb2oa .cdsenv File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Editing the cdb2oa .cdsenv File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5
Post-Processing of the Translated Data . . . . . . . . . . . . . . . . . . . . . . 111
The Mapper Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Mapping Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
LPP-to-LPP Color Mapping (Advanced Nodes Only) . . . . . . . . . . . . . . . . . . . . . . . . 115
Object Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A
CDB to OpenAccess Translator Form Descriptions . . . . . . . . . 119
CDB to OpenAccess Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

February 2018 6 Product Version IC6.1.7

Library specific options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Mapping GUI Options with Command Line Arguments and .cdsenv Variables . . . . 136

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

February 2018 7 Product Version IC6.1.7

February 2018 8 Product Version IC6.1.7

Preface

The CDB to OpenAccess translator allows you to translate designs and reference data from
CDB format to OpenAccess format.

This user guide describes the CDB to OpenAccess database translator, cdb2oa. It is aimed
at CAD developers and designers migrating data from CDB (IC 5141) to OpenAccess
(Virtuoso IC6.1) and assumes that you are familiar with:
■ The Virtuoso design environment and application infrastructure mechanisms designed
to support consistent operations between all Cadence tools.
■ The applications used to design and develop integrated circuits in the Virtuoso design
environment.
■ The design and conversion of technology data as well as other types of Pcell and IP
libraries.
■ Virtuoso technology data.
■ Component description format (CDF).
■ The conversion process for blocks and designs.
Note: All the functionality described in this guide is available IC6.1.6 and ICADV12.1 onward
unless otherwise noted.

This preface contains the following topics:

■ Scope
■ Licensing Requirements
■ Related Documentation
■ Additional Learning Resources
■ Customer Support
■ Feedback about Documentation
■ Typographic and Syntax Conventions

February 2018 9 Product Version IC6.1.7

Scope
The functionality described in this guide can be used only in mature nodes, such as IC6.1.7.

Licensing Requirements
The cdboa translator requires the 111 license for the tool to run. If 111 license is not available,
then the translator will not run and an error message is displayed.

For information on licensing in the Virtuoso design environment, see Virtuoso Software
Licensing and Configuration User Guide.

Related Documentation
This user guide is part of a set of documents to support the Virtuoso design environment on
OpenAccess releases. Other useful Virtuoso design environment on OpenAccess are
covered in dedicated user guides. Where this is the case, reference has been made to the
respective book containing detailed information.

What’s New and KPNS

■ Virtuoso CDB to OpenAccess Translator What’s New
■ Virtuoso CDB to OpenAccess Translator Known Problems and Solutions

Installation, Environment, and Infrastructure

■ Cadence Installation Guide.
■ Virtuoso Design Environment Adoption Guide.
■ Cadence Application Infrastructure User Guide.
■ Component Description Format User Guide.
■ CDB to OpenAccess Translator Known Problems and Solutions.

Technology Information
■ Virtuoso Technology Data User Guide

February 2018 10 Product Version IC6.1.7

■ Virtuoso Technology Data ASCII Files Reference.

■ For information on migrating CDB data from previous releases, see the Compatibility
Guide shipped with the IC 5.1.41 CDB release.

Additional Learning Resources

Video Library
The Video Library on the Cadence Online Support website provides a comprehensive list of
videos on various Cadence products.

To view a list of videos related to a specific product, you can use the Filter Results feature
available in the pane on the left. For example, click the Virtuoso Layout Suite product link
to view a list of videos available for the product.

You can also save your product preferences in the Product Selection form, which opens when
you click the Edit icon located next to My Products.

Virtuoso Videos Book

You can access certain videos directly from Cadence Help. To learn more about this feature
and to access the list of available videos, see Virtuoso Videos.

Rapid Adoption Kits

Cadence provides a number of Rapid Adoption Kits that demonstrate how to use Virtuoso
applications in your design flows. These kits contain design databases and instructions on
how to run the design flow.

To explore the full range of training courses provided by Cadence in your region, visit
Cadence Training or write to [email protected].
Note: The links in this section open in a separate web browser window when clicked in
Cadence Help.

Help and Support Facilities

Virtuoso offers several built-in features to let you access help and support directly from the
software.

February 2018 11 Product Version IC6.1.7

■ The Virtuoso Help menu provides consistent help system access across Virtuoso tools
and applications. The standard Virtuoso Help menu lets you access the most useful help
and support resources from the Cadence support and corporate websites directly from
the CIW or any Virtuoso application.
■ The Virtuoso Welcome Page is a self-help launch pad offering access to a host of useful
knowledge resources, including quick links to content available within the Virtuoso
installation as well as to other popular online content.
The Welcome Page is displayed by default when you open Cadence Help in standalone
mode from a Virtuoso installation. You can also access it at any time by selecting Help
– Virtuoso Documentation Library from any application window, or by clicking the
Home button on the Cadence Help toolbar (provided you have not set a custom home
page).

For more information, see Getting Help in Virtuoso Design Environment User Guide.

Customer Support
For assistance with Cadence products:
■ Contact Cadence Customer Support
Cadence is committed to keeping your design teams productive by providing answers to
technical questions and to any queries about the latest software updates and training
needs. For more information, visit https://www.cadence.com/support.
■ Log on to Cadence Online Support
Customers with a maintenance contract with Cadence can obtain the latest information
about various tools at https://support.cadence.com.

Feedback about Documentation

You can contact Cadence Customer Support to open a service request if you:
■ Find erroneous information in a product manual
■ Cannot find in a product manual the information you are looking for
■ Face an issue while accessing documentation by using Cadence Help

You can also submit feedback by using the following methods:

■ In the Cadence Help window, click the Feedback button and follow instructions.

February 2018 12 Product Version IC6.1.7

■ On the Cadence Online Support Product Manuals page, select the required product
and submit your feedback by using the Provide Feedback box.

February 2018 13 Product Version IC6.1.7

Typographic and Syntax Conventions

The following typographic and syntax conventions are used in this manual.

text Indicates names of manuals, menu commands, buttons, and

fields.
text Indicates text that you must type exactly as presented. Typically
used to denote command, function, routine, or argument names
that must be typed literally.
z_argument Indicates text that you must replace with an appropriate
argument value. The prefix (in this example, z_) indicates the
data type the argument can accept and must not be typed.
| Separates a choice of options.
{ } Encloses a list of choices, separated by vertical bars, from
which you must choose one.
[ ] Encloses an optional argument or a list of choices separated by
vertical bars, from which you may choose one.
[ ?argName t_arg ]
Denotes a key argument. The question mark and argument
name must be typed as they appear in the syntax and must be
followed by the required value for that argument.
... Indicates that you can repeat the previous argument.
Used with brackets to indicate that you can specify zero or more
arguments.
Used without brackets to indicate that you must specify at least
one argument.
,... Indicates that multiple arguments must be separated by
commas.
=> Indicates the values returned by a Cadence® SKILL® language
function.
/ Separates the values that can be returned by a Cadence SKILL
language function.

If a command-line or SKILL expression is too long to fit within the paragraph margins of this
document, the remainder of the expression is moved to the next line and indented. In code
excerpts, a backslash ( \ ) indicates that the current line continues on to the next line.

February 2018 14 Product Version IC6.1.7

February 2018 15 Product Version IC6.1.7

February 2018 16 Product Version IC6.1.7

1
Getting Started with CDB to OpenAccess
Translation

OpenAccess version 2.2 is the application programming interface and reference database
used by tools in the Virtuoso design environment.

Data in these two databases is stored in different formats. The cdb2oa translator lets you
perform the following tasks:
■ Translate an entire design or technology library
■ Translate a specified cellview, including all the views for each of the cell masters
referenced by that cellview
■ Translate selected cells, cellviews, and view types
■ Produce a report on what would happen in a selected translation without performing that
translation

Database Versions and Design Management

The translator supports the following versions of the CDB and OpenAccess databases:
■ CDB versions 4.4.x and later
■ OpenAccess version 2.2

The translator consumes and creates libraries that are consistent with the 5.X library
structure used in the Virtuoso design environment.

Tip
For more information on design management in OpenAccess, see “Design
Management” in the Virtuoso Design Environment Adoption Guide.

February 2018 17 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Getting Started with CDB to OpenAccess Translation

Text Command
The cdb2oa UNIX text command is available only in the Virtuoso design environment. This
is because it relies on a second executable, cdb2oail, to postprocess text objects contained
in the library.

The cdb2oa and cdb2oail executables are at the following location in the hierarchy.
your_install_dir/tools/dfII/bin/

Graphical User Interface

To use the translator’s graphical user interface (GUI), you need access to one of the following
Virtuoso design environments:
■ Layout Design (layout)
■ Physical Design (layoutPlus)
■ Front to Back Design (virtuoso)

Running the Translator in 64-bit Mode

By default the translator runs in 32-bit mode. However, to translate large cellviews, you might
need to use the 64-bit version.

For example, if your design contains large cellviews (typically over 800Mb in size) and the
translator aborts unexpectedly or fails with an internal error while translating one of these
cellviews, use the UNIX commands ps or top to monitor virtual memory usage during the
translation. If virtual memory usage approaches 4 Gb, you need to use the 64-bit version.

To check which version of the translator you are using,

➤ Type the following in a shell window.
cdb2oa -W

If the sub-version contains the string 64b, you are using the 64-bit version. If it does not,
you are using the 32-bit version.

To switch to use the 64-bit version of the translator,

1. Type the following in a shell window.
setenv CDS_AUTO_64BIT “cdb2oa.exe”

2. Run the translator as normal from the command line.

February 2018 18 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Getting Started with CDB to OpenAccess Translation

For more information on running applications in 64-bit mode, see “Running 64-Bit Versions of
Applications” in the Virtuoso Software Licensing and Configuration Guide.

CDB to OpenAccess Translator Engine

The translation flow can be divided into three phases.
■ Command line validation
■ Library scan
■ Library conversion

Command Line Validation

The translator checks that you have supplied all the mandatory arguments, that all of the
arguments you specified are legal, and that the specification is consistent. If these conditions
are satisfied, the translation proceeds; if not, the translator prints a message in the terminal
window describing the problem and telling you what to do to fix it.
Note: The log file is generated only after the command line has been validated. If there is a
problem with the command line, no log file is created.

For information on the command line arguments, type cdb2oa -help in the terminal window
or see Chapter 3, “Using the CDB to OpenAccess Translator from the Command Line.”

Library Scan
After validating the command line, the translator prepares the library for conversion in the
sequence outlined below.
1. Sets up the OpenAccess versions of the library definitions file, cds.lib.
The translator calls OpenAccess functions to create the cds.lib and file if it does not
already exist in the current working directory and update them with the path to the
OpenAccess version of the library being translated.
For information on these files, see “Application Infrastructure Files” on page 29.
2. Identifies any directories in cellviews, which are illegal in CDB, and cells and cellviews
with illegal CDB names
Illegal CDB data cannot be translated. Instead it is marked to be copied to the
OpenAccess version of the library.

February 2018 19 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Getting Started with CDB to OpenAccess Translation

3. Establishes the sequence in which the cellviews will be translated

The translator examines the relationships between the cellviews in the library and
establishes the sequence in which they need to be translated in order to satisfy any
dependencies.
For example, if cell_1 references cell_2, the translator must translate cell_2 before
cell_1 so that it is available in OpenAccess at the time it is referenced by cell_1.
Where possible, the translator uses the parent-child database (pc.db) files associated
with the cellviews to do this. If there is no pc.db file present for a cellview, the translator
opens the cellview, examines the references, and then closes the cellview again.

Tip
When used from the command line, the translator is able to identify dependencies
only within the library being translated. To identify dependencies between different
libraries automatically, you need to use the GUI.

Library Conversion
The translator converts library data from the top down, working from the library directory
through the cell directories to the individual cellviews. Data that is locked is not converted
unless you specify the -ignorelocks argument. Data that already exists in the
OpenAccess version of the library is overwritten unless you specify the -nooverwrite
argument.

The conversion covers

■ Data that is copied to the OpenAccess version of the library (SKILL procedures, rules
files, any other ASCII files in the library)
■ Data that is translated (cellview database files, technology files, and property bags).

Important
The translator does not translate or copy any data located outside the library
directories specified in the CDB cds.lib file.

The translator converts data in the sequence indicated below.

1. Data in the library directory
The translator processes the files in chronological order, preserving the timestamp on
the CDB version of the file. Files with identical timestamps are processed in alphabetical

February 2018 20 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Getting Started with CDB to OpenAccess Translation

order. The translator also copies empty files and files that contain only comments, but
not files that it can identify as backup files; for example, those that end with the
characters ~ and %.
When the translator encounters a CDB technology file, techfile.cds, it translates it
into an OpenAccess technology file, tech.db. If the technology file contains stream
translation rules, they are moved into a separate file called libname.layermap, which
is stored in the same directory as the technology file from which it was derived.
For information on the translation of technology information, see “Technology
Information” on page 31.
2. Data in the cell and cellview directories
The translator copies all non-database files in the cell and cellview directories, along with
any “dot” directories in the cell directory.
3. Cellviews
After the technology information is converted and all relevant data has been copied, the
translator converts the cellview database files, mapping properties, nets, shapes,
instances, terminals, parent-child relationships, groups, inherited connections, signals,
rod purposes, and timestamps to their OpenAccess equivalents.
The cellviews within each cell are translated in chronological order based on the
timestamp of the CDB version of the cellview. This preserves the relative order of
cellviews in the OpenAccess version of the library, meaning that applications which use
timestamps to check the validity of a particular cellview produce consistent results in
CDB and OpenAccess.
The translator cannot translate illegal CDB data, such as directories at cellview level or
cells and cellviews with illegal CDB names. This data is copied to the OpenAccess
version of the library.
When a cellview has been translated, the translator checks that there is no CDB data in
the OpenAccess version and ensures that the permissions set for the OpenAccess
version are the same as those set for the CDB version.
For more information on the translation of cellviews, see “Cellviews” on page 38.

Log File
All the errors and warnings issued during a translation run are recorded in the log file, $HOME/
cdb2oa.log. Log file is created in $HOME/cdb2oa.log.X when CDS_LOG_PATH does
not contain any valid directory or is not defined.

February 2018 21 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Getting Started with CDB to OpenAccess Translation

.x here is the incremental numeric, such as 1, 2, 3.....

You can specify a different location and filename using the -log argument in the command
line. For more information on the -log argument, see “Using the CDB to OpenAccess
Translator from the Command Line” on page 63.

The translator also respects the Cadence global environment variables CDS_LOG_VERSION
and CDS_LOG_PATH.
■ CDS_LOG_VERSION lets you specify a naming convention for your log files. It accepts the
following values:
❑ sequential, which appends a sequential number to the name of the log file; for
example, cdb2oa.log.1, cdb2oa.log.2, and so on
❑ pid, which appends the UNIX process number to the name of the log file; for
example, cdb2oa.log.1719, cdb2oa.log.2250, and so on
■ CDS_LOG_PATH lets you specify a colon-separated list of directories. The log file is saved
to the first valid directory in the list.
Note: Using the -log argument in the command line overrides both of these settings.

Structure
The translator’s log file is divided into three sections:
■ Start
■ Messages
■ Summary

Start Section

The Start section provides information on the version of the translator being used and the
options that you set for the translation run.

Example:
********************************************************************************
Program: @(#)$CDS: cdb2oa version 6.1.2 08/16/2007 09:03
(machine) $ sub-version IC6.1.2.119
Started at: Aug 17th 9:30am 2007
Hierarchy: /grid/cic/cds/IC6.1.2/red
User Name: user
Host Name: host1
Options: -lib design -cdslibpath ../cdb/

February 2018 22 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Getting Started with CDB to OpenAccess Translation

Directory: /user/oa/
Log File: ./cdb2oa.log.2
Copyright (C) 2001-2005 Cadence Design Systems, Inc. All Rights Reserved worldwide
*********************************************************************************

Note: The log file does not include any of the command line validation errors because these
are generated and directed to standard error output (typically the terminal window) before the
log file is created. Nor does it include any messages generated by external subsystems.
These are also directed to standard error output.

Summary Section

The Summary section provides information on the numbers of cells and cellviews that were
translated.
■ A cell is classed as any directory under the library directory that contains a translated
database cellview.
■ A cellview is any directory under a cell that contains either a master.tag or a .cdb file.

Any directory that does not meet these criteria is copied to the OpenAccess version of the
library. The number of such directories at cell and cellview level are also listed.
Note: The statistics do not include data that was copied to OpenAccess because it is illegally
named in CDB. For more information on name spaces and how the translator handles illegal
CDB names, see “Illegal CDB Names” on page 27.

If the library contains only technology information, the summary section tells you whether it
was translated successfully or not.

The summary also lists the messages that were generated by the translator, with specific
variables replaced by variable types, the number of times each message occurred, a
description for each message, and hints on how to recover from specific errors.

Example:
********************************************************************************
Finished at: Dec 12 11:49:21 2002

74 cells and 137 cellviews were translated from library “libName” in times.

In addition:
1 cell level directory was copied to the OpenAccess library.
2 cellview level directories were copied to the OpenAccess library.

Message Summary:

February 2018 23 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Getting Started with CDB to OpenAccess Translation

ERROR (CDBOA-300): Cannot process <path>/<file> because it is locked.

Generated 27 times. This may mean that there are stale lock
files present in your database. Use the -ignorelocks argument
to have cdb2oa ignore these lock files or remove the lock
files manually.

WARNING (CDBOA-502): Cannot find technology database for library <path>/<name>.

Generated once. This may indicate that a technology file is

missing from your library. Check that you have access to all
of the technology information required for the library.

WARNING (CDBOA-700): There may not be enough disk space to complete the
translation.

Generated once. If the translation stopped unexpectedly,

ensure that there is sufficient disk space available.

********************************************************************************

Reporting Progress
If you specify the -report argument, for each cellview, the translator issues a message
listing the cellview being translated and how many of the total number of cellviews have been
processed.
INFO (CDBOA-800): Translating cellview “path/name” (value/value) ...

Disk Space
Throughout the translation run, cdb2oa estimates the amount of disk space required for the
current cellview and compares it with the space available on disk. If it appears that there is
insufficient disk space to accommodate the OpenAccess library, the translator prints a
warning to the log file indicating that it might not be able to complete the conversion. If your
disk space runs out part way through a translation, it is safe to assume that the last translated
cellview is not complete.

Caution
If you use a quota system to allocate disk space between users, the
amount of disk space available to you is likely to be less than that
estimated by the translator.

February 2018 24 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Getting Started with CDB to OpenAccess Translation

Using the CDB to OpenAccess Translator in the Virtuoso

Design Environment
This section describes the translator’s interaction with the Virtuoso design environment
variables files and clarifies the use of name spaces when specifying a cdb2oa command.

Environment Variables Files

The two main system files that control environment settings in Virtuoso design environment
products are .cdsinit and .cdsenv. The cdb2oa translator interacts with these files
differently from other Cadence applications.

The .cdsinit File

The .cdsinit file is used to configure menus, bindkeys and mouse buttons, colors, and
fonts in your Cadence applications. Because these settings are not relevant for cdb2oa, the
translator never loads the .cdsinit file.

Important
Do not use the .cdsinit file to load SKILL code required for parameterized cells
or other design features. Use the libInit.il file instead.

The .cdsenv File

The .cdsenv file lets you configure environment settings for your Design Framework II
applications.

The translator needs to look at this file to check whether it is being used to set the DBUPerUU
(database units per user units) value for the library and, if so, whether the value is consistent
with the value set in the OpenAccess technology file. If the values are different, the translator
issues a warning.

There might be different versions of this file in different locations to capture site, project, and
user-specified settings. The sequence in which the different .cdsenv files are loaded is
significant because the values in each file overwrite those previously loaded. The translator
loads .cdsenv files in the following sequence:
1. your_install_dir/tools/dfII/etc/tools/toolname/.cdsenv
2. your_install_dir/tools/dfII/local/.cdsenv

February 2018 25 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Getting Started with CDB to OpenAccess Translation

3. $HOME/.cdsenv
4. $CWD/.cdsenv
The translator loads any .cdsenv file it finds in the current working directory, unless the
CDS_LOAD_ENV environment variable specifies something different.
For information on the .cdsenv file and the CDS_LOAD_ENV environment variable, see
the Virtuoso Design Environment User Guide.

Name Spaces
Virtuoso design environment tools on both CDB and OpenAccess use the CDB name space.
When a Virtuoso design environment application writes an object to disk, the names are
mapped from the CDB name space to the LibraryUnix name space, which is used by
Cadence tools for library names in the cds.lib file and for library, cell, and cellview directory
names in libraries that are stored on UNIX file systems.

The CDB name space includes certain characters that are reserved for special purposes.
When a Virtuoso design environment application encounters a name containing one of these
characters, it substitutes the escaped hexadecimal code for that character when converting
it to the LibraryUnix name space.

The table below lists the reserved characters in the CDB name space, their purposes, and
their equivalents in the LibraryUnix name space. If there is no LibraryUnix equivalent,
the character is regarded as illegal in the CDB name space.

CDB LibraryUnix
Purpose
Name Space Name Space
Hierarchy delimiter backquote ( ‘ ) #60
Bit delimiter colon ( : ) #3a
Repeat asterisk ( * ) #2a
Open bus left bracket ( < ) none
Close bus right bracket ( > ) none
Name delimiter comma ( , ) none

Additionally, several other characters commonly found in CDB object names, including the
period ( . ) and the hyphen ( - ), are illegal in the LibraryUnix name space. Again,

February 2018 26 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Getting Started with CDB to OpenAccess Translation

Virtuoso design environment applications substitute the escaped hexadecimal equivalent

when writing these objects to disk.

CDB LibraryUnix
Purpose
Name Space Name Space
none period ( . ) #2e
none hyphen ( - ) #2d

Specifying Object Names in the Translator

When using the translator, specify all library, cell, and cellview names in the CDB name space.
The translator maps the CDB name to its LibraryUnix equivalent in order to locate the
object on disk and performs the translation correctly.

For example, If you specify the following command line

cdb2oa -lib lib.1 -cdslibpath ../cdb/ -cell cell-1 -view layout.old

the translator converts the following cellview stored on disk

../cdb/lib#2e1/cell#2d1/layout#2eold

Note: The translator also recognizes object names that are correctly specified in the
LibraryUnix name space.

Illegal CDB Names

If any of the special characters listed above appears unencoded in the LibraryUnix name
space, the translator is unable to map the name to the CDB name space and therefore regards
it as illegal. This scenario is most likely to be caused by a user changing the name of a
directory in the file system.

For an object to be translated it must have a name that is legal in the CDB name space.
■ If you specify an illegal library name, the translator issues an error and stops the
translation. You must assign the library a name that is legal in the CDB name space.
■ If the translator encounters an illegal cell or cellview name, it copies the contents of the
cell or cellview to OpenAccess but does not translate them. This means that you could
end up with CDB data in the OpenAccess version of your library.
■ If a cellview contains an object (for example, a net or a pin) with a name that is illegal in
the CDB name space, the translator translates the cellview but not the illegally-named

February 2018 27 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Getting Started with CDB to OpenAccess Translation

object. Therefore, although the cellview appears to have been translated to OpenAccess,
it is unlikely to be complete.
❑ For instances the special characters, ' ' '(' ')' ',' '/' '\', are converted to an '_' and these
instances are translated. If the -convertspecialchar option is specified during
translation, all special characters (except '?' and '$') are converted to an '_'.
❑ For mosaics the special characters, ' ' '(' ')' '<' '>' ',' '/' '\', are converted to an '_' and
these mosaics are translated. If the -convertspecialchar option is specified
during translation, all special characters (except '?' and '$') are converted to an '_'.

Name Spaces in Log File Messages

When printing messages to the log file, the translator prints object names as they occur in the
CDB name space. However, when it is necessary for the translator to retrieve a path directly
from the file system, you will see messages containing escaped hexadecimal codes like the
ones listed above.

For more information on name mapping in Virtuoso design environment tools, see Chapter 7,
“Name Mapping” in the Cadence Application Infrastructure User Guide.

Multimedia Demonstration

Video
For more information about translating data from CDB to OpenAccess format, see
CDB to OpenAccess Translator.

February 2018 28 Product Version IC6.1.7

2
How CDB Data is Converted

This section tells you what the translator does with the different files and objects in a typical
CDB database and highlights areas where the results in OpenAccess might be other than you
expected.

This chapter discusses the following:

■ Application Infrastructure Files on page 29
■ Technology Information on page 31
■ Cellviews on page 38
■ Parameterized Cellviews on page 41
■ Labels on page 45
■ Text Displays on page 46
■ Properties on page 47
■ Pins and Pin Connectivity on page 53
■ Paths with Extensions on page 58
■ Boundaries on page 59
■ Rows on page 59
■ CDBOA SKILL Functions on page 61

Application Infrastructure Files

The two main infrastructure files handled by the translator are
■ The library definitions file, cds.lib, which defines the libraries that Cadence tools can
access by mapping user library names to physical directory paths

February 2018 29 Product Version IC6.1.7

■ The cdsinfo.tag file, which supports the configuration of key system capabilities,
including the type of design management system used to manage a library

For information on these files, see the Cadence Application Infrastructure User Guide.

Library Definitions File

The cds.lib File

The translator creates a cds.lib file in the current directory if it does not already exist or
updates it if it is already present. It then adds a DEFINE statement to the file, specifying the
name of and the path to the new OpenAccess library being produced.

If the library to be converted is already defined in the cds.lib file, the translator updates the
existing library. If you subsequently translate a second library, an appropriate entry for that
library is added to the existing cds.lib file.

If you use the -oalibpath argument and the library being converted is already defined in
the OpenAccess cds.lib file using a different path, the translator comments out the original
definition and redefines the library using the path you specified.

Tip
To ensure that the correct cds.lib file is updated and that access to the
OpenAccess version of the library is correctly maintained, always run the translator
in the OpenAccess library directory.

By default, all the paths written to the cds.lib file are relative to the current directory. You
can have the translator write absolute paths instead by using the -abspath option on the
command line or turning on the Write absolute paths in OpenAccess cds.lib file option
on the General tab in the CDB to OpenAccess Translator form.

Using absolute paths in the cds.lib file can lead to problems if you need to access the data
across different networks or using different hardware platforms and can adversely affect the
performance of your applications on OpenAccess.

Important
The cdb2oa translator is not supported on sol86 platform.

Additionally, if you convert the same library twice and specify the -abspath argument for
only one of the conversions, then the resulting library definitions files contain two different

February 2018 30 Product Version IC6.1.7

DEFINE statements for the same library. Check the library definitions files regularly to ensure
that the data it contains is consistent.

CDB cds.lib File Copied to OpenAccess

If you copy a CDB cds.lib file to the OpenAccess version of the library, you must
■ Ensure that you have permission to write to the OpenAccess version of the cds.lib file
so that the translator can update it during the conversion.
■ Modify the library definitions so that they point to OpenAccess data and not to CDB data.
❑ If the OpenAccess cds.lib definition for the library being converted points to the
CDB version of the library, the translator stops because this would place the
OpenAccess version of the library in the same location as the CDB version, which
is not permitted.
❑ If any of the other library definitions in the OpenAccess cds.lib file point to CDB
data, the translator issues a warning. The translator will stop if the library you are
converting references CDB data from OpenAccess.

System Information File

The cdsinfo.tag file is an ASCII file specifying various tool, library, design management
system, and file system properties. It is copied to the OpenAccess version of the library.

Technology Information
The technology information in the Virtuoso design environment defines the parameters used
in design sessions, including layer and device definitions, design rules, and display
parameters. There are three main sources of technology information for a CDB design library.
■ A CDB technology file, techfile.cds, stored in the library directory
■ Separate technology libraries, attached to the design library using the techLibName
property in the appropriate library prop.xx file
■ A display resource file, display.drf

For more information, see the Virtuoso Technology Data User Guide.

February 2018 31 Product Version IC6.1.7

Technology File

If the translator encounters a CDB technology file, techfile.cds, in the library directory, it
converts it into an OpenAccess binary technology file called tech.db. The translator handles
automatically most of the changes required by the different technology file formats in CDB
and OpenAccess. The exceptions are described in the sections below.

For more information on CDB and OpenAccess technology files, see the Virtuoso Design
Environment Adoption Guide.

Place and Route Rules

Part of the conversion involves converting place and route technology rules from CDB to
OpenAccess. Messages generated during this step are included in the translator log file and
are also printed to the terminal window from which you started the translator. They are tagged
“Technology Conversion” for identification.

For information on troubleshooting these messages, see the Virtuoso Design Environment
Adoption Guide.

Stream Translation Rules

Stream translation rules are stored in the streamLayers section of the CDB technology
file. They contain the information required to translate your design to GDSII format, mapping
layer-purpose pairs to stream numbers and data types.
For example:
streamLayers(
;( layer streamNumber dataType translate )
;( ----- ------------ -------- --------- )
( ("metal1" "net") 1 0 t )
( ("metal1" "boundary") 2 0 t )
( ("metal2" "drawing" (8 9 10) (8 9 10) t )
( metal3 4 0 nil )
) ;streamLayers

The streamLayers section is not supported in the OpenAccess technology file. The
translator removes the rules from the technology file and saves them in a separate layer
mapping file called libName.layermap located in the same directory as the technology
file.

For example, the layer mapping file for the streamLayers section above looks like this.
Layer Name Layer Purpose Layer Stream Number Datatype Stream Number

metal1 net 1 0

February 2018 32 Product Version IC6.1.7

metal1 boundary 2 0
metal2 drawing 8 8
metal2 drawing 8 9
metal2 drawing 8 10
metal2 drawing 9 8
metal2 drawing 9 9
metal2 drawing 9 10
metal2 drawing 10 8
metal2 drawing 10 9
metal2 drawing 10 10
#metal3 boundary 4 0
#metal3 drawing4 4 0
#metal3 label 4 0
#metal3 pin 4 0
#metal3 net 4 0
#metal3 drawing 4 0

# denotes a comment, reflecting the translate field setting of nil in the original
streamLayers definition.
Note: You can specify a different name for the layer map file using the -layermapfile
argument.

Routing Rules for the IC Shape-Based Router

Routing rules for the IC Shape-Based Router can be stored in the CDB technology file or in
a separate ASCII file. Rules stored in the CDB technology file are picked up automatically by
the translator unless you specify a separate rules file using the -iccrulesfile argument.
If you specify a rules file, only that file is processed and any rules in the technology file are
ignored.

The translator translates these rules to the virtuosoDefaultSetup constraint group in the
OpenAccess technology file. To specify a different constraint group in which to put these
rules, use the -iccconstraintgroup argument.

Attached Technology Libraries

In CDB, you can vary the technology information used in your design by attaching different
technology libraries to individual design libraries, cells, and cellviews. Each cell or cellview in
a library inherits the technology library attached to the library unless another technology
library is attached to the cell or cellview in question.

When you attach a technology library, the translator updates the technology devices in the
design to reference the technology library and adds the techLibName property to the
property bag for the relevant library, cell, or cellview.

February 2018 33 Product Version IC6.1.7

OpenAccess is more restricted; it picks up only technology libraries that are attached at the
library level. Cell and view-specific attachments are ignored.

Important
You must ensure that any attached technology library is defined in the library
definitions files and is translated before you translate the library that references it.
The translator stops if it encounters a reference to an attached library that does not
exist in OpenAccess. This is the case even if the library being translated does not
require technology information; for example, if it contains o®.
Note: Dependencies like this are handled automatically when you use the GUI but not
when you run the translator from the command line.

For information on attaching and detaching technology libraries, see the Virtuoso
Technology Data User Guide.

Setting Units Values in the OpenAccess Technology File

In CDB, the values for user units (userUnits) and database units per user unit
(DBUPerUU) for each cellview type can be stored in various locations.
■ In the design library property bag (prop.xx)
■ In an attached technology file
■ In one of the Cadence environment variables (.cdsenv) files
■ As default values hardcoded in the system

When converting technology information, the translator consolidates these values from the
different locations in CDB into a single location in the OpenAccess technology file.
1. The translator creates the OpenAccess technology file with the system default values for
each cellview type.
2. For each cellview type, the translator searches the CDB data in the sequence above and
compares the first value it finds with the value set for that cellview type in the OpenAccess
technology file.
3. If the values are different, the translator updates the OpenAccess technology file with the
value from CDB and issues a warning.
If you do not have permission to write to the library in question, the translator issues an
error.

February 2018 34 Product Version IC6.1.7

In some cases, the OpenAccess values might be stored in the default technology file,
cdsDefTechLib, rather than in the library’s own technology file. The translator is unable to
update the OpenAccess cdsDefTechLib directly. Instead, it creates a new technology
library, tech.db, containing the correct values, attaches it to the design library, and issues a
warning to explain what it has done.

Validating Technology Information in OpenAccess

Before translating cellviews, the translator checks that any required technology information is
already translated and present in the OpenAccess version of the library. To do this, it checks
the design library properties to see whether there is an attached technology library specified.
■ If there is no attached technology library specified, the translator expects to find
a binary technology file (tech.db) in the OpenAccess library directory.
❑ If there is a tech.db present, the translator uses it.
❑ If there is no tech.db present, the translator issues a warning telling you that it was
unable to find any technology information for the library.
It then proceeds with the translation. You can either interrupt the translator and fix
the technology references in the CDB version of the library or let it run and try to fix
any problems in the OpenAccess version.
■ If there is an attached technology library specified, the translator checks to make
sure it exists in OpenAccess.
❑ If the attached technology library is the design library itself, the translator looks for
the tech.db which should exist already in the OpenAccess library directory.
❍ If there is a tech.db file present, the translator uses it.
❍ If there is no tech.db present, the translator issues an error telling you that the
attached technology library does not exist and stops.
Note: The translator stops in this case because there is a specific reference to
a technology library that does not exist.
❑ If the attached technology library is cdsDefTechLib (the default technology library
shipped with your Cadence installation) or a different technology library, the
translator checks to ensure that the library in question already exists in OpenAccess.
❍ If the attached technology library exists in OpenAccess, the translation
proceeds.
❍ If the attached technology library does not exist in OpenAccess, the translator
issues an error and stops.

February 2018 35 Product Version IC6.1.7

Display Resource File

The display resource file specifies how your layers appear on display devices. It contains
display device definitions; definitions of colors, stipple patterns, and line and fill styles; and
definitions of display packets, which are collections of colors, stipples, and line styles
associated with particular display devices.

The translator copies this file to the OpenAccess version of the library.

Important
If you use a common display.drf file for multiple libraries and store this file
outside the library directory being translated, the translator does not copy it
automatically. The translator does not translate or copy any data located outside the
library directories specified in the CDB cds.lib file.

Sites
Cellviews that are used to define sites in CDB are converted to site definitions (siteDefs)
in the OpenAccess technology file.

To do this, the translator checks all CDB cellviews containing the property prCellType set
to the value site and looks for shapes on the (boundary boundary) or (boundary
drawing) layer-purpose pairs. It then uses these shapes to determine the height and width
for the siteDef.

Once the siteDef has been created, the unrequired cellviews are removed from the
OpenAccess library.

Symbolic Device Masters

Symbolic device masters (syContact, syPin, and syRectPin) are not supported in
OpenAccess.

When CDB technology data is converted to OpenAccess, syContact devices are mapped
to standardViaDef devices, syPin and syRectPin devices are mapped to pin figures,
and the devices are deleted from the technology file.

To let Pcells which instantiate these devices continue to evaluate correctly after conversion,
use the -keepdevicemasters argument to preserve the device cellviews in the
OpenAccess version of the library.

February 2018 36 Product Version IC6.1.7

Important
The -keepdevicemasters argument is provided for compatibility purposes only.
Although the device masters are translated, they are not recognized by the system
as via objects; you cannot update or recreate the device masters in OpenAccess,
and a query to the technology file does not return any symbolic device information.
Use the argument as a temporary solution if you have SKILL Pcells that instantiate
syContact, syPin, syRectPin, and cdsVia devices.
Note: A symbolic contact devices in CDB is converted to a standardViaDef in
OpenAccess if the dbiPDDCreateContact option is set to true in the Pcell code of the
device. However, if the dbiPDDCreateContact option is set to false, then a symbolic
contact device is converted to a customViaDef. To ensure that a symbolic contact device is
always converted to a standardViaDef, even if the dbiPDDCreateContact option is set
to false in the Pcell code, use the -symcontacttostdvia argument.

For more information, see the Virtuoso Design Environment Adoption Guide.

Via Instances
If your CDB design contains vias with master cellviews defined in the design library rather
than in the technology library, these need to be converted to vias in the OpenAccess version
of the technology library. You can do this either manually or automatically.
■ Manually - You can list the master cellviews in a via map file. The translator creates these
master cellviews as oaCustomViaDefs in the technology library and converts the CDB
instances of these masters as oaCustomVias which reference the oaCustomViaDefs
in the technology library. You can pass the via map file to the translator by using either
the command line argument -viamap or the GUI option Via map file on the
Technology tab.
The format of the via map file is as follows.
LibName CellName ViewName layer1 layer2 viaDefName
...

Note: All lines starting with the # symbol will be ignored. The # symbol is meant for
adding comments in the via map file.
■ Automatically - You can use the command line argument -detectvias or the GUI
option Detect vias automatically to let the translator detect the cellviews in the CDB
design that can be represented as viaDefs in OpenAccess. This takes away the effort of
manually creating a via map file. Unlike the translation using the via map file, the
automatic feature detects both oaStandardViaDefs and oaCustomViaDefs in the
CDB design.

February 2018 37 Product Version IC6.1.7

Note: The manual and automatic options should not be used together.
If you neither select Detect vias automatically nor specify a Via map file, the vias will
be translated as instances. Instances take more time for processing and are less efficient
than vias. Moreover, the resulting oaDesigns are larger than required.

Important
If the cellview is created using system reserve layers instead of valid physical layers
then the -detectvias option does not convert the cellview in CDB to the standard
or custom ViaDefs in OpenAccess. In addition, no message will be displayed to the
user if the conversion is not successful.

Cellviews
Cellview database files are translated from CDB format to OpenAccess format and the
filename extension is changed from cdb to oa.

The translator always translates as much of a cellview as possible. Errors encountered in the
translation of a cellview are reported in the log file but do not necessarily cause the translator
to stop. If the log file contains errors against a particular cellview, examine the OpenAccess
version carefully to make sure it meets your needs. In some cases, you might need to fix the
data in CDB and translate the cellview again.

Master Cellviews
For certain operations, such as launching an editor on cellview data, Cadence software
needs to be able to identify the master file in any cellview. The master.tag file is an ASCII
file that specifies which view file inside each cell directory is the master.
Using a cellview called layout.cdb as an example, the translation of the master.tag file
is subject to the following conditions:
■ If layout.cdb is the master in CDB, then layout.oa is made the master in
OpenAccess.
If there is an existing layout.oa file in OpenAccess that is not the master, the translator
makes it the master.
■ If layout.cdb is not the master in CDB, then layout.oa is not made the master in
OpenAccess.

February 2018 38 Product Version IC6.1.7

If there is an existing layout.oa file that is the master, the translator does not change
the specification because there is no way for it to determine what should be master
instead.

Illegal Names
For a cellview to be translated it must have a name that is legal in the CDB name space.
■ For information on what the translator does when it encounters an illegal name, see
“Illegal CDB Names” on page 27.
■ For general information on how the translator handles name spaces, see “Name Spaces”
on page 26.

Empty Cellviews
The translator does not translate or copy cellview data files that are empty. However, to
maintain the hierarchy of the library, the cellview directory containing the empty view file is
always copied to the OpenAccess version of the cellview.

Directories in Cellviews
Neither CDB nor OpenAccess supports directories in cellviews. When the translator
encounters a directory in a cellview, the directory and all its contents are copied to
OpenAccess but are not translated. If the directory in question contains CDB data files, these
will end up in the OpenAccess version of your library.

Tip
If your library has directories in cellviews and if those directories contain data that
needs to be translated, move the directory and its contents up to the cell level in the
hierarchy before running the translator.

Parent-Child Database File

The parent-child database file, pc.db, typically resides in the cellview directory and stores
the hierarchical relationships for that cellview. It is a derived file that allows Cadence hierarchy
functions to navigate descriptions other than CDB; for example, VHDL and Verilog.

Because the PCDB API can get the same information directly from the OpenAccess version
of the cellview, it is not always necessary to copy the pc.db file to OpenAccess. Whether it

February 2018 39 Product Version IC6.1.7

is copied or not depends on whether or not the master cellview, as specified in the
master.tag file, is a CDB cellview.
■ If the master is a CDB cellview, it is converted to an OpenAccess cellview. Because the
PCDB API can get the information it requires from the OpenAccess cellview, the pc.db
file is redundant and is not copied.
■ If the master is not a CDB cellview, the pc.db file is required and is copied to the
OpenAccess version of the library. If the pc.db file is copied, its CDB timestamp is
preserved.

View Types
OpenAccess supports 4 distinct view types; CDB supports many more. The translator
converts view types from CDB to OpenAccess as follows:

CDB OA CDB OA CDB OA

Enum Enum Filename Filename View Type View Type
dbcUnknownCellViewType (no equivalent) N/A N/A N/A N/A

dbcGraphic oacMaskLayout graphic.cdb layout.oa graphic maskLayout

dbcMaskLayout oacMaskLayout layout.cdb layout.oa maskLayout maskLayout

dbcSchematic oacSchematic sch.cdb sch.oa schematic schematicSymbol

dbcSymbolic oacMaskLayout layout.cdb layout.oa maskLayout maskLayout

dbcPCB oacNetlist N/A netlist.oa N/A N/A

dbcSchematicSymbol oacSchematicSymbol symbol.cdb symbol.oa schematicSymbol schematicSymbol

dbcLogicModel oacNetlist N/A netlist.oa N/A netlist

dbcBehavioral oacNetlist N/A netlist.oa N/A netlist

dbcStranger (no equivalent) stranger.cdb N/A stranger N/A

dbcNetlist oacNetlist netlist.cdb netlist.oa netlist netlist

dbcPackage oacNetlist N/A netlist.oa N/A netlist

dbcVerilogMap oacNetlist veriMap.cdb netlist.oa verilogMap netlist

Mismatched View Types

CDB tolerates cellview filenames that do not match the view type stored internally in the data
file. OpenAccess does not. The translator identifies this conflicting view type information and
fixes it by changing the cellview filename in OpenAccess to match the stored view type.

February 2018 40 Product Version IC6.1.7

For example, CDB allows a cellview with the stored view type maskLayout to be called
symbol.cdb. This would be translated into an OpenAccess cellview of type maskLayout
called layout.oa.

The translator issues a warning each time it encounters a mismatched view type. To prevent
these warnings from being generated, refer to the table above and modify your CDB data to
ensure that the view type implied by the filename reflects the view type stored for the cellview.
For example, if the view type is schematic, then the filename should be sch.cdb.

Mosaics
A mosaic is a database object that represents an array of instances of one or more masters.

There are two kinds of mosaics: simple and complex. A simple mosaic is a special kind of
regular array that has only one master, and every cell in the array has the same orientation.
Any mosaic other than the simple mosaic is called a complex mosaic.
■ The translator maps a simple mosaic to an OpenAccess arrayed instance.
■ Complex mosaics are seldom used in CDB and are not supported in OpenAccess.
The translator breaks up complex mosaics into the individual instances that make up the
mosaic.

For information on the issues around mosaics in CDB and OpenAccess, see the Virtuoso
Design Environment Adoption Guide.

Parameterized Cellviews
A parameterized cell, or Pcell, is a graphic, programmable cell that lets you create a
customized instance each time you place it. Pcells are created in the same way as any other
cell and combine the graphic layout of the cell and the parameters assigned to it. After you
compile the master, it is stored in the database as a SKILL procedure.

All Pcells to be translated must comply with the recommendations set out in the Virtuoso
Parameterized Cell Reference, particularly those in section “Creating Pcells Using SKILL”
in Chapter 15.

If your Pcells deviate from the recommendations and, for example, include SKILL functions
that are not intended for use in Pcells, the translator fails.

February 2018 41 Product Version IC6.1.7

Note: An UNIX environment variable CHECK_SKILL is added in cdboa. If the

CHECK_SKILL variable is not set, the current bahaviour will be retained, otherwise a check
will be performed to find out whether or not the Pcell SKILL code dumped is correct.

Referencing SKILL Code

Occasionally, the translator might try to load SKILL code that has not yet been copied to
OpenAccess, causing errors and warnings to be written to the log file. You can prevent these
messages from being generated by moving all of your SKILL code into a .skill directory at
the library level. The translator processes dot files first.

Instance Parameters
The Pcell you create is referred to as the master. You can define the master to have various
parameters. Length and number of gates are examples of parameters of a transistor Pcell.
While creating the instances of a Pcell, you can update the values of parameters such that
the values of those parameters are different on the Pcell master.

Every Pcell instance is associated with two types of parameters — Pcell parameters and cdf
parameters. Parameters might, in turn, be associated with attributes. Every cdf parameter, for
example, is associated with the attribute storeDefault, and every cdf parameter can have
a different setting for the storeDefault attribute. The valid values for the attribute include
yes and no.

Many Pcell and cdf parameters overlap in their names, types, and default values. In these
cases, the value of the storeDefault attribute on the cdf parameter decides which of the
two parameters would take precedence during the CDB to OpenAccess conversion. The
translator obeys the following use model:
■ If storeDefault = yes on a parameter, the translator will retain parameter on the
instance after translation. The default parameter value is taken from the Pcell master or
CDF parameter depending on the storage policy defined.
■ If storeDefault = no on a parameter, the translator will retain the parameter after
translation only if it has non-default value on the instance.

February 2018 42 Product Version IC6.1.7

CDF Support in CDB2OA

For all good CDF data, cdb2oa will be able to take CDF into account while instance creation.
However, for bad CDF data (Pcell superMaster parameter and CDF parameter with same
name and incompatible valueTypes), cdb2oa will drop the override with appropriate warnings.

Compatibility List

superMaster Parameter Type Instance Parameter Type

boolean boolean/integer/float
integer integer/float/double/range
float integer/float/double/range
double integer/float/double/range
string/Filename/IlExpr/NlpExpr string/Filename/IlExpr/NlpExpr
intRange/floatRange/doubleRange range/int/float/double
timeRange time

Two options have been introduced for handling CDF data efficiently.
■ storedefaultspolicy <usepcellvalue | usecdfvalue> specifies whether cdb2oa translator to
consider CDF parameters or Pcell superMaster parameters while creating parameters
on the OA instance. If you do not specify the option Pcell superMaster parameters are
considered.
■ parampolicy <abortontypedifference | abortondefaultvaluedifference | abortonboth>
specifies cdb2oa translator to abort when a mismatch of parameter types and default
values occur between CDF parameter and Pcell superMaster parameter. By default,
appropriate warning will be displayed and translation would continue if there is a
mismatch in type or default values. For example, if the superMaster has the parameter
type as boolean and instance has the parameter type as string or list, then CDBOA does
not do auto-conversion and the warning message will be displayed.

The cdb2oa now consider storeDefaults in the CDF data per parameter basis.

keepCDBInstParams Option
The keepCDBInstParams option allows CDBOA to retain all the parameters on OA
instances even if they have same default values as their master parameters. This option
should be used for User CDF or CDBOA will not consider User CDF and the parameters are
not retained on OA instance by default.

As this option is not parameter specific, CDBOA will end-up putting all the parameters on the
OA instance irrespective of their storeDefault value. For example, the text2 parameter

February 2018 43 Product Version IC6.1.7

has the storeDefault value set to “no” on master, P2. When an instance of P2 is created
in a cellview (both in CDB and OA), the parameter, text2 is not kept on that instance.
However, CDBOA will retain the parameter, text2 on the OA instance along with all other
parameters.

Magnification
CDB supports the magnification of instances but OpenAccess does not. To reproduce
magnified instances in OpenAccess, the translator creates special parameterized cellviews
containing flattened instances of the original cellview master with an additional mag
parameter, used to magnify instances of that master when required.
■ When CDB2OA encounters a CDB instance (including Pcell and hierarchical instances)
that is magnified and the OA instance master does not have a mag parameter, the
translator
1. Creates a new instance of the original cellview master in OpenAccess version of the
library
Note: If the magnified instance is in a separate reference library, the translator creates
the new instance in the OpenAccess version of that reference library. If the translator is
unable to write to the reference library, it creates the new instance in the current library.
2. Flattens this instance
3. Adds a mag parameter to scale the shapes in the instance
4. Saves the instance as a new Pcell cellview called viewName_xform.

If there is already a transformed Pcell available for the cellview master in question, the
translator uses the existing Pcell and applies the appropriate mag value.
■ When CDB2OA encounters a CDB instance with mag != 1, and the OA instance master
is already a pCell with mag as a parameter, then for the instance translation the existing
OA master will be used and not create a new one with the _xform view name.

Transforming Pcells

If the instance to be magnified is itself a Pcell, the translator first creates an instance of the
original Pcell, using the original parameters, and then proceeds from step 2 in the procedure
above.

February 2018 44 Product Version IC6.1.7

Generating Netlists with Magnified Cellviews in OpenAccess

To ensure that your netlister recognizes the magnified instances in OpenAccess, you must
add the new cellview name, viewname_xform, to the netlister’s view name list before
running the netlister.

For example, for a magnified symbol cellview, add symbol_xform to the netlister’s view
name list.

Labels

Bounding Boxes
The bounding boxes of labels might be different in the OpenAccess and CDB versions of the
same cellview.

The difference is caused not by the translator but because of a difference in how OpenAccess
and CDB calculate bounding boxes. OpenAccess rounds the values to the nearest database
unit, whereas CDB truncates the values. Consequently, the width and height of a particular
label could differ by up to 1 (OpenAccess) database unit between OpenAccess and CDB
versions.

If the label or text display is at the edge of a cellview, the difference described above can
cause the bounding box of the cellview (and any instances of that cellview) to be different in
OpenAccess and CDB.

Caution
There can be a situation where cutRows or cutColumns is an even
number and the CutSpacing divided by manufacturing grid resolution is
an odd number. Then during translation there is the off-grid issue
because of a difference in the calculation method of bounding Box in OA
and CDB.

Therefore, to resolve this issue, CDBOA manipulates Origin Offset parameter to retain the
same geometry during CDBOA translation.

February 2018 45 Product Version IC6.1.7

Text Displays

Visibility Settings
Text display objects are used to display the value of a property or attribute for an object. Like
all other design components, they can be assigned visibility attributes that specify whether or
not they are displayed when the cellview is viewed in a display device.

The visibility attributes are implemented differently in CDB and OpenAccess. The translator
maps the CDB settings as indicated in the table below.

CDB OpenAccess

isVisible isNameVisible isValueVisible isVisible format

t t t t oacNameValueTextDisplayFormat
t t n t oacNameTextDisplayFormat
t n t t oacValueTextDisplayFormat
t n n n oacValueTextDisplayFormat
n t t n oacNameValueTextDisplayFormat
n t n n oacNameTextDisplayFormat
n n t n oacValueTextDisplayFormat
n n n n oacValueTextDisplayFormat

Bounding Boxes
The bounding boxes of text displays might be different in OpenAccess and CDB versions of
the same cellview.

The difference is caused not by the translator but because of a difference in how OpenAccess
and CDB calculate bounding boxes: OpenAccess rounds the values to the nearest database
unit, whereas CDB truncates the values. Consequently, the width and height of a particular
text display could differ by up to 1 (OpenAccess) database unit between OpenAccess and
CDB versions.

If the text display is at the edge of a cellview, the difference described above can cause the
bounding box of the cellview (and any instances of that cellview) to be different in
OpenAccess and CDB.

February 2018 46 Product Version IC6.1.7

Properties
The translator converts the CDB properties, wherever appropriate, to the equivalent
OpenAccess attributes.

Property Bags
In CDB, properties of libraries, cells and views are stored in files called prop.xx. To access
the properties, the application would call a function called dbOpenBag. The property bag is
explicitly or implicitly opened to create properties on library, cell or view.

In the Virtuoso design environment on OpenAccess the prop.xx file has been replaced by
a data.dm file. In OpenAccess the properties of objects such as library, cell or view are
created directly in this file and accessed through the corresponding objects.

The translator converts properties stored in prop.xx files to their equivalents in OpenAccess
data.dm files. The CDB properties attached to individual objects are mapped to their
OpenAccess equivalents.

Important
The translator converts property bags only if there is a valid master file in the cell in
question. If the master.tag file points to a nonexistent or invalid master file, the
translator is unable to convert any property bag that is associated with that cellview.

Filename Type Properties

The filename type property, dbcFileNameType, is the only CDB property type that is not
supported in OpenAccess. The translator converts this property to dbcStringType in
OpenAccess.

Net, Pin, and Terminal Properties

The translator converts CDB net, pin and terminal properties to OpenAccess cellview
attributes. If the property name contains a character the OpenAccess considers to be invalid,
the translator issues an error.

February 2018 47 Product Version IC6.1.7

Net Criticality
The default net criticality on CDB is 10 and that on OpenAccess is 0. The following table
depicts how the maximum, minimum, and default net criticality values on both the databases
are mapped.

Net Criticality CDB OpenAccess

Minimum 0 -127
Default 10 0
Maximum 127 +128

The translator converts the net criticality value based on this mapping. Other than the
maximum, minimum, and default net criticality values, one can expect the net criticality on
OpenAccess to be 10 units less than that on CDB.
Note: If the CDB net property prEditNetProperty exists on a net, the translator treats it
as the net criticality value and converts it based on the above described mapping to an
appropriate OpenAccess net priority value.

Ground Sensitivity and Supply Sensitivity

The CDB terminal properties groundSensitivity and supplySensitivity are

converted into OpenAccess terminal attributes, provided the terminal specified in the CDB
property exists in the OpenAccess version of the cellview.

Unplaced Instances
Instances with placement status unplaced are displayed by Virtuoso design environment
applications such as Virtuoso XL on CDB but not on OpenAccess. To view such instances in
your OpenAccess design, use the -resetplacestatus argument with the cdb2oa
command to reset the placement status to none. In case the translator finds any unplaced
instances, it issues a warning message.

For more information on this argument, see “Syntax” on page 65.

Tip
If you are using the GUI, use the Reset placement status option on the Database
tab.

February 2018 48 Product Version IC6.1.7

Timestamps and Counters

Timestamp properties are used for the following main reasons in Virtuoso design
environment tools:
■ To check that the connectivity extracted for a particular cellview is current
■ To check that the geometry of a cellview is current
■ To check that a placed instance is in synch with its master cellview

These operations are facilitated differently in CDB and OpenAccess.

■ CDB uses the values of three main timestamp properties
❑ lastSchematicExtraction, which is updated by the Virtuoso schematic
extractor whenever connectivity is extracted for a particular cellview
❑ schGeometryLastRecorded, which is updated whenever a schematic cellview is
opened by the Virtuoso Schematic Editor
❑ instancesLastChanged, which is updated whenever a cellview is edited
■ OpenAccess maintains a number of counters to represent different timestamps for each
cellview.
Whenever a cellview object is changed in some way, OpenAccess increments the
counter for the object by 1 and the counter for the cellview by 1. These counters replace
the CDB instancesLastChanged property.
The OpenAccess equivalent of the lastSchematicExtraction property is an integer
property called connectivityLastUpdated, created at the end of the extraction
process by each of the extractors mentioned above.
Similarly, the OpenAccess equivalent of the schGeometryLastRecorded property is
another integer property called schGeometryLastUpdated, created whenever a
schematic cellview is opened by the Virtuoso Schematic Editor in OpenAccess.

This section outlines how the translator converts CDB timestamp properties to OpenAccess
counters. For detailed information on this topic, see the Virtuoso Design Environment
Adoption Guide.

February 2018 49 Product Version IC6.1.7

Checking Connectivity

Tip
Cadence recommends that you always run Schematic Editor’s Design – Check
and Save command on the OpenAccess cellviews in order to re-extract the
connectivity information before using translated schematic and symbol data in your
flows.

To check that the connectivity extracted for a particular cellview is current, CDB applications
compare the values of lastSchematicExtraction and instancesLastChanged for
the cellview in question. If lastSchematicExtraction is later than
instancesLastChanged, the connectivity data is current; otherwise, it is not current.

OpenAccess applications compare the value of the cellview counter against the value of the
cellview’s connectivityLastUpdated property. If the values are different, then the
connectivity data is out of date and needs to be re-extracted.

The translator checks whether the connectivity data is current in CDB before translation.
■ If it is current in CDB, the translator retrieves the value of the cellview counter in
OpenAccess and creates the connectivityLastUpdated property with the same
value. OpenAccess applications querying the values of the two counters find that they
are the same and therefore that the connectivity is current.
■ If it is not current in CDB, the translator creates the connectivityLastUpdated
property with a value different from that of the cellview counter. OpenAccess applications
find that the values are different and that connectivity needs to be re-extracted for the
cellview.

Important
Some processes compare the lastSchematicExtraction property with the
UNIX file timestamp to determine whether or not the cellview needs to be
renetlisted. To support this methodology, the translator always copies the
lastSchematicExtraction property from the CDB to the OpenAccess version
of the cellview. If there is no lastSchematicExtraction property in the CDB
version, the translator does not create one.

Checking Geometry

The translator uses a similar scheme to establish the status of cellview geometry. In this case,
the schGeometryLastRecorded property is compared with instancesLastChanged to
determine if the geometry of the cellview is up to date.

February 2018 50 Product Version IC6.1.7

Checking the Currency of a Placed Instance and its Master

In CDB, whenever a cellview is opened, the application retrieves the value of

instancesLastChanged from the master cellview during instance binding and compares
it with the value of the instancesLastChanged property from the instance in the cellview.
If the value from the master is later than the value from the cellview, it means that the master
has been edited since the cellview was last saved.

In OpenAccess, when saving the cellview, the cellview counter from the master is stored
under the name masterChangeCount in the instance header of the parent cellview that
contains the instance. When the cellview is reopened, the cellview counter from the master
is compared with the masterChangeCount counter from the instance header. If the values
are different, then the instance and its master are out of synch.

The translator converts this information from CDB to OpenAccess as follows:

■ If the instance and its master are in synch in CDB and the master has already been
translated to OpenAccess, the translator retrieves the value of the cellview counter from
the master and makes it the value of the masterChangeCount counter in the instance
header. The next time an application compares the values, it detects that they are the
same and therefore that the instance and its master are in synch.
■ If the instance and its master are out of synch in CDB and the master has already been
translated, the translator assigns a value of 0 to masterChangeCount. The next time
an application compares the values of the master’s cellview counter and
masterChangeCount, it detects that they are out of synch.
■ If the master has not yet been translated to OpenAccess, the cellview counter of the
master is unknown. In this case, the translator assumes that the master and its instance
are out of synch and assigns a value of 0 to masterChangeCount. When the master is
translated and the instance bound, the instance and its master are indicated to be out of
synch.

Virtuoso XL Properties
The Virtuoso XL properties listed below have been updated in OpenAccess version 2.2. The
translator automatically converts the CDB property to its OpenAccess equivalent.

CDB OpenAccess
adleVersion lxInternal->version

February 2018 51 Product Version IC6.1.7

CDB OpenAccess
dleCellViewPair lxInternal->source->cell
->dleCVPairCellName
dleCellViewPair lxInternal->source->lib
->dleCVPairLibName
dleCellViewPair lxInternal->source->view
->dleCVPairViewName
dleIgnoredParams lxParamsToIgnore
dleStopList lxStopList
dleTime lxInternal -> time
dleUseCell lxUseCell
dleViewList lxViewList
lxIgnoredParams lxParamsToIgnore
lxIgnoreParamsForCAS lxParamsToIgnoreForCheck
maskLayoutViewName lxStopList

Where conflicts arise

■ If the target property already exists, the translator deletes the old property.
■ If both dleIgnoredParams and lxParamsToIgnore exist, the translator uses the
value specified for lxParamsToIgnore and deletes the value for
dleIgnoredParams.
■ If both lxIgnoredParams and lxParamsToIgnore exist, the values are merged and
entered in lxParamsToIgnoreForCheck.
■ If both dleStopList and maskLayoutViewName exist, they are merged in
lxStopList.

The Virtuoso XL properties listed below are obsolete and are not converted to OpenAccess
2.2.
■ dleSchExtractPath
■ dlpRandomSeed
■ lxTimeStamp
■ posi

February 2018 52 Product Version IC6.1.7

Pins and Pin Connectivity

The translator converts the CDB pin subnet model to the OpenAccess pin group model.

CDB Pin Subnet Model

In CDB, subnet extensions are used to implement strong, weak, and must-join connectivity
pin groups. Subnet extensions are represented by a two-level subnet structure. Pins are
placed at the second level subnets and the connection of the pins is determined by their
relative locations in the structure.

root net

subnet1 subnet2

subnet3 subnet4 subnet5

pin1 pin2 pin3 pin4

fig1 fig2 fig3 fig4

In the picture above,

■ Figures attached to the same second-level subnet are considered to be strongly
connected; for example fig1 and fig2.
■ Figures attached to different second-level subnets which have the same parent subnet
are considered to be weakly connected; for example, fig1, fig2, and fig3.
■ Figures that are attached to different second-level subnets that do not have the same
parent subnet are must connect; for example, fig3 and fig4.
■ Figures that are attached to different root nets are not connected to each other.

February 2018 53 Product Version IC6.1.7

OpenAccess Pin Group Model

In OpenAccess, pin connectivity requirements are represented by
■ Multiple figures associated with a single pin object
■ The inclusion of the mustJoin attribute on terminals that must be connected

net1 net2 net3

term1 term2(mustJoin) term3(mustJoin) term4

pin1 pin2 pin3 pin4

fig1 fig2 fig3 fig4 fig5

In the picture above,

■ Figures on the same pin are strongly connected; for example, fig1 and fig2.
■ Figures on the same terminal but on different pins are weakly connected; for example,
fig2 and fig3.
■ Figures that are on terminals which have the mustJoin attribute set to each other must
be connected, even if the terminals are on different nets; for example, fig3 and fig4.
■ fig5 is not connected to any other figures because term4 does not have the mustJoin
attribute indicating that it connects to another terminal.

February 2018 54 Product Version IC6.1.7

Mapping Connectivity Status from CDB to OpenAccess

The translator removes all of the subnets from the pin model. If a subnet has a non-pin shape,
the shape is moved to the root net.

Strong Connect

CDB OpenAccess

term1 net1 net1 term1

subnet1
pin1

subnet2

fig1 fig2

pin1 pin2

fig1 fig2

Note: For each pin in each group, all meaningful information is moved to the figures. Pin
properties from CDB are recreated on the OpenAccess figures. The translator uses the same
name but prepends it with an underscore; if that name exists already, the translator prepends
another underscore.

February 2018 55 Product Version IC6.1.7

Weak Connect

CDB OpenAccess

term1 net1 net1 term1

subnet1
pin1 pin2

subnet2 subnet3
fig1 fig2

pin1 pin2

fig1 fig2

February 2018 56 Product Version IC6.1.7

Must Connect

The OpenAccess database will contain additional nets and terminals required to model must-
connect pins.

These nets and terminals are named mustConnect_num_originalName to make them

simple to identify. For example, if the original net is called net1, then any new nets created
during conversion are called mustConnect_0_net1, mustConnect_1_net1, and so on.

CDB OpenAccess

term1 net1 net1 term1(mustJoin)

pin1
subnet1 subnet2

subnet3 subnet4 fig1

pin1 pin2
net1_0 term1_0(mustJoin)

fig1 fig2

pin2

fig2

February 2018 57 Product Version IC6.1.7

Translation of Undefined Pin Models

When Pcells are created in CDB without an explicit pin model (i.e., without subnets), by
convention, the CDB application would interpret the connection status. In the case of VXL in
CDB, these pins would be considered strongly connected.

If the pin status is undefined, you can use the -mapundefinedpingroups option with the
cdb2oa command for maskLayout cellviews that do not have explicit pin model information.
The valid values for the -mapundefinedpingroups option include strong (default), weak
and must. Alternatively, you can use the Map undefined pin model to option on the
Database tab in the CDB to OpenAccess Translator form to select one of the pin model.
Using one of these methods allows the undefined CDB pins to be explicitly modeled as one
of strong, weak, or must connect on OpenAccess.

In turn, the cdb2oa translator adds the property defaultPinModel to all supermasters of
maskLayout cellviews in a library, which do not have explicit pin model information. The
defaultPinModel property is set to the same value as is specified for the option -
mapUndefinedPinGroups.

If the subnets do exist, the pin connection status is evaluated based on subnets.

Instance Pins
An instance pin (instPin) is a database object that represents a pin of a terminal in the
master of an instance.

Because they are not used in Virtuoso design environment applications, cdb2oa does not
create any instance pins in the OpenAccess version of the cellview. Instead, the translator
flattens the cellviews and translates the shapes of the pin master to the cellview.
Note: Instance terminals (instTerm) are translated correctly.

Paths with Extensions

In CDB, you can set any value for path extensions, irrespective of the path style. On
OpenAccess, you cannot set a value for a path extension unless the path style is variable.

When translating paths with extensions, if the path style is not variable, the translator resets
beginExt and endExt to 0.

For information on differences in paths with extensions in CDB and OpenAccess, see the
Virtuoso Design Environment Adoption Guide.

February 2018 58 Product Version IC6.1.7

Boundaries
In CDB, place and route boundaries are shapes which use the convention of layer-purpose
pairs (LPPs) to identify them as boundaries. Virtuoso XL uses the layer-purpose pair
(prboundary drawing), while Virtuoso Preview uses layer-purpose pair (prboundary
boundary). On OpenAccess, place and route boundaries are objects (prBoundary) that do
not use conventions to define their purpose.

The translator converts shapes on the CDB place and route boundary layer to an
OpenAccess prBoundary object.

If the CDB cellview is a Virtuoso Preview cellview (viewSubType = designPlanC3), the

translator converts the first shape it finds on layer-purpose pair (prBoundary boundary)
into the OpenAccess prBroundary object. For all other cellview types, the translator
converts the first shape it finds on layer-purpose pair (prBoundary drawing) into the
OpenAccess prBoundary object.

For more information, see the Virtuoso Design Environment Adoption Guide.

Additionally, if the CDB cellview contains a snap boundary, the translator converts it into an
oaSnapBoundary object. If the CDB cellview does not contain a snap boundary, the
translator creates the oaSnapBoundary using the bounding box of the PR boundary.

Rows
Rows represent the placeholders for site elements. In CDB, rows are identified as rectangles
on the layer purpose row drawing. Virtuoso Custom Placer (VCP) rows are also identified
as rectangles on the layer purpose row drawing and additionally have the property
lxVcpRowInfo attached to the shapes.

The translator converts the non-VCP row shapes in CDB to the OpenAccess oaRow objects.

The translator converts the VCP shape-based rows based on the following algorithm:
■ If the row comprises of only standard cells (component type class = stdcell) and the
row elements do not contain rail definitions (dbRailDef), the translator creates the
OpenAccess oaRow object.
■ If the row comprises of only standard cells and the row elements also contain rail
definitions, the translator creates a dbRow object.
■ If the row comprises of both standard and non-standard cells, the translator again
creates a dbRow object.

February 2018 59 Product Version IC6.1.7

■ For all other combinations of rows elements, the translator creates an

oaClusterBoundary object.

The siteDef creation for non-VCP rows is explained in the section Sites on page 36. For VCP
rows, siteDefs are created in the technology file corresponding to each cell with unique width
and height. While creating siteDefs, the following two scenarios are possible:

a. Snap boundary exists: The width and height of the siteDefs created are based on
the bounding box of the snap boundary.
Note: A design cannot contain more than one snap boundary.

b. Snap boundary does not exist: The width and height of the siteDefs created are
based on the bounding box of the PR boundary.
Note: The names of the siteDefs created include the cell width and height information. For
example, if the width and height of a cell are 10,000 and 20,000 DBUs, respectively, the
siteDef would be named cdsSiteDef_10000x20000.

February 2018 60 Product Version IC6.1.7

CDBOA SKILL Functions

You might need to update or correct any data in the data file before or after translation. There
is a method to specify pre or post processing scripts using the -processskillfile
(<skill file name>) function. The SKILL file name includes the definitions of either or
both cdboaPreTrans(libId) and cdboaPostTrans(libId) functions.
■ The cdboaPreTrans(libId) function provides you the utility to run the script to avoid
manual work. It can only print the message that is explicitly given by using the printf()
function and to do that it is required to set the CMD_DBG environment variable to true.
Note: The pre-trigger is limited to accessing ddIds. DB APIs cannot be used in this
trigger. Therefore, opening CDB data in memory and modifying CDB data is not possible.
■ The cdboaPostTrans(libId) function enables you to update the OA data after the
translation. It works on on-disk data and DB APIs can be used in this trigger.
Note: Data type of both libIds is ddId.

February 2018 61 Product Version IC6.1.7

February 2018 62 Product Version IC6.1.7

3
Using the CDB to OpenAccess Translator
from the Command Line

This chapter lists the arguments and switches you can use with the cdb2oa UNIX command
and describes how to use these to accomplish the most common translation tasks.

Tip
You can also use the translator’s GUI, which provides additional support for
converting multiple libraries in a single run, including a function to determine
interdependencies between libraries and establish the sequence in which they need
to be converted. For more information, see Chapter 4, “Using the CDB to
OpenAccess Translator GUI.”

Before You Start with CDB to OpenAccess Translation

The translator issues error messages to report conditions that it cannot resolve. Some of
these messages report errors in connection with the way your data is structured or managed.
To limit the number of these types of errors, use the list below to validate your CDB data
before you start using the translator.
■ Check how to deal with objects and technology data constructs that are not
supported in OpenAccess
For information on how to handle the differences between the databases, see the
Virtuoso Design Environment Adoption Guide.
■ Ensure that all the required technology and reference information is available
in OpenAccess at the time it is referenced
This includes technology information, attached technology libraries, parameterized cell
masters, simulation data, rule decks, scripts, and SKILL code referenced by objects in
the library you are translating. If you can identify the information required, do so and
ensure that it is converted before the rest of the library.

February 2018 63 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

■ Ensure that you are able to read the data and that it is not locked
The translator does not translate data that is locked, unless you use the -ignorelocks
argument. Check that no one else is editing the library and if there are stale file locks
present, remove them.
■ Ensure that there are no invalid view types
The translator maps each of the CDB view types to one of the four OpenAccess view
types. A cellview generated in a release prior to IC 4.4.6 may have an invalid CDB view
type, which the translator is unable to handle. Use the approved migration process to
bring the cellview in question into IC 4.4.6 before running the translator.
■ Ensure that all libraries, cells, cellviews, and cellview components have legal
CDB names
The translator cannot translate objects that have illegal names in CDB. For information
on the CDB name space, see “Name Spaces” on page 26.
■ Check for instance terminals with the same names but on different nets
In releases prior to IC 4.4.6, CDB allows instances to have terminals with the same name
as long as these are attached to different nets. OpenAccess does not. You need to
correct the terminal names in CDB before translating these cellviews, either by editing
the cellviews manually or by regenerating them using the latest version of CDB.

February 2018 64 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Syntax
cdb2oa
-lib t_libName
-cdslibpath t_libPath
[ -oalibpath t_oalibPath ]
[ -cell t_cellName... ]
[ -view t_viewName... ]
[ -viewtype t_type... ]
[ -topdown -cell t_cellName -view t_viewName ]
[ -printonly ]
[ -nooverwrite ]
[ -ignorelocks ]
[ -abspath ]
[ -layermapfile t_fileName ]
[ -iccrulesfile t_fileName ]
[ -mapundefinedpingroups { strong | weak | must } ]
[ -iccconstraintgroup t_name ]
[ -iccrulesmapfile t_name ]
[ -createpathseg ]
[ -nodropinvalidCV ]
[ -keepdevicemasters ]
[ -retainsympins ]
[ -retainsympins ]
[ -convertnonmaskablesympins <rect | dot | ignore> ]
[ -disablecmxuprev ]
[ -resetplacestatus { all | unplaced } ]
[ -skipdir t_list_of_dirNames... ]
[ -viamap t_fileName ]
[ -mapviaparams ]
[ -log t_fileName ]
[ -appendlog ]
[ -report ]
[ (IC6.1.6 only) -tbrule t_fileName ]
[ -prrulelib t_libName]
[ -prrulelibpath t_prruleLibPath ]
[ -force ]
[ -detectvias]
[ -nodm ]
[-storedefaultspolicy <usepcellvalue | usecdfvalue>]
[-parampolicy <abortontypedifference | abortondefaultvaluedifference |
abortonboth>]
[ -loadskillfile]
[ -processskillfile <skillFileName>]
[ -scalelabelsize <scale factor>]
[ -keepcdbinstparams]
[ -mapcdsviatocustviadef]
[ -exitifcdbtechnotexists]

February 2018 65 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

[ -pathtopolygon]
[ -convertspecialchar]
[ -help ]

-lib t_libName
Specifies the name of the CDB library to be translated. Specify
the name in the CDB name space.
This will also be the name of the OpenAccess version of the
library. You cannot use the translator to rename a library. If you
need your library to have a different name in OpenAccess,
rename the CDB version before translating it.
-cdslibpath t_libPath
Specifies the path to the CDB library definitions file that defines
the library to be translated.
The translator accepts any file that uses standard Cadence
cds.lib file syntax and supports the use of the INCLUDE
keyword in these files.
If you do not specify a filename, the translator defaults to
cds.lib.
-oalibpath t_oalibPath
Specifies the directory in which the OpenAccess library is
created. By default, the translator creates the library in the
current directory.
You can enter either a relative or an absolute path. The
directory you specify must exist on your system; the translator
does not create it automatically. If the library is already defined
in the OpenAccess cds.lib file using a different path, the
translator comments out the original definition and redefines
the library using the path you specified.
Note: The translator always creates or updates the
OpenAccess cds.lib file in the current directory irrespective
of any -oalibpath specification.
-cell t_cellName...

February 2018 66 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Specifies the names of the cells to be translated. Specify the

names in the CDB name space.
The translator converts only cells with one of the specified
names. To convert an individual cellview, specify both -cell
and -view.
-view t_viewName...
Specifies the view names to be translated. Specify the name in
the CDB name space.
The translator converts only views with one of the specified
names. To convert an individual cellview, specify both -cell
and -view.
-viewtype t_type...
Specifies the view types to be converted from the CDB library.
Only cellviews that map to one of the specified view types are
translated.
To translate more than one view type, they need to be
separated by a space. For example, you can use cdb2oa –
lib <libraryName> -cdslibpath <path to
cds.lib> -viewtype maskLayout schematic to
translate both maskLayout and schematic view types. If -
viewtype others is used, then translation will happen for
the following:
■ all non-database cellviews
■ all database cellviews that are not among the defined view
types
Note: The view type is distinct from the view name used to
describe the view directory in the library file system. Each view
name is mapped to its corresponding view type in the Cadence
data registry. For more information on the data registry, see the
Cadence Application Infrastructure User Guide.
-topdown -cell t_cellName -view t_viewName

February 2018 67 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Converts all of the cellviews referenced by a single top

cellview.
Use the -cell and -view arguments to specify the top
cellview. To ensure that the OpenAccess version contains all
the required information, the translator converts the specified
top cellview and all of the cellviews present for each of the cell
masters referenced by the top cellview.
-printonly
Reports what would be translated as a result of the cdb2oa
command line, but performs no translation.
The information printed to the log file relates only to content of
the library in question. The -printonly argument cannot
identify interdependencies with other libraries.
-nooverwrite
Prevents the translator from overwriting existing OpenAccess
library data. Instead, it writes only data that does not already
exist in the OpenAccess library. By default, the translator
overwrites any existing data in the OpenAccess library.
-ignorelocks
Ignores any edit locks on the CDB data. By default, when a
CDB cellview is locked, it is not translated.
Note: This argument has no effect on edit locks in the
destination library, which the translator always honors.

February 2018 68 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

-abspath
Specifies that the absolute path to the translated library is to be
written to the cds.lib file. By default the relative path to the
library is written to these files, unless you specify an absolute
path with -oalibpath.
You might use this argument if your database includes multiple
reference libraries that are not all contained in the same
directory.
Note: Using absolute paths in the library definitions files can
lead to problems if you access the data across different
networks or on different hardware platforms. It can also
adversely affect the performance of your applications on
OpenAccess.

Additionally, if you use cdb2oa to translate a particular library

twice and specify the -abspath argument for only one of the
conversions, the resulting library definitions files contain two
different DEFINE statements for the same library. It is advisable
to check these files regularly to ensure that the data they
contain is consistent.
-layermapfile t_fileName
Specifies a name for the layer mapping file, which contains the
stream translation rules removed from the technology file.
By default the file is named libName.layermap. It is placed
in the same directory as the technology file from which it is
derived.
For information on how the translator handles stream
translation rules, see “Stream Translation Rules” on page 32.
-iccrulesfile t_fileName
Specifies the paths to ASCII files containing ICC rules. If you
specify a rules file, only that file is processed and any ICC
rules in the technology file are ignored.
The rules are mapped to the virtuosoDefaultSetup
constraint group in the OpenAccess technology file unless you
specify a different constraint group by using the
-iccconstraintgroup argument.

February 2018 69 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

-mapundefinedpingroups { strong | weak | must }

Maps the pin groups that do not use subnet extensions
(“undefined pin groups”) to one of the specified OpenAccess
pin groups. The default value is strong.
Note: This option is applicable to all cellviews with the view
type maskLayout in a library.
-iccconstraintgroup t_name
Specifies the OpenAccess constraint group into which ICC
rules are mapped. The translator picks up these rules from the
CDB technology file or from a separate ASCII file specified
using the -iccrulesfile argument.
By default the rules are stored in the
virtuosoDefaultSetup constraint group.
-iccrulesmapfile t_name
Specifies the path of the ASCII map file that maps ICC rules
files to constraint group names. The ASCII map file contains
several entries in the format “<ICC rules file path>
<constraint group name>”, with each entry on a
separate line. Do not use this argument along with either -
icculesfile or -iccconstraintgroup; if used, the
translator will not proceed.
Note: An entry in the map file will be ignored if it matches any
of the following:
■ Either ICC rules file path or constraint
group name is missing.
■ ICC rules file path and constraint group
name are not specified in the correct order.
■ The ICC rules file does not exist, is empty or is a
directory.
The ICC rules file path accepts only the complete
path of the ICC rules file.

Any issues encountered by the translator when the -

iccrulesmapfile argument is used are stored in the
iccrulesmapfile.errors file in the run directory.
-createpathseg

February 2018 70 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Converts orthogonal CDB two-point paths to OpenAccess

pathSeg objects.
By default, CDB paths are converted to OpenAccess paths.
However, CDB shapes with the property shapeProp or
shield are converted to pathSeg objects.
Note: Paths are not converted to pathSeg objects if any of the
following is true:
■ Shapes are relative-object design (ROD) objects.
■ Width is zero.
■ The value of the pathStyle property is equal to the value
of the oacRoundPathStyle property.
-nodropinvalidCV Retains invalid cellview directories and their contents. The
cellview directory or the database file specified might be empty
or contain invalid data.
-keepdevicemasters
Creates OpenAccess cellview representations of CDB
technology device masters such as syContact, syPin,
syRectPin, and cdsVia devices.
By default, syContact devices are mapped to
standardViaDef devices, syPin and syRectPin devices
are mapped to pin figures, and the device cellviews are
removed from the technology file.
Use this argument to ensure that Pcells instantiating these
devices continue to evaluate correctly after conversion.
Note: The -keepdevicemasters argument is provided for
compatibility purposes only. Although the device masters are
translated, they are not recognized by the system as via
objects; you cannot update or recreate the device masters in
OpenAccess, and a query to the technology file does not return
any symbolic device information. Use the argument as a
temporary solution if you have SKILL Pcells that instantiate
syContact, syPin, syRectPin, or cdsVia devices.

February 2018 71 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

-retainsympins Disables the flattening of symbolic pins.

Note: The translator supports this argument only when the
argument -keepdevicemasters is used. This is because the
-retainsympins argument will supress the flattening of
syPins and syRectPins only when the masters are
available.
-convertnonmaskabl Specifies cdb2oa translator to convert non-maskable symbolic
esympins <rect | pins to rect pins or dot pins or ignore.
dot | ignore>
-disablecphuprev Disables automatic CPH legacy data uprev.
The data in CDB is cell level component type. After cphUpRev,
the translated data stores old component type data in the LAM
file.
-disablecmxuprev Disables the migration of cmx constraints to different data
model required for IC 6.1.X.
-resetplacestatus { all | unplaced }
Resets the placement status of instances to “none”. Specify
“all” to reset all instances, or “unplaced” to reset only
instances with placement status “unplaced”. OpenAccess
does not display instances with placement status “unplaced”.
-skipdir t_list_of_dirNames...
Specifies a list of directory names to be skipped by the
translator. A directory with one of the specified names is not
translated.
-viamap t_fileName
Specifies a file listing the CDB via cellview masters to be
converted to oaCustomViaDefs in OpenAccess. The
translator adds the oaCustomViaDef definition to the
OpenAccess technology library and converts instances of the
via cellview to OpenAccess customVias referencing the new
definition.
Note: You must have permission to write to the OpenAccess
technology file to use this argument.

February 2018 72 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

-mapviaparams
For symbolic devices and cdsVia instances, use parameter
default values from CDB instance masters instead from OA
stdViaDef parameters list.
-log t_fileName
Logs the translation in the specified file.
If you do not specify -log, the translator searches the
CDS_LOG_PATH environment variable for a suitable location for
the file.
If neither -log nor CDS_LOG_PATH yields a valid, writable
location, the translator records the session in $HOME/
cdb2oa.log.
-appendlog
Appends a record of the current translation to an existing log
file. You must use the -log argument to specify the log file to
which you want to append.
-report
Prints additional information to the log file and standard error
output indicating the progress of the translation.
(IC6.1.6 only) -tbrule t_fileName
(IC6.1.6 only) Specifies the name of the source Toolbox rule
file to be translated.
-prrulelib t_libName

February 2018 73 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Depending on whether the library specified with the lib option

is a technology or a design library, the prruleLib option does
one of the following:
■ Splits the technology library into the base technology
library and a prRules library (t_libName).
■ Attaches the design library to the prRules library
(t_libName). This can happen only if the technology
library, to which the design library is attached, has been
split to create the prRules library.
Note: If a design library has its own technology library and
the technology library has been split, the translated design
library cannot access the prRules information because the
prRules information gets compiled into a separate library.
Therefore, if you want the design library to retain access to
the prRules information, do not use the prruleLib option.
Consider a technology library that has been split. The following
scenarios are possible when a design library, which is attached
to this technology library, is translated:
Case 1: Translating the Design without using the
prruleLib Option
The translated design library is attached to the base
technology library. The prRules information, which is compiled
into a separate prRules library, is lost.
Case 2: Translating the Design using the prruleLib
Option
This scenario has two sub-parts.
2A: The specified prRule library is correct.

The translated design library is attached to the prRules

library, which in turn, has reference to the original
technology library from which it was split.
2B: The specified prRule library is incorrect.

If the base technology reference of the specified prRules

library does not match the base technology library of the
design library being translated, the translator exits.
-prrulelibpath t_prruleLibPath

February 2018 74 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Specifies the directory for creating prRules library. By default,

the cds.lib file is always updated or created in the current
directory. If you do not specify -prrulelibpath, the library is
created into the current directory.
-force
Forces the specified design library to attach to the specified
prRules library.
-detectvias
Enables the translator to automatically detect standard and
custom vias in the CDB design and create the corresponding
viaDefs in the OpenAccess technology database. Do not use
this argument along with the -viamap argument.
Note: You must have the permission to write to the
OpenAccess technology file to use this argument.
-nodm
Ignores the DM settings. The cdboa translation using the
-nodm option ignores all DM related files and directories, and
translates the data to OA without DM information. Therefore,
all cellviews whether checked in or not can be edited after
translation to OA and all .SYNC directories are ignored. If you
try to translate a library that has cellviews checked into a DM
system, such as DesignSync, then the -nodm option is
necessary or else the cdboa translator will crash.
Note: In DesignSync, you can access the checked-in (read-
only) data via symbolic links to a cache area. This will save the
disk space. If the cache method is used to access the data, all
the cellviews in the cdb workspace library directories are
symbolic links to the cache area as well as to some files such
as cdsinfo.tag. When the cached data is translated with the
-nodm option, all the symbolic links are resolved and all the files
and cellviews are translated correctly instead of copies of
symbolic links. Also, all .SYNC directories are ignored during
translation. However, if the target cdsInfo.tgf file has entry for
DMTYPE not equal to none, then this file could not be
overwritten.
-storedefaultspolicy <usepcellvalue | usecdfvalue>

February 2018 75 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Specifies whether cdb2oa translator to consider CDF

parameter or Pcell superMaster parameter while creating a
parameter on the OA instance. If you do not specify the option
Pcell superMaster parameter is considered.
-parampolicy <abortontypedifference |
abortondefaultvaluedifference | abortonboth>
Specifies cdb2oa translator to abort when a mismatch of
parameter types and default values occur between CDF
parameter and Pcell superMaster parameter. By default,
appropriate warning will be displayed and translation would
continue if there is a mismatch in type or default values.
-loadskillfile
Specifies the top level skill file containing user defined skill
routines, which user wants to load during the translation.
-processskillfile
<skillFileName>
Specifies the SKILL file containing SKILL functions
cdboaPreTrans() and cdboaPostTrans(), which user
wants to load during the translation.
-scalelabelsize <scale factor>
Multiplies <scale factor> with the all textLabel’s size.
Note: There is no corresponding UI option impleted for this
command line option in this release.
-keepcdbinstparams
Retains CDB param defaults on instances.
-mapcdsviatocustviadef
Maps cdsVia with non-drawing purpose to customViaDef
instead of stdViaDef.
-exitifcdbtechnotexists
Specifies the cdb2oa translator to abort if CDB technology
library is not defined in the CDB library definitions file.
-pathtopolygon

February 2018 76 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Specifies cdb2oa translator to translate CDB path to

OpenAccess polygon. Only the path with a segment less than
half the width of the path will be converted.
-convertspecialchar
Specifies cdb2oa translator to convert all special characters
except '$' and '?' for instances and mosaics to '_'.
-help
Prints the online help text. The translator displays the same
information if you enter cdb2oa without specifying any
arguments.

UNIX Environment Variables in cdboa

CDBOA supports the following UNIX environment variables:
■ RETAIN_CDB_SLINK - this UNIX environment variable is used to retain relative path
links in cdboa. This environment variable allows cdboa to retain the symbolic links as
they were in CDB. However, it is your responsibility to ensure that same relative links are
also valid for OA library.
By default cdb2oa finds the path for all the CDB links and creates links to these paths in
OA library. Therefore, if cdb library has myFile->../../myFile, then by default he
translated OA library will have myFile-><path_of_cds_lib>/../../myFile.
However, if the RETAIN_CDB_SLINK environment variable is set and the cdb library has
myFile->../../myFile, then the translated OA library will also have myFile->../
../myFile.
■ CHECK_SKILL - To know about this environment variable, refer to section
Parameterized Cellviews.
■ CDBOA_IGNORE_ALL_ASSIGN - this environment variable is used to ignore all
ASSIGN statements in the OpenAccess cds.lib file. If this environment variable is set
then cdb2oa will ignore all attributes set using ASSIGN statements in the cds.lib file.
■ DONT_PRESERVE_FILE_ATT - in case of files copied from CDB to OA database
without translation, if this environment variable is set, cdb2oa will not try to preserve file
attributes.

February 2018 77 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Converting a Library
Note: The examples in this chapter use simple library structures to illustrate the use model
of the translator. The pictures do not show all the files typically found in a CDB library, only
those required to illustrate the point being described have been depicted.

This example uses a CDB library called design containing a number of different cells.

user
cdb
cds.lib
design
cell_1
cell_2
cell_3
...

The cds.lib file defines design as follows:

DEFINE design design

Note: cdb2oa will ignore all ASSIGN statements found in the CDB cds.lib file.

Converting into the Current Directory

To translate library design into the current directory, perform the following steps:
1. In a shell window, create a directory to contain the OpenAccess library.
2. Go to the directory you have just created.

user
cdb
cds.lib
design
cell_1
cell_2
cell_3
...
oa Start the translator in this directory

February 2018 78 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

3. Run the translator in the new directory.

cdb2oa -lib design -cdslibpath ../cdb/

The translator does the following:

❑ Looks in the specified cds.lib file for the path to the CDB library
❑ Creates the OpenAccess cds.lib file in the current directory
❑ Creates the library directory design
❑ Translates the CDB version of the library to OpenAccess and writes the data to the
directory /user/oa/design

The OpenAccess cds.lib file define the library as follows:

DEFINE design design

February 2018 79 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Converting into a Specified Directory

When converting large databases containing many interdependent libraries, the default
behavior of translating the library into the current directory might be restrictive. Use the
-oalibpath argument to direct the OpenAccess version of the library to another location.

For more information on -oalibpath, see “Syntax” on page 65.

Important
Regardless of any -oalibpath specification, the translator always creates or
updates the cds.lib file in the run directory. To ensure that the correct files are
updated and that access to the OpenAccess version of the library is correctly
maintained, Cadence recommends that you always run the translator from the top-
level of the OpenAccess library.

To translate the design library into a specified directory, follow these steps:
1. In a shell window, create a new directory for the OpenAccess version of the library.

user
cdb
cds.lib
design
cell_1
cell_2
cell_3
...
oa Start the translator in this directory

oaNew

design OpenAccess library to be placed in this directory

2. Run the translator in the oa directory.

cdb2oa -lib design -cdslibpath ../cdb/ -oalibpath ../oaNew/design/

The translator does the following:

❑ Looks in the specified cds.lib file for the path to the CDB library
❑ Creates or updates the OpenAccess cds.lib file in the current directory

February 2018 80 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

❑ Translates the library to OpenAccess, writing the data in the /user/oaNew/

design directory.

user
cdb
cds.lib
design
cell_1
cell_2
cell_3
...

oa
cds.lib OpenAccess library definitions files
updated in the current directory

oaNew

design
cell_1 Cellviews translated into the new directory
cell_2
cell_3
...

The OpenAccess cds.lib file define the library as follows:

DEFINE design ../oaNew/design

February 2018 81 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Converting a Cellview
You can use cdb2oa to do the following:
■ Converting a Single Cellview
■ Converting a Hierarchical Cellview within a Single Library
■ Converting a Hierarchical Cellview over Multiple Libraries

Converting a Single Cellview

To translate a specific cellview to OpenAccess, use the -cell and -view arguments on the
command line. For example,
cdb2oa -lib design -cdslibpath ../cdb/ -cell cell_1 -view layout

The translator converts only the layout view for cell_1, ignoring any other views present for
cell_1 and any other cellviews referenced by it.

Converting a Hierarchical Cellview within a Single Library

To produce a complete OpenAccess version of a cellview without translating the entire library,
use the -topdown argument with -cell and -view.

February 2018 82 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

For example, in the sample library, the top_cell layout view references the cell_2 and
cell_3 layouts. All three cells have layout and symbolic views.

user
cdb
cds.lib
design
top_cell
layout
layout.cdb
symbolic
layout.cdb
cell_2
layout
layout.cdb
symbolic
layout.cdb
cell_3
layout
layout.cdb
symbolic
layout.cdb

To convert the hierarchical cellview top_cell, perform the following steps:

1. In a shell window, create a directory to contain the OpenAccess version of the cell.

user
cdb
oa Start the translator in this directory
design

2. Go to the oa directory and run the translator with the -cell, -view, and -topdown
arguments.

February 2018 83 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

cdb2oa -lib design -cdslibpath ../cdb/ -topdown -cell top_cell -view layout

The translator converts the layout view for top_cell and all of the cellviews present for
cell_2 and cell_3.

Converting a Hierarchical Cellview over Multiple Libraries

You can use the translator’s GUI to convert a hierarchical cellview which references cellviews
contained in different libraries.
■ For information on how to do this, see “Converting an Hierarchical Cellview over Multiple
Libraries” on page 103.
■ For general information on how to use the GUI, see Chapter 4, “Using the CDB to
OpenAccess Translator GUI.”

February 2018 84 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Converting Multiple Libraries

Tip
Cadence recommends that you use the GUI to complete this task. The GUI provides
support for converting multiple libraries in a single run, including a function to
determine interdependencies between libraries and establish the correct sequence
for conversion. For more information, see Chapter 4, “Using the CDB to
OpenAccess Translator GUI.”

When using the translator from the command line, you can translate only one library at a time.
To translate multiple libraries, you must run the translator separately on each library in turn.

For example, if your design library references information in libraries, deviceLib1,

deviceLib2, refLib1, and refLib2, the library structure might look like this.

user
cdb
cds.lib
design
devices
deviceLib1
deviceLib2

reflibs

refLib1
refLib2

To translate this database, you need to do the following:

1. Set up the file system structure for the OpenAccess version of the library.
2. Determine the correct sequence of translation.
3. Run cdb2oa once for each of the libraries in the database.

February 2018 85 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Setting up the Structure for the OpenAccess Version of the Library

When translating multiple libraries, Cadence recommends that you set up the directory
structure for the OpenAccess version of the database before you start and then use the
-oalibpath argument to direct the translated libraries to the correct location.

This approach is recommended for two reasons:

1. The process of methodically determining where each library will go is important in
tracking the progress and success of the migration effort.
2. Setting up the directory structure involves not only setting up library directories, but also
other files and directories for storing simulation data, rule decks, SKILL files, scripts, and
design management metadata.
These files and directories introduce many dependencies that must be accounted for
prior to conversion; for example, it is particularly important to locate SKILL files correctly
so that they are available for use by the libInit.il and .cdsinit files.

Important
Regardless of any path specified using -oalibpath, the translator always creates
or updates the cds.lib file in the current working directory.

To set up the directory structure for the OpenAccess libraries,

February 2018 86 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

➤ In a shell window, create a top-level directory to contain the OpenAccess version of the
cds.lib file and a subdirectory for each of the libraries to be translated.

user

cdb
oa Start the translator in this directory
design
devices
deviceLib1
deviceLib2

reflibs

refLib1
refLib2

Determining the Sequence of Translation

You must translate the individual libraries in the correct sequence so that definitions from the
reference libraries are available in OpenAccess at the time they are referenced.

Important
When used from the command line, the translator is unable to determine this
sequence automatically. You must do it manually and run the translator separately
on each of the libraries in turn. The GUI provides a function to do this for you.

To determine the correct sequence of translation, do the following:

1. Identify the top cellview in your design and open it in your Virtuoso design environment.
2. In the layout window, press Shift-f to display all the levels in the design.
3. In the layout window menu bar, choose Design – Hierarchy – Tree. The Tree dialog
box appears.
4. Select Current to bottom and click OK. The layout editor opens a Tree window showing
the entire hierarchy of instances inside the current cellview.

February 2018 87 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

Design Hierarchy
****************************************************************************
Library : design
Cell : top_cell
View : layout
Option : Current to bottom
****************************************************************************

refLib1 cell_1 layout (5)

deviceLib1 cell_6 layout (10)
refLib1 cell_2 layout (1)
refLib1 cell_3 layout (2)
deviceLib2 cell_1 layout (1)
refLib1 cell_4 layout (2)
refLib2 cell_1 layout (1)
.
.
.
(truncated)

The indentation shows the hierarchical relationships between the listed cellviews. The
numbers in parentheses tell you how many instances of each cellview are present. For
example, design top_cell contains 5 instances of cellview refLib1 cell_1, 1
instance of refLib1 cell_2, and so on.
5. Translate the libraries one at a time, working from the lowest level library up to the top
cellview.
cdb2oa -cdslibpath ../cdb/ -lib refLib2 -oalibpath reflibs/refLib2
cdb2oa -cdslibpath ../cdb/ -lib deviceLib2 -oalibpath devices/deviceLib2
cdb2oa -cdslibpath ../cdb/ -lib deviceLib1 -oalibpath devices/deviceLib1
cdb2oa -cdslibpath ../cdb/ -lib refLib1 -oalibpath reflibs/refLib1
cdb2oa -cdslibpath ../cdb/ -lib design -oalibpath design

Resolving Circular Dependencies

A circular dependency occurs when a cellview contains an instance of a cellview from another
library which itself contains an instance of a cellview from the first library.

To resolve this situation, work from the lowest level in the hierarchy back up to the top cellview,
translating individual cellviews as required so that the dependencies are satisfied.

February 2018 88 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

For example,

refLib1/cell_4/layout

refLib2/cell_1/layout

refLib1/cell_6/layout

The layout editor’s Tree window shows the relationships like this.

Design Hierarchy
****************************************************************************
Library : design
Cell : top_cell
View : layout
Option : Current to bottom

****************************************************************************
.
.
.
refLib1 cell_4 layout (1)
refLib2 cell_1 layout (1)
refLib1 cell_6 layout (2)
.
(truncated)

To resolve the dependency shown, perform the following steps:

1. Use the -cell and -view arguments to translate only cellview refLib1/cell_6/
layout.
cdb2oa -lib refLib1 -cdslibpath ../cdb/ -oalibpath ./reflibs/refLib1 -cell
cell_6 -view layout

2. Translate library refLib2.

cdb2oa -lib refLib2 -cdslibpath ../cdb/ -oalibpath .reflibs//refLib2

3. Translate the rest of library refLib1, using the -nooverwrite option to prevent
cell_6 layout from being translated again.
cdb2oa -lib refLib1 -cdslibpath ../cdb/ -oalibpath ./reflibs/refLib1 -
nooverwrite

February 2018 89 Product Version IC6.1.7

© 2003-2018 All Rights Reserved.
CDB to OpenAccess Translator User Guide
Using the CDB to OpenAccess Translator from the Command Line

February 2018 90 Product Version IC6.1.7

4
Using the CDB to OpenAccess Translator
GUI

This chapter describes how to use the CDB to OpenAccess Translator GUI.

Getting Started
■ Choosing a Run Directory
■ Starting the Translator
■ Running the Translator

Converting a Library
■ Converting into the Current Directory
■ Converting into a Specified Directory

Converting a Cellview
■ Converting a Single Cellview
■ Converting an Hierarchical Cellview within a Single Library
■ Converting an Hierarchical Cellview over Multiple Libraries

Converting Multiple Libraries

■ Setting up the Structure for the OpenAccess Version of the Library
■ Converting Multiple Libraries
■ Resolving Circular Dependencies

Customizing the Translation Environment

■ Copying the cdb2oa .cdsenv File
■ Editing the cdb2oa .cdsenv File

February 2018 91 Product Version IC6.1.7

Getting Started
This section tells you how to start the GUI and outlines what happens after you start the
conversion. The examples in this chapter use simple library structures to illustrate the use
model of the translator.
Note: The figures in this chapter do not show all the files typically found in a CDB library; only
those required to illustrate the point being described have been depicted.

For more information about the translator forms, see Appendix A, “CDB to OpenAccess
Translator Form Descriptions”. The translator issues error messages to report conditions that
it cannot resolve. For information on how to limit the number of these errors, see “Before You
Start with CDB to OpenAccess Translation” on page 63.

Choosing a Run Directory

The translator always creates or updates the cds.lib file in the run directory. To ensure that
the correct files are updated and that access to the OpenAccess version of the library is
correctly maintained, run the translator from the top-level of the OpenAccess library.

If the library being converted is already defined in the OpenAccess cds.lib file using a
different path, the translator comments out the original definition and redefines the library
using the path you specified.

Starting the Translator

You can follow these steps to start the GUI:
1. Start the Virtuoso design environment by typing virtuoso in a shell window.
2. From the CIW menu bar, choose Tools – Conversion Tool Box.
3. In the Conversion Tool Box window, click CDB to OpenAccess Translator.

Important
The CDB to OpenAccess Translator form will not be displayed if any cellview is open
either in the read or edit mode. However, if you want to open the form, close the
already opened cellviews. Also, you can use the command line to execute the
translation.

February 2018 92 Product Version IC6.1.7

Running the Translator

After you have set the options you need, click OK on the CDB to OpenAccess Translator
form to run the conversion. The translator creates and executes a script called
run_cdb2oa.csh in the run directory. The script contains one cdb2oa command for each
library you want to convert. For example,
cdb2oa -cdslibpath ../cdb/ -lib design -log ./cdb2oa.gui.log -appendlog -
mapundefinedpingroups strong

February 2018 93 Product Version IC6.1.7

Converting a Library
This section describes the following:
■ Converting into the Current Directory
■ Converting into a Specified Directory

The example in this section uses a CDB library called design containing a number of
different cells.

user
cdb
cds.lib
design
cell_1
cell_2
cell_3
...

The cds.lib file defines design as follows:

DEFINE design ./design

Converting into the Current Directory

You can follow these steps to translate the library design into the current directory:

February 2018 94 Product Version IC6.1.7

1. In a shell window, go to the top-level directory of the OpenAccess version of the library.
If you are translating the library for the first time, create a new directory, say oa, and go
to that.

user
cdb
cds.lib
design
cell_1
cell_2
cell_3
...
oa Start the translator in this directory

2. Start the translator in the oa directory as described in Starting the Translator section. The
CDB to OpenAccess Translator form appears.
3. Type the path to the cds.lib file in the Path to cds.lib file field. The translator lists the
design library in the Libraries to convert pane. You can also specify the path to the
cds.lib file using the Browse button.
4. Click OK to convert the library. The translator creates and executes a script called
run_cdb2oa.csh in the current directory. This file contains the cdb2oa command to
convert the library in question.
cdb2oa -cdslibpath ../cdb/ -lib design -log ./cdb2oa.gui.log -appendlog -
mapundefinedpingroups strong

This command does the following:

❑ Looks in the specified cds.lib file for the path to the CDB library
❑ Creates the OpenAccess cds.lib file in the current directory
❑ Creates the library directory, design, in the current directory
❑ Translates the CDB version of the library to OpenAccess and writes the data to the
oa/design directory.

February 2018 95 Product Version IC6.1.7

The OpenAccess cds.lib file define the library as follows:

DEFINE design design

Converting into a Specified Directory

When converting large databases containing many interdependent libraries, the default
behavior of translating the library into the current directory might be restrictive. Use the
OpenAccess library path field in the Library specific options form (General tab) to direct
the OpenAccess version of the library to another location.

Tip
This section describes how to do this for a single library. For information on
translating multiple libraries, see “Converting Multiple Libraries” on page 105.

February 2018 96 Product Version IC6.1.7

To translate library design into a specified directory, follow these steps:

1. In a shell window, go to the top-level directory of the OpenAccess version of the library.
If you are translating the library for the first time, create a new directory and go to that.

user
cdb
cds.lib
design
cell_1
cell_2
cell_3
...
oa Start the translator in this directory

oaNew

design OpenAccess library to be placed in this directory

2. Start the translator in the oa directory as described in “Starting the Translator” on

page 92. The CDB to OpenAccess Translator form appears.
3. Type the path to the cds.lib file in the Path to cds.lib file field. The translator lists the
design library in the Libraries to convert pane.
4. In the Libraries to convert pane, select the design library and click the Set library
options button. The Library specific options form appears.
5. In the OpenAccess library path field on the General tab, type the location for the
OpenAccess version of the library. For example,
../oaNew/design

6. Click OK to return to the CDB to OpenAccess Translator form and then click OK again
to convert the cellview. The translator creates and executes a script called

February 2018 97 Product Version IC6.1.7

run_cdb2oa.csh in the current directory. This file contains the cdb2oa command to
convert the library in question.
cdb2oa -cdslibpath ../cdb/ -lib design -oalibpath ../oaNew/design -log ./
cdb2oa.gui.log -appendlog -mapundefinedpingroups strong

This command does the following:

❑ Looks in the specified cds.lib file for the path to the CDB library
❑ Creates or updates the OpenAccess cds.lib file in the current directory
❑ Converts the library into the oaNew/design directory.

The OpenAccess cds.lib file define the library as follows:

DEFINE design ../oaNew/design

February 2018 98 Product Version IC6.1.7

Converting a Cellview
You can use the CDB to OpenAccess translator to do the following:
■ Converting a Single Cellview
■ Converting an Hierarchical Cellview within a Single Library
■ Converting an Hierarchical Cellview over Multiple Libraries

Converting a Single Cellview

To translate a specific cellview to OpenAccess, you can perform the following steps:
1. In a shell window, go to the top-level directory of the OpenAccess version of the library.
If you are translating the library for the first time, create a new directory and go to that.
2. Start the translator as described in “Starting the Translator” on page 92.
3. Type the path to the cds.lib file in the Path to cds.lib file field. The translator lists the
design library in the Libraries to convert pane.
4. Select the design library and click Set library options. The Library specific options
form appears.
5. Click the Conversion tab and enter the names of the cell and view you want to convert
in the Cells and Views fields.
6. Click OK to return to the CDB to OpenAccess Translator form and then click OK again
to convert the cellview. The translator creates and executes a script called
run_cdb2oa.csh in the current directory. This file contains the cdb2oa command to
convert the specified cellview. For example,
cdb2oa -lib design -cdslibpath ../cdb/ -cell cell_1 -view layout

The translator converts only the layout view for cell_1, ignoring any other views present
for cell_1 and any other cellviews referenced by it.

To convert multiple selected cellviews, specify the names of the cells and views in the fields
provided. Separate names with a space. For example,

Cell names View names Translates...

cell_1 layout ...a single cellview
cell_1 ...all the views for cell_1

February 2018 99 Product Version IC6.1.7

Cell names View names Translates...

layout ...the layout views for all the cells in the
library
cell_1 cell_2 layout symbolic ...the layout and symbolic views for the
specified cells

Converting an Hierarchical Cellview within a Single Library

To produce a complete OpenAccess version of a cellview without translating the entire library,
use the controls in the Hierarchical conversion frame on the Conversion tab of the Library
specific options form.

Consider the library depicted in the following figure. The top_cell layout view references
the cell_2 and cell_3 layouts.

February 2018 100 Product Version IC6.1.7

All the three cells have layout and symbolic views.

user
cdb
cds.lib
design
top_cell
layout
layout.cdb
symbolic
layout.cdb
cell_2
layout
layout.cdb
symbolic
layout.cdb
cell_3
layout
layout.cdb
symbolic
layout.cdb

To convert the hierarchical cellview top_cell, perform the following steps:

1. In a shell window, go to the top-level directory of the OpenAccess version of the library.
If you are translating the library for the first time, create a new directory and go to that.

user
cdb
oa Start the translator in this directory
design

2. Start the translator in the top-level directory as described in “Starting the Translator” on
page 92.

February 2018 101 Product Version IC6.1.7

3. Type the path to the cds.lib file in the Path to cds.lib file field. The translator lists the
design library in the Libraries to convert pane.
4. Select the design library and click Set library options. The Library specific options
form appears.
5. Click the Conversion tab.
6. In the Hierarchical conversion frame, select the Convert hierarchical cellview check
box and specify the top cellview by typing the values in the Cell name and View name
fields.
7. Click OK to return to the CDB to OpenAccess Translator form and then click OK again
to convert the cellview. The translator creates and executes a script called
run_cdb2oa.csh in the current directory. This file contains the cdb2oa command to
convert the cellview in question. The script used by the GUI uses the -cell, -view, and
-topdown command line arguments for performing the hierarchical conversion.

February 2018 102 Product Version IC6.1.7

The translator converts the layout view for top_cell and all of the cellviews present for
cell_2 and cell_3.

Converting an Hierarchical Cellview over Multiple Libraries

The translator can also convert an hierarchical cellview which references cellviews contained
in different libraries. The steps are the same as those described in “Converting an
Hierarchical Cellview within a Single Library” on page 100. All you need to ensure is that the
dependency libraries have been translated first.

Click Order on the CDB to OpenAccess Translator form to determine the dependencies
between the libraries. Translate the dependency libraries first in one or multiple runs of the
translator. Finally, to convert the hierarchical cellview, select the Convert hierarchical
cellview check box on the Conversion Tab and specify the values in the Cell name and View
name fields.

February 2018 103 Product Version IC6.1.7

The GUI uses the -cell, -view, and -topdown command line arguments for performing
the hierarchical conversion.

February 2018 104 Product Version IC6.1.7

Converting Multiple Libraries

The translator GUI lets you convert multiple libraries in a single run. For example, if your
design library references information in libraries, deviceLib1, deviceLib2, refLib1,
and refLib2, the library structure might look like this.

user
cdb
cds.lib
design
devices
deviceLib1
deviceLib2

reflibs

refLib1
refLib2

To translate this database, you need to do the following:

1. Set up the file system structure for the OpenAccess version of the library.
2. Run the translator in the top-level of the OpenAccess hierarchy.

Setting up the Structure for the OpenAccess Version of the Library

When translating multiple libraries, Cadence recommends that you set up the directory
structure for the OpenAccess version of the database before you start and then use the
OpenAccess library path field to direct the translated libraries to the correct location.

This approach is recommended for two reasons:

■ The process of methodically determining where each library will go is important in
tracking the progress and success of the migration effort.
■ Setting up the directory structure involves not only setting up library directories, but also
other files and directories for storing simulation data, rule decks, SKILL files, scripts, and
design management metadata.

February 2018 105 Product Version IC6.1.7

These files and directories introduce many dependencies that must be accounted for
prior to conversion; for example, it is particularly important to locate SKILL files correctly
so that they are available for use by the libInit.il and.cdsinit files.

Important
Regardless of any path specified in the OpenAccess library path field, the
translator always creates or updates the cds.lib file in the current working
directory.

To set up the directory structure for the OpenAccess libraries, create a top-level directory to
contain the OpenAccess version of the cds.lib file and a subdirectory for each of the
libraries to be translated.

user

cdb
oa Start the translator in this directory
design
devices
deviceLib1
deviceLib2

reflibs

refLib1
refLib2

Converting Multiple Libraries

To convert multiple libraries, perform the following steps:
1. In a shell window, go to the top-level directory of the OpenAccess version of the library.
2. Start the translator as described in “Starting the Translator” on page 92.
3. Enter the path to the cds.lib file in the Path to cds.lib file field. The translator lists
the design library in the Libraries to convert pane.

February 2018 106 Product Version IC6.1.7

4. Click Order to determine the sequence in which these libraries need to be converted.
The translator determines the dependencies between the libraries and changes the order
appropriately.
5. Select the first library in the list and click Set library options. The Library specific
options form appears.
Note: You can manually select all the design libraries in the Libraries to convert pane
that you want to convert.
6. In the OpenAccess library path field on the Conversion Tab, specify the path to the
directory you want to use. For example, for refLib1, you would enter the following.
reflibs/refLib1

7. Click OK to close the Library specific options form. For more information about this
form, see Appendix A, “CDB to OpenAccess Translator Form Descriptions”.
8. Repeat steps 5 and 6 for each of the libraries to be converted.
9. In the CDB to OpenAccess Translator form, click OK to convert the listed libraries.
The translator creates and executes a script called run_cdb2oa.csh in the current
directory. This file contains one cdb2oa command for each library to be converted.
cdb2oa -cdslibpath ../cdb/ -lib refLib1 -oalibpath reflibs/refLib1 -log ./
cdb2oa.gui.log.1 -appendlog -mapundefinedpingroups strong
cdb2oa -cdslibpath ../cdb/ -lib deviceLib2 -oalibpath devices/deviceLib2 -log
./cdb2oa.gui.log.2 -appendlog -mapundefinedpingroups strong
cdb2oa -cdslibpath ../cdb/ -lib deviceLib1 -oalibpath devices/deviceLib1 -log
./cdb2oa.gui.log.3 -appendlog -mapundefinedpingroups strong
cdb2oa -cdslibpath ../cdb/ -lib refLib2 -oalibpath reflibs/refLib2 -log ./
cdb2oa.gui.log.4 -appendlog -mapundefinedpingroups strong
cdb2oa -cdslibpath ../cdb/ -lib design -oalibpath design -log ./
cdb2oa.gui.log.5 -appendlog -mapundefinedpingroups strong

February 2018 107 Product Version IC6.1.7

Resolving Circular Dependencies

A circular dependency occurs when a cellview contains an instance of a cellview from another
library which itself contains an instance of a cellview from the first library. For example,

refLib1/cell_4/layout

refLib2/cell_1/layout

refLib1/cell_6/layout

When using the GUI, the translator is able to resolve most of these dependencies for you.
However, from time to time you might be left with some unresolved dependencies at the end
of the translation run.

To resolve these, use the -cell and -view arguments to work from the lowest level in the
hierarchy back up to the top cellview, translating individual cellviews as required so that the
dependencies are satisfied. For more information on how to do this, see “Determining the
Sequence of Translation” on page 87 and “Resolving Circular Dependencies” on page 88.

February 2018 108 Product Version IC6.1.7

Customizing the Translation Environment

You can pre-populate the Library specific options form by using the CDS environment
(.cdsenv) file. This file stores the default settings that you can override to customize the
translation environment to suit your requirements. For more information about .cdsenv file,
see Chapter 9, “Specifying Environment Settings”, in the Virtuoso Design Environment
User Guide.

Copying the cdb2oa .cdsenv File

Copy the .cdsenv from the following location to your current working directory:
installation_directory/tools/dfII/etc/tools/ddserv/

If the .cdsenv file is stored in your home directory, it gets loaded when you start the
translator and any of your customized settings come in effect.

Editing the cdb2oa .cdsenv File

After copying the default .cdsenv file to your home or current working directory, you can edit
it using a text editor. Make the changes based on your requirements and save the file. A
sample of the cdb2oa .cdsenv file with overridden default values is shown below.

ddserv.cdb2oa iccrulesfile string "../testiccrule.txt"

ddserv.cdb2oa useiccmap boolean nil
ddserv.cdb2oa iccconstraintgroup string "techlib1"
ddserv.cdb2oa iccrulesmapfile string "iccrule.map"
ddserv.cdb2oa cell string ""
ddserv.cdb2oa view string ""
ddserv.cdb2oa appendlog boolean nil
ddserv.cdb2oa keepdevicemasters boolean t
ddserv.cdb2oa retainsympins boolean nil
ddserv.cdb2oa createpathseg boolean t
ddserv.cdb2oa unplaced boolean t
ddserv.cdb2oa all boolean t

The table in the Mapping GUI Options with Command Line Arguments and .cdsenv Variables
section lists all the default cdb2oa .cdsenv variables and the corresponding GUI options.

February 2018 109 Product Version IC6.1.7

February 2018 110 Product Version IC6.1.7

5
Post-Processing of the Translated Data

This chapter describes how you can process the translated OpenAccess design data after
the cdb2oa conversion.

The Mapper Utility

The mapper utility can work in the following ways:
■ On an entire library, when both -cell and -view options are not specified
■ On an individual cellview, when both -cell and -view options are specified
■ On all views present in a cell, when only the -cell option is specified
■ On a specific cellview under each cell, when only the -view option is specified

The libraryon which the mapper utility is run must have write permissions for mapping. If the
library does not have write permission for mapping, then use the -makelibwritable option
to grant write permission to all cellviews of the library, recursively. The syntax is as follows:
mapper -lib <libName> -map <mapFilePath> --makelibwritable

The standalone mapper utility can do the following:

■ Resetting the layer/purpose for a shape (Mapping Techniques)
■ Creation of OpenAccess objects from shapes that belong to specified LPPs (Object
Mapping)
Note: Use this tool only for the translated OpenAccess design data.

Mapping Techniques
Traditionally, the mapper utility allows only the purpose-to-purpose mapping using a map file.
This method allows you to move all the shapes on <Layer1 Purpose1> to <Layer1
Purpose2>.

February 2018 111 Product Version IC6.1.7

You can also use the LPP name mapping option -namemap to move all the shapes from
<Layer1 Purpose1> to <Layer2 Purpose2>. The syntax of -namemap is as follows:
mapper -lib <libName> -map <mapFilePath> -namemap [-cell] [-view]

Here, the -cell option works on a specific cell and the -view option works on a specific
view in the technology file. In case only -cell option is specified, it works on all the views
present in that cell. Whereas, if only -view option is specified, it works on a specific cellview
under each cell.

Otherwise, mapper works as LPP number mapping and the syntax is as follows:
mapper -lib <libName> -map <mapFilePath>

The details of these methodologies are given below:

■ Purpose-to-Purpose Mapping: It includes the purpose-to-purpose mapping through
a map file. The map file maps the purpose in one layer-purpose pair to another purpose.
The entries in the map file should be of the following format:
<Layer> <Purpose1> <Purpose2>

Shapes on all valid <Layer> <Purpose1> pairs will be moved to the valid <Layer
Purpose2> pairs. However, shapes will not move if the target layer-purpose does not
exist or is unknown.
❑ Both names and numbers can be used to specify the layer-purpose pairs in the map
file. However, a map file contains either all the names or all the numbers.
■ LPP-to-LPP Mapping: It includes the LPP-to-LPP mapping through a map file, which
moves shapes from source LPP to target LPP. The entries in the map file should be of
the following format:
<Layer1 Purpose1> <Layer2 Purpose2>

Shapes on all valid <Layer1 Purpose1> will be moved to a valid <Layer2

Purpose2> pairs. In addition, a single map file can have multiple valid entries in any of
the following formats:

<Layer1 Purpose1> <Layer2 Purpose2>

<Layer1 Purpose1> <Purpose2> (For backward Compatibility)
<Layer1 Purpose1> <Layer1 Purpose2> (Recommended)

■ LPP-to-LPP Copying: Unlike LPP-to-LPP mapping, it includes the LPP-to-LPP

copying through a map file, which copies shapes from source LPP to target LPP using
the following syntax:
mapper -lib <libName> -map <mapFilePath> -copy [-cell] [-view]

The entries in the map file should be of the following format:

February 2018 112 Product Version IC6.1.7

<Layer1 Purpose1> <Layer2 Purpose2>

Shapes on all valid <Layer1 Purpose1> will be copied to a valid <Layer2

Purpose2> pairs. In addition, a single map file can have multiple valid entries in any of
the following formats:
<Layer1 Purpose1> <Layer2 Purpose2>
<Layer1 Purpose1> <Purpose2> (For backward Compatibility)
<Layer1 Purpose1> <Layer1 Purpose2> (Recommended

If you want to perform one-LPP-to-multiple-LPP copying, see Handling Duplicate Entries.

■ P&R Object Mapping: The layer map file can also have only two tuple entries, such as
<Layer1> <Layer2> for the layer mapping of P&R objects. In this case, the
oaLayerBlockages and oaLayerHalo associated with <Layer1> will be moved to
<Layer2> after running the mapper utility.

Rules for Interpreting Entries in a Map File

❑ Shapes on system-reserved layer/purpose or targeted to system-reserved layer/
purpose are not allowed to be moved. In any of these cases, the error message will
be displayed and all such entries will be ignored.
❑ Both LLPs should be the valid LPPs that are defined in the technology file. For
example, if a map file contains:
metal1 drawing metal2 drawing

then, both LPPs metal1 drawing and metal2 drawing should be defined
in the technology file.
❑ Wildcard characters ‘*’ and ‘?’ can be used for specifying the layer and purpose
names. Wildcard characters are allowed in place of source layer and purpose
names. Though the use of wildcard characters generates a lot of possible layer-
purpose combinations, shapes on only the valid LPP will be migrated. For example,
the valid wildcard entries in a map file are:
* drawing metal1 drawing
metal2 * metal1 drawing
* * metal1 drawing
via* drawing metal2 drawing1
*1 drawing1 metal2 drawing1

However, wildcard characters are not allowed in place of target layer-purpose

names because one-to-many mapping is not permitted.
Note: In case any duplicate entry is found because of a wildcard character, the
ignore message will be displayed if the -reportallerrors option is specified.

February 2018 113 Product Version IC6.1.7

❑ The map file is processed line-by-line and therefore it works in a cascade mode. For
example, if the map file contains the following entries:
metal1 drawing1 metal2 drawing2
metal2 drawing2 metal3 drawing3

then, all the shapes on LPP metal1, drawing1 will be moved to LPP
metal3, drawing3.
Note: All blank lines and the lines starting with the # symbol will be ignored. The #
symbol is meant for adding comments in the map file.
❑ Handling Duplicate Entries
To understand how duplicate entries are handled, consider a map file with following
entries:
metal1 drawing1 metal2 drawing
metal1 drawing1 metal3 drawing1
If the -copy option is specified, all the shapes on the single source OA LPP will be
copied to multiple destination OA LPPs. Additionally, a warning with information
about the duplicate entry, in which all column values match in the map file, will be
displayed.
If the -copy option is not specified, the sequence of entries in the map file is
considered. While reading the entries, the map file takes the top-to-bottom approach
and gives precedence to the first entry. Any duplicate entry is ignored and an ignore
warning message is displayed. In this scenario, if a duplicate entry is found because
of a wildcard character and if the -reportallerrors option is specified, an ignore
warning message will be displayed.

February 2018 114 Product Version IC6.1.7

LPP-to-LPP Color Mapping (Advanced Nodes Only)

It includes the LPP-to-LPP color mapping through a map file, which moves shapes from
source LPP to target LPP with respective photomask color and color state.

The entries in the map file should be of the following format:

Shapes on all valid <Layer1 Purpose1> will be moved to a valid <Layer2 Purpose2>
pairs with respective photomask color <PhotoMaskColor> and color state <ColorState>.
In addition, a single map file can have multiple valid entries in any of the following formats:
<Layer1 Purpose1> <Layer2 Purpose2> <PhotoMaskColor> <ColorState>
<Layer1 Purpose1> <Layer1 Purpose2> <PhotoMaskColor> <ColorState>
(Recommended)

Let's consider an example where you have two shapes on LPP1. Now, this tool will migrate
the shapes from the source LPP to the target LPP, LPP2 with respective photo mask colors
and color states as shown below:
Metal1 drawing1 Metal2 drawing2 mask1Color locked

Note: The Photomask color information, which is specified in an entry of the layerMap file
is validated against the number of photomask color support in the technology for that
particular target LPP.

Object Mapping
In object mapping a LPP cannot be specified twice against two different objects. If this is done
the order of the entries will change the output. The object map is parsed on the basis of layer
and purpose names. Specifying the layer and purpose numbers is not allowed. They will be
treated as strings only.

The option name for object mapping is -objectmap and the syntax is as follows:
mapper -lib <libName> -objectmap <mapFilePath>

PR and Snap Boundary Mapping

In PR and Snap boundary mapping, all the shapes would be queried on the specified LPP.
However, if multiple shapes are found only the first shape will be considered for PR boundary.
Whereas, in case of snap boundary, mapper will try to merge the bounding boxes of the
shapes and come up with a enveloping snap boundary. This is considered as an error from
the mapper’s perspective. Therefore, multiple shapes on the specified LPP should be
avoided.

February 2018 115 Product Version IC6.1.7

Map file syntax

<layer name> <purpose name> boundary pr
<layer name> <purpose name> boundary snap

If prBoundary or a snapBoundary already exists, it will be destroyed. However, if the same

LPP has been specified twice, once with snap and later with pr or vice versa, only the first
entry will be considered.The subsequent entries will be ignored and a warning message will
be displayed.

Layer Blockage Mapping

Incase of layer blockage mapping, all shapes on specified LPP will be queried and would be
converted to layer blockages on the same layer and the shapes will be deleted. The
appropriate values for blockage types are: route, fill, slot, pin, feedthru, screen,
and routing. Incase, any other type string is specified, it would not be accepted and an error
message will be displayed.

Map file syntax

<layer name> <purpose name> blockage <blockage type>

If the same LPP has been specified twice, once with one blockage type and later with another
blockage type, then only the first entry will be considered and all the subsequent entries will
be ignored. Layer blockage can not have a blockage type of placement.

An optional density argument is added for layer blockage mapping to set the maxDensity
attribute only if the blockage sub type is screen. The syntax for it is as follows:
<layer name> <purpose name> blockage screen <maxDensity>

Adding LPP to Specified Net Mapping

All shapes in the specified net will be queried and added to the specified net. If the specified
net is not found in the design block an error message will be displayed.

Map file syntax

Note: All three types of object mappings support the characters '*' and '?' as wild cards in
the syntax. These wild cards can be used only for layer and purpose names.

February 2018 116 Product Version IC6.1.7

Syntax
The command line syntax for the mapper utility is as follows:
mapper
-map mapFileName
-lib libName
[ -namemap ]
[ -copy ]
[ -cell ]
[ -view ]
[ -reportallerrors ]
[ -objectmap ]
[ -help ]

-map mapFileName
Specifies the name of the map file that maps one purpose to
another. If the mapping is in the name format, use the -
namemap argument with the -map argument.
-lib libName
Specifies the name of the input OpenAccess library to be
processed.
-namemap
Specifies that the entries in the map file are in the form of
names and not numbers. The mapper utility, by default,
assumes the mapping in the map file to be in the number
format.
-copy
Copies shapes from source LPP to target LPP.
-cell
Specifies the cell name.
-view
Specifies the view name.
-reportallerrors
Prints all the error and warning messages that are issued when
the utility comes across invalid layer-purpose combinations. A
number of invalid layer-purpose combinations are generated as
a result of using wildcard characters in the map file.

February 2018 117 Product Version IC6.1.7

-objectmap
Specifies the object map file.
-help
Prints the list of mapper command arguments and their
descriptions. The utility displays the same information if you
type mapper without specifying any arguments.

February 2018 118 Product Version IC6.1.7

A
CDB to OpenAccess Translator Form
Descriptions

This appendix describes the following CDB to OpenAccess translation-related forms:

■ CDB to OpenAccess Translator on page 120
This is the main form that lets you select the library to convert. It also provides full support
for converting multiple libraries in a single run, including a function to determine
interdependencies between libraries and establish the sequence in which they need to
be converted.
■ Library specific options on page 123
The options on this form are distributed among various tab pages. All the options operate
at the library level. This form allows you to limit the translation to specific cellviews of the
selected library and lets you specify different options for different libraries in a multiple
library conversion. It lets you convert a complete hierarchical cellview, including all the
cellviews referenced by a specified top cellview.
The CDB to OpenAccess Translator form allows selection of multiple libraries. After
selecting multiple libraries, the Library specific options form will allow you to set the
options only for the selected libraries. By default, the Library Specific options form
displays the previously saved options that were specified in the form, irrespective of the
selected library.

February 2018 119 Product Version IC6.1.7

CDB to OpenAccess Translator

The CDB to OpenAccess Translator form contains the CDB library selection frame. Use
the controls in this frame to specify the libraries to be converted.

Path to cds.lib file specifies the path to the CDB library definitions file that defines the
library to be translated. The translator accepts any file that uses standard Cadence cds.lib
file syntax and supports the use of the INCLUDE keyword in these files. If you do not specify
a filename, the translator defaults to cds.lib.

Caution
Changing the path to the cds.lib file to specify a different cds.lib file can
cause irreversible loss of your settings.

Libraries not to convert lists the libraries referenced in the specified cds.lib file but not
currently in the Libraries to convert field.

Libraries to convert lists the libraries to be converted. When you specify the path to the
cds.lib file, the translator automatically moves all the valid libraries defined in that
cds.lib file into this field.
Note: Reference libraries shipped with Cadence software are excluded from the list.

February 2018 120 Product Version IC6.1.7

The libraries are converted in the order in which they are listed. To ensure that they are
converted in the correct order, click the Order button before running the conversion. Use the
arrow buttons to move libraries into and out of this field.
Up moves a selected library up one place in the list.
Down moves a selected library down one place in the list.
Order determines the sequence in which the list of libraries must be converted in order
to satisfy the cellview dependencies between them.

To increase the size of Libraries not to convert and Libraries to convert fields without
scroll bars, you can use an environment variable, increaseform of data type integer to
.cdsenv. Setting this variable 0 will display the default form and setting this variable to any
non-zero value will increase the form according. For example, if you want to display 30
characters without having scroll bar, then you can set the variable to 30.

Important
If you set the environment variable less than 22, then it will display the default form.

Set library options opens the Library specific options form for the selected library(s). Use
this form to limit the cellviews that are converted from an individual library and to specify
different options for different libraries in a multiple library conversion.

Sort list displays the list of libraries in sorted order in the Libraries to convert field. If the
Sort list check box is selected then the libraries will remain sorted irrespective of clicking the
arrow buttons. However, if you click the Up, Down, or Order button then the Sort list check
box will be deselected.

Generate run files only generates a run script without running the translation. The script
is created in the run directory and is called run_cdb2oa.csh. It contains one cdb2oa
command for each library to be converted.

If you are converting a hierarchical cellview, this button also generates a file called
cellList, which contains an ordered list of all the cellviews referenced by the top cellview.

Table A-1 Common Buttons in the CDB to OpenAccess Translator Form

Option Name Description

OK Used to accept all the changes on the form. All options present
on the respective forms are saved to CDB to OpenAccess
Translator form.

February 2018 121 Product Version IC6.1.7

Option Name Description

Cancel Used to reject all the changes on the form. Use the Cancel
button to exit the CDB to OpenAccess Translator form.
Apply Used to incorporate all the option settings in the form.
Help Used to invoke online help.

February 2018 122 Product Version IC6.1.7

Library specific options

This form pertains to a specific library for which you might want to customize various settings.
You can launch this form by clicking Set library options on the main CDB to OpenAccess
Translator form. The Library specific options form comprises of the following tabs:
■ General Tab
■ Database Tab
■ Technology Tab
■ Conversion Tab
■ Post Processing Tab

February 2018 123 Product Version IC6.1.7

General Tab

Run translator in preview mode (does not run the conversion) reports what would be
translated as a result of the current settings, but performs no translation. Therefore, the
remaining options on the General tab, other than those that specify the log file name and the
OpenAccess library path, are automatically disabled when the preview option is selected. The
report is printed to the same terminal window that is used to launch the translator.

Retain invalid cellviews and directories retains even the invalid cellview directories and
their contents.

February 2018 124 Product Version IC6.1.7

Ignore CDB locks ignores any edit locks on CDB data. By default, when a CDB cellview is
locked, it is not translated.

Report conversion progress prints additional information to the log file and standard error
output indicating the progress of the translation.

Write absolute paths in OpenAccess cds.lib file specifies that the absolute path to the
converted library is written to the OpenAccess cds.lib file. By default, the translator writes
the relative path in these files, unless you specify an absolute path using the OpenAccess
library path field.
Note: Using absolute paths in library definitions files can lead to problems if you access
the data across different networks or on different hardware platforms. It can also
adversely affect the performance of your applications on OpenAccess.

Skip directories lists the directory names to be skipped by the translator. A directory with
one of the specified names is not translated.

Write log to file logs the translation in the specified file. By default the translator appends
the conversion log to a file called cdb2oa.gui.log stored in the run directory.

Append option allows you to append the log file that has been specified in the Write log to
file field. This is the default option.

Overwrite option allows you to overwrite the log file that has been specified in the Write log
to file field. To overwrite the specified file, select the Overwrite option.

OpenAccess library path specifies a location for the OpenAccess version of the library.
The directory you specify must exist on your system; the translator cannot create it
automatically. You can enter either a relative or an absolute path. The last element of the path
is the library directory into which the library cells and other files are to be translated.
Note: Regardless of any path you enter in this field, the translator always updates the
cds.lib file in the current directory.

Abort if parameter types differ for overlapped super master and CDF parameters
specifies the cdb2oa translator to abort when a mismatch of parameter type occurs between
CDF parameter and Pcell superMaster parameter. By default, an appropriate warning will be
displayed and translation would continue if there is a mismatch in parameter type.

Abort if default values differ for overlapped super master and CDF parameters specifies
the cdb2oa translator to abort when a mismatch of default value occurs between CDF
parameter and Pcell superMaster parameter. By default, an appropriate warning will be
displayed and translation would continue if there is a mismatch in default values.

February 2018 125 Product Version IC6.1.7

Retain CDB parameter defaults on instances specifies the cdb2oa translator to retain the
CDB parameters defaults on instances.

Use defaults from Pcell parameters specifies cdb2oa translator to consider Pcell
superMaster parameters as master parameters while creating parameters on the OA
instance. If you do not select an option, by default Pcell superMaster parameter is considered.

Use defaults from CDF specifies cdb2oa translator to consider CDF parameter while
creating parameters on the OA instance. If you do not select an option, by default Pcell
superMaster parameter is considered.

User SKILL file specifies the top level SKILL file containing device definitions, which can be
loaded during the translation.

Process SKILL file specifies the SKILL file containing SKILL functions cdboaPreTrans()
and cdboaPostTrans, which can be loaded during the translation.

February 2018 126 Product Version IC6.1.7

Database Tab

Preserve device masters creates OpenAccess cellview representations of CDB

technology device masters such as syContact, syPin, syRectPin, and cdsVia devices.
By default, syContact devices are mapped to standardViaDef devices, syPin and
syRectPin devices are mapped to pin figures, and the device cellviews are removed from
the technology file. Use this option to ensure that Pcells instantiating these devices continue
to evaluate correctly after the conversion.

Do not flatten symbolic pins disables the flattening of the symbolic pins, syPins and
syRectPins. You can use this option only if the Preserve device masters option is
selected.

February 2018 127 Product Version IC6.1.7

Create pathSeg objects converts CDB 2-point paths to OpenAccess pathSeg objects. By
default, the CDB paths are converted to OpenAccess paths.
Note: 2-point paths, which are relative-object design (ROD) objects, are not converted
to pathSeg objects.

Half width path to polygon converts CDB path to OpenAccess polygon. Only the path with
a segment less than half width of the path is converted.

Use the Convert Half Width Path to Polygon option to translate all 1/2 width paths as
BOUNDARY. However, you can deselect the Convert Half Width Path to Polygon option to
translate 1/2 width path as path and not as a polygon.

Reset placement status resets the placement status of instances to “none” so that they
are displayed correctly in OpenAccess. OpenAccess does not display instances with
placement status “unplaced”.
Unplaced resets only the instances with placement status “unplaced”.
All resets all the instances.

Map undefined pin model to maps pin groups without subnet extensions to one of the
selected pin group model: Strong, Weak, and Must. The default pin model is Strong.

Do not overwrite existing OpenAccess data prevents the translator from overwriting
existing OpenAccess library data. Instead, it writes only data that does not already exist in the
OpenAccess library. By default, the translator overwrites any existing data in the OpenAccess
library.

Disable CPH uprev inactivates the automatic uprev of the CPH legacy data. The data in
CDB is cell-level component type. After cphUpRev, the translated data stores old component
type data in the LAM file.

Ignore DM Settings ignores all DM related files and directories, and translates the data to
OA without DM information. Therefore, all cellviews whether checked in or not can be edited
after translation to OA and all .SYNC directories are ignored. By default, the Ignore DM
Settings option is unchecked.

Disable CMX uprev inactivates the automatic uprev of the CMX legacy data. The data in
CDB is cell-level component type. After cmxUpRev, the translated data stores old component
type data in the LAM file.

Convert non-maskable symbolic pin to allows you to either drop non-maskable symbolic
pins by selecting the ignore option or to convert the non-maskable symbolic pins to rect or
dot by selecting the rect or dot option respectively. If none of the check boxes are selected
then, by default, all non-maskable symbolic pins are converted to rect.

February 2018 128 Product Version IC6.1.7

Maps cdsVia with non-drawing purpose to customViaDefs forces the CDBOA

translator to translate a cdsVia with non-drawing purpose to cdsViaDef, even if it is
possible to map the cdsVia to standardViaDef.

Convert special characters allows you to convert all special characters except '$' and '?'
for instances and mosaics to '_'.

February 2018 129 Product Version IC6.1.7

Technology Tab

Create layer map file specifies a name for a layer map file to contain stream translation
rules removed from the CDB technology file. By default, the file is called
libName.layermap and is placed in the same directory as the technology file from which
it is derived. For information on how the translator handles stream translation rules, see
“Stream Translation Rules” on page 32.

Detect vias automatically lets the translator identify the cellviews in the CDB design that
can be represented as standard or custom viaDefs in OpenAccess. If you use this option, you
do not need to manually create a via map file. Therefore, the Via map file field is disabled
when the Detect vias automatically option is selected.

February 2018 130 Product Version IC6.1.7

Note: You must have the permission to write to the OpenAccess technology file to use
this option.

Via map file specifies a file listing the CDB via cellview masters to be converted to
oaCustomViaDefs in OpenAccess. The translator adds the oaCustomViaDef definition to
the OpenAccess technology library and converts instances of the via cellview to OpenAccess
customVias referencing the new definition.
Note: You must have permission to write to the OpenAccess technology file to use this
option.

ICC rules files specifies the path to an ASCII file containing ICC rules. If you specify a rules
file, only that file is processed and any ICC rules in the technology file are ignored. The rules
are mapped to the virtuosoDefaultSetup constraint group in the OpenAccess
technology file unless you specify a different constraint group using the
-iccconstraintgroup argument.

ICC constraint group name specifies the OpenAccess constraint group into which ICC
rules are mapped. The translator picks up these rules from the CDB technology file or from a
separate ASCII file specified using the ICC rules files argument. By default the rules are
stored in the virtuosoDefaultSetup constraint group.

Use ICC rules map file specifies that a map file is to be used for mapping ICC rules files to
constraint group names.

ICC rules map file specifies the path of the map file. The map file is in ASCII format. The
map file contains several entries in the format “<ICC rules file path>
<constraint group name>”, with each entry on a separate line. Do not use this
argument along with either -icculesfile or -iccconstraintgroup; if used, the
translator will not proceed.

Toolbox rules file specifies the path of the Toolbox rule file. If a toolbox rule file is
specified, cdb2oa GUI will compile the command argument -tbrule. Specifying the
toolbox rules file would enable in faster deployment of Toolbox rule file from CDB to OA.

Map via parameters specifies that while translating CDB to OA, instances of symbolic
devices use the parameter default values from CDB master rather than OA stdViaDefs. By
default, the Map via parameters option is deselected.

ITDB frame specifies the Incremental Technology Database (ITDB) information for CDB to
OpenAccess translation.
PR rules library path specifies the path for creating the prrules library. If you do not
specify a path for the prrulelib library, by default the library is created in the current
directory.

February 2018 131 Product Version IC6.1.7

PR rules library name specifies the name of the prRules library. Depending on
whether the library being translated is a technology or a design library, the translator
does one of the following:
❑ Splits the technology library into the base technology library and the specified
prRules library
❑ Attaches the design library to the specified prRules library. This can happen only if
the technology library, to which the design library is attached, has been split to
create the prRules library.
Note: If a design library has its own technology library and the technology library
has been split, the translated design library cannot access the prRules information
because the prRules information gets compiled into a separate library. Therefore, if
you want the design library to retain access to the prRules information, do not use
the prruleLib option.
Consider an example in which the design library dlib is attached to the technology
library techlib on CDB. First, translate the technology library and specify the PR rules
library name as prlib. The technology library will split into the base technology library
basetechlib and the prRules library prlib. Next, translate the design library dlib.
The following scenarios are possible for translating the design library:
Case 1: No PR Rules Library is Specified
The translator will create dlib and attach it to basetechlib. In this case, the prRules
information will be lost.
Case 2: A PR Rules Library is Specified
2A: If the name of the prRules library is specified as prlib, the translator will create
dlib and attach it to prlib.
2B: If the name of the prRules library is specified as pr1 such that its base technology
reference does not match the basetechlib, the translator exits and issues an error
message.
Force attach prRules Library allows the translator to overlook any mismatches
between the specified prRules library and the base technology library and attaches the
design library to the specified prRules library. The specified prRules library should exist,
else the translator issues error messages.

Abort if CBT tech not defined specifies the translator to abort if CDB technology library is
not defined in the CDB library definitions file.

February 2018 132 Product Version IC6.1.7

Conversion Tab

Cells specifies the names of the cells to be translated. The translator converts only the cells
with one of the specified names.

Views specifies the view names to be translated. The translator converts only the views with
one of the specified names.

View types specifies the view types to be converted. Only cellviews that map to one of the
specified view types are translated. The valid view types are maskLayout, schematic,
symbol, netlist, schematicSymbol, verilogMap, and others.

February 2018 133 Product Version IC6.1.7

Note: The view type is distinct from the view name used to describe the view directory
in the library file system. Each view name is mapped to its corresponding view type in
the Cadence data registry. For more information on the data registry, see the Cadence
Application Infrastructure User Guide.

Hierarchical conversion frame produces a complete OpenAccess version of a hierarchical

CDB cellview.
Convert hierarchical cellview converts all of the cellviews referenced by a specified
top cellview.
Cell name and View name specify the top cellview to be converted.

Post Processing Tab

Setting the map file invokes the mapper utility after the cdboa translation is complete to
process the translated OpenAccess design data. The Mapper is an independent post
processing utility that is launched using the cdb2oa GUI interface. The Post Processing tab
in the cdb2oa GUI contains the settings for the mapper utility. The Post Processing tab allows
you to do the following:
■ Object Mapping

February 2018 134 Product Version IC6.1.7

■ Purpose Mapping

Object map file specifies the name of the object map file. The object map file maps the
shapes on a particular layer purpose to a specified OpenAccess object type.

Purpose map file specifies the name of the purpose map file. This would allow you to change
the shapes on a purpose to a new purpose.

Report all errors displays all the error and warning messages that are send out when the
utility comes across invalid layer-purpose combinations. A number of invalid layer-purpose
combinations are generated as a result of using wildcard characters in the map file. By
default, no errors and warnings are displayed for the invalid layer-purpose combinations. To
view all the errors and warnings, select the Report all errors option.

Map file uses layer and purpose names specifies that the entries in the map file are in the
form of names and not numbers. The mapper utility, by default, assumes the mapping in the
map file to be in the number format. By default the Map file uses layer and purpose names
option is deselected.

February 2018 135 Product Version IC6.1.7

Mapping GUI Options with Command Line Arguments and .cdsenv

Variables
The following table lists the various CDB to OpenAccess translator GUI options and the
corresponding command line arguments of the cdb2oa command. It also maps the GUI
options with the corresponding .cdsenv file variables.

GUI Option Command Line Argument .cdsenv Variable

General Tab
Path to cds.lib file -cdslibpath t_libPath cdbacdslibpath
Libraries not to convert -lib t_libName defaultconvert
Libraries to convert This variable by default
populates libraries in the
Libraries to convert pane.
By setting it to nil, the
cds.lib libraries will list in
the Libraries not to convert
pane.
Set library options No equivalent command line No equivalent .cdsenv
argument variable
Generate run files only No equivalent command line No equivalent .cdsenv
argument variable
Run translator in preview -printonly No equivalent .cdsenv
mode (does not run the variable
conversion)
Retain invalid cellviews and -nodropinvalidCV nodropinvalidCV
directories
Ignore CDB locks -ignorelocks ignorelocks
Report conversion progress -report report
Write absolute paths in -abspath abspath
OpenAccess cds.lib file
Skip directories -skipdir t_dirName... skipdir
Write log to file -log t_fileName log

February 2018 136 Product Version IC6.1.7

GUI Option Command Line Argument .cdsenv Variable

Append (default) -appendlog appendlog
Overwrite
OpenAccess library path -oalibpath t_libPath oalibpath
Abort if parameter types -storedefaultspolicy usecdf
differ for overlapped super <usepcellvalue |
master and CDF usecdfvalue>
parameters
Abort if default values differ
for overlapped super
master and CDF
parameters
Use defaults from Pcell -parampolicy abortontypedifference
parameters <abortontypedifference
|
Use defaults from CDF
abortondefaultvaluedif abortondefaultvaluedifferenc
ference | abortonboth> e
User Skill File -loadskillfile userskillfile
Database Tab
Preserve device masters -keepdevicemasters keepdevicemasters
Do not flatten symbolic pins -retainsympins retainsympins
Create pathSeg objects -createpathseg createpathseg
Reset placement status -resetplacestatus all
unplaced
Map undefined pin model -mapundefinedpingroups strong
weak
must
Do not overwrite existing -nooverwrite nooverwrite
OpenAccess data
Disable CPH uprev -disablecphuprev disablecphuprev
Ignore DM Settings -nodm nodm
Disable CMX uprev -disablecmxuprev disablecmxuprev

February 2018 137 Product Version IC6.1.7

GUI Option Command Line Argument .cdsenv Variable

Technology Tab
Create layer map file -layermapfile layermapfile
t_fileName
Detect vias automatically -detectvias detectvias
Via map file -viamap t_fileName viamap
ICC rules file -iccrulesfile iccrulesfile
t_fileName
ICC constraint group name -iccconstraintgroup iccconstraintgroup
t_name
Use ICC rules map file -iccrulesmapfile useiccmap
t_name
ICC rules map file iccrulesmapfile
Map via parameters -mapviaparams viaparams
PR rules library path -prrulelibpath No equivalent .cdsenv
t_prruleLibPath variable
PR rules library name -prrulelib t_libName No equivalent .cdsenv
variable
Force attach prRules -force No equivalent .cdsenv
Library variable
Conversion Tab
Cells -cell cell
Views -view view
View types -viewtype No equivalent .cdsenv
variable
Convert hierarchical -topdown -cell No equivalent .cdsenv
cellview t_cellName -view variable
t_viewName
Post Processing Tab
Map file uses layer and -namemap namemap
purpose names
Report all errors -reportallerrors reportallerrors
Object map file -objectmap objmapfile

February 2018 138 Product Version IC6.1.7

GUI Option Command Line Argument .cdsenv Variable

Purpose map file -map purpmapfile

February 2018 139 Product Version IC6.1.7

February 2018 140 Product Version IC6.1.7

Index
Numerics illegal names in 27
instance pins 58
64-bit mode, running 18 magnified 44
master.tag 38
parameterized cells See parameterized
A cells
paths with extensions 58
application infrastructure files pc.db 39
cds.lib 30 site cellviews missing in
cdsinfo.tag 31 OpenAccess 36
view types
mapping from CDB to
B OpenAccess 40
mismatched 40
boundaries, mapping shape-based visibility settings for text display
boundaries 59 objects 46
bounding boxes, differences in 45, 46 command line
validation 19
connectivity
C pins and pin connectivity 53
counters See timestamps
CDB
objects not supported 63
permissions 64 D
versions supported 17
cdb2oa database units per user unit See technology
GUI 92 information, setting values for
location of executable 18 units 34
overview of the translator DBUPerUU See database units per user
engine 19 to 21 unit 34
running in 64-bit mode 18 disk space
syntax 65 estimating 24
cdb2oail quotas 24
location of executable 18 display resource file, display.drf 36
CDBA name space
illegal names in 27, 64
cds.lib E
converting 30
relative and absolute paths in 30 empty cellviews 39
cdsinfo.tag 31 environment variables files
cellviews .cdsenv 25
bounding boxes, differences in 45, 46 .cdsinit 25
determining the sequence of
translation 20
directories in 39
empty cellviews 39

February 2018 141 Product Version IC6.1.7

G P
graphical user interface parameterized cells
run files introduced 41
SKILL functions in 41
parent-child database file, pc.db 39
H pcells See parameterized cells
pins
hierarchical conversion and pin connectivity 53
over multiple libraries 103 properties 47
within a single library 100 Virtuoso XL properties 51
prRules See technology file,
conversion 32
L
labels R
bounding boxes, differences in 45, 46
log file related documents 10
CDS_LOG_PATH 22 run files See graphical user interface
CDS_LOG_VERSION 22
location 21
messages excluded 23 S
naming convention 22
structure 22 sites 36
stream translation rules 32
syntax
M cdb2oa 65
command line validation 19
magnification 44
master.tag file 38
mosaics 41 T
techfile.cds See technology information 32
N techfilemapping file 59
technology information
name spaces attached technology libraries 33
illegal CDBA names 27 conversion 32
in log file messages 28 display.drf 36
introduced 26 setting values for units 34
mapping special characters from CDBA stream translation rules 32
to LibraryUnix 26 techfile.cds 32
specifying object names 27 validating in OpenAccess 35
text display objects
bounding boxes, differences in 45, 46
O visibility settings 46
timestamps
OpenAccess introduced 49
introduced 17 translating
versions supported 17 from the command line 63
from the GUI 91

February 2018 142 Product Version IC6.1.7

validating CDB data 63

troubleshooting
log file 21

U
usage
cdb2oa 65
userUnits See technology information,
setting values for units 34

V
validating CDB data 63
versions
CDB and OpenAccess versions
supported 17
vias
automatic detection 37, 130
via map file 37, 130, 131
visibility settings 46
for text display objects 46

February 2018 143 Product Version IC6.1.7

February 2018 144 Product Version IC6.1.7

Intrusion Detection Honeypots
From Everand
Intrusion Detection Honeypots
Chris Sanders
3/5 (2)
Dev Guide
100% (3)
Dev Guide
195 pages
Become A Member: Answer Key 4.pdf - Cambridge English Empower B1+ Unit..
No ratings yet
Become A Member: Answer Key 4.pdf - Cambridge English Empower B1+ Unit..
1 page
Computers Quiz - Basic Computer Science Quiz Questions
80% (5)
Computers Quiz - Basic Computer Science Quiz Questions
10 pages
(CDL) Design Data Translator's Reference PDF
No ratings yet
(CDL) Design Data Translator's Reference PDF
598 pages
White Paper Operational Acceptance Testing en
100% (1)
White Paper Operational Acceptance Testing en
26 pages
Metastock Developer Kit
100% (1)
Metastock Developer Kit
152 pages
Gray Hat Hacking the Ethical Hacker's
From Everand
Gray Hat Hacking the Ethical Hacker's
Çağatay Şanlı
5/5 (1)
Eetop - CN Vivaxlug
No ratings yet
Eetop - CN Vivaxlug
1,191 pages
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
From Everand
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
Matthew C. Smith
No ratings yet
Modelsim User
No ratings yet
Modelsim User
820 pages
Content Creation Revolution with chatGPT
From Everand
Content Creation Revolution with chatGPT
Maria Cowen
No ratings yet
ChatGPT for Business: Strategies for Success
From Everand
ChatGPT for Business: Strategies for Success
Matthew C. Smith
1/5 (1)
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
From Everand
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
Michael Basler
No ratings yet
Software Patterns Made Easy
From Everand
Software Patterns Made Easy
Justice Nanhou
No ratings yet
MKS Implementer User Guide v.5.3 PDF
No ratings yet
MKS Implementer User Guide v.5.3 PDF
456 pages
CAS Single Sign On Handbook
100% (1)
CAS Single Sign On Handbook
131 pages
OVM UserGuide
100% (1)
OVM UserGuide
158 pages
DOC00310 Verix EVo ACT Programmers Guide
75% (4)
DOC00310 Verix EVo ACT Programmers Guide
348 pages
A To Z of Internet: Everything You Wanted to Know
From Everand
A To Z of Internet: Everything You Wanted to Know
Bittu Kumar
No ratings yet
CES WebSuite New
No ratings yet
CES WebSuite New
112 pages
EQ Administration Guide v5.7 PDF
No ratings yet
EQ Administration Guide v5.7 PDF
504 pages
RC DP
No ratings yet
RC DP
112 pages
Cadence Design With RTL Compiler Physical PDF
No ratings yet
Cadence Design With RTL Compiler Physical PDF
108 pages
IntegrationsUserGuide Integrity 10 4
No ratings yet
IntegrationsUserGuide Integrity 10 4
216 pages
Banner Translation Service: Installation and Administration Guide
No ratings yet
Banner Translation Service: Installation and Administration Guide
5 pages
Cics 400 Administration and Operations Guide
No ratings yet
Cics 400 Administration and Operations Guide
343 pages
TLE 6.2 SAP R3 and R4 Setup and User Guide
No ratings yet
TLE 6.2 SAP R3 and R4 Setup and User Guide
145 pages
Equitrac - Installation Guide
0% (1)
Equitrac - Installation Guide
97 pages
Business Process Insight Integration Train - Hewlett-Packard Company
No ratings yet
Business Process Insight Integration Train - Hewlett-Packard Company
430 pages
PC 81 TransformationGuide
No ratings yet
PC 81 TransformationGuide
552 pages
Installation Guide
0% (1)
Installation Guide
438 pages
Converting MicroSim® Schematics Designs To OrCAD Capture® Designs
No ratings yet
Converting MicroSim® Schematics Designs To OrCAD Capture® Designs
44 pages
Dokumen - Tips - Doc00310 Verix Evo Act Programmers Guide
No ratings yet
Dokumen - Tips - Doc00310 Verix Evo Act Programmers Guide
348 pages
MFGPRO OracleDatabaseOnUNIXServer IG v09
No ratings yet
MFGPRO OracleDatabaseOnUNIXServer IG v09
146 pages
Modelsim User
No ratings yet
Modelsim User
854 pages
Vse ICCF User's Guide
100% (2)
Vse ICCF User's Guide
509 pages
Eetop - CN Adexl
No ratings yet
Eetop - CN Adexl
1,136 pages
Fcug
No ratings yet
Fcug
101 pages
Violin Memory Array Software Configuration Guide R3.4
No ratings yet
Violin Memory Array Software Configuration Guide R3.4
163 pages
MSDK 9.1 Read - DISK PDF
No ratings yet
MSDK 9.1 Read - DISK PDF
152 pages
Student Notebook PresentationMaterialLog
No ratings yet
Student Notebook PresentationMaterialLog
1,320 pages
Vedit Tut
No ratings yet
Vedit Tut
106 pages
XPCICSCOBOLUserGuide PDF
No ratings yet
XPCICSCOBOLUserGuide PDF
194 pages
OVM UserGuide
No ratings yet
OVM UserGuide
164 pages
ROSCOE - B001723e - System Reference Guide
No ratings yet
ROSCOE - B001723e - System Reference Guide
374 pages
EcoStruxure Hybrid DCS GPL Process Templates Reference Manual - Eng - EIO0000004043.00
No ratings yet
EcoStruxure Hybrid DCS GPL Process Templates Reference Manual - Eng - EIO0000004043.00
1,270 pages
sg247844 GPFS
No ratings yet
sg247844 GPFS
426 pages
Sigtran Openss7
100% (1)
Sigtran Openss7
150 pages
Apb SVT Uvm User Guide
No ratings yet
Apb SVT Uvm User Guide
60 pages
Mfgpro Manager Functions
No ratings yet
Mfgpro Manager Functions
214 pages
StudentManual Cf238stud
No ratings yet
StudentManual Cf238stud
716 pages
Pci 32 gsg260
No ratings yet
Pci 32 gsg260
34 pages
SDI April2023 Transformations en
No ratings yet
SDI April2023 Transformations en
163 pages
Parallel Job Advanced Developer Guide
No ratings yet
Parallel Job Advanced Developer Guide
857 pages
PLC Proworx32 Software User Manual v1.0
No ratings yet
PLC Proworx32 Software User Manual v1.0
326 pages
Control M PDF
No ratings yet
Control M PDF
608 pages
Questa Sim User PDF
No ratings yet
Questa Sim User PDF
1,978 pages
Cybersecurity for Executives: A Guide to Protecting Your Business
From Everand
Cybersecurity for Executives: A Guide to Protecting Your Business
Matthew C. Smith
No ratings yet
Blog Smarter, Not Harder: SEO, Blogging, and AI Strategies to Skyrocket Your Traffic
From Everand
Blog Smarter, Not Harder: SEO, Blogging, and AI Strategies to Skyrocket Your Traffic
Jay Nans
No ratings yet
Plain JavaScript: Learning the Front-End
From Everand
Plain JavaScript: Learning the Front-End
Roger Beans-Rivet
No ratings yet
Mastering Python Advanced Concepts and Practical Applications
From Everand
Mastering Python Advanced Concepts and Practical Applications
Aissa Younes
No ratings yet
Module 1: Ims Database Structures
No ratings yet
Module 1: Ims Database Structures
51 pages
Identying and Measuring Developmentes in AI
No ratings yet
Identying and Measuring Developmentes in AI
68 pages
Traditional Approach VS OO Approach
100% (16)
Traditional Approach VS OO Approach
17 pages
LIM Guide 22.1.0
No ratings yet
LIM Guide 22.1.0
55 pages
Sony Xperia XA1 Plus - Schematic Diagarm
No ratings yet
Sony Xperia XA1 Plus - Schematic Diagarm
115 pages
G2 Quick Start Tutorial PDF
No ratings yet
G2 Quick Start Tutorial PDF
19 pages
How To Find and Remove Duplicate Files On Windows
No ratings yet
How To Find and Remove Duplicate Files On Windows
8 pages
Computer Fundamentals
No ratings yet
Computer Fundamentals
48 pages
Legion Slim 7 15 6 Userguide en
No ratings yet
Legion Slim 7 15 6 Userguide en
32 pages
Nsa325 481aaaj1c0
No ratings yet
Nsa325 481aaaj1c0
8 pages
Seed Map - Minecraft App 2
No ratings yet
Seed Map - Minecraft App 2
1 page
Scriptie Yildirim
No ratings yet
Scriptie Yildirim
105 pages
Bug Life Cycle
No ratings yet
Bug Life Cycle
4 pages
Ami Aptio Afu User Guide Nda
No ratings yet
Ami Aptio Afu User Guide Nda
32 pages
Iviewhmixecplctutorial
No ratings yet
Iviewhmixecplctutorial
10 pages
Lesson 1 Excel
No ratings yet
Lesson 1 Excel
8 pages
AKAI Pro MPK Mini Quick Start Guide
No ratings yet
AKAI Pro MPK Mini Quick Start Guide
10 pages
(FREE PDF Sample) Pro Spring MVC With WebFlux: Web Development in Spring Framework 5 and Spring Boot 2 2nd Edition Marten Deinum Ebooks
100% (1)
(FREE PDF Sample) Pro Spring MVC With WebFlux: Web Development in Spring Framework 5 and Spring Boot 2 2nd Edition Marten Deinum Ebooks
55 pages
Tyrone Assin GIC
No ratings yet
Tyrone Assin GIC
5 pages
Technical Interview Questions AWS
No ratings yet
Technical Interview Questions AWS
5 pages
Nano
No ratings yet
Nano
5 pages
CarTool v2.2.0 Release Notes
No ratings yet
CarTool v2.2.0 Release Notes
7 pages
POS Report Development Walkthrough
No ratings yet
POS Report Development Walkthrough
3 pages
Copier IR2230 2830 3530seriesbrochure
No ratings yet
Copier IR2230 2830 3530seriesbrochure
6 pages
Intune Privacy and Data Protection Overview
No ratings yet
Intune Privacy and Data Protection Overview
13 pages
Kali Linux 2.0 Top 10 Post Install Tips
No ratings yet
Kali Linux 2.0 Top 10 Post Install Tips
1 page
Vigash Mini Project
No ratings yet
Vigash Mini Project
75 pages
1SDC210102D0201 - Ekip Connect
No ratings yet
1SDC210102D0201 - Ekip Connect
4 pages