Circuit change analysis using information sharing across different scenarios

Abstract

A circuit simulation (110) is performed for a plurality of different scenarios (120). These simulations are affected by statistical variations, and the simulations produce preliminary analyses (130) of the circuit for different scenarios. A complete characterization of the circuit for the scene of interest is estimated by migrating the complete characterization of the reference scene from the reference scene to the scene of interest (166). A complete characterization of the reference scene is produced by additional simulation of the circuit under the reference scene. A reference scene may be identified (140) by grouping different scenes into clusters.

Description

Technical Field

[0001] This disclosure relates to the characterization of integrated circuits. Background Technology

[0002] The complexity of advanced integrated circuits (ICs) exacerbates the impact of process variations introduced throughout IC manufacturing. These variations are statistical in nature and result in stochastic deviations from the intended behavior of the design. Meanwhile, designs that optimize performance, power, and area (PPA) in conjunction with the push for ultra-low voltage designs have yielded smaller design margins and greater sensitivity to these statistical variations.

[0003] Variation analysis characterizes the response of a given design considering these statistical variations. One objective is to estimate the probability distribution of the response of interest. This can then be used for yield analysis, design optimization, logic synthesis, and so on. An example application is standard cell characterization. Standard cells are building blocks for ASIC designs. They can have very high replication rates, with millions of instances of a given cell appearing in a design. Therefore, they must function correctly under a wide range of process and operating conditions. At such high replication rates, the response of each instance of a cell can vary significantly due to statistical variations. Therefore, characterizing the response at high sigma values ​​(i.e., modeling the extreme tails of the probability distribution of the response) is important for building robust designs for many different scenarios. Summary of the Invention

[0004] In some aspects, circuit simulations are performed for many different scenarios. These simulations are affected by statistical variations, and the simulations produce preliminary analyses of the circuits for different scenarios. A complete representation of the circuit for the scenario of interest is estimated by transferring the complete representation previously generated for the reference scenario to the scenario of interest. A complete representation of the reference scenario can be generated through additional simulations of the circuit beyond the preliminary analysis. The reference scenario can be identified by grouping the different scenarios into clusters.

[0005] In other aspects, the database stores previously evaluated scenarios, including preliminary analyses and complete representations for those scenarios. Simulations of unevaluated scenarios are performed to generate preliminary analyses for those scenarios. The database is accessed based on the similarity between the preliminary analyses of unevaluated and evaluated scenarios to identify reference scenarios for the unevaluated scenarios from the evaluated scenarios. If a reference scenario is identified, the complete representation for the reference scenario is transferred to estimate the complete representation for the unevaluated scenarios. If no reference scenario is identified, additional simulations of the circuit are performed under the unevaluated scenarios. Unevaluated scenarios, preliminary analyses, and complete representations can be stored in the database for future reference. Unevaluated scenarios can be processed in order of increasing probability of identifying reference scenarios for unevaluated scenarios.

[0006] Other aspects include components, devices, systems, improvements, methods, processes, applications, computer-readable media, and other technologies related to any of the foregoing. Attached Figure Description

[0007] This disclosure will be more fully understood from the detailed description given below and from the accompanying drawings illustrating embodiments of this disclosure. The drawings are provided to give knowledge and understanding of embodiments of this disclosure and are not intended to limit the scope of this disclosure to these particular embodiments. Furthermore, the drawings are not necessarily drawn to scale.

[0008] Figure 1 These are illustrations for multi-scenario change analysis according to some embodiments of this disclosure.

[0009] Figure 2 This is another illustration of multi-scenario change analysis according to some embodiments of the present disclosure.

[0010] Figure 3 This is yet another illustration of multi-scenario change analysis based on some embodiments of the present disclosure.

[0011] Figure 4 This is a block diagram of a system for multi-scenario change analysis according to some embodiments of the present disclosure.

[0012] Figure 5 Flowcharts depict various processes used during the design and manufacture of integrated circuits according to some embodiments of this disclosure.

[0013] Figure 6 A diagram depicts an example computer system in which embodiments of the present disclosure may operate. Detailed Implementation

