Cadence CDB To OA

OpenAccess to CDB Translator User Guide
Product Version 6.1.5

March 2012
© 2004-2012 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.
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Licensing in OACDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Related Documents for OACDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Installation, Environment, and Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Technology Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Typographic and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1
Overview of the OpenAccess to CDB Translator . . . . . . . . . . . . . 11
DFII on OpenAccess and Standard OpenAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Database Versions Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Running the Translator in 64-bit Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Use Model of the OpenAccess to CDB Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Technology Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
OpenAccess to CDB Translator Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Command Line Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Library Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Library Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
The Translator in the Cadence DFII Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Environment Variables Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Name Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2
How DFII on OpenAccess Data is Converted . . . . . . . . . . . . . . . . . 21
Application Infrastructure Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
The Library Definitions File: cds.lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
The System Information File: cdsinfo.tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Technology Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
March 2012 3 Product Version 6.1.5

Layers, Purposes, and Layer-Purpose Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
The Display Resource File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Cellviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Illegal OpenAccess names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Directories in Cellviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Identifying the Master Cellview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
The Parent-Child Database File: pc.db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Cellview Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
View Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Timestamps and Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Paths with Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Visibility Settings for Text Display Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Bounding Boxes of Labels and Text Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Parameterized Cellviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Magnification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Design Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Filename Type Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Nets and Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Regular Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Mosaics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Instance Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Instance Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3
Using the OpenAccess to CDB Translator from the Command
Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Converting a Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Updating an Existing CDB Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Converting into a Specified Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Converting a Cellview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Converting Multiple Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Setting up the Structure for the CDB Version of the Library . . . . . . . . . . . . . . . . . . . . 43
Determining the Sequence of Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Resolving Circular Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49


Preface
The OpenAccess to CDB translator, oa2cdb, allows you to translate designs and reference
data from OpenAccess to CDB format, provided the CDB technology is already available.
This user guide describes the OpenAccess to CDB database translator, oa2cdb. It is aimed
at designers who are working in a mixed design environment with IC6.1 and IC5.1.41 parallel
design flows and processes and are developing IP or modifying designs on IC6.1, which need
to be transferred back to IC5.1.41. It 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.
Licensing in OACDB
The oacdb translator requires the 111 license for the tool to run. If the 111 license is not
available, then the translator will not run and an error message is displayed.
Related Documents for OACDB

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.

Preface
Installation, Environment, and Infrastructure

■ For information on installing Cadence products, see the Cadence Installation Guide.
■ For general information about the Virtuoso design environment on OpenAccess,
including CDB features not supported in the Virtuoso design environment on
OpenAccess and differences in database behavior, objects, connectivity, technology
information, and C and SKILL functions for CDB, Virtuoso design environment on
OpenAccess, and OpenAccess, see the Virtuoso Design Environment Adoption
Guide.
■ For information on library structure, the library definitons file, and name mapping for data
shared by multiple Cadence tools, see the Cadence Application Infrastructure User
Guide.
■ For information on Component Description Format, see the Component Description
Format User Guide.
■ For information on using the cdb2oa translator to convert data from CDB to Virtuoso
design environment on OpenAccess, see the CDB to OpenAccess Translator User
Guide.
■ For information on known issues associated with the cdb2oa translator, see the CDB to
OpenAccess Translator Known Problems and Solutions document.
■ For information on converting between standard OpenAccess place and route objects
and Virtuoso design environment on OpenAccess representations, see “DFII on
OpenAccess and Standard OpenAccess” on page 11.
■ For information on known problems associated with the translator and ways to solve or
work around those problems, see the OpenAccess to CDB Translator Known
Problems and Solutions.
Technology Information
■ For information on technology files and libraries, see the Virtuoso Technology Data:
ASCII Files Reference Manual and the Virtuoso Technology Data User Guide.
■ For information on migrating CDB data from previous releases, see the Compatibility
Guide shipped with IC 5.1 releases on CDB.
Typographic and Syntax Conventions

This section describes the typographic and syntax conventions used in this manual.

Preface
text Indicates text you must type exactly as it is presented. These

words represent command (function or routine) or option names.
variables Indicates text you must replace with text appropriate to your
system. An example is: cd your_install_dir/tools/
dfII/samples/local
z_argument Indicates text that you must replace with an appropriate

argument. The prefix (in this case, z_) indicates the data type
the argument can accept. Do not type the data type or
underscore.
text Indicates names of manuals, menu commands, form buttons,

and form fields.
[ ] Indicates and encloses optional argument(s) except when they

enclose keyboard bindkeys. When used with vertical bars, they
enclose a list of choices from which you can choose one.
Although this document refers to commands by their complete
menu names, if a bindkey is available for a command, it is
included in brackets after the command name. For example,
Zoom – In [z].
{ } Used with vertical bars, they denote a list of choices from which
you must choose one.
| Separates a choice of options.
… Indicates that you can repeat the previous argument.
=> Precedes the values returned by a Cadence® SKILL language

function.
/ Separates the possible values that can be returned by a

Cadence SKILL language function.

Preface

1
Overview of the OpenAccess to CDB
Translator
CDBA is the application programming interface (API) and CDB the reference database used
by Virtuoso design environment tools. OpenAccess is a high performance, open-source API
and reference database used by the new generation of Virtuoso design environment tools.
DFII on OpenAccess and Standard OpenAccess

Virtuoso design environment tools on CDB use a convention of shapes on specific layer-
purpose pairs (LPPs) to represent the following place and route objects: blockages, place and
route boundaries, snap boundaries, groups, regions, routes, rows, and sites.
With the exception of the Virtuoso Chip Editor, all of the Virtuoso design environment
applications that have been ported to OpenAccess continue to generate and consume these
shape-based representations. Such databases are also known as “DFII-as-is” or “DFII on
OpenAccess”.
Standard OpenAccess defines a number of non-shape object types for this data. The next
generation of IC tools (for example, Cadence Encounter) do not use shape-based data, but
instead use the standard OpenAccess objects. There are also differences in the way in which
pin connectivity and routing and gcell grids are represented in DFII on OpenAccess and
standard OpenAccess. The table below provides some examples.
Type of Data DFII on OpenAccess Standard OpenAccess

Place and route Shape on layer-purpose pair Instance of oaPrBoundary
boundary (prBoundary boundary)
Routed net geometry Paths and vias Instance of oaRoute
Pin connectivity Subnet hierarchy Instances of oaPinGroups
(must/strong/weak)

Overview of the OpenAccess to CDB Translator
The diagram below illustrates the relationship between the oa2cdb translator and the DFII
on CDB, DFII on OpenAccess and standard OpenAccess database formats.
DFII on CDB DFII on OpenAccess

Environment Environment
Applications Applications
DFII on
CDB cdb2oa OpenAccess
oa2cdb
Important
The oa2cdb translator converts DFII on OpenAccess representations of place
and route data. It does not handle standard OpenAccess place and route
objects.
Database Versions Supported

The oa2cdb translator supports the following versions of the OpenAccess and CDB
databases:
■ Up to OpenAccess version 2.0.x delivered with ICOA 5.1.41 software
■ CDB version 4.4.6 and later
Important
You cannot use the ICOA 5.1.41 version of the oa2cdb translator to translate
OpenAccess 2.2 data. Use the IC 6.1.1 version of the oa2cdb translator to translate
OpenAccess 2.2 data.

Running the Translator in 64-bit Mode

By default the translator runs in 32-bit mode. However, to translate very large cellviews, you
might need to use the 64-bit version.
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 whether you are using the 64-bit version of the translator,
1. Type the following in a shell window.
oa2cdb -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 “oa2cdb.exe”
2. Run the translator from the command line.
Important
Running in 64-bit mode adversely affects the performance of the translator.
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.
Use Model of the OpenAccess to CDB Translator

The different groups in the IC design chain are highly interdependent, with teams
collaborating on designs as well as creating IP and libraries for use by different groups. While
some groups might still be working in the CDB environment, others might already have
migrated to OpenAccess in order to use some capability provided only on that database.
The oa2cdb translator is designed to let design groups using the different formats to continue
to share and leverage each other’s work. You can use it to
■ Translate an entire library.
■ Translate a specified cellview.

■ Translate selected cells, cellviews, and view types.
The translator use model assumes that all the OpenAccess data to be converted originated
in CDB. This means that all the required technology information exists already in CDB.
Because of this, the translator does not convert technology information.
However, it does perform some operations that are required in order to associate a library with
the correct technology information. For more information, see “Technology Information” on
page 22.
OpenAccess to CDB 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 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 oa2cdb -help in the terminal window
or see Chapter 3, “Using the OpenAccess to CDB 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. Examines the contents of the source library and determines the data to be translated
based on the command line arguments.

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

The translator examines the instance headers of the cellviews in the library and
establishes the sequence in which they need to be translated in order to satisfy any
dependencies. For example, it is not possible to create an instance terminal in CDB until
the instance’s master is available, therefore all cellview masters referenced by a
particular cellview must be translated before that cellview.
3. Creates the CDB version of the library and sets up the CDB version of the cds.lib file.
If the CDB version of the library does not exist, the translator first creates the associated
UNIX directory.
The translator creates the cds.lib file if it does not already exist in the run directory
and updates it with the path to the CDB version of the library.
For information on the cds.lib file, see “Application Infrastructure Files” on page 21.
Library Conversion
The translator converts data from the library level down through the cells to the individual
views. Data that exists already in the CDB version of the library is overwritten unless you
specify the -nooverwrite argument.
Note: Technology information associated with an existing library and library property bags
are never changed, regardless of whether the -nooverwrite argument is specified.
The conversion covers

■ Data that is copied to the CDB version of the library (SKILL procedures, rules files, and
miscellaneous ASCII files in the library)
■ Data that is translated (cellview database files, property bags).
The translator converts data in the sequence indicated below.

1. Data at the Library Level
The translator copies all non-database files including empty files and files that contain
only comments, preserving the timestamp from the OpenAccess version of the file. The
translator does not copy backup category files with suffixes .Cat% and .TopCat%.
Symbolic links are recreated.
It also translates the property bag file and sets up the CDB version of the library with the
required technology information. For more information, see “Technology Information” on
page 22.

2. Data at Cell and Cellview Level

Then, for each cell, the translator processes all of the files at cell level and for each view
of each cell, it processes all files at view level. Symbolic links are recreated.
Finally it processes the cellview database file itself, mapping nets, signals, shapes,
instances, instance terminals, terminals, pins, inherited connections, properties, parent-
child relationships, groups and timestamps to their CDB equivalents.
Note: The translator cannot translate illegal OpenAccess data, such as directories at
cellview level or cells and cellviews with illegal CDBA names.
For more information on the translation of cellviews, see “Cellviews” on page 25.
Log File
All the errors and warnings issued during a translation run are recorded in a log file. By
default, the log file is saved to the following path: $HOME/oa2cdb.log.
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, oa2cdb.log.1, oa2cdb.log.2, and so on
❑ pid, which appends the UNIX process number to the name of the log file; for
example, oa2cdb.log.1719, oa2cdb.log.2250, and so on
■ CDS_LOG_PATH lets you specify a colon-separated list of directories in which to save the
log file.
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: oa2cdb.exe version 5.0.2 04/17/2004 00:47 (cds125840) $
sub-version 5.12.41.145
Started at: Apr 20 16:29:56 2004
Hierarchy: /cds/5.12.41/red
User Name: user
Host Name: host1
Options: -lib overview -cdslibpath ../oa/cds.lib
Directory: /user/cdbnew
Log File: stderr
Copyright (C) 2001 Cadence Design Systems, Inc. All Rights Reserved
********************************************************************************
Messages Section
The Messages section records the messages issued by the translator.

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 views that were
translated.
■ A cell is classed as any directory under the library directory.
■ A view is any directory under a cell directory.
The summary also lists the messages that were generated by the translator and the number
of times each message occurred. Each message provides information on what happened, the
likely cause, and hints on how to recover from specific errors.
Example:
********************************************************************************
Finished at: Apr 20 16:31:02 2004
41 cells and 103 cellviews were translated from library “libName“ in 66.0s.

