 |
 |
 |
 |
 |
 |
 |
 |
 |
|
|
|
|
|
|
|
|
|
OpenAccess 2.2 incorporates new and expanded capabilities for library and design management (DM). The library structure is improved and provides the ability to store associations between files, the ability to use AppDefs on library objects, and a Version Control API. Libraries have access modes (shared, non-shared, and read-only) to specify how the library will be available to clients.
The new features and enhancements to library management are:
See also: OpenAccess Libraries and Design Management in the Programmers Guide.
In addition to the traditional directory-based model that uses the file system, a new server-based DM system relies on a database to persistently record and manage library files. Both design management (DM) systems are included with OpenAccess as alternative plug-in solutions.
OpenAccess supports version control for versioning, check out, check in, and change history for library contents. A third-party version control solution can be incorporated through the OpenAccess plug-in interface.
The library API is expanded significantly. You can use a lib.defs file to identify libraries and their paths, and you can open all existing libraries at once by reading this file. You use the following API to open all libraries included in the default lib.defs file:
oaLibDefList::openLibs()
To locate lib.defs, this function performs a search that includes your current directory, your login directory, and the data directory for your installation hierarchy.
If you prefer, you can devise your own library definition file naming convention and read your library definition file by supplying the filename. For example:
oaLibDefList::openLibs("../projectLib.defs")
See also: Library Definition Files in the OpenAccess Libraries and Design Management article of the Programmers Guide.
You can open a library directly, without using the lib.defs file, by using:
oaLib::open(const oaScalarName &name,
const oaString &libPath,
const oaString &writePath="",
oaLibMode mode=oaSharedLibMode)
When an application adds or deletes a library, the lib.defs file should be updated accordingly.
See: Changing the Library Definition File in the OpenAccess Libraries and Design Management article of the Programmers Guide.
The access mode for a library is specified when the library is opened using oaLib::open. When using oaLibDefList::openLibs, the access mode can be specified by an ASSIGN statement in the library definition file.
OpenAccess provides shared, non-shared, and read-only library access modes, with the default being shared. Each mode is valid only if the DM system implementation supports it.
See also: Accessing Objects in Libraries in the OpenAccess Libraries and Design Management article of the Programmers Guide.
Applications call oaLib::getAccess on a library to establish access. At this point, the application can get data out of the library as shown in this example, which gets the primary file in an oaCellView:
oaNativeNS nameSpace;
oaScalarName(nameSpace, "viewName");
if ( lib1->getAccess(oacReadDMTransType) ) {
oaCell *cell = oaCell::get(lib1, oaScalarName(nameSpace, "cellName"));
oaView *view = oaView::get(lib1, oaScalarName(nameSpace, "viewName"));
oaCellView *cv = oaCellView::get(cell, view);
oaDMFile *cvfile = cv->getPrimary();
cvfile->getPath(filePath);
lib1->releaseAccess();
}
The application calls oaLib::releaseAccess when finished with the current traversal. All pointers to DM objects (other than the oaLib itself) become invalid as soon as the access is released.
See also: Accessing Objects in Libraries in the OpenAccess Libraries and Design Management article of the Programmers Guide.
OpenAccess provides two design management (DM) systems. The new system is a server-based, database solution that is more efficient and improves overall system performance. The other is based on the traditional directory-based solution that uses the file system to manage libraries and design data. These DM solutions are designated as:
See also: DM Systems in the OpenAccess Libraries and Design Management article of the Programmers Guide.
The Turbo DM system uses a database and server-based implementation to provide a high-speed design management solution. This system supports library attributes that you use to specify the server host, port number, log filename, and a third-party version control system. The Turbo system supports leader-follower associations among library files. When a leader is destroyed, the operation is applied to all followers. When a version control operation is applied to a leader, the operation also is applied to the followers. The Turbo files and organization are intentionally opaque. Access to libraries through the Turbo system are entirely through the API.
The FileSys DM system organizes library information using a directory structure of the file system. This system provides compatibility with previous versions of OpenAccess. Library files are stored in directories with names based on the cell and view names of the object. When you choose the FileSys DM system for a library, you can include an attribute to designate a third-party version control system.
Libraries are logical containers that are represented as oaLib objects. Within libraries are oaCell (cell containers), oaView (view containers), oaCellView (cellView containers), and oaDMFile objects. Each cellView includes one oaDMFile, which is the primary file that holds the primary data for a cellView. The following figure shows the organization of the library and relationships among the library objects.
Each view has a designated view type, which is persistent. The view type is designated using the oaViewType object. Several reserved view types include maskLayout, schematic, netlist, and wafer. You create a view type using:
oaViewType::get(oaReservedViewType type)
When you open a design database, you designate a view type using the following API:
oaDesign::open(const oaScalarName &libNameIn,
const oaScalarName &cellNameIn,
const oaScalarName &viewNameIn,
const oaViewType viewType,
oaChar mode)
You can get the primary file for a cellview by using the API:
oaCellView::getPrimary()
In addition to the library name, path, access mode, and persistent attributes; you designate the DM system for a library when it is created. You use the API:
oaLib::create(const oaScalarName &name,
const oaString &libPath,
oaLibMode mode=oacSharedLibMode,
const oaString &dmSystem="oaDMTurbo",
const oaDMAttrArray *dmAttrList=NULL)
Applications choose a DM system at run time by using a plug-in interface to load a shared library. This plug-in interface uses programming techniques similar to those used in the Microsoft ® COM technology. The DM plug-in implementation provides a versionable interface that can be revised or upgraded to provide new functionality without breaking prior versions of the interface. The following figure illustrates the DM plug-in implementation.
OpenAccess does not include a version control implementation, but a third-party version control plug-in can be loaded by OpenAccess at runtime.
For more information, see Example Version Control Code in How to Write a Plug-in.
Copyright © 2003-2010 Cadence Design Systems, Inc.
All rights reserved.