[0014] Various aspects of this disclosure relate to circuit variation analysis using information sharing across different scenarios. Variation analysis characterizes the response of a given circuit design across many different scenarios, taking into account the statistical variations in each scenario.

[0015] Traditional variation analysis methods involve running Monte Carlo simulations to model statistical variation. To cover the desired tail region for a given standard deviation (sigma) requirement for a specific scenario, a sufficient number of simulations must be run in that scenario to generate enough samples within the tail region. For higher sigma tail regions, even more samples are needed. In a typical multi-scenario analysis framework, the number of scenarios (e.g., corners) can range from tens to thousands. Standard cells can be characterized under many different process, voltage, and temperature conditions because they can be used in many designs with different operating conditions. In such a process, designs are typically characterized independently under each scenario considered, with the goal of capturing the high-sigma tail region of the response distribution. As the number of scenarios and the target sigma increase, the computational cost for variation characterization can quickly become prohibitively expensive.

[0016] Although the designed response differs from scenario to scenario, the behavior across different scenarios is often similar. Therefore, knowledge gained from representing one scenario can be used to accelerate the representation of other scenarios with similar behaviors. Treating the representation of different scenarios as independent, unrelated tasks ignores the opportunity for cross-scenario information sharing and reduces redundant work.

[0017] In some respects, sharing information across different scenarios accelerates multi-scenario variation analysis of circuit designs. Sharing information from earlier scenario representations can speed up the representation of subsequent scenarios. Given that behavior may be similar across different scenarios, information sharing can avoid costly cold starts by providing knowledge accumulated from previously similar scenarios as a starting point for each new scenario. Previous information can be fused with a small amount of simulation in the new scenario to transfer knowledge to the new scenario and continue with any additional necessary steps to complete the representation.

[0018] The technical advantages of this disclosure include, but are not limited to, the following: It can reduce the computational cost of completing multi-scenario change analysis. It eliminates the need to run a full characterization analysis for each scenario. Instead, the characterization of a scenario evaluated later can be based on a full characterization of a similar scenario evaluated earlier, which can then be transferred to the scenario of current interest.

[0019] Figure 1This is a flowchart for performing multi-scenario variation analysis of a circuit design. Circuit design 110 will be evaluated under many different scenarios 120. Different scenarios can include different corners, including different process conditions, different voltage conditions, and different temperature conditions. They can also include different signal patterns (e.g., different input test signals) and different load conditions. Another example of different scenarios is the implementation of a circuit using different devices, such as using a low-threshold transistor versus a high-threshold transistor. These scenarios can be referred to as different test platforms. For convenience, these different variations are referred to as different scenarios.

[0020] Figure 1 The process characterizes the circuits under these different scenarios. Different characteristics can be evaluated. For example, characterization can include estimating timing delay, hold margin, noise level, and voltage variation metrics. The purpose of characterization can be standard cell variation characterization, multi-angle standard cell variation characterization, standard cell robustness checking, or general multi-angle multi-test-platform variation analysis.

[0021] These scenarios exhibit statistical variation. For a given scenario, the metric of interest can vary according to some probability distribution. Figure 1 The representation explains this statistical variation. For example, taking into account these statistical variations and in all scenarios, the result of the representation can be an estimate of the high-sigma value of the metric of interest.

[0022] Figure 1 The process proceeds as follows. At step 130, simulations of the circuit are performed to generate preliminary analyses of the circuit for different scenarios. In one approach, this is achieved by running a small number of Monte Carlo simulations under each scenario. The number of simulations is insufficient to produce the desired complete characterization, but sufficient to determine whether different scenarios behave similarly. To facilitate comparison of these simulations in a later step 140, the same seed can be used for simulations of different scenarios. Furthermore, to reduce the number of simulations used to generate a good preliminary analysis, the distribution of the simulations can be designed to provide a good sample of the probability distribution of interest, rather than relying on purely random selection of samples.

