|Publication number||US7805698 B1|
|Application number||US 11/857,985|
|Publication date||Sep 28, 2010|
|Filing date||Sep 19, 2007|
|Priority date||Sep 19, 2007|
|Publication number||11857985, 857985, US 7805698 B1, US 7805698B1, US-B1-7805698, US7805698 B1, US7805698B1|
|Inventors||Kenneth Ferguson, Kenneth Mackie, Gilles S. C. LAMANT, Sravasti Gupta Nair|
|Original Assignee||Cadence Design Systems, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (14), Referenced by (12), Classifications (10), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates to computer-aided design and more particularly, some embodiments relate to design configuration within a computer aided design system.
In some design systems, a logical design may be constructed from instances of cells in a logical design library. For example, a library can contain predefined logical functions that can be combined together to create a logical design. The logical design can then be mapped to an actual physical design. The physical design may include the actual placement of transistors on a die, for example. A logical design can have multiple physical designs. In other words, a logical design might be implemented in a number of different ways. For example, physical elements such as transistors, logic gates, input/output pins, etc. can be altered, placed at different locations on a die, different types of technologies can be used, and so on. Additionally, a logical design can also have multiple physical designs because of considerations relating to different optimization criteria, different design goals, or different yield goals.
In order to create a physical design, mappings may be defined that detail how to map instances of logical cells from logical libraries to instances of physical layout cells from technology-specific physical libraries. In some computer aided design systems, library-mapping attributes are embedded within the logical design library. Attributes are various properties to be implemented within, for example, a digital logic design. Examples of attributes include but are not limited to logic gate topology to use for a particular instance of a logic cell. One example of logic gate topology attributes can include the particular logic gates, the size and layout of those logic gates, and the like. Another example of an attribute within a logic design is the location within a design for a particular logic function within a library, for example, a designer might want a certain logic function adjacent to a particular output pin of a device.
In some cases both logical and physical libraries may be technology specific. As discussed above, a logical design can also have multiple physical designs because of considerations relating to different optimization criteria, different design goals, different yield goals, etc. For example, a logical source, such as a schematic, might typically change from configuration to configuration in the design of some custom integrated circuits. Alternatively, as discussed above, some custom integrated circuit designers and manufacturers may use a generic design library.
Mapping to a new physical library, for example, for a new technology, might require the user to change the attributes stored as properties in the logical library. This may require the designer to change attributes on a transistor-by-transistor basis. This might, in some cases, be time consuming, especially in a large design. Additionally, in some cases, mapping to multiple technology libraries may be difficult because only one set of mapping information may be stored as properties in each logical library cell or instance.
Directives and attributes used to map logical design components to physical design components are, in some cases, embedded inside the logical design itself. This may require the logical design cells and instances to be modified after the logical design is complete.
Modifications to the mapping between the logical design and the physical design might mean that changes to logical design elements are required. This means that the person who defines the mapping has to have write privileges to the data base that contains the logical design. For example, this might involve the addition or modification of properties within the data base that contains the logical design. In some cases mapping a single generic logical library to multiple technology-specific physical libraries may be difficult because it might be necessary to store different properties for each physical library on the same cells in the logical library.
Further, in some systems it is not possible to visualize the logical design elaborated in the context of a physical domain because the logical design tools do not read the physical design mapping attributes that are added to the logical design. In some cases, the first opportunity for the user to see the effects of the physical design elaboration directives is during the creation of the physical layout inside the physical layout editor itself.
In some cases, designers need to override the standard library mappings that are set for each cell with individual settings for a particular cell, or for instances or occurrences of those cells inside a particular design. In some systems, this may be accomplished using design attribute settings. For example, global design attributes to control embedded elaboration, such as global stop lists and view lists for elaboration, are specified as options in the physical design editor. Design-level overrides for the cells and instances in a specific design have to be specified in a separate ASCII text file.
Designers might require that a portion of their logical design be mapped to a newly created physical cell, known as a soft block. The invention provides a mechanism to specify which portion of the logical design is mapped to a soft block and a mechanism to allow the soft block layout parameters to be specified easily. A separate tool was often used to specify the parts of the logical design hierarchy that were to be implemented as soft blocks.
Designers could benefit from a tool that may open a schematic design and elaborate a physical design hierarchy from it, obeying the attributes specified for mapping from the logical to the physical domain. Some computer aided design systems embed elaboration of the physical design inside the physical layout editor. In some cases a user may not visualize the physical design elaboration until implementing the physical design, and the task of setting the logical to physical mapping attributes was done in the logical design editor without the user being able to see the effects of the mapping attributes on the physical design elaboration.
According to one embodiment of the invention, a new method to address configuring a logical design and libraries of design elements with additional information is proposed that may be used to create a physical design from that logical design. Logical designs might be generic, i.e. not targeted to a specific technology process, while physical design libraries are normally targeted towards specific technology. Consequently, there can be a mapping from the cells in a logical library to cells that correspond to their implementation in a physical library.
In one embodiment, annotations required to map from logical design to physical design may be stored in a separate design view. This design view is called a physical configuration view. The annotations required to map logical library cells to physical library cells may be stored in an XML file known as a library attributes mapping file (“LAM file”). By using a separate design view it may be possible to define and edit the mapping from a logical design to a physical design without requiring write access to the logical design.
In another embodiment, a new tool, known as a physical hierarchy configuration editor, may read the physical configuration view for a design and the LAM files for the libraries in the design. The tool may present to the user an elaborated view of the logical design, in the context of the physical design, with all the physical design mapping attributes displayed.
In one embodiment, the physical hierarchy configuration editor lets the user modify the physical mapping attributes of cells, instances, and occurrences in the logical design and save the modifications back to the physical configuration view. The updated physical configuration view may then be used within the physical layout editor tool to elaborate the physical design components and drive the physical implementation.
In yet another embodiment, the physical hierarchy configuration editor may be open at the same time as the logical design editor, in which case modifications to the logical design are immediately reflected in the physical hierarchy configuration editor. Similarly, it may be open at the same time as the physical layout editor, in which case modifications to the physical configuration are immediately notified to the physical layout editor.
Other features and aspects of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the features in accordance with embodiments of the invention. The summary is not intended to limit the scope of the invention, which is defined solely by the claims attached hereto.
The present invention, in accordance with one or more various embodiments, is described in detail with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict typical or example embodiments of the invention. These drawings are provided to facilitate the reader's understanding of the invention and shall not be considered limiting of the breadth, scope, or applicability of the invention. It should be noted that for clarity and ease of illustration these drawings are not necessarily made to scale.
The figures are not intended to be exhaustive or to limit the invention to the precise form disclosed. It should be understood that the invention may be practiced with modification and alteration, and that the invention be limited only by the claims and the equivalents thereof.
In many instances, a logical design can be physically implemented in a number of ways. For example, even a single NAND gate can be implemented using different types of transistors or process technologies, including, for example, NMOS, CMOS, BiCMOS, or PMOS transistors, just to name a few of the conventionally available process technologies. Accordingly, because a logical design can have many different physical implementations, additional information may need to be stored to define a mapping from the logical design to the physical implementation. In one embodiment, a new method to address configuring a logical design and libraries of design elements with additional information is provided that can be used to create a physical design from that logical design. Annotations required to map from a logical design to a physical design may be stored in a separate design view, rather than storing the information in the logical design. This can allow different mappings to be created for a given logical design and, in one embodiment, such mappings can be performed without modifying the logical design.
Before describing the invention in detail, it is useful to describe an example environment with which the invention might be implemented. In one embodiment, the invention can be implemented using computer aided design software running on a computer or computing system. The computer or computing system might be a personal computer, minicomputer, mainframe, etc. The computer might include various input devices, such as a keyboard, mouse, trackball, etc.; various output devices, such as a monitor, printer, etc.; various communication ports such as network connections, USB ports, serial and parallel I/O ports, etc.; and various storage devices, such as ROM, RAM, disk drives, magnetic disks, magnetic tape drives, etc. Additionally, it will be understood by one of ordinary skill in the art that the computer may be a workstation, desktop computer, laptop computer, or other computing system.
The input devices can be used by the designer to input design elements for a design on which he or she is working. A keyboard, tablet, pointing device and the like might be used to enter commands, data and other information; access libraries and directories; select, move and position design elements; and otherwise control the operation of the computing system. Monitors and printing devices can be used to provide a visual display of the design as well as other ancillary information to aid the developer in the design process, including various GUIs, graphical representations and other information. Storage devices, whether networked or local, can be used to store data and other information including design tools, design kit information, libraries and so on.
Having thus described an example environment where design software can run on a computer, we will now discuss various example embodiments of methods and systems for physical hierarchy configuration in terms of this example environment. These methods and systems may include storing annotations required to map from a logical design to a physical design in a separate design view. In another embodiment annotations required to map logical library cells to physical library cells can be stored in a separate file. After reading this description in terms of this environment, it will become apparent to one of ordinary skill in the art how alternative embodiments can be provided and how the invention can be implemented in alternative environments.
Referring now to
In one embodiment, the physical hierarchy configuration engine or module may read LAM files associated with libraries, for example, libraries “physLib1” and “physLib2”, along with a specified physical configuration view for the “top level” design illustrated in
Referring again to
As discussed above, The NAND gates 100 and 102 of
In addition to occurrence name, the table illustrated in
As discussed above, a logical design may be mapped to a physical design so that the logical design may be implemented in some device, such as an ASIC or other electronic circuit. The table of
The inherited view list in one embodiment indicates mapping of an occurrence name. For example, “Top/I3” maps to “schematic2” (
The inherited stop list can be used to tell the system how far down to go within a given hierarchy. By modifying the entry in the Inherited Stop List column, it may be possible to control the physical cell views searched during elaboration for the occurrence in that row and all its descendants. In
Ignore indicates in one embodiment that a device should be ignored. For example, GND and VDD might be ignored. GND and VDD indicate power connections. These connections generally do not require a logic gate. They may take up some routing resources, for example, but generally, the power connections are not a logic gate.
Force descend forces the design tool to descend lower into a design hierarchy. This can allow a designer to use a higher or lower level design item. Accordingly, in the example, force descend is generally set to “n” for no. In other words, do not force descend. Accordingly, TOP/I1, for which force descend is set to “y”, will include entries in physical library, physical cell, and physical view for each occurrence down to the lowest level gates. Top/I2 for which force descend is set to “n”, will not include entries in physical library, physical cell, and physical view for each occurrence down to the lowest level logic gates. The NAND2 gate from the phyLib is a known device, and the physical design can be expressed in terms of NAND2, rather than requiring Top/I2 to be expressed in terms of lower level gates.
As will be understood by those of ordinary skill in the art and illustrated in
In one embodiment, the physical hierarchy configuration editor can be implemented such that the user may modify the computed entries in the columns for each row. For example, to map a specific logical occurrence to a specific physical cell view, the user enters the information under the Physical Library, Physical Cell or Physical View columns in the row corresponding to that occurrence. In
Similarly, the user may modify the Inherited View List entry to control the elaboration of the logical design hierarchy. In
By modifying the entry in the Inherited Stop List column, it may be possible to control the physical cell views searched during elaboration for the occurrence in that row and all its descendants. In
The Force Descend feature in one embodiment lets the user specify that even if a logical occurrence or instance or cell has a mapping to a physical cell view, then that mapping should be ignored and instead the elaborator engine should descend into the children and search for mappings to physical cell views at that level. For example, in
The Ignore setting for an occurrence or instance or cell in one embodiment causes that object to be ignored when mapping to the physical design. For example, some logical cells might always be ignored since because they generally do not map to cells in the physical domain. For example, in the design shown in
In one embodiment, when working with a top-level logical design some of the logical cell views instantiated in this top-level design may already have a configuration cell view defined for them. In one embodiment, an elaborator might be configured to choose to elaborate into a sub-physical configuration cell view instead of the regular schematic cell view. This means that all of the configuration settings specified inside the sub-configuration will be honored while the top-level design is elaborated without the need to specify them again in the top level physical configuration cell view.
The elaboration tree may be expandable and contractible. For example, in one embodiment a hierarchical logical instance can be in an unexpanded state, e.g., where none of its subcomponents are visible in the elaboration tree. If a logical instance in the tree is expanded an instance at the next level of the elaboration tree can be displayed. Conversely, a logical instance in the tree can also be contracted such that lower level sub-components of a logical instance are not visible.
In one embodiment, library attribute mapping information may be stored in a separate XML file called a LAM file rather than embedding the mapping attributes inside the logical cells.
In one embodiment of the LAM file, the logical to physical mapping information is not embedded inside the logical cell views inside the logical library. This means that mappings may be created without modifying the logical design. Logical designers can therefore in one embodiment safely make their logical cell views read-only without preventing creation of library mapping information at a later time. In another embodiment, there may be a different LAM file for each unique physical library to which a given logical library is mapped.
In one embodiment, a new engine and graphical tool can read LAM files and physical configuration views to create and display an elaborated physical design representation. Using the physical hierarchy configuration editor in one embodiment, configuration information can be edited globally or on a cell, instance or occurrence basis. The result of any modification can be displayed in a tabular graphical format like the one shown in the
In some cases, storing the design attribute settings in a separate cell view may allow for a design system that has a clean separation between the logical design, the physical design, and the configuration data that maps between the two. Additionally, the physical configuration view might be opened and edited in a new design elaboration tool. The example illustrated in
When storing design attribute settings in the physical configuration view the physical configuration information might be supported as design data. This can be done in one embodiment instead of storing the settings in a separate ASCII text file map or as options in the physical layout editor itself. Accordingly, in such an embodiment the invention can be configured such that a user may use the physical hierarchy configuration editor to open a physical configuration view and view, edit, and save the configuration information independent from editing the logical or physical design to which the configuration data refers. In one embodiment, multiple physical configuration views may be created for a single logical design, facilitating the exploration of alternative physical implementations of the logical design and the saving of these alternative physical elaboration choices.
In one embodiment, the functions of partitioning logical design components into new physical layout views, and storing the specification of these partitions in the physical configuration views can be incorporated into the physical hierarchy configuration editor. In this way, the same tool might be used to control and edit the elaboration settings from logical to physical cells and to generate the partition specifications for new physical layout cells. Such partition specifications might include the specification of the coordinates of the physical boundary of the physical boundary of the partition, the I/O pin specification including layer, width, number of pins, and the definition of obstructions within the partition, (or soft block as it is known).
By incorporating the partitioning of sections of the logical design into soft blocks in the physical configuration editor, all of the tasks associated with configuring the cells, instances and occurrences inside a logical design for mapping to physical design may be completed using a single tool.
In another embodiment, a new engine for elaborating the components in a folded logical design may incorporate into components in an unfolded logical design, with mapping annotations that specify how to map these logical design components to physical design components. Accordingly, the engine may read the logical design, a physical configuration view and any LAM files and configuration views of cells in the logical design, and generates an unfolded tree containing the logical design occurrences annotated with mapping information required to map these components into the physical domain.
In some cases, the design elaboration may be visualized in a new graphical tool referred to herein as a physical hierarchy configuration editor. In one embodiment, a physical hierarchy configuration editor can be configured to display a current design elaboration tree and can further be configured to allow the user to modify both the logical elaboration and physical mapping settings. Such modifications can be made, for example, either globally or on a cell, instance or occurrence basis. In one embodiment, modifications made to the configuration settings in the physical hierarchy configuration editor can be saved into the physical configuration view being edited.
The physical hierarchy configuration editor may be invoked, for example, by opening a physical configuration view. The logical design might be opened concurrently in the logical design editor tool and in that case, modifications to the logical design can be automatically reflected in the physical hierarchy configuration editor. Similarly, the physical layout editor may be opened on the layout view and any changes made in the physical hierarchy configuration editor can be likewise honored by the physical layout editor.
In one embodiment of the invention, a physical design elaboration engine can be configured to elaborate a logical design by applying the physical design mapping attributes specified in LAM files physical configuration views. The physical hierarchy configuration editor tool may, in one embodiment, show a graphical tree representation of the logical design elaboration annotated with physical design mapping attributes as shown in
In one embodiment, a physical design elaboration engine may read LAM files and physical configuration views to create an unfolded representation of the logical design. Such a representation can, in one embodiment, be annotated with the mapping information required to map it to a physical design domain. In another embodiment, an editor might display the logical design tree elaborated for a physical design, allow edits to be made to control this elaboration, and save the modifications made to a physical configuration view. In one embodiment, physical mapping can be displayed and edited in a tabular format for each logical occurrence in the logical design.
The physical hierarchy configuration editor, the logical design editor, and the physical layout editor can be separate components or integrated together at varying levels of integration. Integration may facilitate incremental edits to the logical design, the physical configuration, or both, without requiring the design to be completely re-elaborated. As discussed above, the graphical representation of the elaboration is displayed in the editor in tabular format as shown in
In one embodiment, annotations required to map from logical design to physical design may be stored in the physical configuration view 904. This file may, in some embodiments, be read by logical design editor 900 and the configuration physical hierarchy engine and editor 906 (configuration engine 906). Configuration physical hierarchy engine and editor 906 might be a text editor, for example, that can be used to read and edit the physical configuration view 904.
Logical design editor 900 may also be configured to output a logical design to configuration physical hierarchy engine and editor 906. Configuration physical hierarchy engine and editor 906 may also process LAM files 908 and output an elaborated logical design with physical design annotation 910. The elaborated logical design with physical design annotation 910 may be input into physical design editor 912, which in one embodiment may output a physical design 914.
At block 1010 a logical component in the logical design can be identified. The logical component can be, for example, a logical library device, such as a NAND gate.
At block 1020 a logical to physical design annotation can be read. In one embodiment, a physical configuration view can be used to store settings required to map a particular logical cell view to a physical device. For example, the physical design annotation can indicate pins to be used for inputs and outputs in a design, areas of a die to be used for specific logical functionality, etc.
At block 1030 a logical to physical library annotation can be read. For example, in one embodiment, a library attributes mapping file (LAM file) can be read. The LAM file can contain information that specifies how cells in a library map to physical cells. The physical cells can correspond to cells in a physical device. In some cases, separating the library attribute mapping information from the logical and physical cells may mean that logical cells do not need to be edited and annotated with mapping information.
At block 1040 the physical design can be displayed. This can allow a designer to review the design, for example, to highlight any missing mappings so that layout generation will not produce errors due to missing mappings. In some embodiments, the designer might also be able to compare one physical design implementation to another physical design implementation.
It will be understood by those of ordinary skill in the art that the systems and methods described may be implemented in hardware, software, or some combination of hardware and software. Additionally, the software might run on one or more processors, microprocessors, controllers, microcontrollers, etc. As used herein, the term module might describe a given unit of functionality that may be performed in accordance with one or more embodiments of the present invention. As used herein, a module might be implemented utilizing any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, logical components or other mechanisms might be implemented to make up a module. In implementation, the various modules described herein might be implemented as discrete modules or the functions and features described may be shared in part or in total among one or more modules. In other words, as would be apparent to one of ordinary skill in the art after reading this description, the various features and functionality described herein may be implemented in any given application and may be implemented in one or more separate or shared modules in various combinations and permutations. Even though various features or elements of functionality may be individually described or claimed as separate modules, one of ordinary skill in the art will understand that these features and functionality may be shared among one or more common software and hardware elements, and such description shall not require or imply that separate hardware or software components are used to implement such features or functionality.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not of limitation. Likewise, the various diagrams may depict an example architectural or other configuration for the invention, which is done to aid in understanding the features and functionality that might be included in the invention. The invention is not restricted to the illustrated example architectures or configurations, but the desired features may be implemented using a variety of alternative architectures and configurations. Indeed, it will be apparent to one of skill in the art how alternative functional, logical or physical partitioning and configurations may be implemented to implement the desired features of the present invention. Also, a multitude of different constituent module names other than those depicted herein may be applied to the various partitions. Additionally, with regard to flow diagrams, operational descriptions and method claims, the order in which the operations are presented herein shall not mandate that various embodiments be implemented to perform the recited functionality in the same order unless the context dictates otherwise.
Although the invention is described above in terms of various exemplary embodiments and implementations, it should be understood that the various features, aspects and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described, but instead may be applied, alone or in various combinations, to one or more of the other embodiments of the invention, whether or not such embodiments are described and whether or not such features are presented as being a part of a described embodiment. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments.
Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term “including” should be read as meaning “including, without limitation” or the like; the term “example” is used to provide exemplary instances of the item in discussion, not an exhaustive or limiting list thereof; the terms “a” or “an” should be read as meaning “at least one,” “one or more” or the like; and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. Likewise, where this document refers to technologies that would be apparent or known to one of ordinary skill in the art, such technologies encompass those apparent or known to the skilled artisan now or at any time in the future.
A group of items linked with the conjunction “and” should not be read as requiring that each and every one of those items be present in the grouping, but rather should be read as “and/or” unless expressly stated otherwise. Similarly, a group of items linked with the conjunction “or” should not be read as requiring mutual exclusivity among that group, but rather should also be read as “and/or” unless expressly stated otherwise. Furthermore, although items, elements or components of the invention may be described or claimed in the singular, the plural is contemplated to be within the scope thereof unless limitation to the singular is explicitly stated.
The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to” or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent. The use of the term “module” does not imply that the components or functionality described or claimed as part of the module are all configured in a common package. Indeed, any or all of the various components of a module, whether control logic or other components, may be combined in a single package or separately maintained and may further be distributed across multiple locations.
Additionally, the various embodiments set forth herein are described in terms of exemplary block diagrams, flow charts and other illustrations. As will become apparent to one of ordinary skill in the art after reading this document, the illustrated embodiments and their various alternatives may be implemented without confinement to the illustrated examples. For example, block diagrams and their accompanying description should not be construed as mandating a particular architecture or configuration.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5671432 *||Jun 2, 1995||Sep 23, 1997||International Business Machines Corporation||Programmable array I/O-routing resource|
|US6631508 *||Jun 7, 2000||Oct 7, 2003||Xilinx, Inc.||Method and apparatus for developing and placing a circuit design|
|US7146586 *||Nov 19, 2003||Dec 5, 2006||Prophicy Semiconductor , Inc.||System and method for automated electronic device design|
|US7278122 *||Jun 23, 2005||Oct 2, 2007||Ftl Systems, Inc.||Hardware/software design tool and language specification mechanism enabling efficient technology retargeting and optimization|
|US7386819 *||Jul 28, 2005||Jun 10, 2008||Altera Corporation||Methods of verifying functional equivalence between FPGA and structured ASIC logic cells|
|US7526740 *||Aug 10, 2006||Apr 28, 2009||Prophicy Semiconductor, Inc.||System and method for automated electronic device design|
|US7530048 *||Apr 9, 2005||May 5, 2009||Cadence Design Systems, Inc.||Defect filtering optical lithography verification process|
|US7546571 *||Sep 8, 2004||Jun 9, 2009||Mentor Graphics Corporation||Distributed electronic design automation environment|
|US7549133 *||Dec 27, 2006||Jun 16, 2009||Dongbu Electronics Co., Ltd.||System and method for qualifying a logic cell library|
|US20060101368 *||Oct 8, 2004||May 11, 2006||Mentor Graphics Corporation||Distributed electronic design automation environment|
|US20080128637 *||Dec 1, 2006||Jun 5, 2008||Cadence Design Systems, Inc.||Method and system for logic design for cell projection particle beam lithography|
|US20090007031 *||Jun 27, 2007||Jan 1, 2009||Cadence Design Systems, Inc.||Method and system for implementing cached parameterized cells|
|US20090113369 *||Oct 31, 2007||Apr 30, 2009||Cadence Design Systems, Inc.||Registry for electronic design automation of integrated circuits|
|US20090172624 *||Dec 27, 2007||Jul 2, 2009||Cadence Design Systems, Inc.||Method and System for Implementing Stacked Vias|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8645421 *||Sep 30, 2008||Feb 4, 2014||Sas Institute Inc.||Attribute based hierarchy management for estimation and forecasting|
|US8689169 *||Dec 30, 2010||Apr 1, 2014||Cadence Design Systems, Inc.||Method, apparatus, and article of manufacture for providing in situ, customizable information in designing electronic circuits with electrical awareness|
|US8694933||Dec 30, 2010||Apr 8, 2014||Cadence Design Systems, Inc.||Methods, systems, and articles of manufacture for implementing electronic circuit designs with simulation awareness|
|US8694950||Dec 30, 2010||Apr 8, 2014||Cadence Design Systems, Inc.||Methods, systems, and articles of manufacture for implementing electronic circuit designs with electrical awareness|
|US8701067||Jul 22, 2011||Apr 15, 2014||Cadence Design Systems, Inc.||Methods, systems, and articles of manufactures for implementing electronic circuit designs with IR-drop awareness|
|US8762914||Dec 30, 2010||Jun 24, 2014||Cadence Design Systems, Inc.||Methods, systems, and articles of manufacture for constraint verification for implementing electronic circuit designs with electrical awareness|
|US8782577 *||Dec 30, 2010||Jul 15, 2014||Cadence Design Systems, Inc.||Method, apparatus, and article of manufacture for providing in situ, customizable information in designing electronic circuits with electrical awareness|
|US9223925||Apr 7, 2014||Dec 29, 2015||Cadence Design Systems, Inc.||Methods, systems, and articles of manufacture for implementing electronic circuit designs with simulation awareness|
|US9330222||Dec 30, 2010||May 3, 2016||Cadence Design Systems, Inc.||Methods, systems, and articles of manufacture for implementing electronic circuit designs with electro-migration awareness|
|US20100082521 *||Apr 1, 2010||Sas Institute Inc.||Attribute-Based Hierarchy Management For Estimation And Forecasting|
|US20120023471 *||Dec 30, 2010||Jan 26, 2012||Cadence Design Systems, Inc.||Method, apparatus, and article of manufacture for providing in situ, customizable information in designing electronic circuits with electrical awareness|
|US20120023472 *||Dec 30, 2010||Jan 26, 2012||Fischer Ed|
|U.S. Classification||716/103, 716/123, 716/104, 716/117, 716/139|
|Cooperative Classification||G06F17/5072, G06F17/505|
|European Classification||G06F17/50D2, G06F17/50L1|
|Sep 19, 2007||AS||Assignment|
Owner name: CADENCE DESIGN SYSTEMS, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FERGUSON, KENNETH;MACKIE, KENNETH;LAMANT, GILLES;AND OTHERS;SIGNING DATES FROM 20070820 TO 20070906;REEL/FRAME:019849/0331
|Nov 30, 2010||CC||Certificate of correction|
|Mar 28, 2014||FPAY||Fee payment|
Year of fee payment: 4