Message Summary:
ERROR (OACDB-653): Cannot translate <number> instance terminals for instance

“<name>” in cellview ‘<lib> <cell> <view>’ because the CDB
master cellview ‘<lib> <cell> <view>’ is not available.
Ensure that the master is available in OpenAccess, translate
it to CDB first and rerun the translator for the remaining
cells in the library.
Generated 118 times.
WARNING (OACDB-527): Layer-purpose pair ‘<layerName> <purposeName>’ is not

defined in the CDB technology file of library “<name>”
Generated 21 times.
WARNING (OACDB-445): Cannot determine the master file for OpenAccess cellview
‘<lib> <cell > <view>’. No cellview database file is
translated. Check your OpenAccess data.
Generated 11 times.
********************************************************************************
The Translator in the Cadence DFII Environment

This section describes the translator’s interaction with the Cadence DFII environment
variables files and clarifies the use of name spaces when specifying an oa2cdb command
line.
Environment Variables Files

The two main system files that control environment settings in DFII products are .cdsinit
and .cdsenv. The .cdsinit file is used to configure menus, bindkeys and mouse buttons,
colors, and fonts in your Cadence applications. The .cdsenv file lets you configure
environment settings for your Design Framework II applications. Because these settings are
not relevant for oa2cdb, the translator never loads .cdsinit or .cdsenv files.
Important
Do not use the .cdsinit file to load SKILL code required for parameterized cells
or other design features.
Name Spaces
DFII tools on both OpenAccess and CDB use the CDB name space. When a DFII application
writes an object to disk, the CDB names are mapped to the LibraryUnix name space, which

is used by Cadence tools for library names in cds.lib files and for library, cell, and view
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 DFII application encounters a name containing one of these characters, it substitutes
the escaped hexadecimal code for that character when converting it to LibraryUnix.
The table below lists the reserved characters in the CDBA name space, their purposes, and
their equivalents in LibraryUnix. If there is no LibraryUnix equivalent, the character is
regarded as illegal in the CDBA name space.
Purpose CDBA LibraryUnix

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 object names in the CDBA name
space, including the period ( . ) and the hyphen ( - ), are illegal in the LibraryUnix name
space. Again, DFII applications substitute the escaped hexadecimal equivalent when writing
these objects to disk.
Purpose CDBA LibraryUnix

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 CDBA name
space. The translator maps the CDBA 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

oa2cdb -lib lib.1 -cdslibpath ../oa/cds.lib -cell cell.1 -view layout.old
the translator converts the following cellview stored on disk

lib#2e1/cell#2e1/layout#2eold
Note: The translator also recognizes object names that are correctly specified in the
LibraryUnix name space.
Illegal Names in the CDBA Name Space
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 CDBA name space and therefore
regards it as illegal. This is most likely to have been 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 CDBA name space.
■ If you specify an illegal library name, the translator issues an error and stops the
translation. You must assign the library a legal name in the CDBA name space before
you can translate it.
■ If a cellview contains an object (for example, a net or a pin) with a name that is illegal in
the CDBA name space, the translator translates the cellview but not the illegally-named
object. Therefore, although the cellview appears to have been translated to CDB, it is
unlikely to be complete.
Name Spaces in Log File Messages
When printing messages to the log file, the translator prints object names as they occur in the
CDBA 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 DFII tools, see Chapter 7, “Name Mapping” in the
Cadence Application Infrastructure User Guide.

2
How DFII on OpenAccess Data is
Converted
This section tells you what the translator does with the different files and objects in a typical
DFII on OpenAccess database and highlights areas where the results in CDB might be other
than you expected.
Application Infrastructure Files

The two main infrastructure files handled by the translator are
■ The library definitions file (typically called cds.lib), which defines the libraries that
Cadence tools can access by mapping user library names to physical directory paths
■ 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.
The Library Definitions File: cds.lib

The translator creates a cds.lib file in the current directory if it does not already exist. If the
CDB version of the library is being created for the first time, the translator adds a DEFINE
statement to the cds.lib file specifying the name of and the path to the new CDB library. If
the CDB version of the library already exists, the cds.lib file is not updated and 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.
Tip
To ensure that the correct cds.lib file is updated and that access to the CDB
version of the library is correctly maintained, always run the translator from the
directory that contains the CDB cds.lib file.

How DFII on OpenAccess Data is Converted
Copying the OpenAccess cds.lib File to CDB
If you copy an OpenAccess cds.lib file to the CDB run directory, you must
■ Ensure that you have permission to write to the CDB version of the file so that the
translator can update it during the conversion.
■ Modify the library definitions so that they point to CDB data and not to OpenAccess data.
If the CDB cds.lib definition for the library being converted points to the OpenAccess
version of the library, the translator stops because this would place the CDB version of
the library in the same location as the OpenAccess version, which is not permitted.
Using Environment Variables in cds.lib Files
If you use environment variables in your cds.lib files, ensure that these are set
appropriately for the database you are using. Library definitions in a CDB cds.lib file must
point only to CDB data and those in OpenAccess cds.lib files must point only to
OpenAccess data.
The System Information File: cdsinfo.tag

The cdsinfo.tag file is an ASCII file specifying various tool, library, design management
system, and file system properties. It is generated automatically when the translator creates
a new library in CDB therefore there is no need for oa2cdb to copy or convert the file.
DFII technology information 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 an OpenAccess design library.
■ An OpenAccess technology file, tech.db, stored in the library directory
■ Separate technology libraries, attached to the design library using the techLibName
property in the library dd.db file
■ A display resource file, display.drf
For more information, see the Technology File and Display Resource File User Guide.
The translator use model assumes that data originated CDB and therefore that all the
required technology information is already available in CDB.

Important
The oa2cdb translator does not convert any technology information.
However, because of the differences in the way that technology information is handled in CDB
and DFII on OpenAccess, there are several operations that oa2cdb must perform in order to
associate the correct technology information with the target library in CDB. These operations
are summarized in the table below.
If the OpenAccess library And the CDB library Action

Contains a tech.db file Does not exist You must specify the -tech
argument in order to attach a
technology library for the new
CDB library.
The technology library you
specify must be defined in
the cds.lib file in the run
directory.
Exists already The translator uses the
technology information
already associated with the
existing CDB library.
Has an attached technology Does not exist The attached technology
library library must be available in
CDB and must be defined in
the CDB cds.lib file.
Otherwise, the translator is
unable to proceed.
Exists already The translator uses the
already associated with the
existing CDB library.
Has no technology Does not exist The translator attaches the
information CDB default technology
library, cdsDefTechLib, to
the new CDB library.
Exists already The translator uses the CDB
library’s technology file or
attached library, if available.

Note: Use the -tech argument only when you are creating a new CDB library and the
OpenAccess library contains a tech.db file.
Layers, Purposes, and Layer-Purpose Pairs

The oa2cdb translator checks that each layer-purpose pair (LPP) defined in the OpenAccess
tech.db file has an equivalent LPP in the CDB technology file and issues a warning for any
LPPs that do not.
Note: The check is based on the layer and purpose names, not the numbers.
Reserved Purposes
DFII on OpenAccess has several reserved purposes: drawing, fill, slot, OPCSerif,
OPCAntiSerif, annotation and gapFill. While drawing is likely always to exist in
CDB, the other purposes and their associated LPPs must be defined in the CDB technology
file if they are used in the OpenAccess library.
SKILL Code
Because the numbers assigned to reserved and user-defined layers and purposes might be
different in OpenAccess and CDB, all SKILL code attached to pcells must use layer and
purpose names to access the numbers, rather than using hard-coded numbers.
Units
In CDB, the values for user units (userUnits) and database units per user unit
(DBUPerUU) for each view type can be stored in various locations.
■ In the design library property bag (prop.xx)
■ In an associated technology file
■ In one of the Cadence environment variables (.cdsenv) files
■ As default values hardcoded in the system
In DFII on OpenAccess these values are stored only in the technology file.
If the values exist in the CDB technology file, oa2cdb checks that they are consistent with the
values stored in OpenAccess version. If the values are different, the translator issues an error

message and the translation stops. The translator cannot update these values in CDB
because to do so would render existing cellviews inconsistent with new units values.
The Display Resource File
The display resource file specifies how your layers appear on display devices. It defines
■ Display devices
■ Colors, stipple patterns, and line and fill styles
■ Display packets, which are collections of colors, stipples, and line styles associated with
particular display devices
If this file is located at the library level, it is copied to the CDB version of the library.
Cellviews
Cellview database files are translated from OpenAccess format to CDB format and the
filename extension is changed from oa to cdb.
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 CDB version
carefully to make sure it meets your needs. In some cases, you might need to fix the data in
OpenAccess and translate the cellview again.
Illegal OpenAccess names

DFII tools on both OpenAccess and CDB use the CDBA name space. For an OpenAccess
cellview to be translated it must have a name that is legal in the CDBA name space.
If the translator encounters an illegal cell or view name, it copies the contents of that cell or
view to CDB but does not translate them. This means that you could end up with OpenAccess
data in the CDB version of your library.
If a cellview contains an object (for example, a net or a pin) with an illegal name, the translator
translates the cellview but not the illegally-named object. Therefore, although the cellview
appears to have been translated to CDB, it is unlikely to be complete.
For information on how the translator handles name spaces, see “Name Spaces” on page 18.

Directories in Cellviews
Neither CDB nor OpenAccess supports directories in cellviews. The translator does not
convert directories contained in cellviews.
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.
Identifying the Master Cellview

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 view directory is the master. The master.tag
file is automatically created when the CDB cellview is created.
The Parent-Child Database File: pc.db

The parent-child database file, pc.db, typically resides in a CDB cellview directory and stores
the hierarchical relationships for that cellview. It is a derived file that allows many 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, the cdb2oa translator copies the pc.db file to OpenAccess only if there is no
CDB cellview database file to be translated. Otherwise it is skipped.
The oa2cdb translator behaves similarly: It copies a pc.db file to CDB only if there is no
OpenAccess cellview database file present. Otherwise the file is skipped with a message. If
the pc.db file is copied, its timestamp is preserved.
Cellview Attributes
The CDB attributes cellViewStatus and cellViewPurpose have no equivalents in
OpenAccess. They are set to unknown by oa2cdb.
The following attributes are not supported in CDB and are skipped by oa2cdb: cellType,
eeqMaster, siteDefName, and symmetry.
View Types
The translator converts the four OpenAccess view types to their CDB equivalents.

Timestamps and Counters