[0023] At point 140, based on the preliminary analysis generated at point 130, the different scenarios 120 are grouped into clusters. This clustering will later be used to determine which scenarios share information. Using the results from the preliminary simulation 130, the behavioral similarity between different scenarios can be quantified. A small sample size can be used to compare the performance of different scenarios and assess the similarity of behavior under statistical variation. This can be used to calculate similarity metrics (e.g., the correlation between simulation results across different scenarios). The preliminary analysis 130 provides a data-driven clustering scheme that does not require any information about the design or scenario.

[0024] When physical information or other metadata about the scene is available, it can also be used for clustering. For example, a multi-angle setup can have different angles defined by changing load conditions, voltage, and temperature. If each of these parameters can take one of three values ​​(minimum, nominal, and maximum), this information can be used as a similarity metric. Table 1 below shows the three angles and their corresponding parameters. The metadata indicates that angles 1 and 2 are more similar than angles 1 and 3. Table 1: Scene parameters indicate similarity. Physical information may also include device-level information (e.g., threshold voltage) or other design and / or scenario characteristics that can be used to assess the similarity between different scenarios. Therefore, a quantitative similarity metric can be calculated based on this metadata.

[0025] Similarity based on scene metadata can be enhanced through preliminary analysis. Given a similarity metric, clustering step 140 groups scenes into clusters. Scenes in the same cluster are identified as good candidates to benefit from information sharing. The number of clusters does not need to be predetermined; it can be determined dynamically. Various methods can be used to obtain the number of clusters, including minimum cluster similarity requirements, maximum cluster merge distance, and dynamic clustering cutoff methods (e.g., the elbow method). Furthermore, available computational resources and scheduling considerations can also be taken into account in the clustering step.

[0026] In some implementations, clustering step 140 selects one or more anchor scenarios for each cluster. In one approach, the anchor scenario is the base scenario of the cluster, and other scenarios within the cluster are evaluated relative to the anchor scenario (and may also be other scenarios within the cluster). In this case, a complete representation of the anchor scenario can be completed before the complete evaluation of other scenarios within the cluster. Therefore, a complete representation of the anchor scenario will be available when evaluating other scenarios. In another approach, the evaluation of later scenarios within a cluster uses information from the anchor scenario and all other previously evaluated scenarios within the cluster. It is also possible to restrict sharing within each cluster to the anchor scenario and the scenario of current interest, without using information from non-anchor scenarios within the cluster.

[0027] At step 150, full representations for different scenarios are scheduled. Clustering information from step 140 can be used for scheduling. For example, if anchor scenarios are identified, these anchor scenarios can be scheduled for full representations before other scenarios in the same cluster. Furthermore, priority can be given to clusters whose full representations have not yet been estimated. These methods increase the probability that scenarios evaluated later in a cluster will resemble previously evaluated scenarios, allowing information from previous full representations to be reused.

[0028] For example, suppose the number of tasks (T) in a multi-corner analysis is much larger than the number of available cores (C). Here, each task is a complete representation of a scenario within a scenario. This means that not all T-representation tasks can be executed in parallel, and some scenarios will be evaluated after others. When T >> C, the clustering information from 140 provides dependencies that can be used in the scheduler. For example, consider a case with 10 clusters, each containing 10 tasks (scenarios) and 10 available CPUs. These tasks are run in batches. For each batch, each CPU executes one task from the tasks. Scheduling with good information reuse is to include one task from each cluster in each batch. b In, from each cluster b -1 information from previous tasks can be used by the task b This allows for maximum reuse of information while still ensuring full utilization of resources. On the other hand, scheduling with poor information reuse involves running all tasks from the cluster in the same batch. Minimal information sharing is possible when evaluating all similar scenarios in parallel.

[0029] Therefore, the scheduler uses clustering schemes and information about available resources to schedule representation tasks, with the aim of maximizing both information reuse and resource utilization.

[0030] At point 160, a complete representation of the scene is generated. This step performs the complete representation task for all scenes by utilizing the information-sharing scheme established in clustering step 140. At point 162, it is determined whether other scenes similar to the currently interesting scene have already been fully represented. These previously evaluated scenes will be referred to as reference scenes. Anchor scenes are examples of reference scenes.

