To reduce costs, circuit designers have developed design libraries which contain numerous standard design objects grouped by specific function, along with known electrical operating characteristics and parametric values including, for example, resistance and capacitance. Standard cell libraries are illustrative of design libraries that contain commonly used medium-scale integration (MSI) structures such as decoders, registers, and counters and commonly used large-scale integration (LSI) structures such as memories, programmable logic arrays, and microprocessors. The circuit designer utilizes the standard cells and custom cells to design and optimize the layout of circuit by, for example, reducing propagation delays and minimizing the size of the chip to increase the number of chips which can be fabricated on a single wafer.
The organizational and usage structure of design libraries is not without limitations, however. In particular, the requirements of librarians, i.e., design users performing updates on the library, and other users requiring access for design implementation are usually incompatible, thereby resulting in an unwieldy and inefficient database management system. Librarians require the library to be on an “unstable” platform to load updates. Design end-users, however, require constant access to the library on a “stable” platform in order to design a circuit, due to the inherent time constraints on a circuit design project. Typically, librarians require many hours of “downtime” to completely load and compile the library updates. Further, the amount of downtime may increase if the library updates fail to compile or, once compiled, crash the computer system containing the libraries.
A system and method are disclosed that provide for updating a library in a design database environment operable to be accessed by at least one design user. In one embodiment, a first engine associates an update file with appropriate design objects to generate an uncompiled update file in a trusted space environment. A second engine associated with the trusted space environment compiles the uncompiled update file into a compiled update file. A third engine transfers the compiled update file from the trusted space environment into the library in the design database environment.
In the drawings, like or similar elements are designated with identical reference numerals throughout the several views thereof, and the various elements depicted are not necessarily drawn to scale. Referring now to
In one embodiment, the libraries 108-118 define a standard cell library that represents the development of the physical layout of a circuit design for all design circuit elements including leaf cells ranging from simple gates to latches and flip-flops. Further, the standard cell library may be a process-optimized cellular layout that takes advantage of special layers, local interconnects, and other features that may be unique to a given fabrication and design process. In this respect, the standard cell library described herein may be a generic library, a vendor process specific library, or a combination thereof. Each of the cells and sizes described in the library include the necessary port and connectivity information required for schematic, i.e., synthesis based, auto place-and-routing. Moreover, the standard cell library is fully interfaceable with a synthesis tool such that an adequate selection of cells and sizes of these cells may be made by manipulating the original netlists.
At the same level of hierarchy as the library structures 108-118, a structure having a suite of scripts that facilitate and govern the movement and validation of the data between the library structures 108-118 is also provided. A validation script is included for running a number of pertinent IC design tools on an individual cell, a list of cells, or a block. A global list of all cells used in the library infrastructure is also provided in the script structure. In one configuration, this global list may be comprised of artwork and schematic of every cell individually placed with space in between them. Other scripts such as update_lib and copy_lib script are operable to update and copy a LIB structure. Other structures at this level of hierarchy may comprise entities for performing maintenance-related functions. For example, a verilog_validation structure is operable to contain a Verilog behavioral description of all cells in the composite list of the cells. A valid_cell structure is operable as a script to validate the correct Verilog modeling of the cells therein. A check_in_out structure may be provided as a entity containing scripts that govern check_in, check_out and back_up functionality with respect to the various cells. Another structure, designated as xchecks, is operable to contain various lists and scripts pertaining to performing a final cross-checking of the library cells. Additionally, a lib.log file may be provided containing all known modifications.
The library organization described herein provides for effective management and use of the libraries 108-118 in the design database environment 102. As alluded to hereinabove, synthesis interface 120 of interface 104 facilitates file updates to any of the libraries 108-118 by a librarian 122 or User 1124—User N 128 by providing a trusted space in which the file updates can be built before being transferred to the appropriate library or libraries. As used herein, “trusted space” and “trusted space environment” are deemed to be equivalent and generally mean a computer-supported memory space or a process therein that is relatively impervious to other processes and threads being executed on the computer platform. Further, the design database arrangement provides both a main primary library, i.e., the library 108, which is undisturbed and a mirror library, i.e., the library 110, which may be accessed for updating. With this arrangement, the librarian may install and build a release of updates in the library 110 without interfering with the users' utilization of libraries 108 and 114-118. Moreover, while users 124-128 interface with libraries 108 and 112-118 in the design database environment 102, the librarian 122 can utilize the synthesis interface 120 so that the librarian may develop synthesis updates away from the design database environment 102 on a stable platform.
Once the release of updates is installed in library 110, at a point which will cause minimal inconvenience to the users, the updates may be propagated to the other libraries with the utilization of the aforementioned suite of scripts. Moreover, the synthesis interface 120 allows for real time/minimum downtime synthesis updates and a central depository to archive these updates with respect to the various library versions 108-118. In one embodiment, to transfer the updates from library 110 to library 108, library 108 may be redefined such that library 108 resides in the unstable space and may be accessed by at least one librarian. Similarly, library 110 may be redefined such that library 110 resides in the stable space and may be accessed by at least one user. Alternatively, the permissions associated with library 108 and library 110 may be changed such that library 108 resides in the unstable space and library 110 resides in the stable space.
Each of the custom and synthesis structures 204 and 206 contain the same design elements, e.g., cells. In particular, the custom file structure 204 includes file structures relating to gates 210, latches 212, passive design elements 214, and combinatorial design elements 216. The combinatorial design element file structure 216 may be further divided into a static file structure 218 and a dynamic file structure 220. Similarly, the synthesis file structure 206 includes gates 224, latches 226, passive design elements 228, and combinatorial design elements 230 that may be further divided into static 232 and dynamic 234 design elements. It should be appreciated that although the same cells may be provided in the custom and synthesis structures, custom and synthesis design elements have different maintenance requirements and the separation of the custom and synthesis cells provides more power to the librarian to meet the needs of users.
As will be discussed in greater detail hereinbelow, a synth files structure, which is disposed at the same hierarchical level as the custom structure 204 and synthesis file structure 206, contains files pertinent to synthesis and the updating of the files of the synthesis structure 206. In particular, the synth files structure 208 supports a link from a portion of the synthesis interface in order to effectuate the transfer of the update files from the design user space 106 to the design database environment 102. It should further be appreciated that the teachings disclosed herein are compatible with any standard cell format and are not limited to the hierarchical arrangements presented herein.
With respect to the LIB 2 file structure, an archive file structure 262 provides a symbolic link to an archival database which may be used as a single storage area for all generated synthesis file packages and file updates relating to LIB 2. Accordingly, in operation, after a copy of the contents is built and transferred to the appropriate library in the design database environment, the archival file structure 262 transfers the contents to the archival database. A build structure 264 contains the scripts required to build the update files and the space for building the update files.
In one embodiment, the scripts include a lef_“process_id” script and a lib_“process_id” script used for synthesizing and processing the content of the aforementioned core_files file structure. Each synthesis cell also contains a script file structure 266 that includes, for example, files relating to synthesis operations such as defining physical structure and timing paths of the design objects.
Once all of the pertinent files are placed in the build directory and built, they can all be copied into a current structure 268, which as will be described in further detail hereinbelow, comprises a convenience link in the form of a symbolic link to the synth files structure of LIB 2. Hence, all of the data encapsulated by the script file structure 266 and the build structure 264 in the trusted space provided by the build structure 264 can be transferred to the synth files structure of LIB 2 substantially instantaneously, causing minimal downtime for users. Specifically, by building, i.e., compiling, testing, and related operations, the file updates prior to their transferring, not only can the file updates be substantially instantaneously transferred but any file corruptions that occur in the synthesis interface 252 are not propagated to the design database environment.
The transfer engine 318 utilizes a current file structure 322 to transfer the compiled files 316 from the trusted space environment 302 to a library 324 in the design database environment 304. By only transferring compiled files 316 which are completely tested and built, it should be appreciated that the resources of the design database environment 304 are not unnecessarily expended or tied-up. Similar to the library 200 described in
In one embodiment, the compiled files 316 are transferred from the trusted space environment 302 to the synth files structure 332 via symbolic link 334. The symbolic link 334, i.e., a “symlink” or “soft link,” is a link which refers to another file by its pathname. In contrast to a hard link, a symbolic link has no restrictions as to where it can point. Hence, the symbolic link can point to another file in another data structure residing in another system or design space. In the illustrated example, the current file structure refers to the synthesis file structure 332, which receives the compiled files 316 from the trusted space environment 302 and integrates the compiled files 316 into the synthesis file structure 330. After the update files are transferred and successfully installed in the target library 324, the transfer engine 318 may utilize an archive file structure 338 and a symbolic link 340 to transfer the compiled files 316 from the trusted space environment 302 to an archive data structure 336. It should be appreciated that although the archive data structure 336 is depicted in the design database environment 304, the archive data structure 336 may also be in an environment that is different from the environment of library 324.
Each of the script engine 308, compiler 314, and transfer engine 318 may comprise any combination of hardware, software, and firmware. Moreover, the script engine 308, compiler 314, and transfer engine 318 may be supported and/or embodied by the file structures discussed in association with
Although the invention has been particularly described with reference to certain illustrations, it is to be understood that the forms of the invention shown and described are to be treated as exemplary embodiments only. Various changes, substitutions and modifications can be realized without departing from the spirit and scope of the invention as defined by the appended claims.