US20130091098A1 - Method of speeding up access to design databases having large numbers of design units - Google Patents
Method of speeding up access to design databases having large numbers of design units Download PDFInfo
- Publication number
- US20130091098A1 US20130091098A1 US13/449,334 US201213449334A US2013091098A1 US 20130091098 A1 US20130091098 A1 US 20130091098A1 US 201213449334 A US201213449334 A US 201213449334A US 2013091098 A1 US2013091098 A1 US 2013091098A1
- Authority
- US
- United States
- Prior art keywords
- file
- files
- design
- computer
- archive
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
Definitions
- the invention relates in general to a method for file accessing, and more particular to a method for speeding up file accessing to design databases for integrated circuits (ICs).
- ICs integrated circuits
- Design databases for electronic design automation (EDA) tools typically store design units on a file basis, that is, one design unit takes one disk file to store. Furthermore, there is some kind of correlation between a design unit name and its corresponding disk file name. There are some immediate advantages using this scheme.
- OS operating system's
- ls on UNIX
- the design database manager can take advantage of the services that the OS's file system offers, for example, file locking and file renaming.
- FIG. 1A shows an example of directory tree used by OpenAccess DMFileSys data manager to implement a design library.
- a design unit in OpenAccess is called a cellview.
- Each cellview, in DMFileSys mode, takes at least two levels of sub-directories and two files therein to implement.
- the first-level sub-directory is right underneath the root directory of the library, and the name of the sub-directory follows the cell name part of the cellview.
- Right underneath the cell sub-directory is a second-level sub-directory for the view name part of the cellview.
- the view sub-directory includes two files: master.tag and layout.oa.
- the master.tag is a text file that describes the name of the primary database file in the sub-directory; the layout.oa is the layout view for the design unit. In DMFileSys, therefore, if there are N cellviews in a design library, it will take 2N directories and 2N files to implement.
- FIG. 1B demonstrates another example of directory tree structure in OpenAccess used by a data manager called DMTurbo.
- DMTurbo there is an XML file, called lib.xml, in the library directory.
- lib.xml XML file
- the mapping of a cellview name to its corresponding file name is described in lib.xml.
- N+1 the number of directories and files on the disk is substantially smaller than that of DMFileSys, but which still incurs large amounts of overhead when the number of cellviews is large.
- the one-file-per-design-unit scheme will therefore create a huge number of files on disk in a design database. Consequently, performance of EDA tools will come to a halt when they have to access these kinds of databases.
- One object of the present invention is to speed up database access of the electronic design automation (EDA) tool.
- the EDA tool accesses a plurality of design files, and each of the plurality of design files is associated with one of a plurality of design units for an integrated circuit (IC).
- IC integrated circuit
- the plurality of design files are encapsulated into an archive file, that is, the archive file comprises a plurality of data units, wherein each of the data units corresponds to a design file.
- a request to read a design file will be redirected to read the corresponding data unit in the archive file.
- a fast storage is introduced to further speed up file access.
- the corresponding data unit for the design file is first extracted from the archive file to the fast storage. Then the design file is returned from the fast storage.
- a request to save an updated design file will be redirected to update the corresponding data unit in the archive file.
- FIG. 1A and FIG. 1B are examples showing the directory trees created by an existing database manager
- FIG. 2A and FIG. 2B are schematic flow diagrams for handling a design file read request in accordance with current invention
- FIG. 3A and FIG. 3B are schematic flow diagrams for handling a design file save request in accordance with current invention
- FIG. 4A and FIG. 4B are schematic block diagrams depicting two embodiments of the software architecture in accordance with current invention.
- FIG. 5A illustrates an example of disk file structure and data reading flow applied on an existing database manager in accordance with current invention.
- FIG. 5B illustrates an example of disk file structure and data saving flow applied on an existing database manager in accordance with current invention.
- an “archive” concept is introduced for improving the performance of existing electronic design automation (EDA) tools that need to access a huge number of design files on disks.
- EDA electronic design automation
- FIG. 2A shows a schematic flow diagram in one embodiment of the invention.
- the design files for an integrated circuit (IC) design are encapsulated into an archive file
- the archive file comprises a plurality of data units, wherein each of the plurality of data units corresponds to a design file (step 21 ).
- a request is provided to read a design file (step 22 ).
- the request is redirected to read the archive file (step 23 ).
- the corresponding data unit for the design file can be returned (step 24 ). Since the size of a data unit can be variable, an index table can be used to indicate the size and location of the corresponding data unit in the archive file.
- step 24 further comprises three sub-steps as illustrated in FIG. 2B .
- the corresponding data unit is extracted from the archive file to a storage device (step 241 ).
- the storage device can be a hard disk or a fast storage including a random access memory (RAM) disk or a solid state drive (SSD) for speeding up the file access.
- RAM random access memory
- SSD solid state drive
- the corresponding data unit in the storage device can be returned for the design file (step 242 ).
- the current data unit is deleted from the storage device after being returned (step 243 ).
- a design file may be updated and need to be saved back to the archive files.
- FIG. 3A illustrates the corresponding schematic flow diagram.
- a request is provided to save the design file (step 31 ), and then the request is redirected to save the corresponding data unit for the design file into the archive file (step 32 ).
- the corresponding data unit size information in an index table is updated due to the changes of design file.
- the corresponding location information in the index table is also updated if the original location and space cannot fit the updated data unit.
- step 32 further comprises three sub-steps.
- the request is redirected so that the design file is saved into a storage device (step 321 ).
- the storage device can be a hard disk or a fast storage including a random access memory (RAM) disk or a solid state drive (SSD) for speeding up the file access.
- RAM random access memory
- SSD solid state drive
- the design file in the storage device is saved into the archive file as a data unit (step 322 ).
- the current design file is deleted from the storage device after being saved (step 323 ).
- the design files for the integrated circuit (IC) design can be encapsulated into more than one archive file, wherein the number of archive files is dramatically smaller than the number of design files.
- a single design file can be split into multiple archive files.
- a data unit of an archive file may refer to only a portion of the single design file.
- Block 41 represents the EDA tool application which provides requests to access design files through application file access interface (dash line 411 ) provided by an existing database manager.
- Block 44 is the file access functions of database manager for accessing design files from a storage device.
- Block 43 is an archive file system which stores the archive file.
- Block 42 is an adaptation layer which contains functions wrapping the file access activities underneath.
- Block 45 is a storage device such as hard disk system which can be accessed by the database manager through the file access functions of the database manager (block 44 ).
- the request is redirected to the corresponding wrapper functions in block 42 to locate corresponding data unit in the archive file for the design file and extract the corresponding data unit to the hard disk system (block 45 ).
- the file access functions of database manager (block 44 ) can read the corresponding data unit from the hard disk system (block 45 ).
- the corresponding wrapper functions in block 42 will delete the data unit in the hard disk system (block 45 ).
- a write (save) request for a design file is provided through the application file access interface ( 411 )
- the request is redirected to the corresponding wrapper functions in block 42 to call the file access functions of database manager (block 44 ) to update the design file by saving the design file into the hard disk system (block 45 ).
- the corresponding wrapper functions in block 42 will update the corresponding data unit in the archive file according to the design file in the hard disk system (block 45 ) and then delete the design file in the hard disk system (block 45 ) after the design file is saved in the archive file.
- a fast storage system (block 46 ) instead of the hard disk system (block 45 ) is used to further speed up the file access.
- the hard disk system (block 45 ) and the fast storage system (block 46 ) can exist at the same time.
- the file access functions of database manager can access the corresponding design unit from an external file (i.e., the archive file in block 43 ) according to an index information
- the corresponding data unit can be returned to the application through the adaptation layer (block 421 ) which provides the application file access interface ( 411 ) and wraps the archive file access activities underneath, without the assistance of storage devices (block 45 or block 46 ). Therefore, the storage devices (block 45 or block 46 ) are not needed in this case.
- FIG. 5A provides an example to explain how the current invention is applied on OpenAccess database manager with DMTurbo mode.
- a request to read a cellview is provided.
- the request is redirected to the wrapper functions as described above.
- the corresponding cellview 59 is extracted from an archive file 57 to a fast storage 55 as file 54 (as path 512 indicates) by looking up corresponding entry 58 in an index table file 56 to identify the location of cellview 59 (as path 511 indicates).
- lib.xml file 52 under the root directory 51 is originally used for the database manager to map a cellview name to its corresponding cellview file.
- the lib.xml file 52 is modified to map every cellview to a dummy file f000000 ( 53 ) which is a symbolic link to the cellview file 54 in the fast storage 55 as indicated by dash line 510 .
- the database manager proceeds in its normal way of accessing the cellview file 54 through the symbolic link.
- the file 54 in the fast storage 55 is deleted so that the fast storage 55 is ready for the next request.
- index table file 56 shown in FIG. 5A is separated from the archive file 57 , it is possible to store the index table in the archive file 57 .
- FIG. 5B For a scenario of updating an existing cellview, please refer to FIG. 5B .
- the database manager will write the updated cellview to the fast storage 55 as file 541 .
- the contents of file 541 are then copied from the fast storage 55 to the archive file 57 (as path 513 indicates) by looking up corresponding entry 581 in the index table file 56 to decide the location of cellview 591 (as path 511 indicates). After that, the file 541 in the fast storage 55 is deleted so that the fast storage 55 is ready for the next request.
- each cellview file is accessed through the archive files collectively as illustrated in FIG. 5A and FIG. 5B . Moreover, by using a fast storage, the performance of file access can be further improved.
- batch mode a full design database is first created on disk. Then, a utility program moves all the design files from the design library to the archive files and creates corresponding index tables. It then deletes all the design files in the design library.
- the preparation of the archive files and index tables can be done incrementally. Wrapper functions in block 44 as shown in FIG. 4 may be used in conjunction with the flow diagram demonstrated in FIG. 3B .
- the archive files and the index tables are empty.
- the database manager will write it to the fast storage.
- it is moved to an archive file and the corresponding index table is updated accordingly.
- the file in the fast storage is deleted so that the system is ready for the next design file creation.
- data units for design files may be compressed in the archive files. Consequently, when reading data units from archive files, a decompression process becomes necessary.
- Data compression usually reduces the size of disk space needed to store design files. Time spent in central processing unit (CPU) for data compression or decompression is offset by the time saved in disk I/O due to reduced data size.
- CPU central processing unit
Abstract
Description
- This application claims the benefit of priority of U.S. Provisional Application No. 61/544,285, filed Oct. 7, 2011, and titled “Method of Speeding up Access to Design Database Having Large Numbers of Design Units”, the contents of which are herein incorporated by reference in its entirety.
- 1. Field of the Invention
- The invention relates in general to a method for file accessing, and more particular to a method for speeding up file accessing to design databases for integrated circuits (ICs).
- 2. Description of the Prior Art
- Design databases for electronic design automation (EDA) tools typically store design units on a file basis, that is, one design unit takes one disk file to store. Furthermore, there is some kind of correlation between a design unit name and its corresponding disk file name. There are some immediate advantages using this scheme.
- For example, users can use operating system's (OS's) shell commands, such as “ls” on UNIX, to see the design files underneath a design library and to get a feel for how many design units there are, what their names are, etc. Also, using this scheme, the design database manager can take advantage of the services that the OS's file system offers, for example, file locking and file renaming.
- Performance-wise, this scheme is normally acceptable because even though modern day's IC designs can be very large, the number of distinct design units is normally manageable. Taking OpenAccess, an industrial standard of electronic design database from Silicon Integration Initiative (Si2) organization, as an example, there are two kinds of storage schemes offered by OpenAccess, namely DMFileSys and DMTurbo; and both of them use the same one-design-unit-in-one-disk-file scheme.
- However, during the last stage of integrated circuit (IC) design process as well as in the early stage of IC manufacturing process, there may be a need to “uniqueify” a design. This is the step in which a distinct design unit is created for each and every design unit instance. This can result in a huge number of design units in a design library, say, in the range of hundreds of thousands or more.
- Please refer to
FIG. 1A which shows an example of directory tree used by OpenAccess DMFileSys data manager to implement a design library. A design unit in OpenAccess is called a cellview. Each cellview, in DMFileSys mode, takes at least two levels of sub-directories and two files therein to implement. The first-level sub-directory is right underneath the root directory of the library, and the name of the sub-directory follows the cell name part of the cellview. Right underneath the cell sub-directory is a second-level sub-directory for the view name part of the cellview. The view sub-directory includes two files: master.tag and layout.oa. The master.tag is a text file that describes the name of the primary database file in the sub-directory; the layout.oa is the layout view for the design unit. In DMFileSys, therefore, if there are N cellviews in a design library, it will take 2N directories and 2N files to implement. - Please further refer to
FIG. 1B which demonstrates another example of directory tree structure in OpenAccess used by a data manager called DMTurbo. In DMTurbo, there is an XML file, called lib.xml, in the library directory. For each cellview in the design library, a separate disk file is created in the library directory for the cellview. The mapping of a cellview name to its corresponding file name is described in lib.xml. As a result, in DMTurbo, if there are N cellviews in a design library, there will be (N+1) files in the library directory—the number of directories and files on the disk is substantially smaller than that of DMFileSys, but which still incurs large amounts of overhead when the number of cellviews is large. - The one-file-per-design-unit scheme will therefore create a huge number of files on disk in a design database. Consequently, performance of EDA tools will come to a halt when they have to access these kinds of databases.
- Therefore, what is needed is an efficient data access scheme without using a large number of files or directories in order to speed up data access.
- One object of the present invention is to speed up database access of the electronic design automation (EDA) tool. The EDA tool accesses a plurality of design files, and each of the plurality of design files is associated with one of a plurality of design units for an integrated circuit (IC).
- In one embodiment of the present invention, the plurality of design files are encapsulated into an archive file, that is, the archive file comprises a plurality of data units, wherein each of the data units corresponds to a design file. A request to read a design file will be redirected to read the corresponding data unit in the archive file.
- In one embodiment of the present invention, a fast storage is introduced to further speed up file access. When requesting to access the design file, the corresponding data unit for the design file is first extracted from the archive file to the fast storage. Then the design file is returned from the fast storage.
- In one embodiment of the present invention, a request to save an updated design file will be redirected to update the corresponding data unit in the archive file.
- With the number of disk files dramatically reduced, it eliminates the bottleneck of using a huge number of design files for accessing design data.
- Other objects, technical contents, features and advantages of the present invention will become apparent from the following description taken in conjunction with the accompanying drawings wherein are set forth, by way of illustration and example, certain embodiments of the present invention.
- The foregoing aspects and many of the accompanying advantages of this invention will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:
-
FIG. 1A andFIG. 1B are examples showing the directory trees created by an existing database manager; -
FIG. 2A andFIG. 2B are schematic flow diagrams for handling a design file read request in accordance with current invention; -
FIG. 3A andFIG. 3B are schematic flow diagrams for handling a design file save request in accordance with current invention; -
FIG. 4A andFIG. 4B are schematic block diagrams depicting two embodiments of the software architecture in accordance with current invention; -
FIG. 5A illustrates an example of disk file structure and data reading flow applied on an existing database manager in accordance with current invention; and -
FIG. 5B illustrates an example of disk file structure and data saving flow applied on an existing database manager in accordance with current invention. - The detailed explanation of the present invention is described as following. The described preferred embodiments are presented for purposes of illustrations and description, and they are not intended to limit the scope of the present invention.
- In this invention, an “archive” concept is introduced for improving the performance of existing electronic design automation (EDA) tools that need to access a huge number of design files on disks.
- Please refer to
FIG. 2A which shows a schematic flow diagram in one embodiment of the invention. First, the design files for an integrated circuit (IC) design are encapsulated into an archive file In other words, the archive file comprises a plurality of data units, wherein each of the plurality of data units corresponds to a design file (step 21). Next, in an EDA tool, a request is provided to read a design file (step 22). Then, the request is redirected to read the archive file (step 23). Thus, the corresponding data unit for the design file can be returned (step 24). Since the size of a data unit can be variable, an index table can be used to indicate the size and location of the corresponding data unit in the archive file. - In one embodiment, step 24 further comprises three sub-steps as illustrated in
FIG. 2B . First, the corresponding data unit is extracted from the archive file to a storage device (step 241). In one embodiment, the storage device can be a hard disk or a fast storage including a random access memory (RAM) disk or a solid state drive (SSD) for speeding up the file access. - Next, the corresponding data unit in the storage device can be returned for the design file (step 242). At last, in order to simplify successive access for design files, the current data unit is deleted from the storage device after being returned (step 243).
- In addition, a design file may be updated and need to be saved back to the archive files. Please refer to
FIG. 3A which illustrates the corresponding schematic flow diagram. First, a request is provided to save the design file (step 31), and then the request is redirected to save the corresponding data unit for the design file into the archive file (step 32). In one embodiment, the corresponding data unit size information in an index table is updated due to the changes of design file. Furthermore, the corresponding location information in the index table is also updated if the original location and space cannot fit the updated data unit. - In one embodiment, referring to
FIG. 3B , step 32 further comprises three sub-steps. First, the request is redirected so that the design file is saved into a storage device (step 321). In one embodiment, the storage device can be a hard disk or a fast storage including a random access memory (RAM) disk or a solid state drive (SSD) for speeding up the file access. - Next, the design file in the storage device is saved into the archive file as a data unit (step 322). At last, in order to simplify successive access for design files, in one embodiment, the current design file is deleted from the storage device after being saved (step 323).
- In one embodiment, the design files for the integrated circuit (IC) design can be encapsulated into more than one archive file, wherein the number of archive files is dramatically smaller than the number of design files. Moreover, in one embodiment, a single design file can be split into multiple archive files. In this case, a data unit of an archive file may refer to only a portion of the single design file. Thus, when accessing the single design file, all corresponding data units in the multiple archive files should be retrieved and collected together.
- Furthermore, please refer to
FIG. 4A which depicts one embodiment of the invention in view of software architecture.Block 41 represents the EDA tool application which provides requests to access design files through application file access interface (dash line 411) provided by an existing database manager.Block 44 is the file access functions of database manager for accessing design files from a storage device.Block 43 is an archive file system which stores the archive file.Block 42 is an adaptation layer which contains functions wrapping the file access activities underneath.Block 45 is a storage device such as hard disk system which can be accessed by the database manager through the file access functions of the database manager (block 44). - When a read request for a design file is provided through the application file access interface (411), the request is redirected to the corresponding wrapper functions in
block 42 to locate corresponding data unit in the archive file for the design file and extract the corresponding data unit to the hard disk system (block 45). Thus the file access functions of database manager (block 44) can read the corresponding data unit from the hard disk system (block 45). After that, the corresponding wrapper functions inblock 42 will delete the data unit in the hard disk system (block 45). - On the other hand, when a write (save) request for a design file is provided through the application file access interface (411), the request is redirected to the corresponding wrapper functions in
block 42 to call the file access functions of database manager (block 44) to update the design file by saving the design file into the hard disk system (block 45). After that, the corresponding wrapper functions inblock 42 will update the corresponding data unit in the archive file according to the design file in the hard disk system (block 45) and then delete the design file in the hard disk system (block 45) after the design file is saved in the archive file. In one embodiment, a fast storage system (block 46) instead of the hard disk system (block 45) is used to further speed up the file access. In one embodiment, the hard disk system (block 45) and the fast storage system (block 46) can exist at the same time. - In one embodiment, referring to
FIG. 4B , if the file access functions of database manager (block 441) can access the corresponding design unit from an external file (i.e., the archive file in block 43) according to an index information, then the corresponding data unit can be returned to the application through the adaptation layer (block 421) which provides the application file access interface (411) and wraps the archive file access activities underneath, without the assistance of storage devices (block 45 or block 46). Therefore, the storage devices (block 45 or block 46) are not needed in this case. - To sum up, by encapsulating the extra work needed to support the archive file accessing in the functions in the adaptation layer, the changes made to the underneath file structure will be transparent to application programs as well as existing database managers. In other words, the execution performance can be improved without changing the application programs or the database managers for maintaining the same behavior from user's perspective.
-
FIG. 5A provides an example to explain how the current invention is applied on OpenAccess database manager with DMTurbo mode. - Initially a request to read a cellview is provided. Next, according to the invention, the request is redirected to the wrapper functions as described above. Then the corresponding
cellview 59 is extracted from anarchive file 57 to afast storage 55 as file 54 (aspath 512 indicates) by looking up correspondingentry 58 in anindex table file 56 to identify the location of cellview 59 (aspath 511 indicates). - As illustrated in
FIG. 1B ,lib.xml file 52 under theroot directory 51 is originally used for the database manager to map a cellview name to its corresponding cellview file. However, in order to force the database manager to access thefast storage 55, thelib.xml file 52 is modified to map every cellview to a dummy file f000000 (53) which is a symbolic link to thecellview file 54 in thefast storage 55 as indicated bydash line 510. Then, the database manager proceeds in its normal way of accessing thecellview file 54 through the symbolic link. After that, thefile 54 in thefast storage 55 is deleted so that thefast storage 55 is ready for the next request. - Although the
index table file 56 shown inFIG. 5A is separated from thearchive file 57, it is possible to store the index table in thearchive file 57. - For a scenario of updating an existing cellview, please refer to
FIG. 5B . As described above, since every cellview is mapped to the dummy cellview file f000000 (53), which is symbolically linked to thefast storage 55, the database manager will write the updated cellview to thefast storage 55 asfile 541. The contents offile 541 are then copied from thefast storage 55 to the archive file 57 (aspath 513 indicates) by looking up correspondingentry 581 in theindex table file 56 to decide the location of cellview 591 (aspath 511 indicates). After that, thefile 541 in thefast storage 55 is deleted so that thefast storage 55 is ready for the next request. - The reason why the invention can greatly reduce the time needed for disk access is that the number of directories and the number of disk files are greatly reduced for the whole IC design. Unlike in the original DMTurbo mode where each cellview file has to be accessed separately, each cellview file is accessed through the archive files collectively as illustrated in
FIG. 5A andFIG. 5B . Moreover, by using a fast storage, the performance of file access can be further improved. - As for preparing an archive file for a design, typically there are two ways: batch mode and incremental mode. In batch mode, a full design database is first created on disk. Then, a utility program moves all the design files from the design library to the archive files and creates corresponding index tables. It then deletes all the design files in the design library.
- Alternatively, the preparation of the archive files and index tables can be done incrementally. Wrapper functions in
block 44 as shown inFIG. 4 may be used in conjunction with the flow diagram demonstrated inFIG. 3B . Initially, the archive files and the index tables are empty. Each time a new design file is created and saved, the database manager will write it to the fast storage. Then, it is moved to an archive file and the corresponding index table is updated accordingly. The file in the fast storage is deleted so that the system is ready for the next design file creation. - Moreover, in one embodiment, data units for design files may be compressed in the archive files. Consequently, when reading data units from archive files, a decompression process becomes necessary. Data compression usually reduces the size of disk space needed to store design files. Time spent in central processing unit (CPU) for data compression or decompression is offset by the time saved in disk I/O due to reduced data size.
- The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustrations and description. They are not intended to be exclusive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents.
Claims (16)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/449,334 US10152482B2 (en) | 2011-10-07 | 2012-04-18 | Method of speeding up access to design databases having large numbers of design units |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201161544285P | 2011-10-07 | 2011-10-07 | |
US13/449,334 US10152482B2 (en) | 2011-10-07 | 2012-04-18 | Method of speeding up access to design databases having large numbers of design units |
Publications (2)
Publication Number | Publication Date |
---|---|
US20130091098A1 true US20130091098A1 (en) | 2013-04-11 |
US10152482B2 US10152482B2 (en) | 2018-12-11 |
Family
ID=48042752
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/449,334 Active US10152482B2 (en) | 2011-10-07 | 2012-04-18 | Method of speeding up access to design databases having large numbers of design units |
Country Status (1)
Country | Link |
---|---|
US (1) | US10152482B2 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150286647A1 (en) * | 2014-04-02 | 2015-10-08 | International Business Machines Corporation | Directly accessing archived data and executable files |
US20150363167A1 (en) * | 2014-06-16 | 2015-12-17 | International Business Machines Corporation | Flash optimized columnar data layout and data access algorithms for big data query engines |
US20170132345A1 (en) * | 2014-02-12 | 2017-05-11 | Synopsys, Inc. | Dynamically Loaded System-Level Simulation |
US20170154147A1 (en) * | 2015-11-26 | 2017-06-01 | Kla-Tencor Corporation | Methods to Store Dynamic Layer Content Inside a Design File |
US9952808B2 (en) | 2015-03-26 | 2018-04-24 | International Business Machines Corporation | File system block-level tiering and co-allocation |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060010154A1 (en) * | 2003-11-13 | 2006-01-12 | Anand Prahlad | Systems and methods for performing storage operations using network attached storage |
US9020992B1 (en) * | 2010-12-09 | 2015-04-28 | Symantec Corporation | Systems and methods for facilitating file archiving |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5907703A (en) * | 1996-05-08 | 1999-05-25 | Mijenix Corporation | Device driver for accessing computer files |
US6634008B1 (en) * | 1999-06-20 | 2003-10-14 | Fujitsu Limited | Methodology server based integrated circuit design |
US6564365B1 (en) * | 2001-08-03 | 2003-05-13 | Hewlett-Packard Development Company, L.P. | Method of simultaneously displaying schematic and timing data |
EP2102750B1 (en) * | 2006-12-04 | 2014-11-05 | Commvault Systems, Inc. | System and method for creating copies of data, such as archive copies |
-
2012
- 2012-04-18 US US13/449,334 patent/US10152482B2/en active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060010154A1 (en) * | 2003-11-13 | 2006-01-12 | Anand Prahlad | Systems and methods for performing storage operations using network attached storage |
US9020992B1 (en) * | 2010-12-09 | 2015-04-28 | Symantec Corporation | Systems and methods for facilitating file archiving |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170132345A1 (en) * | 2014-02-12 | 2017-05-11 | Synopsys, Inc. | Dynamically Loaded System-Level Simulation |
US10331824B2 (en) * | 2014-02-12 | 2019-06-25 | Synopsys, Inc. | Dynamically loaded system-level simulation |
US11055258B2 (en) * | 2014-04-02 | 2021-07-06 | International Business Machines Corporation | Directly accessing archived data and executable files |
US20150286647A1 (en) * | 2014-04-02 | 2015-10-08 | International Business Machines Corporation | Directly accessing archived data and executable files |
US20150363167A1 (en) * | 2014-06-16 | 2015-12-17 | International Business Machines Corporation | Flash optimized columnar data layout and data access algorithms for big data query engines |
US9846567B2 (en) * | 2014-06-16 | 2017-12-19 | International Business Machines Corporation | Flash optimized columnar data layout and data access algorithms for big data query engines |
US10048937B2 (en) | 2014-06-16 | 2018-08-14 | International Business Machines Corporation | Flash optimized columnar data layout and data access algorithms for big data query engines |
US10162598B2 (en) | 2014-06-16 | 2018-12-25 | International Business Machines Corporation | Flash optimized columnar data layout and data access algorithms for big data query engines |
US9952808B2 (en) | 2015-03-26 | 2018-04-24 | International Business Machines Corporation | File system block-level tiering and co-allocation |
US11593037B2 (en) | 2015-03-26 | 2023-02-28 | International Business Machines Corporation | File system block-level tiering and co-allocation |
US10558399B2 (en) | 2015-03-26 | 2020-02-11 | International Business Machines Corporation | File system block-level tiering and co-allocation |
US20170154147A1 (en) * | 2015-11-26 | 2017-06-01 | Kla-Tencor Corporation | Methods to Store Dynamic Layer Content Inside a Design File |
US10387601B2 (en) * | 2015-11-26 | 2019-08-20 | Kla-Tencor Corporation | Methods to store dynamic layer content inside a design file |
Also Published As
Publication number | Publication date |
---|---|
US10152482B2 (en) | 2018-12-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7512639B2 (en) | Management of time-variant data schemas in data warehouses | |
US10152482B2 (en) | Method of speeding up access to design databases having large numbers of design units | |
AU2014201593B2 (en) | Shared cache used to provide zero copy memory mapped database | |
US20060041606A1 (en) | Indexing system for a computer file store | |
JP2018505501A (en) | Application-centric object storage | |
US20120303628A1 (en) | Partitioned database model to increase the scalability of an information system | |
US20090132560A1 (en) | Hierarchical Grouping Columns | |
CN105718507A (en) | Data migration method and device | |
US11157466B2 (en) | Data templates associated with non-relational database systems | |
KR100419836B1 (en) | System and method for accessing non-relational data by relational access method | |
US9430503B1 (en) | Coalescing transactional same-block writes for virtual block maps | |
WO2021179722A1 (en) | Sql statement parsing method and system, and computer device and storage medium | |
US11151081B1 (en) | Data tiering service with cold tier indexing | |
CN116841988A (en) | Data migration method, device and equipment applied to blockchain | |
WO2020041950A1 (en) | Data update method, device, and storage device employing b+ tree indexing | |
US20180060362A1 (en) | Method and system for implementing distributed lobs | |
US20220129428A1 (en) | Database key compression | |
US11132334B2 (en) | Methods and apparatus for filtering dynamically loadable namespaces (DLNs) | |
US20080177785A1 (en) | System, and program product for rebasing an application | |
KR101510025B1 (en) | Method and system for extending data storage system functions | |
US20100191738A1 (en) | Apparatus, system, and method for modifying data set names | |
CN103501341A (en) | Method and device for establishing Web service | |
US20080082535A1 (en) | Method and system for automatically generating a communication interface | |
US20230153455A1 (en) | Query-based database redaction | |
CN113326288A (en) | Data processing method and device and electronic equipment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SPRINGSOFT USA, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HUNG, YAO-JIH;DOIG, ROBERT CAMERON;WANG, YUNG LE;AND OTHERS;SIGNING DATES FROM 20120412 TO 20120413;REEL/FRAME:028069/0232 Owner name: SPRINGSOFT, INC., TAIWAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HUNG, YAO-JIH;DOIG, ROBERT CAMERON;WANG, YUNG LE;AND OTHERS;SIGNING DATES FROM 20120412 TO 20120413;REEL/FRAME:028069/0232 |
|
AS | Assignment |
Owner name: SYNOPSYS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SPRINGSOFT USA, INC.;REEL/FRAME:030820/0490 Effective date: 20130712 |
|
AS | Assignment |
Owner name: SYNOPSYS TAIWAN CO., LTD., TAIWAN Free format text: ACQUISITION;ASSIGNOR:SPRINGSOFT, INC.;REEL/FRAME:030831/0119 Effective date: 20121203 |
|
AS | Assignment |
Owner name: SYNOPSYS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SYNOPSYS TAIWAN CO., LTD.;REEL/FRAME:038320/0364 Effective date: 20160324 |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |