Patent Application
20220284161
The present disclosure relates to verification of circuit designs in general and more specifically to automated identification of a design hierarchy and generation of simplified reduced model for efficient static verification of circuit designs.
A static verification system may include various static verification tools for verifying completeness and consistency of low power, clock crossing, structural linting or other intents of the design at different implementation stages. Static verification techniques may produce violations to identify the structural and consistency related issues in the design. A violation report may be generated that includes violation instances that state the type of problem present in the design along with structural/auxiliary information. Increased size and complexities of circuit designs has significantly impacted the overall turnaround time (TAT) for static verification. As a result, static verification runs often do not complete because traditional computing machines are not able to accommodate the huge memory footprint demanded by the verification tools. In addition, the total runtime of full design sign-off runs may take very long time, for example, several days. This in turn significantly impacts the overall verification convergence cycles.
A system performs efficient verification of a circuit design. The system receives a circuit design including circuit blocks. The system identifies some of the circuit blocks as modeled circuit blocks. The system generates simplified reduced models (SRMs) for the modeled circuit blocks. A simplified reduced model includes circuit details sufficient for static verification of the circuit design but excludes some of the circuit details for the modeled circuit block. The system performs static verification of the circuit design using the simplified reduced models.
In an embodiment, the system performs distributed execution over multiple processors for determining the SRMs. The techniques disclosed allow distribution execution, thereby allowing the process to complete in reasonable time.
The disclosure will be understood more fully from the detailed description given below and from the accompanying figures of embodiments of the disclosure. The figures are used to provide knowledge and understanding of embodiments of the disclosure and do not limit the scope of the disclosure to these specific embodiments. Furthermore, the figures are not necessarily drawn to scale.
Aspects of the present disclosure relate to verification of circuit designs. A system performs static verification of a circuit design represented as a hierarchy of circuit blocks. According to an embodiment, the hierarchy of circuit blocks includes a top-level circuit block and circuit blocks within the top-level circuit block. The system identifies the modeled circuit blocks based on an analysis of the hierarchy. The system identifies some of the modeled circuit blocks to be replaced by a simplified reduced model (SRM) circuit block. An SRM circuit block retains details of the actual circuit design that are useful for static verification and represents the rest of the circuit design within the SRM circuit block by a simplified model used in static verification. The simplified reduced model is simpler and more efficient for performing static verification by a verification system, e.g., a processor. In this disclosure, the terms intellectual property (IP), block and circuit block are used interchangeably.
Each modeled circuit block may be separately verified. Accordingly, the static verifications of the individual modeled circuit blocks and of the top-level circuit block using the simplified reduced models (rather than the full circuit blocks) may be parallelized. This reduces the execution time of the verification of large circuit designs.
In one aspect, the system identifies the modeled circuit blocks using auxiliary information describing the circuit design. Auxiliary data refers to data that is provided by the user during circuit design for electronic design automation operations performed on the circuit design other than circuit verification, for example, unified power format specification for power intent, system design constraints used to specify the design intent, including timing, power and area constraints for a design, and so on. Examples of auxiliary specifications include a unified power format (UPF) specification, a system design constraints (SDC) specification, a common power format (CPF) specification, or an instrumentation design constraints (IDC) specification associated with the circuit design. The system uses the auxiliary information to determine boundaries of circuit blocks as well as constraints for the simplified reduced models of the modeled circuit blocks.
The use of simplified reduced models makes the process of static verification computationally efficient. For example, simplified reduced models typically have smaller memory footprint compared to the full circuit blocks, thereby allowing larger circuits to be loaded in memory and processed efficiently compared to other approaches. The generation of the simplified reduced models and verification of the underlying circuit blocks may be performed in a distributed fashion using multiple processors to improve the execution time. Automatic identification of simplified reduced models makes the overall process less cumbersome, and less error prone compared to manual approaches.
In an embodiment, the system further determines constraints associated with modeled circuit blocks used as SRMs and used the constraints in static verification of the circuit design. In an embodiment, the system receives commands for performing operations related to circuit design, for example, commands for specifying power intent, design constraints, instrumentation constraints, and so on. The system extracts parameters of the command and generates constraints based on the parameters.
In an embodiment, the system receives an auxiliary specification associated with the circuit design and selects the modeled circuit blocks based on the auxiliary specification. In one embodiment, the system receives parameters describing circuit blocks of the circuit design and determines a weighted aggregate of the parameters. The system selects the modeled circuit blocks based on a weighted aggregate of the parameters.
The circuit design 110 received as input for verification is labeled TOP. The TOP circuit design 110 includes many circuit blocks 120a, 120b, and so on that are interconnected via connections 115, for example connections 115a, 115b, 115c, 115d, 115e, and so on. The system identifies a set of modeled circuit blocks that represents circuit blocks that are candidates for being determined as SRM circuit blocks. Certain circuit blocks may not be used as modeled circuit blocks for example, circuit blocks that include too few gates (i.e., below a first threshold value) or too many gates (i.e., above a second threshold value). In an embodiment, the SRM identification module 410 determines the modeled circuit blocks and the SRM circuit blocks. An SRM circuit block may also be referred to herein as an SRM. The system automatically identifies BLK1120a and BLK2120b from among the modeled circuit blocks as SRM circuit blocks. The system performs verification of the circuit design TOP 110, by performing verification of the SRM blocks, i.e., BLK1120a and of BLK2120b, rather than the full circuit design. The verification of the circuit design using SRMs is computationally efficient and takes significantly fewer computing resources.
SRMs of BLK1 and BLK2 may be manually constructed. However, typically the boundaries or circuit blocks are not well identified. Furthermore, the block level constraints in terms of auxiliary inputs (for example, UPF/SDC/etc.) are not available. As a result, the circuit designer could manually create all of these prerequisites before enabling the SRM based verification run of the TOP block. However, this is time consuming and error prone. The overall turnaround time may not be reduced because of manual interventions.
The system according to various embodiments, automatically determines the circuit block boundaries as well as the constraints of the determined circuit blocks. The system automatically identifies the SRM boundaries in a design by determining the circuit blocks that should be represented by SRMs based on analysis of the design structures. After identification of the block level boundaries, the system further generates the associated constraints (UPF/SDC/etc.) for these circuit blocks. Once the system automatically extracts boundaries and associated constraints for a block, the system invokes a distributed scheduler to perform distributed execution of the process of generation of SRM circuit blocks using multiple processors. Once SRM circuit blocks are generated in a distributed fashion, the system automatically starts the TOP level verification run using the SRM circuit blocks.
The above-mentioned steps may be performed for a given circuit design without any manual intervention. The system and process disclosed herein improves the turnaround time of the system-on-chip sign-off runs. The disclosed techniques can be extended to any static verification system or tool, for example, low power verification tool, clock domain crossing (CDC) verification tool, and reset domain crossing (RDC) verification tool, and so on.
The circuit design store 440 stores the circuit design being processed. The circuit design store 440 also includes metadata describing the circuit design, for example, the circuit blocks, metadata indicating whether a circuit block is identified as a modeled circuit block, SRMs, and so on.
The SRM identification component 410 analyzes the circuit design and various inputs received from users that may be provided in connection with circuit verification as well as input provided by users for performing operations other than circuit verification, for example, specifying power intent for power optimization.
The constraint generation component 420 determines constraints applicable to the various SRMs after SRMs are identified.
The distributed execution component 430 schedules the various actions necessary for performing distributed execution of the verification process.
The system receives 510 a circuit design including multiple circuit blocks. The system determines 520 that some of the circuit blocks are modeled circuit blocks, i.e., candidates for being selected as SRM circuit blocks. The system generates 530 simplified reduced models for the modeled circuit blocks. The simplified reduced models include circuit details sufficient for static verification of the circuit design and exclude at least some of the circuit details for the modeled circuit block. The system performs 540 static verification of the circuit design using the simplified reduced models of the modeled circuit blocks, for example, by performing distributed execution using multiple processors.
The system uses a lightweight design read which creates a design database with less memory footprint. A light weight design read builds a simpler data structure compared to a read performed for a specific EDA task, for example, for timing analysis. As a result, the light weight design consumes less memory for storage and also less processing power for analyzing. Utilizing this design database, the system performs structural analysis to identify the circuit block hierarchies. The identified circuit blocks become candidates for SRM generation.
The system uses various methods to select the modeled circuit blocks for SRM generation. According to one embodiment, the system analyzes auxiliary data provided by user. The system determines whether the auxiliary data includes (1) explicit specification (or explicit guidance) of circuit block boundaries that can be used for defining SRMs, for example, constructs that explicitly identify module definitions for providing constraints (2) implicit specification (or implicit guidance) of circuit block boundaries, for example, constructs that may not directly identify module boundaries for providing constraints but can be used indirectly for inferring module definitions and corresponding constraints.
Explicit guidance represents a structured way in which block boundaries and associated constraints are specified, for example, using a construct that specifies a circuit block and provides all constraints related to the circuit block in one or more files, for example, UPF files or SDC files. The construct loads all the constraints in one run, for example, UPF files loaded by a load command or SDC files loaded in an SOC run. The construct may specify the circuit block instance, for example, by specifying a hierarchical name. As an example, the constraints for circuit block identified by the hierarchical name u1/u2/u3/inst may be loaded by the following commands that act as explicit guidance of circuit block boundaries.
load_upf file1.upf-scope u1/u2/u3/inst
load_upf file2.upf-scope u1/u2/u3/inst
Implicit guidance represents an unstructured way in which circuit block boundaries and associated constraints are specified. For example, circuit block constraints may be specified using an SOC constraint file in scattered manner User can add multiple set_scope command with different hierarchical names to provide the reference of a circuit block. In this embodiment, the system analyzes the various hierarchical names used in the specification to identify the ones that are referring to the same circuit block. Following is an example of specification that uses different hierarchical names “u1/u2/u3/inst”, “u3/inst”, and “u2/u3/inst” to refer to the same circuit block.
set_scope u1/u2/u3/inst
. . . . . .
. . . . . . .// some constructs
set_scope . ./. ./
. . .
set_scrope u3/inst
. . . .
. . . .
. . .
set_scope . ./. ./. ./
. . .
set_scope u2/u3/inst
. . . . . .
set_scope.
The different set_scope commands may also refer to different circuit blocks. The system according to an embodiment, collects the various hierarchical names specified by the set_scope commands to identify the hierarchical names that refer to the same circuit blocks and collects the constraints specified by the corresponding set_scope constructs.
A construct may also be referred to herein as a command Examples of auxiliary data represent specification received from user in a context other than circuit verification, for example, unified power format specification for power intent, system design constraints used to specify the design intent, including timing, power and area constraints for a design, and so on. The system receives from the user, explicit/implicit inputs regarding the boundaries of circuit block to be modeled as SRMs (SRM blocks or SRM circuit blocks). The system utilizes these inputs automatically and uses them to identify boundaries for SRM circuit blocks.
According to one embodiment, if a user explicitly provides the information regarding circuit block hierarchies in its auxiliary data, the system utilizes this information to identify SRM circuit blocks. As an example, for specifying power constraints using UPF, the auxiliary data includes specification using load_upf construct through which user explicitly provides the circuit block boundaries. The following are example UPFs including Top.upf, M3.upf, and M4.upf that may be loaded using a load_upf command based on explicit user guidance.
Top.upf
M3.upf
M4.upf
In this example, the system reads the UPF specification and analyzes various commands to identify circuit block boundaries for modeled circuit blocks. The system may use predefined rules for analyzing the commands For example, if the system identifies the command create_power_domain, the system determined whether the command specifies an—include_scope argument. If the command specifies the -include_scope argument, the system uses the value specified for the argument, for example, TOP as a modeled circuit block. Accordingly, from the command “create_power_domain TOP -include_scope” the system determines TOP as a modeled circuit block. Similarly, the system extracts the value of the argument—scope from the command load_upf as a circuit block. For example, the system analyzes the command “load_upf M3.upf -scope M3” to determine that M3 is a modeled circuit block and the system analyzes the command “load_upf M4.upf -scope M4” to determine that M4 is a modeled circuit block.
According to another embodiment, the system uses guidance based on implicit user provided auxiliary data. If a user implicitly provides information regarding circuit block hierarchies in its auxiliary data, the system utilizes that information for identification of SRM circuit blocks. The following is an example specification based on UPF. The UPF specification used set_scope as an example construct through which user implicitly provides the circuit block boundaries. The following shows examples of auxiliary input with implicit user guidance including top.upf, m2_aux.upf, and M4_aux.upf.
Top.upf
M3_aux.upf
M4_aux.upf
The system analyzes the example auxiliary inputs and identifies the command “create_power_domain TOP—include_scope” to determine that the current circuit block is set to TOP. The specification uses command “set_scope” to change (or set) the scope of the power intent specification. For example, the system analyzes “set_scope M3” to infer that the content of the UPF module “M3.upf” represents a modeled circuit block. Accordingly, the system analyzes the set_scope command specified for identifying the scope of the power intent for determining an SRM circuit block. The system identifies all the set_scope commands in the UPF specification and determines SRM circuit blocks based on the modules specified as inputs to the set_scope commands or instances of modules that may be specified as inputs to the set_scope command For example, the system determines an SRM circuit block based on M3.upf based on command “set_scope M3”, an SRM circuit block based on M4.upf based on command “set_scope M4”, and so on. Accordingly, the system identifies M3 and M4 as SRM circuit blocks based on both explicit and implicit approaches. The explicit and implicit guidance are used to identify SRM circuit blocks from modeled circuit blocks.
According to another embodiment, the system identifies SRM circuit blocks based on a design complexity of the circuit blocks. For example, if user does not implicitly provide any indication regarding circuit boundaries or in addition to the explicit/implicit auxiliary data provided by the user, the system may rely on different design parameters to identify a modeled circuit block as an SRM candidate. The system may perform analysis of one or more of the following example design parameters to determine if a modeled circuit block is a desired candidate as an SRM circuit block: (1) a total gate count inside the circuit block hierarchy, (2) a depth of the circuit block hierarchy (3) a height of the design tree for the circuit block (length of the longest downward path from root to the leaf node), and (4) a total count of application specific gates of a type and/or characteristic inside the hierarchy.
The system automatically extracts these parameters from the circuit design and various types of auxiliary data provided by the user and uses a weighted aggregate of these parameters to determine whether a modeled circuit block should be used as an SRM circuit block.
An example weighted model is given below where the various parameters are assigned weights, (e.g., parameter 1 value (Param1Val), parameter 2 value (Param2Val), parameter K value (ParamKVal) are assigned weights W1, W2, Wk, respectively. The system may assign weights based on a measure of significance of the parameter in deciding the overall weight for a modeled circuit block to qualify as an SRM candidate.
Total Weight=W1* Param1Val+W2* Param2Val++Wk * ParamKVal (1)
The total aggregate weight for a modeled circuit block represents an SRM score of the modeled circuit block. Accordingly, if the SRM score exceeds a threshold value for a modeled circuit block, the system determines that the modeled circuit block is an SRM circuit block.
In some embodiments, the system uses a threshold on the gate count of a modeled circuit block to determine whether the modeled circuit block should be used as an SRM circuit blocks. For the example of
The system identifies a modeled circuit block as an SRM circuit block if the use of this SRM circuit block provides a desired gain in terms of run time and memory for a top-level run for the entire circuit design or for a portion of the circuit design. If the system uses modeled circuit blocks with very few (below a threshold number of) design gates as SRM circuit blocks, then the final SoC run using all these SRM block will not be optimized in terms of memory and run time. Therefore, the system analyzes various parameters of modeled circuit blocks to determine which modeled circuit blocks should be used as SRM circuit blocks. An example parameter is gate count of the circuit blocks.
For example, in
Once the system identifies SRM circuit blocks, the system generates required constraints (e.g., UPF, Clock (SDC), . . . ) for the identified SRM circuit blocks. In an embodiment, the system uses explicit guidance provided by the user in auxiliary data. The system receives explicit information describing circuit block constraints in auxiliary data and uses it as constraints for SRM circuit blocks if the corresponding circuit block was identified as an SRM circuit block.
As an example of explicit guidance, the system receives from the user, a load_upf command in an auxiliary design file. The load_upf command identifies a circuit block instantiated in the circuit design or a module definition. The auxiliary design file may be specified for a circuit block as an argument of the load_upf command Following are example UPF specifications for modules top.upf, M3.upf, and M4.upf. The UPF specification of a module includes constructs that are used by the system as constraints for verification.
M3.upf
M4.upf
The system may use the module definition or instances identified by the load_upf command as modeled circuit blocks and further determine whether the modeled circuit block is an SRM circuit block. In some embodiments, the system uses the module definition or instances identified by the load_upf command as SRM circuit blocks. The system may further extract the arguments of the corresponding load_upf command to determine the constraints for the SRM circuit blocks. For example, the system determines that the “load_upf M3.upf” command was specified for M3 modeled circuit block that was identified as an SRM circuit block. The system extracts the argument M3.upf specified for the load_upf command and extracts the constraints for the corresponding M3 SRM circuit block from the M3.upf module. Similarly, the system determines that the “load_upf M4.upf” command was specified for M4 modeled circuit block and determines that M4 should be used as an SRM circuit block based on the use of the circuit block in the load_upf command In this example the system determines module boundaries for an SRM block and constraints for the SRM circuit block from explicitly provided auxiliary data via a load_upf command The load_upf command is an example of auxiliary data provided by the user.
In other embodiments, the user may specify other types of auxiliary data, for example, an SDC command that explicitly identifies an instance of a module or a module for purposes of defining timing constraints or area constraints. In other embodiments, the user may specify other types of auxiliary data, for example, an IDC command that explicitly identifies an instance of a module or a module for purposes of defining constraints used for purposes of debugging.
Following is an example of SDC commands that may be used for determining SRM circuit blocks and their constraints.
In another embodiment, the system uses implicit guidance provided by the user in auxiliary data. If the user does not explicitly provide the information regarding circuit block hierarchies, the system analyzes auxiliary design data to extract constructs which give information about various circuit block hierarchies used in the design. The system uses that implicit information to identify the circuit block hierarchy as well as to generate required constructs for the identified hierarchies.
For example, the UPF command set_scope may not provide the full constraint information directly. The set_scope command includes an indication of the start of the scope (e.g., “set_scope Mx”) and an indication of the end of the scope (e.g., “set_scope . . ”.) Accordingly, a pair of commands specifies the boundary of the scope and constraints may be specified between the pair of commands representing the boundary of the scope. The system identifies all commands specified between the pair of set_scope commands specifying the boundary of the scope and uses them as constraints for a corresponding SRM circuit block. The SRM circuit block may be identified by one of the set_scope commands of the pair, for example, the first set_scope command of the pair. Following are example UPF specifications used for determining constraints for SRM circuit blocks.
M3_aux.upf
M4_aux.upf
The example UPF specification includes multiple set_scope commands The system identifies commands between a pair of set_scope commands and exports the identified commands in an auxiliary data file, for example, M3_aux.upf or M4_aux.upf. The system uses the information in the auxiliary data file to extract constraints for the corresponding SRM circuit blocks.
When a user does not provide any information in the auxiliary information then the system may identify various circuit block hierarchies based on other constructs which may not be specified for circuit block definition. For example, the system may receive a create_power_domain command specified by the user to identify circuit blocks and generate constructs for those hierarchies. The system uses the arguments of the create_power_domain command to determine SRM circuit blocks and their constraints. Accordingly, the system may identify a set of commands S1 such that each command in S1 independently identifies a module M1; the system collects these as constraints for an SRM circuit block corresponding to module Mx. Similarly, the system may identify a set of commands S2 such that each command in S2 independently identifies a module My and collects these as constraints for an SRM circuit block corresponding to module My. This may be repeated for other SRM circuit blocks. The commands of the sets S1, S2, and so on may be interleaved and mixed with various other commands in a specification provided as an auxiliary data and the system analyzes the auxiliary data to extract these constraints and group them for different SRM circuit blocks.
Following is an example UPF specification illustrating the determination of constraints for SRM circuit blocks when the user does not provide any information in the auxiliary information.
M3_aux.upf
M4_aux.upf
In this example load_upf or set_scope is not used in top level upf. In this example, the system interprets various other commands (e.g., create_power_domain) to generate the required SRM circuit blocks and constraints.
Once the SRM candidates are identified and the required constructs are generated, the system generates the SRM circuit blocks for each circuit block hierarchy on a distributed machine framework. To generate SRM circuit blocks for each hierarchy, the system generates a setup file for each modeled circuit block.
To decrease the overall turnaround time, the distributed execution by the system forks out separate jobs for each identified SRM circuit block on a different computing system. Machine pool may be provided by user through setup command
In some scenarios, the number of circuit block hierarchies is more than the number of machines available in the machine pool. To handle such a scenario, two separate mechanisms may be implemented by the system. The system may perform pipelining of jobs. More than one jobs may be pipelined into one machine. Separate pipeline queue may be created for each machine and more than one job pushed into these queues. Once one job from the queue is completed, then next job from the queue is assigned to the machine. Alternatively, the system may execute more than one job on the same machine concurrently. Machines may have multiple cores available. The system utilizes this fact and pushes more than one job on the same machine.
Other distributed framework concepts like fault tolerance, resource sharing, concurrency etc. are also handled during the distributed execution by the system. After completion of all the SRM circuit block generation runs, the system performs full chip run using the generated SRM circuit blocks. The final result of the full chip run is sent to the user at the end of the full run.
The system receives 630 via a verification application, inputs associated with the circuit design, for example, the circuit design 615 and power intent 620 specified using the UPF format, and a setup file 625. The system receives the following additional input from the user including the machine configuration 610 and a command to invoke distributed execution.
The system performs a light weight read 635 of the design and extracts circuit block hierarchy from the circuit design. For example, following is a sample design snippet.
module top (in1,in2,in3,in4,out1,out2,out3);
The system populates 637 design tree information and a mapping from instance names to modules based on the light weight design read. This information is stored in an instance tree store 640. For example, based on the above design snippet, the system determines that the command “layer1 inst1 (in1, in2, . . . )” indicates that the instance instl is mapped to module layerl and the command “low h1 (i1, in2, . . . )” indicates that the instance h1 is mapped to module low and command “high h2 (w1, w2, . . . )” indicates that the instance h2 is mapped to module high.
The system performs a lightweight read 645 of any auxiliary data, for example, the UPF input. The system generates 647 the UPF configuration based on the UPF 620 input. The constraints extracted from the auxiliary data such as UPF specification is stored in the constraints store 650. Following is an example UPF specification. For the following snippet of UPF, the system identifies that load_upf command has been used for two hierarchies inst1 and h2. It means we can create UPF configuration for these hierarchies. Since these UPF are used for instances inst1 and h2 respectively, a master module of inst1 and h2 can be identified as a partition for SRM creation. The following shows a sample user UPF.
The system detects the set_scope commands in the specification to determine that the possible candidates for SRM circuit blocks in this example are modules layerl and HIGH. The system generates SRM creation setup for modules layerl and HIGH. Following are example setup files generated by the system. When the system identifies the candidates for SRM generation run, the system starts separate SRM model generation runs for each of the SRM candidate run. To execute these runs, the system uses some input configuration file (which contains setup parameters). Since SRM block generation are not directly initiated by user, the system internally starts the run. Therefore, the system generates the setup file for each run. These scripts represent the setup file for each of the runs.
The system also generates setup for full SoC (top-level) run using these two SRM circuit blocks. Following is a sample set of instructions generated by the system. Once all the SRM models are created, the system performs a full top-level run after stitching all the circuit blocks into SoC. In some embodiments, the system may perform a run for a portion of the SoC. Following script is the setup file for this full top-level run:
The system subsequently performs the distributed execution 655. The distributed framework is provided with input of these three system generated files and user provided machine configuration as input to start the SRM creation jobs on the provided pool of computing machines, for example, 660a, 660b, 660c, 660d, and so on. The system further performs the top-level execution 670 of the verification. The system may generate a report of the progress of the job for users to view. The system may further generate a report with status of each run along with details of path of saved session and violation report.
Specifications for a circuit or electronic structure may range from low-level transistor material layouts to high-level description languages. A high-level of representation may be used to design circuits and systems, using a hardware description language (‘HDL’) such as VHDL, Verilog, SystemVerilog, SystemC, MyHDL or OpenVera. The HDL description can be transformed to a logic-level register transfer level (‘RTL’) description, a gate-level description, a layout-level description, or a mask-level description. Each lower representation level that is a more detailed description adds more useful detail into the design description, for example, more details for the modules that include the description. The lower levels of representation that are more detailed descriptions can be generated by a computer, derived from a design library, or created by another design automation process. An example of a specification language at a lower level of representation language for specifying more detailed descriptions is SPICE, which is used for detailed descriptions of circuits with many analog components. Descriptions at each level of representation are enabled for use by the corresponding tools of that layer (e.g., a formal verification tool). A design process may use a sequence depicted in
During system design 714, functionality of an integrated circuit to be manufactured is specified. The design may be optimized for desired characteristics such as power consumption, performance, area (physical and/or lines of code), and reduction of costs, etc. Partitioning of the design into different types of modules or components can occur at this stage.
During logic design and functional verification 716, modules or components in the circuit are specified in one or more description languages and the specification is checked for functional accuracy. For example, the components of the circuit may be verified to generate outputs that match the requirements of the specification of the circuit or system being designed. Functional verification may use simulators and other programs such as testbench generators, static HDL checkers, and formal verifiers. In some embodiments, special systems of components referred to as ‘emulators’ or ‘prototyping systems’ are used to speed up the functional verification.
During synthesis and design for test 718, HDL code is transformed to a netlist. In some embodiments, a netlist may be a graph structure where edges of the graph structure represent components of a circuit and where the nodes of the graph structure represent how the components are interconnected. Both the HDL code and the netlist are hierarchical articles of manufacture that can be used by an EDA product to verify that the integrated circuit, when manufactured, performs according to the specified design. The netlist can be optimized for a target semiconductor manufacturing technology. Additionally, the finished integrated circuit may be tested to verify that the integrated circuit satisfies the requirements of the specification.
During netlist verification 720, the netlist is checked for compliance with timing constraints and for correspondence with the HDL code. During design planning 722, an overall floor plan for the integrated circuit is constructed and analyzed for timing and top-level routing.
During layout or physical implementation 724, physical placement (positioning of circuit components such as transistors or capacitors) and routing (connection of the circuit components by multiple conductors) occurs, and the selection of cells from a library to enable specific logic functions can be performed. As used herein, the term ‘cell’ may specify a set of transistors, other components, and interconnections that provides a Boolean logic function (e.g., AND, OR, NOT, XOR) or a storage function (such as a flipflop or latch). As used herein, a circuit ‘block’ may refer to two or more cells. Both a cell and a circuit block can be referred to as a module or component and are enabled as both physical structures and in simulations. Parameters are specified for selected cells (based on ‘standard cells’) such as size and made accessible in a database for use by EDA products.
During analysis and extraction 726, the circuit function is verified at the layout level, which permits refinement of the layout design. During physical verification 728, the layout design is checked to ensure that manufacturing constraints are correct, such as DRC constraints, electrical constraints, lithographic constraints, and that circuitry function matches the HDL design specification. During resolution enhancement 730, the geometry of the layout is transformed to improve how the circuit design is manufactured.
During tape-out, data is created to be used (after lithographic enhancements are applied if appropriate) for production of lithography masks. During mask data preparation 732, the ‘tape-out’ data is used to produce lithography masks that are used to produce finished integrated circuits.
A storage subsystem of a computer system (such as computer system 800 of
The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
The example computer system 800 includes a processing device 802, a main memory 804 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), a static memory 806 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 818, which communicate with each other via a bus 830.
Processing device 802 represents one or more processors such as a microprocessor, a central processing unit, or the like. More particularly, the processing device may be complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device 802 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 802 may be configured to execute instructions 826 for performing the operations and steps described herein.
The computer system 800 may further include a network interface device 808 to communicate over the network 820. The computer system 800 also may include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse), a graphics processing unit 822, a signal generation device 816 (e.g., a speaker), graphics processing unit 822, video processing unit 828, and audio processing unit 832.
The data storage device 818 may include a machine-readable storage medium 824 (also known as a non-transitory computer-readable medium) on which is stored one or more sets of instructions 826 or software embodying any one or more of the methodologies or functions described herein. The instructions 826 may also reside, completely or at least partially, within the main memory 804 and/or within the processing device 802 during execution thereof by the computer system 800, the main memory 804 and the processing device 802 also constituting machine-readable storage media.
In some implementations, the instructions 826 include instructions to implement functionality corresponding to the present disclosure. While the machine-readable storage medium 824 is shown in an example implementation to be a single medium, the term “machine-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable storage medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine and the processing device 802 to perform any one or more of the methodologies of the present disclosure. The term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.
Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm may be a sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Such quantities may take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. Such signals may be referred to as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the present disclosure, it is appreciated that throughout the description, certain terms refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage devices.
The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the intended purposes, or it may include a computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various other systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the method. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the disclosure as described herein.
The present disclosure may be provided as a computer program product, or software, that may include a machine-readable medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium such as a read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices, etc.
In the foregoing disclosure, implementations of the disclosure have been described with reference to specific example implementations thereof. It will be evident that various modifications may be made thereto without departing from the broader scope of implementations of the disclosure as set forth in the following claims. Where the disclosure refers to some elements in the singular tense, more than one element can be depicted in the figures and like elements are labeled with like numerals. The disclosure and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
This application claims the benefit under 35 U.S.C. § 119(e) of U.S. Provisional Patent Application Ser. No. 63/155,859, “Automated Design Hierarchy Identification and Simplified Reduced Model Generation for Static Verification,” filed Mar. 3, 2021, which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63155859 | Mar 2021 | US |