Timestamp properties are used for three main purposes in DFII tools.
■ To verify that the connectivity extracted for a particular cellview is current
■ To verify that the geometry of a cellview is current
■ To verify 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
❑ instancesLastChanged, which is updated whenever a cellview is edited
❑ lastSchematicExtraction, which is updated by the Virtuoso schematic
extractor, or by the Diva® or the Assura® layout extractors, whenever connectivity is
extracted for a particular cellview
❑ schGeometryLastRecorded, which is updated whenever a schematic cellview is
opened by the Virtuoso schematic editor
■ DFII on OpenAccess maintains a counter for each cellview, as well as for many other
database objects.
❑ 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 OpenAccess counters to CDB timestamp
properties.

Verifying Connectivity
Tip
Cadence recommends that you always run Schematic Editor’s Design – Check
and Save command on the CDB cellviews in order to re-extract the connectivity
information before using translated schematic and symbol data in your flows.
To verify that the connectivity extracted for a particular cellview is 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.
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.
The translator checks whether the connectivity data is current in OpenAccess.

■ If it is current (i.e., the cellview counter value is the same as the
connectivityLastUpdated property value), oa2cdb creates the CDB
lastSchematicExtraction time property with a value later than the
instancesLastChanged property value.
CDB applications comparing the values of the two properties find that the connectivity is
current.
■ If the connectivity was not current in OpenAccess, the translator does not create the
lastSchematicExtraction property in CDB.
CDB applications are able to determine that connectivity needs to be re-extracted for the
cellview.
Verifying Geometry
The translator uses a similar policy to establish the status of cellview geometry. In this case,
the schGeometryLastUpdated property is compared with the cellview counter value to
determine if the geometry of the cellview is up to date in OpenAccess.
■ If it is current (i.e., the cellview counter value is the same as the
schGeometryLastUpdated property value), oa2cdb creates the CDB
schGeometryLastRecorded property with a value later than the
instancesLastChanged property value.

CDB applications comparing the values of the two properties find that the geometry was
updated after the instance was last modified, therefore the geometry is current.
■ If the geometry was not current in OpenAccess, the translator does not create the
schGeometryLastRecorded property in CDB.
CDB applications are able to determine that geometry needs to be updated for the
cellview.
Verifying 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 of 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 as
an integer property 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 OpenAccess to CDB as follows:

■ If all the instances and their masters are in synch in OpenAccess and all the masters are
already available in CDB, the translator checks that the instancesLastChanged
property value on a cellview is greater than the maximum value of the
instancesLastChanged properties on all the masters plus one. If it is not, the
translator sets it to that value.
The next time an application compares the values, it detects that the instances were
changed after their master and therefore that the instances and masters are in synch.
■ If a master is not available or if there is an instance that is not in synch with its master,
the translator sets the instancesLastChanged property to zero and removes the
lastSchematicExtraction and schGeometryLastRecorded timestamps
altogether.
CDB applications will determine that all instances are out of synch with their master.

Paths with Extensions

In CDB, you can set any value for extensions, irrespective of the path style. In DFII on
OpenAccess, you cannot set a value for extensions unless the style is variable.
When translating paths with extensions, if the path style is not variable, the translator sets
beginExt and endExt to 0.
For information on differences in paths with extensions in CDB and OpenAccess, see “Paths
with Extensions” in Chapter 5 of the Virtuoso Design Environment Adoption Guide.
Labels
There are three types of label objects in CDB.
■ a normal label
■ an IL label
■ an NLP label
A normal label is equivalent to an oaText object in OpenAccess. An IL or NLP label is

equivalent to an oaEvalText object, each one associated to a specific text callback object
that contains the code to evaluate the text string before displaying it.
When converting an oaText object, there is a direct mapping for all OpenAccess attributes
except alignment, which is mapped to the justify attribute in CDB.
Each oaEvalText object is translated either to a CDB NLP label or an IL label depending
on whether the value of the name attribute of the oaDataCallback is _NLP_ or skill.
An oaEvalText object with a textDataCallback named _CDF_ and an integer property

called CDFDPFMT is converted to a CDB text display of type dbcParamAssoc.
oaEvalText objects with no text callback or with a text callback with an unknown name are
skipped with a warning to the log file.
Visibility Settings for Text Display Objects

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 OpenAccess settings as indicated in the table below.
OpenAccess CDB
isVisible format isVisible isNameVisible isValueVisible
t oacNameValueTextDisplayFormat t t t
t oacNameTextDisplayFormat t t n
t oacValueTextDisplayFormat t n t
n oacValueTextDisplayFormat t n n
n oacNameValueTextDisplayFormat n t t
n oacNameTextDisplayFormat n t n
n oacValueTextDisplayFormat n n t
n oacValueTextDisplayFormat n n n
Bounding Boxes of Labels and Text Displays

The bounding boxes of labels and 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
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.
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, the associated code is stored in the database as a SKILL procedure.

The translator converts the pcell master cellview as a regular cellview. It then retrieves the
parameter values from the OpenAccess master parameters and the SKILL code attached to
the master, and uses this information to transform the CDB regular cellview into a
parameterized master cellview.
Note: All the 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.
Magnification
CDB supports the magnification of instances but OpenAccess does not. To reproduce
magnified instances in OpenAccess, the cdb2oa 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. The pcell cellviews are
named viewName_xform.
When the oa2cdb translator encounters a pcell master with the mag and rotation
parameters, it converts it to a regular CDB cellview. Instances of such masters are translated
as regular magnified instances.
Properties
Design Database Files

The properties, groups, or extensions associated with a library, cell, or view are stored in
OpenAccess design database (dd.db) files located in the appropriate library, cell, or view
directory. For example, library properties are contained in a file called libName/dd.db.
The translator converts dd.db files to CDB prop.xx files (also known as property bags) by
mapping the OpenAccess properties to their CDB equivalents.
Note: OpenAccess dd.db files can store properties, groups, and extensions but CDB
prop.xx files store only properties. OpenAccess groups and extensions defined in dd.db
files are skipped.

Filename Type Properties

The CDB filename type property, dbcFileNameType, is not recreated by the translator
because this type does not exist in OpenAccess. The cdb2oa translator converts this
property to a string property in OpenAccess and oa2cdb converts it back into a string
property in CDB.
Nets and Signals

When converting nets, the translator sets the sigType and global attributes on all signals
associated with a CDB net. However, the following OpenAccess sigType values have no
equivalent in CDB: tieOff, tieHigh, tieLow, and reset. They are mapped to unknown
in CDB.
The connStatus attribute is skipped because its semantics are different in CDB and
OpenAccess.
The following attributes are skipped because they have no equivalent in CDB: original,
routePattern, routeSpec, shieldNet1, shieldNet2, source, and voltage.
Terminals
When converting terminals, the translator converts all the OpenAccess termType values to
their CDB equivalents except tristate, which is set to unknown and a warning issued to
the log file.
The OpenAccess routeMethod, pinConnectMethod, and antennaData attributes are

skipped because they have no equivalents in CDB.
Additionally, in CDB a net can be associated with at most one terminal, while OpenAccess
supports multiple terminals on each net. If the translator finds a terminal with the same net in
CDB, the terminal currently being translated is skipped with an error.
Pins
oa2cdb is able to convert only pins that are represented either by a shape or an instance
object. OpenAccess pins that are represented by routes are skipped with an error.
Additionally, the OpenAccess pinGroup and placementStatus attributes have no

equivalents in CDB and are therefore skipped.

Regular Instances
Two of the values for the placementStatus attribute – cover and none – do not in exist in
CDB. The translator sets these to unknown.
The priority and source attributes are skipped because they have no equivalent in CDB.
Mosaics
A mosaic is a database object in CDB 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 cdb2oa translator maps a simple mosaic to an OpenAccess arrayed instance.
Complex mosaics are not supported in OpenAccess so cdb2oa breaks up complex
mosaics into the individual instances that make up the mosaic before conversion.
■ The oa2cdb translator maps an OpenAccess regular arrayed instance with no instance
terminals to a simple mosaic instance in CDB. If the OpenAccess regular arrayed
instance has instance terminals, it is converted into several CDB scalar instances.
■ OpenAccess parameterized arrayed instances are translated into several CDB
parameterized scalar instances.
■ Complex mosaics are not regenerated.
For information on the issues around mosaics in CDB and OpenAccess, see section
“Mosaics” in Chapter 3 of the Virtuoso Design Environment Adoption Guide.
Instance Terminals
The OpenAccess routeMethod attribute had no equivalent in CDB and is skipped by the
conversion.
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 DFII applications, cdb2oa does not
create any instance pins in the OpenAccess version of the cellview. Similarly, oa2cdb does
not support the conversion of instance pins to CDB.

3
Using the OpenAccess to CDB Translator
from the Command Line
This section lists the arguments and switches you can use with the oa2cdb UNIX command
and describes how to use these to accomplish the most common translation tasks. The
oa2cdb executable is available at the following location.
your_install_dir/tools/dfII/bin/oa2cdb
Getting Help
To get help on the translator syntax and usage, type the following command in a shell window.
oa2cdb -help
This prints the argument descriptions provided later in this chapter.
The software displays the same information if you enter oa2cdb without specifying any
arguments.
Syntax
oa2cdb
-lib t_libName
-cdslibpath t_libPath
[ -cdblibpath t_cdbLibPath ]
[ --cell t_cellName... ]
[ -view t_viewName... ]
[ -view t_viewName... ]
[ -tech t_cdbTechLibName ]
[ -nooverwrite ]

Using the OpenAccess to CDB Translator from the Command Line
[ -incremental ]
[ -help ]
-lib t_libName
Specifies the name of the OpenAccess library to be translated.
Specify the name in the CDBA name space.
This will also be the name of the CDB version of the library.
You cannot use the translator to rename a library. If you need
your library to have a different name in CDB, rename the
OpenAccess version before translating it.
-cdslibpath t_libPath
Specifies the path to the OpenAccess cds.lib file, which
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.
-cdblibpath t_cdbLibPath
Specifies the directory in which the CDB library is created.
You can enter either a relative path or an absolute path. The
parent directory of the directory you specify must exist on your
system; the translator cannot create it automatically. The last
element of the path is the library directory into which the library
cells and other files are to be translated. The translator creates
this directory automatically.
If the library is already defined in the CDB cds.lib file, this

argument is considered illegal and the translator stops.
Note: The translator always creates or updates the CDB
cds.lib file in the current directory regardless of any
-cdblibpath specification.
-cell t_cellName...

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

names in the CDBA 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 names
in the CDBA 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_viewType...
Specifies the view types to be converted. Only cellviews that
map to one of the specified view types are translated.
Note: The view type is distinct from the view name used to
describe the view directory in the library file system. For
information on view types in OpenAccess, see the Virtuoso
Design Environment Adoption Guide.
-tech t_cdbTechLibName
Specifies the name of a CDB technology library to be attached
when creating a new library. The technology library you specify
must be defined in the CDB cds.lib file in the current
directory.
Note: Use this argument only when the CDB library does not
already exist and the OpenAccess library has its own
tech.db technology file. oa2cdb does not translate
technology files.
-nooverwrite
Prevents the translator from overwriting existing CDB library
data. Instead, it writes only data that does not already exist in
the CDB version of the library.
By default the translator overwrites existing data in the CDB
library.
-incremental

Incrementally translates only the routing data from

OpenAccess to CDB and adds the route information on top of
the cellview.
Note: The translated cellview should already exist on CDB
before this argument can be used.
-help
Prints this help text.
Converting a Library
Important
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 an
OpenAccess library, only those required to illustrate the point being described.
This example uses an OpenAccess library called design containing a number of different
cells. This library was previously converted from CDB using the cdb2oa translator.
user
oa
cds.lib
design
cell_1/
cell_2/
cell_3/
...
cdb
cds.lib
design
cell_1/
cell_2/
cell_3/
...