[0031] If no reference scene exists, a full representation of the scene of interest is performed at position 164. This might involve running a Monte Carlo simulation set of the scene, augmented by predictions from a machine learning model.

[0032] If there are (multiple) reference scenes, then at position 166, the complete representation of the current scene is determined by reusing information from the complete representation of the reference scenes. This is called transferring the complete representation from the reference scenes to the current scene.

[0033] As an example of using anchor scenarios, at the beginning of branch 160, all scenarios in the cluster have not yet been fully evaluated. Among these unevaluated scenarios, the anchor scenario is the first scenario to be fully represented. Additional simulations are run to complete the Monte Carlo-based representation (branch 164). These results are stored in a database. Information storage may include simulation results, simulation seeds, tail sample information, machine learning models, model predictions, etc.

[0034] For subsequent scenarios, step 162 determines that a reference scenario is available. This is the anchor scenario previously evaluated. This determination can be based on the similarity from the preliminary analysis. Alternatively, since clustering is formed based on the similarity from the preliminary analysis, the determination can be based on cluster membership. Branch 166 then estimates the complete representations of these later scenarios by transferring the complete representations of the anchor scenarios to the scenarios of interest. When more complete representations are completed, they can be stored in the database at 168 for reuse in later scenarios. In some cases, only the complete representations generated by the original Monte Carlo simulation (branch 164) are stored.

[0035] Here are some examples of migrating shared information from one scenario to another. At the start of a complete representation of the new scenario, information stored for the reference scenarios(s) in the cluster is loaded and migrated to the scenario being analyzed. The migrated information provides a quick start to the new scenario, where useful data can be used with zero or minimal simulation cost.

[0036] In many cases, the process of estimating a complete representation of a scene relies on machine learning algorithms to reduce the number of simulations required to complete the task. State-of-the-art machine learning methods offer a wide range of approaches to repurpose models for similar tasks. The original model is trained on a large dataset in its native setting (e.g., a complete simulation of a reference scene) and tuned on a very small number of samples in a new setting (i.e., for the scene of current interest).

[0037] These methods include Bayesian methods and transfer learning. Bayesian methods can be used to combine prior information with limited information from the current scene to reduce modeling costs. Transfer learning can be used to transfer models across different scenes using a small number of simulations. Multi-scene machine learning models are another approach. These can be built and dynamically updated. For example, machine learning models can be built to predict different scenes within a cluster. These methods reduce the number of training samples (simulations) used to build models for evaluating new scenes.

[0038] Results such as sample sorting, simulation output, and tail samples can be transferred from one scene to another. For example, tail regions discovered in one scene can be transferred to another. In one approach, transfer is achieved by identifying samples in the tail regions (e.g., simulation seeds) and transferring these samples to the new scene. Samples can also be transferred for other purposes. Predictions from machine learning models can also be transferred using a small number of new samples / predictions. These techniques can be used to improve models, select optimal samples for simulation, and so on.

[0039] Some usage patterns can be used only Figure 1 A subset of the technologies described, or variations of those technologies that can be used. See below. Figure 2 and Figure 3 Two alternative usage modes are discussed.

[0040] Figure 2 This shows the completion of the initial scene set. Figure 1 The process involves initial processing of scenarios, with additional scenarios added later for use cases in the evaluation. Database 280 stores the results of the initial processing from these scenarios. This includes clustering, as well as representations of different scenarios. Figure 2 The process for evaluating new scenario 220 is illustrated. At 230, a preliminary analysis of the new scenario is generated. At 262, based on the preliminary analysis, it is determined whether the new scenario belongs to one of the previously defined clusters. In other words, the system checks whether the new scenario is similar to scenarios that have already been evaluated. If the new scenario belongs to an existing cluster, it is linked to that cluster at 266, and the previous information from the cluster is used for a complete representation of the new scenario. Otherwise, if the new scenario is not similar to any previous cluster, a new single-member cluster with the new scenario is created at 264, and a complete representation is performed without information reuse. Adding the new cluster to the database 280 allows information from the new scenario to be reused even for later scenarios. Thus, useful information is preserved. If there are a large number of new scenarios to be evaluated, this can be used... Figure 1 and Figure 2 The mixing of elements. For example, a scheduler can be used after identifying which new scenarios belong to a new cluster.

