 |
 |
 |
 |
 |
 |
 |
 |
 |
|
|
|
|
|
|
|
|
|
When you save an oaDesign, it is typically written to a file in an oaCellView. That file is the primary file. See oaCellViews in OpenAccess Libraries and Design Management for more information about primary files.
An oaDesign can have associated, non-primary files. For example, the design might have parasitics that are stored in a separate, non-primary file. The name of the non-primary file is determined by the design management (DM) system for the containing library and is not determined by OpenAccess.
Applications can add additional files to an oaCellView that contains an oaDesign database. If these files contain additional information about the design, they should be set as followers of the design database file. See Leader-Follower File Associations in OpenAccess Libraries and Design Management for more information.
When you save an oaTech, is it saved as a file in an oaLib.
An oaDesign can be read by many processes simultaneously, but can only be written to (or appended to) by a single process. When an oaDesign is opened for write or append, OpenAccess locks the database file.
If the oaCellView already exists and has a previous database, the database will be locked, but nothing will be written into the library at this time. If the oaCell, oaView, or oaCellView do not exist, they are created when the lock is established. If that database is closed without saving, then its oaCell, oaView, and oaCellView are deleted if they are otherwise empty.
It is possible for reader processes to have a database open at the same time as the single writer process. If readers are active when the oaDesign is opened for write, the readers continue to see the older copy of the database, even if it has not been read in completely. Processes that open the oaDesign for read (r) after it has been opened for write (w) continue to get the old database contents until the writer saves the database. Readers never get an error and never get a mix of old data and new data. Readers do not see the new data unless they close the oaDesign and reopen it.
For details about how file locking is handled in the OpenAccess FileSys Design Management system, see File Locking.
If you close an empty oaDesign that has never been saved, an empty primary file remains in the oaCellView. The oaCell and oaView empty containers are left behind as well.
An oaDesign opened in 'w' mode is entirely empty. Any objects created are only in memory (not on disk) until the design is saved. Even after a save, the design is available in memory until it is purged or all opens of it are closed and all instHeaders to which it is bound are removed.
OpenAccess can partially read in designs. When an oaDesign is opened in 'a' or 'r' modes, objects of a given type are read in as you touch a given class. Touch refers to actions such as creating an object of a specified class or iterating over the object type.
Partial read-in does not apply to small designs (currently, those less than 128Kbytes). For designs over 128Kbytes, object type categories are unread until the first object of that type is accessed. At that time, all objects of that type are read into memory. The granularity of what is read at a single touch can be determined by the oaDesignDataTypeEnum values. For example, one entry is oacNetDataType. This determines that all oaNets are read together, not just subclasses such as oaScalarNet.
For each partially read design, OpenAccess must keep an open file descriptor. This descriptor is released when a design is completely read. The current OpenAccess database implementation allows a maximum of 128 such partially read designs per session. If an additional design is opened after an initial 128 are opened and partially read, the smallest of the partially read designs is completely read, and its file descriptor is released.
If a database is partially read over an NFS filesystem, OpenAccess creates an .oacache file to preserve the original state of the data for the reader even if the database is subsequently written by another process. OpenAccess removes these .oacache files when they are no longer needed. Note that .oacache files are hard links and do not consume additional disk space unless another process overwrites the original database.
Parasitic data does not follow this pattern. Parasitics can be paged in and out explicitly by API load and unload calls. This means that not all of a design's parasitics are in memory at one time. Also, a specified net's parasitics can be paged out before a design is closed, even if the parasitics are modified.
When an oaDesign opened in append or write mode is saved, the data is first written to a temporary file. After the write completes, the temporary file is renamed to the persistent filename. This way, if a save operation fails for any reason, it does not corrupt the previously saved oaDesign on disk.
When you use parasitics, OpenAccess creates a temporary file that holds any modified parasitic data that is paged out. This can happen even if the design is in read mode because it is possible to modify designs in this mode. This temporary file is used until the containing oaDesign is closed or saved. If the oaDesign is saved, the parasitic data is copied to the persistent parasitic file. If the oaDesign is closed without saving, the temporary file is discarded and the parasitic information is lost.
Return to Programmers Guide topics
Copyright © 2001-2010 Cadence Design Systems, Inc.
All rights reserved.