The cds.lib file defines design as follows:

DEFINE design ./design
Updating an Existing CDB Library

The translator use model assumes that the OpenAccess data to be converted originated in
CDB. This means that all required technology information, simulation data, rule decks, SKILL
files, scripts, and design management metadata exists already in CDB. You simply want to
convert design data modified in OpenAccess back to CDB.
To do this,
1. Move into the directory that contains the existing CDB cds.lib file.
user
oa
cds.lib
design
cell_1/
cell_2/
cell_3/
...
cdb Run the translator in this directory
cds.lib
design
cell_1/
cell_2/
cell_3/
...
2. Run the translator in the cdb directory using the following command line.
oa2cdb -cdslibpath ../oa/cds.lib -lib design
The translator
❑ Looks in the specified cds.lib file for the path to the OpenAccess library

❑ Establishes the existence and physical location of the CDB library from its definition
in the cds.lib file
❑ Translates the OpenAccess version of the library to CDB, overwriting the data in the
cdb/design directory.
user
oa
cds.lib
design
cell_1/
cell_2/
cell_3/
...
cdb
cds.lib CDB version of the cds.lib file

design Library directory
cell_1/
Cellviews updated in this directory.
cell_2/
cell_3/
...
The CDB cds.lib file defines 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
-cdblibpath argument to direct the CDB version of the library to a specific directory.
The -cdblibpath argument accepts either a relative or an absolute path. The parent
directory of the directory you specify must exist on your system; the translator cannot create
it automatically. The last element of the path is the library directory into which the library cells
and other files are to be translated. The translator creates this directory automatically.

If the library is already defined in the CDB cds.lib file, the translator stops. You can use this
option only when the CDB version of the library does not exist.
Important
Regardless of any -cdblibpath specification, the translator always creates or
updates the cds.lib file in the run directory. To ensure that the correct cds.lib
file is updated and that access to the CDB version of the library is correctly
maintained, Cadence recommends that you always run the translator from the top
level of the CDB library.
For an example of how to use -cdblibpath, see Converting Multiple Libraries on page 43.
To translate the design library into a specified directory,

1. Create a new directory for the new CDB version of the library.
user
oa
cds.lib
design
cell_1
cell_2
cell_3
...
cdb Start the translator in this directory
cdbNew CDB library to be placed in this directory
2. Run the translator in the cdb directory.

oa2cdb -cdslibpath ../oa/cds.lib -lib design -cdblibpath ../cdbNew/design
The software
❑ Looks in the specified cds.lib file for the path to the OpenAccess library
❑ Creates or updates the CDB cds.lib file in the current directory, cdb.

❑ Creates the cdbNew/design directory and translates the data into it.
user
oa
cds.lib
design
cell_1
cell_2
cell_3
...
cdb
cds.lib CDB version of the cds.lib file
updated in the current directory
cdbNew
design
cell_1 Cellviews translated into the new library.
cell_2
cell_3
...
The OpenAccess cds.lib file defines the library as follows:

DEFINE design ../cdbNew/design
Converting a Cellview
To translate a specific cellview to OpenAccess,
➤ Use the -cell and -view arguments on the command line.
oa2cdb -lib design -cdslibpath ../oa/cds.lib -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 Multiple Libraries

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 directory structure might look like this.
user
oa
cds.lib
design
devices
deviceLib1
deviceLib2
reflibs
refLib1
refLib2
To translate this database, you need to

1. Set up the file system structure for the CDB version of the library if it does not exist
already
2. Determine the correct sequence of translation
3. Run oa2cdb once for each of the libraries in the database
Setting up the Structure for the CDB Version of the Library
Important
If your OpenAccess data originated in CDB, the correct directory structure exists
already in CDB and is represented in the existing cds.lib file. When converting
the libraries, oa2cdb will automatically translate them into the correct locations. The
-cdblibpath argument is not required.

If you are translating multiple libraries from OpenAccess to CDB for the first time, Cadence
recommends that you set up the directory structure for the CDB version of the database
before you start. Then use the -cdblibpath 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.
Important
Regardless of any path specified using -cdblibpath, the translator always
creates or updates the cds.lib file in the current working directory.
To set up the directory structure for the CDB libraries,

➤ Create a top level directory to contain the CDB version of the cds.lib file and parent
directories to contain the libraries to be translated.
user
oa
cdb Start the translator in this directory
design
devices
reflibs
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 CDB at the time they are referenced. The translator cannot
determine this sequence automatically. You must do it manually and run the translator
separately on each of the libraries in turn.
To determine the correct sequence of translation,

1. Identify the top cellview in your design and open it in your Virtuoso design environment.
2. Type Shift-f to display all the levels in the design.
3. Click Design – Hierarchy – Tree, select Current to Bottom, and click OK.
The layout editor opens the Tree window showing the entire hierarchy of instances inside
the current cellview.
Design Hierarchy
****************************************************************************
Library : design
Cell : top_cell
View : layout
Option : Current to bottom
****************************************************************************
refLib1 cell_1 layout (5)

.
.
.
(truncated)
The indentation shows the hierarchical relationships between the cellviews listed. The
numbers in parentheses tell you how many instances of each cellview are present. For
example, design top_cell layout contains 5 instances of cellview refLib1
cell_1 layout, 1 instance of refLib1 cell_2 layout, and so on.
4. Translate the libraries one at a time, working from the lowest level library up to the top
cellview.
oa2cdb -lib refLib2 -cdslibpath ../oa/cds.lib -cdblibpath reflibs/refLib2
oa2cdb -lib deviceLib2 -cdslibpath ../oa/cds.lib -cdblibpath devices/
deviceLib2
pa2cdb -lib deviceLib1 -cdslibpath ../oa/cds.lib -cdblibpath devices/
deviceLib1
oa2cdb -lib design -cdslibpath ../oa/cds.lib -cdblibpath 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.
For example:
refLib1/cell_4/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
****************************************************************************
.
.
.
.
.
.
(truncated)
To resolve the dependency shown,