[0041] exist Figure 3 In this process, multiple scenarios begin with a very small number of scenarios, but more scenarios are added as time progresses. At point 330, a preliminary analysis of the scenarios is generated. In this case, no clustering or scheduling is performed. Instead, at point 362, each new scenario is compared with previously evaluated scenarios to determine which scenarios (if any) can be used as reference scenarios. If similar scenarios have been previously evaluated, at point 366, information from those scenarios is reused to perform a complete representation of the new scenario. If no similar scenarios exist, at point 364, a complete representation of the new scenario is performed without information reuse. At point 368, the results of these new evaluations can be stored in database 380 for later reuse.

[0042] Figure 4 This is a block diagram of a system that can be used to implement the process described herein. The system includes a project database 410, which includes designed and evaluated scenarios. The system also includes a simulator 420 that performs Monte Carlo simulations. Database 480 stores information from previous evaluations. This can include preliminary analyses to determine whether scenarios are similar, as well as complete characterizations that allow for the reuse of information between similar scenarios. Software tool 400 includes implementations... Figures 1 to 3 The software modules in steps x30 through x60 are as follows: Module 430 controls simulator 420 to generate preliminary analysis. Module 440 processes scene similarity comparisons, including grouping scenes into clusters (if applicable). Module 450 is a scheduler that schedules complete evaluations of different scenes. Module 460 processes the generation of complete representations. This includes determining whether information reuse is available, transferring information from other scenes, and controlling simulator 420 to run additional simulations as needed.

[0043] Figure 5 An example set of processes 500 is shown used during the design, verification, and manufacturing of an article of art, such as an integrated circuit, to transform and verify design data and instructions representing the integrated circuit. Each of these processes can be constructed and enabled as multiple modules or operations. The term "EDA" stands for "Electronic Design Automation." These processes begin with the creation of a product concept 510 and are transformed using information provided by the designer to create an article of art using the EDA process set 512. When the design is finalized, the design is tape-out 534, which occurs when the artwork (e.g., geometric pattern) of the integrated circuit is sent to a manufacturing facility to create a mask set, which is then used to manufacture the integrated circuit. After tape-out, the semiconductor chip is manufactured 536, and packaging and assembly processes 538 are performed to produce the finished integrated circuit 540.

[0044] The specifications of a circuit or electronic structure can range from low-level transistor material placement to high-level description languages. Hardware description languages ​​(“HDLs”), such as VHDL, Verilog, SystemVerilog, SystemC, MyHDL, or OpenVera, can be used to design circuits and systems using high-level representations. HDL descriptions can be transformed into logic-level register-transfer-level (“RTL”) descriptions, gate-level descriptions, placement-level descriptions, or mask-level descriptions. Each lower-level representation, as a more detailed description, adds more useful details to the design description, such as more details about the described modules. Lower-level representations as more detailed descriptions can be computer-generated, exported from a design library, or created by another design automation process. An example of a specification language used to specify lower-level representations that provide more detailed descriptions is SPICE, which is used for detailed descriptions of circuits with many analog components. Descriptions at each representation level are enabled for use by the corresponding system at that level (e.g., a formal verification system). The design process can use… Figure 5 The sequence described herein. The process described should be enabled by the EDA product (or EDA system).

[0045] During system design phase 514, the functionality of the integrated circuit to be manufactured is specified. The design can be optimized for desired characteristics such as power consumption, performance, area (physical and / or lines of code), and cost reduction. At this stage, the design can be divided into different types of modules or components.

[0046] During logic design and functional verification 516, modules or components in a circuit are specified in one or more description languages, and the functional accuracy of the specifications is checked. For example, components of a circuit can be verified to generate outputs that match the requirements of the specifications for the circuit or system being designed. Functional verification can use simulators and other programs, such as testbed generators, static HDL checkers, and formal verifiers. In some embodiments, a specific system of components, referred to as a “simulator” or “prototype system,” is used to accelerate functional verification.

[0047] During the synthesis and design phase for Test 518, HDL code is transformed into a netlist. In some embodiments, the netlist may be a graph structure, where edges represent components of the circuit, and nodes represent how the components are interconnected. Both HDL code and netlist are hierarchical artifacts that can be used by EDA products to verify that the integrated circuit performs according to a specified design during manufacturing. The netlist can be optimized for a target semiconductor manufacturing technology. Additionally, the finished integrated circuit can be tested to verify that it meets specification requirements.

[0048] During netlist verification (520), the netlist is checked to ensure it meets timing constraints and corresponds to the HDL code. During design planning (522), the overall planar diagram of the integrated circuit is constructed, and timing and top-level routing analyses are performed on it.

[0049] During layout or physical implementation 524, physical placement (such as the location of circuit components like transistors or capacitors) and routing (connecting circuit components via multiple conductors) occur, and cells can be selected from a library to implement a specific logic function. As used herein, the term "cell" can specify a set of transistors, other components, and interconnections that provide Boolean logic functions (e.g., AND, OR, NOT, XOR) or stored functions (such as flip-flops or latches). As used herein, a circuit "block" can refer to two or more cells. Both cells and circuit blocks can be referred to as modules or components and are enabled as physical structures and in simulation. Parameters, such as size, are specified for the selected cell (based on "standard cells"), and it is made accessible in the database for use in EDA products.

[0050] During the analysis and extraction phase 526, circuit functionality is verified at the layout level, allowing for improvements to the layout design. During physical verification 528, the layout design is checked to ensure that manufacturing constraints (such as DRC constraints, electrical constraints, and lithographic constraints) are correct and that the circuit functionality matches the HDL design specifications. During resolution enhancement 530, the geometry of the layout is transformed to improve how the circuit design is manufactured.

[0051] During the tape-out process, data is created for the production of a photomask (if appropriate, after the application of photolithography enhancement). During mask data preparation 532, the "tape-out" data is used to generate a photomask, which is used to produce the finished integrated circuit.

[0052] Computer systems (such as) Figure 6 The storage subsystem of the computer system (600) can be used to store programs and data structures used by some or all of the EDA products described herein, as well as products used to develop units for libraries and physical and logical designs for using libraries.

[0053] Figure 6 An example machine of computer system 600 is shown, within which a set of instructions can be executed to cause the machine to perform any one or more of the methods discussed herein. In alternative implementations, the machine can be connected (e.g., networked) to other machines in a LAN, intranet, extranet, and / or the Internet. The machine can operate as a server or client machine in a client-server network environment, as a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0054] A machine can be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, network device, server, network router, switch, or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) specifying the actions to be taken by that machine. Furthermore, while a single machine is shown, the term "machine" should also be considered as any collection of machines that individually or jointly execute (or multiple sets of) a set of instructions to perform any one or more of the methods discussed herein.

[0055] Example computer system 600 includes processing device 602 communicating with each other via bus 630, main memory 604 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), static memory 606 (e.g., flash memory, static random access memory (SRAM), etc.), and data storage device 618.

[0056] Processing device 602 represents one or more processors, such as microprocessors, central processing units, etc. More specifically, processing device may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor that implements other instruction sets, or a processor that implements a combination of instruction sets. Processing device 602 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. Processing device 602 may be configured to execute instructions 626 for performing the operations and steps described herein.

[0057] The computer system 600 may also include a network interface device 608 for communication via a network 620. The computer system 600 may also include a video display unit 610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 612 (e.g., a keyboard), a cursor control device 614 (e.g., a mouse), a graphics processing unit 622, a signal generation device 616 (e.g., a speaker), a graphics processing unit 622, a video processing unit 628, and an audio processing unit 632.

[0058] Data storage device 618 may include machine-readable storage medium 624 (also referred to as non-transitory computer-readable medium) storing one or more sets of instructions 626 or software embodying any one or more of the methods or functions described herein. During execution of instructions 626 by computer system 600, instructions 626 may also reside wholly or at least partially in main memory 604 and / or processing device 602, which also constitute machine-readable storage media.