1. Use the -cell and -view arguments to translate only cellview refLib1/cell_6/
layout.
oa2cdb -lib refLib1 -cdslibpath ../oa/cds.lib -cdblibpath reflibs/refLib1 -
cell cell_6 -view layout
2. Translate library refLib2.


3. Translate the rest of library refLib1, using the -nooverwrite option to prevent the
cellview translated previously from being translated again.
oa2cdb -lib refLib1 -cdslibpath ../oa/cds.lib -nooverwrite
Note: Because refLib1 exists already, you do not need to use -cdblibpath. The
library is updated automatically in the correct location.


Index
A D
application infrastructure files display resource file, display.drf 25
cds.lib 21
cdsinfo.tag 22
E
B empty cellviews 26
bounding boxes, differences in 31

L
C labels
CDB log file
introduced 11 CDS_LOG_PATH 16
versions supported 12 CDS_LOG_VERSION 16
cds.lib location 16
converting 21 messages excluded 17
cdsinfo.tag 22 naming convention 16
cellviews structure 16
determining the sequence of
translation 15 M
directories in 26
empty cellviews 26 magnification 32
instance pins 34 master.tag file 26
instance terminals 34 mosaics 34
magnified 32 multiple libraries 43
master.tag 26 determining the sequence of
parameterized cells See parameterized translation 44
cells resolving circular dependencies 45
paths with extensions 30
pc.db 26
view types N
mapping from OpenAccess to
CDB 26 name spaces
visibility settings for text display illegal CDBA names 20
objects 30 in log file messages 20
command line introduced 18
validation 14 mapping special characters from CDB to
counters See timestamps LibraryUnix 19
specifying object names 19

O verifying geometry 28
verifying the currency of a placed
oa2cdb instance and its master 29
getting help 35 translating
location of executable 35 from the command line 35
overview of the translator multiple libraries 43
engine 14 to 16 determining the sequence of
syntax 35 translation 44
OpenAccess resolving circular dependencies 45
DFII on OpenAccess 11 single libraries
illegal names in 20 into a target directory 43
introduced 11 troubleshooting
standard OpenAccess 11 log file 16
versions supported 12
U
P usage
parameterized cells oa2cdb 35
introduced 31
SKILL functions in 32
parent-child database file, pc.db 26 V
pcells See parameterized cells
properties 25 versions
CDB and OpenAccess versions
supported 12
R visibility settings 30
for text display objects 30
related documents 7
S
syntax
command line validation 14
conventions 8
getting help with 35
oa2cdb 35
T
display.drf 25
text display objects
visibility settings 30
timestamps
introduced 27
verifying connectivity 28

Cadence CDB To OA

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Cadence CDB To OA

Diunggah oleh

Hak Cipta:

Format Tersedia

OpenAccess to CDB Translator User Guide

Product Version 6.1.5

March 2012 3 Product Version 6.1.5

Layers, Purposes, and Layer-Purpose Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

March 2012 4 Product Version 6.1.5

Converting into a Specified Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

March 2012 5 Product Version 6.1.5

March 2012 6 Product Version 6.1.5

Related Documents for OACDB

March 2012 7 Product Version 6.1.5

Installation, Environment, and Infrastructure

Typographic and Syntax Conventions

March 2012 8 Product Version 6.1.5

text Indicates text you must type exactly as it is presented. These

z_argument Indicates text that you must replace with an appropriate

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

[ ] Indicates and encloses optional argument(s) except when they

| Separates a choice of options.

… Indicates that you can repeat the previous argument.

=> Precedes the values returned by a Cadence® SKILL language

/ Separates the possible values that can be returned by a

March 2012 9 Product Version 6.1.5

March 2012 10 Product Version 6.1.5

DFII on OpenAccess and Standard OpenAccess

Type of Data DFII on OpenAccess Standard OpenAccess

March 2012 11 Product Version 6.1.5

DFII on CDB DFII on OpenAccess

Database Versions Supported

March 2012 12 Product Version 6.1.5

Running the Translator in 64-bit Mode

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

2. Run the translator from the command line.

Use Model of the OpenAccess to CDB Translator

March 2012 13 Product Version 6.1.5

■ Translate selected cells, cellviews, and view types.

OpenAccess to CDB Translator Engine

Command Line Validation

March 2012 14 Product Version 6.1.5

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

The conversion covers

The translator converts data in the sequence indicated below.

March 2012 15 Product Version 6.1.5

2. Data at Cell and Cellview Level

March 2012 16 Product Version 6.1.5

The Messages section records the messages issued by the translator.

March 2012 17 Product Version 6.1.5

ERROR (OACDB-653): Cannot translate <number> instance terminals for instance

Generated 118 times.

WARNING (OACDB-527): Layer-purpose pair ‘<layerName> <purposeName>’ is not

The Translator in the Cadence DFII Environment

Environment Variables Files

March 2012 18 Product Version 6.1.5

Purpose CDBA LibraryUnix

Purpose CDBA LibraryUnix

Specifying Object Names in the Translator

For example, If you specify the following command line

March 2012 19 Product Version 6.1.5

oa2cdb -lib lib.1 -cdslibpath ../oa/cds.lib -cell cell.1 -view layout.old

the translator converts the following cellview stored on disk

Illegal Names in the CDBA Name Space

Name Spaces in Log File Messages

March 2012 20 Product Version 6.1.5

Application Infrastructure Files