[0059] In some implementations, instruction 626 includes instructions for implementing functions corresponding to this disclosure. Although machine-readable storage medium 624 is shown as a single medium in the example implementation, the term "machine-readable storage medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) storing one or more instruction sets. The term "machine-readable storage medium" should also be understood to include any medium capable of storing or encoding instruction sets for machine execution and causing the machine and processing device 602 to perform any one or more methods of this disclosure. Therefore, the term "machine-readable storage medium" should be understood to include, but is not limited to, solid-state memories, optical media, and magnetic media.

[0060] Certain parts of the preceding detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within computer memory. These algorithmic descriptions and representations are the most effective way for those skilled in the art of data processing to communicate the essence of their work to others skilled in the art. An algorithm can be a sequence of operations that leads to a desired result. These operations are those that require physical manipulation of physical quantities. Such quantities can take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Such signals can be referred to as bits, values, elements, symbols, characters, items, numbers, etc.

[0061] However, it should be remembered that all these and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to those quantities. Unless otherwise expressly stated in this disclosure, it should be understood that throughout the description, certain terms refer to the actions and processes of a computer system or similar electronic computing device that manipulate and convert data represented as physical (electronic) quantities in the registers and memories of the computer system into other data similarly represented as physical quantities in the computer system's memory or registers or other such information storage devices.

[0062] This disclosure also relates to means for performing the operations described herein. Such means may be specifically configured for the intended purpose, or it may comprise 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 magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards or optical cards, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0063] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various other systems may be used in conjunction with the programs taught herein, or it may be convenient to construct more specialized devices to perform the methods. Furthermore, this disclosure is described without reference to any particular programming language. It should be understood that the teachings of this disclosure as described herein can be implemented using various programming languages.

[0064] This disclosure may be provided as a computer program product or software, and may include a machine-readable medium having instructions stored thereon, the described instructions being usable for programming a computer system (or other electronic device) to perform processes according to this disclosure. Machine-readable media include any mechanism for storing information in a machine-readable (e.g., computer-readable) form. For example, machine-readable (e.g., computer-readable) media include machine-readable (e.g., computer-readable) storage media, such as read-only memory (“ROM”), random access memory (“RAM”), disk storage media, optical storage media, flash memory devices, etc.

[0065] In the foregoing disclosure, implementations of this disclosure have been described with reference to specific example implementations thereof. It is clear that various modifications may be made thereto without departing from the broader spirit and scope of the implementations of this disclosure as set forth in the appended claims. Where this disclosure relates to elements in the singular tense, more than one element may be depicted in the drawings, and similar elements are labeled with similar numbers. Therefore, this disclosure and the drawings are to be considered illustrative rather than restrictive.

Claims

1. A method comprising: The circuit is simulated in multiple different scenarios to generate a preliminary analysis of the circuit for the different scenarios, wherein the simulation is affected by statistical variations; Based on the preliminary analysis, the different scenarios are grouped into clusters; as well as Estimating a complete representation of the circuit for a first scenario within the scenario by a processing device includes: transferring a complete representation for a reference scenario from the reference scenario to the first scenario, wherein the reference scenario and the first scenario are grouped in the same cluster, and the complete representation for the reference scenario is generated by additional simulation of the circuit.

2. The method according to claim 1, wherein the different scenarios include at least one of the following: different processing conditions, different voltage conditions, different temperature conditions, different input signal modes, different load conditions, and implementation of the circuit using different devices.

3. The method of claim 1, wherein the complete characterization of the circuit includes measures for at least one of the following: timing delay, hold-up margin, noise level, and voltage variation.

4. The method according to claim 1, wherein the complete characterization of the circuit includes at least one of the following: standard cell variation characterization, multi-angle standard cell variation characterization, standard cell robustness check, and general multi-angle multi-test bench variation characterization.

5. The method of claim 1, wherein grouping the different scenarios into clusters is based on the correlation between the preliminary analyses of the different scenarios.

6. The method of claim 1, wherein grouping the different scenarios into clusters is further based on metadata describing the different scenarios.

7. The method of claim 1, wherein grouping the different scenarios into clusters uses at least one of the following: minimum similarity requirement within clusters, maximum cluster merge distance, and dynamic cluster truncation method.

8. The method of claim 1, wherein transferring the complete representation for the reference scenario comprises: Train and apply a multi-scenario machine learning model for the scenarios in the same cluster.

9. A non-transitory computer-readable medium comprising stored instructions, which, when executed by a processing device, cause the processing device to: A simulation of the circuit is performed in a first scenario to generate a preliminary analysis of the circuit for the first scenario, wherein the simulation is affected by statistical variations; Based on the similarity between the preliminary analysis of the first scenario and the preliminary analysis of the second scenario, the second scenario is identified; as well as Estimating a complete characterization of the circuit for the first scenario includes: The complete representation for the second scenario is transferred to the first scenario.

10. The non-transitory computer-readable medium of claim 9, wherein transferring the complete representation for the second scenario to the first scenario comprises: The samples used to generate a complete representation of the second scenario are transferred to the first scenario; as well as Use the migrated samples to perform additional simulations in the first scenario.

11. The non-transitory computer-readable medium of claim 9, wherein transferring the complete representation for the second scenario to the first scenario comprises: The machine learning model used to generate the complete representation for the second scenario is transferred to the first scenario.

12. The non-transitory computer-readable medium of claim 11, wherein the transfer of the machine learning model uses at least one of the following: Bayesian methods and transfer learning.

13. The non-transitory computer-readable medium of claim 9, wherein transferring the complete representation for the second scenario to the first scenario comprises: The tail region of the statistical changes for the second scenario is migrated to the first scenario.

14. The non-transitory computer-readable medium of claim 9, wherein transferring the complete representation for the second scenario to the first scenario comprises: The simulation results used to generate the complete representation for the second scenario are transferred to the first scenario.

15. The non-transitory computer-readable medium according to claim 9, further comprising: Verify the estimate of the complete representation for the first scenario.

16. A system comprising: A database is configured to: store evaluated scenarios of circuit operation, corresponding preliminary analyses of the circuit for the evaluated scenarios, and corresponding complete representations of the circuit for the evaluated scenarios; wherein the representation for the evaluated scenarios is generated through simulations of the circuit affected by statistical variations; and A memory for storing instructions, and a processing device coupled to the memory and for executing the instructions, wherein the instructions, when executed, cause the processing device to: Simulations of the circuit are performed under multiple unevaluated scenarios to generate a preliminary analysis of the circuit for the unevaluated scenarios; Based on the similarity between the preliminary analysis of the unevaluated scenario and the preliminary analysis of the evaluated scenario, the database is accessed to identify reference scenarios for the unevaluated scenario from the evaluated scenarios. as well as Estimate the complete characterization of the circuit for the unevaluated scenario, including: For the unevaluated scenario where the reference scenario is identified, the complete representation for the reference scenario is retrieved from the database, and the complete representation for the reference scenario is migrated to the unevaluated scenario. as well as For unevaluated scenarios where the reference scenario is not identified, additional simulations of the circuit are performed under the unevaluated scenarios, and the unevaluated scenarios, preliminary analysis, and complete characterization are stored in the database.

17. The system of claim 16, wherein the estimation of the complete representation of the circuit for the unevaluated scenario is scheduled in an order that increases the probability of identifying a reference scenario for the unevaluated scenario.

18. The system of claim 16, wherein the instructions, when executed, cause the processing device to further group the different scenarios into clusters based on the preliminary analysis; and the estimated complete representation of the circuit for the unevaluated scenario is scheduled in an order that prioritizes clusters whose complete representations have not yet been estimated.

19. The system of claim 16, wherein the preliminary characterization and the complete characterization are performed using Monte Carlo simulations, and the preliminary analysis is performed using fewer Monte Carlo simulations than the complete characterization.

20. The system of claim 19, wherein the preliminary analysis for different unevaluated scenarios uses the same seed for the Monte Carlo simulation.

Images