Predicting metrics in early stage circuit design based on machine learning

Abstract

When designing a circuit to meet certain constraint requirements, it is challenging to determine whether a given circuit design will meet the constraints. At early stages of a circuit design (e.g., synthesis or placement), a designer can have limited information to rely on in order to determine whether the final circuit or some design variation thereof will meet the constraints without needing to fully design the circuit. The methods described herein use a machine learning (ML) model to predict whether an entire circuit is likely to meet a constraint based on features of a partial circuit design at an early stage of the design flow. Additionally, the disclosed methods allow for ranking various circuit designs or design implementations to determine the best candidate to proceed with full design.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of U.S. Patent Application No. 62 / 989,687, titled “Machine Learning-Based Prediction of Achievable QoR Metrics at Post-Route and Post-Route Optimization Stages to Enable Early-Stage Design Exploration,” filed March 14, 2020, the entirety of which is incorporated herein by reference. TECHNICAL FIELD

[0003] The present disclosure relates generally to the field of electronic design automation (EDA), and more specifically to the use of machine learning (ML) in the prediction of results quality (QoR) metrics for portions of EDA circuit design. BACKGROUND

[0004] Design closure for many modern circuits, such as system-on-chip (SoC) designs, has become computationally complex. Additionally, physical designers spend a significant amount of time and resources at early stages such as synthesis, initial placement, or placement optimization to try to improve design quality by exploring multiple metrics such as performance, area, timing, power, etc.

[0005] Designers currently run multiple iterations of the implementation flow to observe the results quality (QoR) of each of its runs to get feedback. This process is time consuming as a complete implementation flow can take days to weeks to complete.

[0006] Therefore, what is needed is a method to obtain QoR metrics for a design run at an early design stage, thereby avoiding the time investment needed to observe such QoR metrics from a complete run. SUMMARY

[0007] Systems, methods, and computer program products for prediction of machine learning (ML) based metrics in early stage circuit design are disclosed herein. In an example method, a partial circuit design run for a circuit is generated. By executing an ML model on the partial circuit design run, a predicted quality of results (QoR) metric is produced for the partial circuit design run. The ML model is trained using features extracted from a training circuit at a development stage and actual QoR metrics from a full design run of the training circuit. Based on the predicted QoR metric, a determination is made that the partial circuit design run satisfies a constraint on the predicted QoR metric. And, based on the determination, a full circuit design run for the circuit is executed from the partial circuit design run.

[0008] This summary is not intended to provide any specific inventive, exemplary, or illustrative aspects of the present disclosure, as it can be used in commerce. Additionally, this summary is not intended to represent key or important elements of the innovations, embodiments, or examples, or limit the scope of the subject matter of the present disclosure. The innovations, embodiments, and / or examples found in the present disclosure are not all-inclusive, but rather, describe the basic scope of the subject matter. As such, one use of this summary is as a prelude to the detailed description presented below. BRIEF DESCRIPTION OF DRAWINGS

[0009] The present disclosure will become more fully understood from the detailed description and the accompanying drawings given below. The drawings are used to provide knowledge and understanding of embodiments of the present disclosure, and do not limit the scope of the present disclosure to these particular embodiments. Furthermore, the drawings are not necessarily to scale.

[0010] Figure 1 A back-end physical implementation flow with various stages of synthesis to place / route selection / issuance is shown in accordance with an embodiment.

[0011] Figure 2 A prediction element of a ML-QoR modeling and prediction flow in accordance with an embodiment is shown.

[0012] Figure 3 is a flow diagram showing an example predictor utilized by a ML-QoR modeling and prediction flow in accordance with an embodiment.

[0013] Figure 4 is a table showing a prediction of a flow end QoR metric that enables ordering of design runs using order statistics in accordance with an embodiment.

[0014] Figure 5 A flow diagram depicting various processes used during the design and fabrication of integrated circuits in accordance with some embodiments of the present disclosure.

[0015] Figure 6 An abstract diagram depicting an example simulation system in accordance with some embodiments of the present disclosure.

[0016] Figure 7 An abstract diagram depicting an example computer system in which embodiments of the present disclosure can operate is shown.

[0017] Figure 8 Integration of ML-QoR with ICCII / FC according to embodiments is shown.

[0018] Figure 9 Timing prediction flow with ML timing model according to embodiments is shown.

[0019] Figure 10 Example timing prediction flow results according to embodiments are shown.

[0020] Figure 11 Example results for a set of ranking runs in an example design according to embodiments are depicted.

[0021] Figure 12 Example results for timing prediction according to embodiments are shown.

[0022] Figure 13 Example routing score flow according to embodiments is shown.

[0023] Figure 14 Example routability score results according to embodiments are shown. DETAILED DESCRIPTION

[0024] Aspects of the present invention relate to prediction of machine learning (ML) based metrics in early stage circuit design. Circuit designers working at early design stages (e.g., synthesis, placement, placement optimization, etc.) often have to decide among multiple possible design solutions to fully simulate. The process of fully simulating a circuit can be time consuming, especially for more complex circuits such as system on chip (SoC) designs. The methods disclosed herein allow a designer to use ML models to analyze early stage circuit designs to predict whether the final circuit design will meet design constraints.

[0025] Currently, there are no tools that provide accurate and reliable estimates of the required quality of results (QoR) metrics in early stages of design and flow. In particular, there is a need for tools to provide a prediction on whether a given circuit design run has the potential to meet QoR targets or whether it should be discarded to save resources. Existing heuristic models lack the accuracy of the disclosed ML model approach, as well as the simplicity of integrating into the early stage design flow disclosed herein. Typical QoR metrics are optimized for timing, routability, area, power, runtime, and memory, including for each full flow run. Designers have started to rely on many heuristic methods to estimate these QoR metrics in early design stages, but many complex factors such as advanced node technology can exacerbate the difference between predicted QoR metrics and actual metrics, which can only be determined by full flow runs. And since full flow runs typically take days to complete, better prediction models are needed.

[0026] In addition to providing predictions for QoR target constraints, the ML model disclosed herein can help early stage circuit designers predict end-of-flow QoR and bottlenecks by providing a fast and accurate method. Metrics can be provided in real-time as feedback to designers to help improve register transfer level (RTL) synthesis, constraints, and placement in early stages such as synthesis and placement.

[0027] Additionally, when a designer has multiple possible available designs that can meet QoR target constraints, the ML model disclosed herein can provide the designer with an accurate method of ranking multiple runs at early design stages based on estimated end-of-flow QoR metrics using order statistics. This allows the designer to only perform full design for the highest ranked early stage design that is expected to best meet a given set of QoR targets. Currently, ranking multiple designs based on QoR metrics again requires full flow runs for accuracy.

[0028] The QoR “look-ahead” prediction and ranking method uses ML techniques to model how each of the following aspects impacts QoR metrics of the final circuit design at various design stages during a development flow associated with one or more full circuit designs: (1) placement changes during optimization; (2) netlist changes due to clock tree synthesis (CTS) and multiple rounds of optimization; (3) impact of routing on timing window; (4) timer and extraction changes; and (5) user flow settings.

[0029] The ML-QoR model is then used during development of new circuit designs to (a) identify which design runs have potential to meet established QoR targets and which runs can be discarded to save resources, (b) quickly and accurately predict flow- end QoR and bottlenecks, which are provided as feedback to improve RTL / constraints / layout during the synthesis and placement phases of circuit design development, and (c) accurately rank multiple runs based on estimated flow-end QoR metrics at early design stages using order statistics.

[0030] Figure 1 A back-end physical implementation flow 100 is shown in accordance with an embodiment, with various stages from synthesis to routing selection / issue. Various stages 102a-102h are described, which correspond to exemplary design stages of an implementation flow for a circuit design. Features are extracted from each of the various early design stages (e.g., stages 102a-102e) and provided to each of the various ML models in the ML model store 108 for processing.

[0031] During training, results of later design stages (e.g., stages 102f-102g) can be used to determine actual QoR metrics and adjust the ground truth for the ML models in the ML model store 108 accordingly. Features extracted from early design stages 102a-102e can be weighted differently during training for the ML models in the ML model store 108 to produce QoR metric results that are known at the end of later design stages 102f-102g. According to one embodiment, ground truth labels are collected at the post-routing stage, at the detailed routing 102f, or at the post-routing optimization 102g step for each QoR metric.

[0032] In machine learning, the term "ground truth" refers to the accuracy of the classification of a training set for a supervised learning technique. This is used in statistical models to prove or disprove research hypotheses. The term "ground truthing" refers to the process of collecting the appropriate target (provable) data for the test. As an example, Bayesian spam filtering is a typical use case for supervised learning, where an algorithm is taught the difference between spam and non-spam messages by hand. This depends on the ground truth of the messages used to train the algorithm - inaccurate messages in the ground truth will correlate to inaccuracies in the resulting spam / non-spam decisions.

[0033] Different ground truths are collected at later stages 102f-102g of the design flow for various ML models in the ML model storage 108. For timing prediction, ground truth features are collected for all constrained endpoints in each multi-angle multi-mode scenario. For routability prediction, ground truth features are collected after detailed routing 102f is performed on the design. For area / power, ground truth features are collected for all instances in each multi-angle multi-mode scenario. Based on the assumption that these features contribute to the changes in power and area during the implementation flow, these features are used as ground truths. Those skilled in the relevant art will appreciate that other features can be collected as appropriate to establish the ground truths needed for the complete circuit design.

[0034] Past runs 104 can be used to provide features used in the training. According to embodiments, past runs 104 are selected for use in the ML models of the ML model storage 108 based on previous implementation runs of the same design (earlier version) or similar designs of the partial circuit under test using the same techniques and processes. These saved past runs 104 can then have the required features extracted for training the particular partial circuit design based on similar features of the saved past runs 104 to the partial circuit design. As non-limiting examples, an associated position vector indicating the relative placement positions of two associated cells in a given placement solution, and an associated path stage vector of the number of stages present in the signal path between the two cells in the placement solution run can be extracted. The training phase can include multiple designs or multiple implementations of the same design obtained by varying the constraints, flow settings, and layout context.

[0035] During the development phase of training the circuit design, conventional electronic design automation (EDA) tools (e.g., placement tools, site selection tools, routing tools, routing selection tools, etc.) can be used to generate past runs 104 to generate multiple complete circuit design runs. For example, placement EDA tools are used to generate placement solution runs for a current version of the first circuit design, where each placement solution run is generated by applying an associated set of preconditions to the current test circuit design and then performing all the regular placement tool operations needed to generate a complete placement solution.

[0036] For example, as the placement tool completes the placement process, actual delay / timing values are computed for each pair of associated cells using known techniques, and then the delay / timing model is modified as needed (e.g., using known techniques such as mean squared error loss) so that its predictions for each pair of associated cells more accurately correspond to the computed actual delay / timing values. That is, during the early stages of the model training process, the model can generate relatively inaccurate predicted timing / delay values that differ significantly from the actual delay / timing values computed at the end of each training run, but over time the model is gradually modified until it generates predicted delay / timing values that precisely match the actual delay / timing values.

[0037] In the execution flow for the ML model, the EDA tool is configured to run the flow on a set of designs for the early stages (e.g., placement selection 102c). As part of the training process, training features are extracted at the early stages. The EDA tool continues through the end of routing 102f and routing selection 102g. For predicting design rule checks (DRCs), labels are extracted after detailed routing 102f. For predicting timing and power, labels are extracted at the end of routing selection 102g.

[0038] The ML model storage 108 includes multiple ML models, each trained to predict a separate QoR metric. For example, the disclosed ML training algorithm can be used to train a delay / timing ML model that predicts the amount of time required to transmit a signal between two associated cells used in a given placement solution run (“delay / timing”).

[0039] With the training method, the ML models in the ML model storage 108 can be configured to consider various factors that can impact QoR metrics early in the design implementation flow, such as placement changes during optimization, netlist changes due to clock tree synthesis (CTS) and multiple rounds of optimization, the impact of routing on timing windows, timer and extraction changes, and user flow settings. In subsequent runs of the same modified design or a new design, the EDA tool will only run through the early design stages (e.g., 102a or 102b), at which point it will extract the prediction features.

[0040] By training the ML model in the ML model storage 108, features from early design stages (e.g., stages 102a-102e) can be provided to the ML model to predict various QoR metric predictions 110, such as QoR predictions for timing, routability, area, power, runtime, and memory for partial circuit designs. Additionally, design and layout constraints 106 can be provided by varying constraints, flow settings, and layout context to determine QoR predictions 110 for multiple designs or multiple implementations of the same design. The QoR predictions 110 can thus be provided without a full circuit design. Designers can explore parameters in runtime, constraints, layout, and flow settings in an efficient manner.

[0041] In addition to predicting achievable QoR metrics at early design stages, EDA tools can also provide multiple partial circuit designs (e.g., manually selected or generated based on constraints 106) for which QoR predictions 110 can be generated. These design runs are then ranked against each other for a given QoR metric, providing designers with an understanding of which runs are most likely to produce the best results for a given QoR metric. Designers can then use this ranking to proceed with a full design of one or more of the highest ranked partial designs and discard the rest. According to one embodiment, traditional EDA tools can be used to generate full circuit design runs for the highest ranked partial circuit designs.

[0042] Figure 2 A prediction element of the ML-QoR modeling and prediction flow 200 is shown, according to an embodiment. The design 202 is a partial circuit design in an early stage of design (e.g., after physical synthesis or placement). According to an embodiment, features to be analyzed by the ML-QoR model are extracted from the design 202, such as netlist features 204, timing constraints 206, electrical features 208, and physical features 210.

[0043] The features 204, 206, 208, and 210 are provided to various ML-QoR models in order to predict QoR metrics. For example, a delay / timing predictor 212, a DRC predictor 214, a power model 218, an area model 220, and a memory model 222 are all examples of ML-QoR models 216 that are used to predict corresponding QoR metrics. These ML-QoR models 216 can provide a final QoR prediction 224 for each of various QoR metrics, such as timing, area, power, routability, runtime, and memory.

[0044] Those skilled in the relevant art will appreciate that the ML-QoR models 216 can be trained using the training methods described above in a variety of different ways. The details of each ML-QoR model are not discussed herein. However, for ease of understanding, each of the ML-QoR models in the ML-QoR models 216 can be broadly described by the particular prediction made given early stage / pre-routing features such as the features 204, 206, 208, and 210. For example, the delay / timing predictor 212 (ML-Delay) can be trained to predict timing after the routing optimization stage. The predictor 214 (ML-DRC) can be trained to predict DRC severity and hotspots after detailed routing. The power model 218 (ML-Power) can be trained to predict cell’s internal leakage and net’s switching power after the routing optimization stage. The area model 220 (ML-Area) can be trained to predict the number of cells and cells’ area after the routing optimization stage. And the memory model 222 (ML-Memory) can be trained to predict peak memory usage of the routing and routing optimization stages.

[0045] The collection of ML-QoR models 216 enables prediction of individual designs as well as multiple designs or multiple implementations of the same design by varying constraints, flow settings, and layout context. During the test stage, based on a partial circuit of the design 202, the ML-QoR models are relied on for their QoR predictions and the EDA tool does not carry through to the end of the design flow. For each predictor (ML-Delay, ML-DRC, ML-Power, etc.) in the collection, the features extracted in the early stage are sufficient to describe the netlist transformation in an anticipatory manner. Figure 8 An integration 800 of the ML-QoR with Synopsys IC Compiler II (ICC II) and Fusion Compiler (FC) is shown in accordance with an embodiment.

[0046] Figure 3 A flow diagram 300 showing exemplary predictors utilized by the ML-QoR modeling and prediction flow in accordance with an embodiment. The ML-QoR predictor 302 can obtain results from a plurality of predictors such as the ML-Delay predictor 304, the ML-DRC predictor 306, and the ML-Power predictor 308 in order to determine an overall QoR prediction (e.g., score). These exemplary predictors are configured to be invoked by the EDA tool and receive feature information for a partial circuit design from the EDA tool.

[0047] The ML-QoR predictor 302 uses a collection of predictors such as the ML-Delay predictor 304, the ML-DRC predictor 306, and the ML-Power predictor 308 to enable prediction of individual designs as well as multiple designs or multiple implementations of the same design by varying constraints, flow settings, and layout context.

[0048] For timing prediction, the ML-delay predictor 304 correlates pre- and post- routing timing to predict the delay / margin for each timing endpoint at 310. The ML-delay predictor 304 makes these predictions by receiving unique features 316 about the partial circuit design from the EDA tool, including physical features, logical features, constraints, clocks, timing, etc. Likewise, the ML-delay predictor 304 is trained using these features from the partial circuit design, tested against ground truth information for corresponding QoR results from the full circuit design.

[0049] Figure 9 A timing prediction flow with ML timing model 900 is shown, in accordance with an embodiment. The flow is similar to Figure 1 the flow shown, but is an exemplary method specific to timing prediction. Figure 10 Exemplary timing prediction flow results 1000 are shown, in accordance with an embodiment. These results show the accuracy of the predictions from the timing model (e.g., Figure 3 ML-delay predictor 304) of FIG. 9, and thus their usefulness in running a full flow circuit design.

[0050] Figure 12 Exemplary results for timing prediction 1200 are shown, in accordance with an embodiment. Any machine learning based prediction tool will have modeling errors. The ML models described herein can use order statistics to compute the size and distribution of the errors. In one embodiment, a confidence interval based timing is computed for each endpoint prediction, and the sum of the mean, standard deviation, coefficient of variation, and confidence interval based total negative slack (TNS) rank are used to compute a final ranking for each design / implementation. These results computed for a number of results for timing prediction 1200 are shown by way of non-limiting example.

[0051] For DRC prediction, the ML-DRC predictor 306 predicts the severity of DRC errors, and can provide a heatmap for each layout cell at 312. The ML-DRC predictor 306 makes these predictions by receiving unique features 318 about the partial circuit design from the EDA tool, including estimated net routing, cell type placement, layers, etc. Likewise, the ML-DRC predictor 306 is trained using features from the partial circuit design, tested against ground truth information for corresponding QoR results from the full circuit design.

[0052] The ML-DRC predictor 306 is used to predict post-routing DRC and to generate a canonical representation of different types of DRC in a given technology node. Figure 13An exemplary routability score flow 1300 is shown according to an embodiment. These representations can be in an image (e.g., bitmap) format, a text format, or any other format. The formatted data can represent a DRC heat map. In one embodiment, the ML-DRC predictor 306 processes the predicted DRC report for each design (or design implementation), performs a convolution with the stored canonical representation of the DRC (e.g., the training DRC severity patterns, also in the same format as the representation), and computes a new "routability score." The routability score provides feedback to the designer about the DRC diversity of the design (or design implementation), i.e., a low score indicates that the design (or design implementation) has few DRCs and is routable, while a high score indicates that the design (or design implementation) has a large number of DRCs and can be non-routable. This score can be used to perform a ranking among designs (or design implementations) to select the best design (or design implementation) or the best set of designs. Figure 14 An exemplary result of the routability score is shown 1400 according to an embodiment. By running the well-trained ML-DRC predictor 306 on the early stage partial circuit design, the ML-QoR routing ranking can be determined for a hypothetical 7nm design using the routability score that is strongly correlated with actual routing- selected DRCs.

[0053] Similarly for power prediction, the ML-Power predictor 308 predicts per-net power (switching) and per-cell power (leakage, internal) at 314. The ML-Power predictor 308 makes the prediction by receiving unique features 320 about the partial circuit design from the EDA tool, which includes the neighborhood of cells, nets, library characteristics, constraints, etc. Likewise, the ML-Power predictor 308 is trained using features from the partial circuit design, tested against ground truth information from the full circuit design for corresponding QoR results.

[0054] Figure 4 is a table 416 showing the achievable flow end QoR metric prediction that enables ranking of design runs using order statistics according to an embodiment. In the exemplary method 400 shown, the design 402 is run five times (e.g., five different implementations 404, 406, 408, 410, and 412), but can also represent five different designs. The features required for each ML model in use are provided by the early stage partial circuit design (e.g., placement-selection as shown in the method 400), which are provided to one or more ML models 414 and used to compute a ranking for each QoR result for each ML model for each run. This application in the early flow stage (e.g., synthesis or placement) enables the designer to select the design (or design implementation) that can achieve the QoR constraints and discard the remaining designs, thereby improving productivity.

[0055] Figure 11 Example results of a set of ranking runs in an exemplary design according to an embodiment are depicted. While the concept of confidence intervals as discussed above Figure 12 The concept of confidence intervals is provided to help deal with modeling errors, but the lower CI TNS (i.e., the confidence interval of the TNS) statistics are used in a unique way to make the prediction and ranking methodology robust. The TNS is a function of the worst negative margin of all the endpoints in the design. As a result, the lower CI TNS of the prediction (example: 95% lower confidence interval) is presented as a more relevant metric for the design TNS and for the TNS ranking calculation. This result is provided without the need to design the circuit completely in a full flow run.

[0056] Figure 5 A set of exemplary processes 500 are shown that are used during the design, verification, and manufacture of an article of manufacture, such as an integrated circuit, to transform and verify design data and instructions representing a design of an integrated circuit. Each of these processes can be constructed and implemented in multiple formats and in multiple levels of granularity as multiple modules or operations. The term "EDA" represents the term "electronic design automation." These processes begin with the creation of a product concept 510 with information provided by a designer that is transformed to create an article of manufacture using a set of EDA processes 512. When the design is complete, the design is taped-out 534, which is when the artwork (e.g., geometric patterns) for the integrated circuit is sent to a fabrication facility to manufacture a mask set that is then used to manufacture the integrated circuit. After tape-out, 536 semiconductor dies are manufactured and packaging and assembly processes 538 are performed to produce a complete integrated circuit 540.

[0057] Specifications for a circuit or electronic structure can range from low-level transistor material layout to high-level description language. High-level abstractions can 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 into a logic-level register transfer level ('RTL') description, a gate-level description, a layout-level description, or a mask-level description. Each lower level of abstraction that is less abstract adds more useful detail to the design description, e.g., for the modules that the description includes. The lower level of abstraction that is less abstract can be computer generated, derived from a design library, or created by another design automation process. An example of a specification language at a lower level of abstraction language that specifies more detailed descriptions is SPICE, which is used for detailed descriptions of circuits with many analog components. The description at each level of abstraction enables use by the corresponding tools (e.g., formal verification tools) of that layer. The design process can use the order shown. EDA products (or tools) should enable the processes described. Figure 5 The order shown. EDA products (or tools) should enable the processes described.

[0058] During system design 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. The design can be partitioned into different types of modules or components at this stage.

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

[0060] During synthesis and design for testing 518, the HDL code is converted to a netlist. In some embodiments, the netlist can be a graph structure where the edges of the graph structure represent components of the circuit and the nodes of the graph structure represent how the components are interconnected. Both the HDL code and the netlist are artifacts that can be used by EDA products to verify that the integrated circuit, when manufactured, performs according to the specified design. The netlist can be optimized for the target semiconductor manufacturing technology. Furthermore, a complete integrated circuit can be tested to verify that the integrated circuit meets the requirements of the specification.

[0061] During netlist verification 520, the netlist is checked for compliance with timing constraints and correspondence with the HDL code. During design planning 522, the overall floorplan for the integrated circuit is constructed and analyzed for timing and top-level routing.

[0062] During layout or physical implementation 524, physical placement (such as positioning of circuit components such as transistors or capacitors) and routing (connecting circuit components through multiple conductors) occurs, and selection of cells from a library to enable particular logic functions can be performed. As used herein, the term “cell” can specify a group of transistors, other components, and interconnections that provide a Boolean logic function (e.g., AND, OR, NOT, XOR) or a storage function such as a flip-flop or latch. 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 for both physical structures and simulation. Parameters are specified for the selected cells (based on “standard cells”), such as size, and made accessible in a database for use by EDA products.

[0063] During analysis and extraction 526, circuit functionality is verified at the placement level, allowing for improvements to the placement design. During physical verification 528, the placement design is checked to ensure that manufacturing constraints are correct, such as DRC constraints, electrical constraints, lithographic constraints, and that the circuit device functionality matches the HDL design specification. During resolution enhancement 530, the geometry of the placement is transformed to improve how the circuit design can be manufactured.

[0064] During tape-out, data is created for use (if appropriate, after lithographic enhancement is applied) in the production of a photomask. During mask data preparation 532, the tape-out data is used to generate a photomask, which is used to produce a complete integrated circuit.

[0065] Computer systems (such as) Figure 7 Computer system 700 or Figure 6 The storage subsystem of the host system (607) can be used to store some or all of the programs and data structures used by the EDA products described herein, and the products are used for the development of units of the library and the physical and logical design of the library.

[0066] Figure 6 An abstract diagram of an example simulation environment 600 is depicted. Simulation environment 600 can be configured to verify the functionality of a circuit design. Simulation environment 600 may include a host system 607 (e.g., a computer as part of an EDA system) and a simulation system 602 (e.g., a set of programmable devices such as a field-programmable gate array (FPGA) or a processor). The host system generates data and information by using compiler 610 to construct the simulation system to simulate the circuit design. The circuit design to be simulated is also referred to as the design under test (“DUT”), where data and information from the simulation are used to verify the functionality of the DUT.

[0067] Host system 607 may include one or more processors. In embodiments where the host system includes multiple processors, the functions performed by the host system as described herein may be distributed across multiple processors. Host system 607 may include compiler 610 to translate a specification written in a description language to represent the DUT, and to generate data (e.g., binary data) and information for constructing simulation system 602 to simulate the DUT. Compiler 610 may translate, modify, refactor, add new functionality, and / or control the timing of the DUT.

[0068] The host system 607 and the emulation system 602 exchange data and information using signals carried by the emulation connection. The connection can be, but is not limited to, one or more cables, such as cables having pin configurations compatible with recommended standard 232 (RS232) or universal serial bus (USB) protocols. The connection can be a wired communication medium or network, such as a local area network or a wide area network, such as the Internet. The connection can be a wireless communication medium or network with one or more access points using wireless protocols, such as Bluetooth or IEEE 802.11. The host system 607 and the emulation system 602 can exchange data and information through a third device, such as a web server.

[0069] The emulation system 602 includes a plurality of FPGAs (or other modules), such as FPGAs 6041 and 6042 and additional FPGAs to 604 N Each FPGA can include one or more FPGA interfaces through which the FPGA is connected to other FPGAs (and possibly other emulation components) for the FPGAs to exchange signals. The FPGA interfaces can be referred to as input / output pins or FPGA pads. While the emulator can include FPGAs, embodiments of the emulator can include other types of logic blocks instead of or in addition to FPGAs for emulating the DUT. For example, the emulation system 602 can include custom FPGAs, special purpose ASICs for emulation or prototyping, memory, and input / output devices.

[0070] The programmable device can include an array of programmable logic blocks and an interconnect structure that enables the programmable logic blocks to be interconnected according to the descriptions in the HDL code. Each programmable logic block can enable complex combinational functionality or enable logic gates such as AND, and XOR logic blocks. In some embodiments, the logic blocks can also include memory elements / devices, which can be simple latches, flip-flops, or other blocks of memory. Depending on the length of the interconnects between different logic blocks, signals can arrive at the input terminals of the logic blocks at different times, and thus can be temporarily stored in the memory elements / devices.

[0071] The FPGAs 6041-604 N may be placed on one or more boards 6121 and 6122 and additional boards 612 M The plurality of boards can be placed into an emulation unit 6141. The boards within the emulation unit can be connected using the backplane of the emulation unit or any other type of connection. Additionally, a plurality of emulation units (e.g., 6141 and 6142 through 614 K ) can be connected to each other by cables or any other means to form a multi-emulation unit system.

[0072] For the DUT to be emulated, the host system 607 transmits one or more bit files to the emulation system 602. The bit files can specify a description of the DUT and can further specify partitions of the DUT created by the host system 607 with trace and injection logic, mapping of the partitions to FPGAs of the emulator, and design constraints. Using the bit files, the emulator configures the FPGAs to perform the functions of the DUT. In some embodiments, one or more FPGAs of the emulator can have trace and injection logic built into the silicon of the FPGA. In such embodiments, the FPGAs can not be configured by the host system to emulate the trace and injection logic.

[0073] The host system 607 receives a description of the DUT to be emulated. In some embodiments, the DUT description is in a description language (e.g., register transfer language (RTL)). In some embodiments, the DUT description is in a netlist level file or a mix of netlist level files and HDL files. If a portion of the DUT description or the entire DUT description is in HDL, the host system can synthesize the DUT description to create a gate level netlist using the DUT description. The host system can use the netlist of the DUT to partition the DUT into a plurality of partitions, where one or more of the partitions include trace and injection logic. The trace and injection logic traces interface signals exchanged through the interfaces of the FPGAs. In addition, the trace and injection logic can inject the traced interface signals into the logic of the FPGAs. The host system maps each partition to an FPGA of the emulator. In some embodiments, the trace and injection logic is included in selected partitions for a set of FPGAs. The trace and injection logic can be built into one or more FPGAs of the emulator. The host system can synthesize multiplexers to be mapped into the FPGAs. The trace and injection logic can use the multiplexers to inject the interface signals into the DUT logic.

[0074] The host system creates bit files that describe each partition of the DUT and the mapping of the partitions to the FPGAs. For partitions in which trace and injection logic is included, the bit files also describe the included logic. The bit files can include placement and routing information as well as design constraints. The host system stores the bit files and information describing which FPGAs will emulate each component of the DUT (e.g., to which FPGAs each component is mapped).

[0075] Upon request, the host system transmits the bit files to the emulator. The host system sends a signal to the emulator to begin emulation of the DUT. During or at the end of the emulation of the DUT, the host system receives the results of the emulation from the emulator over the emulation connection. The results of the emulation are data and information generated by the emulator during the emulation of the DUT, which includes the interface signals and the states of the interface signals that have been traced by the trace and injection logic of each FPGA. The host system can store the results of the emulation and / or send the results of the emulation to another processing system.

[0076] After simulating the DUT, the circuit designer can request to debug a component of the DUT. If such a request is made, the circuit designer can specify a time period of the simulation for debugging. The host system uses the stored information to identify which FPGAs are simulating the component. The host system retrieves the interface signals associated with the time period and trace by injection logic of each identified FPGA. The host system sends a signal to the simulator to re-simulate the identified FPGAs. The host system transmits the retrieved interface signals to the simulator to re-simulate the component for the specified time period. The trace by injection logic of each identified FPGA injects the respective interface signals it receives from the host system into the logic of the DUT mapped to the FPGA. In the case of multiple re-simulations of the FPGAs, the results are merged to produce a full debug view.

[0077] The host system receives the signals traced by the logic of the identified FPGAs during the re-simulation of the component from the simulation system. The host system stores the signals received from the simulator. The signals traced during the re-simulation can have a higher sampling rate than the sampling rate during the initial simulation. For example, in the initial simulation, the traced signals can include a saved state of the component every X milliseconds. However, in the re-simulation, the traced signals can include a saved state every Y milliseconds, where Y is less than X. If the circuit designer requests to view the waveform of the signals traced during the re-simulation, the host system can retrieve the stored signals and display a plot of the signals. For example, the host system can generate a waveform of the signals. Thereafter, the circuit designer can request to re-simulate the same component for a different time period or to re-simulate another component.

[0078] The host system 607 and / or the compiler 610 can include subsystems such as, but not limited to, a design synthesizer subsystem, a mapping subsystem, a run-time subsystem, a results subsystem, a debug subsystem, a waveform subsystem, and a storage subsystem. The subsystems can be structured and enabled as single or multiple modules, or two or more can be structured as one module. Together, the subsystems make up the simulator and monitor the simulation results.

[0079] The design synthesizer subsystem converts the HDL representing the DUT 605 to gate level logic. For a DUT to be simulated, the design synthesizer subsystem receives a description of the DUT. If the description of the DUT is in HDL in whole or in part (e.g., RTL or other abstraction level), the design synthesizer subsystem synthesizes the HDL of the DUT to create a gate level netlist having a description of the DUT in gate level logic.

[0080] The mapping subsystem partitions the DUT and maps the partitions to the emulator FPGAs. The mapping subsystem uses the netlist of the DUT to partition the DUT at the gate level into multiple partitions. For each partition, the mapping subsystem retrieves the gate level description of the traces and injection logic and adds the logic to the partition. As described above, the traces and injection logic included in the partition are used to track the signals exchanged via the interface of the FPGA to which the partition is mapped (track interface signals). The traces and injection logic can be added to the DUT prior to partitioning. For example, the traces and injection logic can be added by the design synthesizer subsystem prior to or after synthesizing the HDL of the DUT.

[0081] In addition to including the traces and injection logic, the mapping subsystem can include additional tracking logic in the partitions to track the state of certain DUT components that are not tracked and injected. The mapping subsystem can include the additional tracking logic in the DUT prior to partitioning or in the partitions after partitioning. The design synthesizer subsystem can include the additional tracking logic in the HDL description of the DUT prior to synthesizing the HDL description.

[0082] The mapping subsystem maps each partition of the DUT to an FPGA of the emulator. For partitioning and mapping, the mapping subsystem uses design rules, design constraints (e.g., timing or logic constraints), and information about the emulator. For components of the DUT, the mapping subsystem stores information in the storage subsystem that describes which FPGAs will emulate each component.

[0083] Using the partitioning and mapping, the mapping subsystem generates one or more bit files that describe the created partitions and the mapping of the logic to each FPGA of the emulator. The bit files can include additional information, such as constraints of the DUT and wiring information for connections between the FPGAs and connections within each FPGA. The mapping subsystem can generate a bit file for each partition of the DUT and can store the bit file in the storage subsystem. Upon request from the circuit designer, the mapping subsystem transmits the bit files to the emulator, and the emulator can use the bit files to configure the FPGAs to emulate the DUT.

[0084] If the emulator includes a dedicated ASIC that includes the traces and injection logic, the mapping subsystem can generate a specific configuration that connects the dedicated ASIC to the DUT. In some embodiments, the mapping subsystem can save information for the tracked / injected signals and where the information is stored on the dedicated ASIC.

[0085] The runtime subsystem controls the simulation performed by the simulator. The runtime subsystem can cause the simulator to start or stop performing the simulation. Additionally, the runtime subsystem can provide input signals and data to the simulator. The input signals can be provided directly to the simulator through a connection or indirectly through other input signal devices. For example, the host system can control the input signal devices to provide input signals to the simulator. The input signal devices can be, for example, test boards (directly or through cables), signal generators, another simulator, or another host system.

[0086] The results subsystem processes simulation results generated by the simulator. During the simulation and / or after the simulation is complete, the results subsystem receives the simulation results from the simulator generated during the simulation. The simulation results include the signals tracked during the simulation. In particular, the simulation results include the interface signals tracked by the traces and injection logic of each FPGA and can include signals tracked by additional logic included in the DUT. Each tracked signal can span multiple cycles of the simulation. The tracked signals include multiple states and each state is associated with a time of the simulation. The results subsystem stores the tracked signals in the storage subsystem. For each stored signal, the results subsystem can store information indicating which FPGA generated the tracked signal.

[0087] The debug subsystem allows a circuit designer to debug components of the DUT. After the simulator has simulated the DUT and the results subsystem has received the interface signals tracked by the traces and injection logic during the simulation, the circuit designer can request to debug a component by re-simulating the component for a particular time period. In the request to debug the component, the circuit designer identifies the component and indicates the time period to simulate to debug. The circuit designer's request can include a sample rate indicating a frequency at which the states of the component being debugged should be saved by the tracking logic.

[0088] The debug subsystem uses the information stored by the mapping subsystem in the storage subsystem to identify the one or more FPGAs of the simulator that are simulating the component. For each identified FPGA, the debug subsystem retrieves from the storage subsystem the interface signals tracked by the traces and injection logic of the FPGA during the time period indicated by the circuit designer. For example, the debug subsystem retrieves the states tracked by the traces and injection logic associated with the time period.

[0089] The debug subsystem transmits the retrieved interface signals to the simulator. The debug subsystem instructs the debug subsystem to use the identified FPGAs and, for each identified FPGA, the traces and injection logic of the FPGA to inject its respective tracked signals into the logic of the FPGA to re-simulate the component for the requested time period. The debug subsystem can further transmit the sample rate provided by the circuit designer to the simulator so that the tracking logic tracks the states at the appropriate intervals.

[0090] To debug a component, the emulator can use the FPGA to which the component is mapped. Additionally, re- emulation of a part can be performed at any point specified by the circuit designer.

[0091] For the identified FPGA, the debug subsystem can transmit instructions to the emulator to load a plurality of emulator FPGAs with the same configuration as the identified FPGA. The debug subsystem also sends a signal to the emulator to use the plurality of FPGAs in parallel. Each FPGA from the plurality of FPGAs is used with a different time window of interface signals to generate a larger time window in a shorter amount of time. For example, an identified FPGA can take an hour or more to use an amount of cycles. However, if a plurality of FPGAs have the same data and structure as the identified FPGA, and each FPGA from the plurality of FPGAs runs a subset of cycles, the emulator can take a few minutes to use all of the cycles for the FPGAs collectively.

[0092] The circuit designer can identify a hierarchy or list of DUT signals to re- emulate. To enable this, the debug subsystem determines the FPGAs necessary to retrieve the hierarchy or list of emulated signals, retrieves the necessary interface signals, and transmits the retrieved interface signals to the emulator for re- emulation. Thus, the circuit designer can identify any element (e.g., component, device, or signal) of the DUT to debug / re- emulate.

[0093] The waveform subsystem generates waveforms using the tracked signals. If the circuit designer requests to view the waveform of a signal tracked during an emulation run, the host system retrieves the signal from the storage subsystem. The waveform subsystem displays a plot of the signal. For one or more signals, the waveform subsystem can automatically generate a plot of the signal as the signal is received from the emulator.

[0094] Figure 7 An exemplary machine of a computer system 700 is shown in FIG. 7 within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein can be executed. In alternative implementations, the machine can be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine can operate in the capacity of a server or a client machine in client-server network environment, as a peer machine in peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

[0095] The machine can 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.

[0096] Example computer system 700 includes a processing device 702, a main memory 704 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), a static memory 706 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 718, which communicate with each other via a bus 730.

[0097] Processing device 702 represents one or more processors such as a microprocessor, a central processing unit, or the like. More particularly, the processing device can 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 702 can 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. Processing device 702 can be configured to execute instructions 726 for performing the operations and steps described herein.

[0098] Computer system 700 can further include a network interface device 708 to communicate over the network 720. The computer system 700 also can include a video display unit 710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse), a graphics processing unit 722, a signal generation device 716 (e.g., a speaker), a graphics processing unit 722, a video processing unit 728, and an audio processing unit 732.

[0099] The data storage device 718 can include a machine readable storage medium 724 (also known as a computer readable medium) on which is stored one or more sets of instructions 726 or software embodying any one or more of the methodologies or functions described herein. The instructions 726 can also reside, completely or at least partially, within the main memory 704 and / or within the processing device 702 during execution thereof by the computer system 700, the main memory 704 and the processing device 702 also constituting machine readable storage media.

[0100] In some implementations, the instructions 726 include instructions to implement functionality corresponding to the techniques taught herein. While the machine-readable storage medium 724 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 702 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.

[0101] 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 means 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 is here, and generally, is considered to be a self- consistent sequence of operations that leads to a desired result. The operations are those requiring physical manipulations of physical quantities. They can be either abstract, symbolic quantities, it will be appreciated that all of the various

[0102] 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 preceding discussion, 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.

[0103] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus can be specially constructed for the intended purposes, or it can comprise a computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can 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.

[0104] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various other systems can be used with programs in accordance with the teachings herein, or it can prove convenient to construct a more specialized apparatus to perform the method. In addition, the disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of the disclosure as described herein.

[0105] The present disclosure can be provided as a computer program product, or software, that can include a machine-readable medium having stored thereon instructions, which can 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.

[0106] In the foregoing disclosure, implementations of the present disclosure have been described with reference to particular examples. It is apparent that a variety of modifications can be made to the implementations described without departing from the wider spirit and scope of the implementations of the present disclosure as set out in the following claims. Where the present disclosure refers to some elements in the singular, there can be plural of said elements in one or more of the drawings and same reference numerals have been used to designate the same elements. The present disclosure and figures are therefore to be considered in all respects as illustrative and not restrictive.

Claims

1. A method for prediction based on machine learning metrics, comprising: A partial circuit design for a circuit is generated by one or more processors and then executed. The one or more processors generate a predictive quality of R (QoR) metric for the partial circuit design run by executing a machine learning (ML) model on the partial circuit design run, wherein the ML model is trained using features extracted from the training circuit during the development phase and the actual QoR metric from the full design run of the training circuit; The partial circuit design is determined to meet the constraints on the predicted QoR metric by the one or more processors and based on the predicted QoR metric. as well as Based on the determination that the partial circuit design operation satisfies the constraints, the one or more processors execute the complete circuit design operation for the circuit from the partial circuit design operation.

2. The method according to claim 1, further comprising: Additional circuitry designed for the circuitry is generated by the one or more processors and run. The one or more processors execute the ML model by running the additional partial circuit design to generate additional predicted QoR metrics for the run of the additional partial circuit design; Based on the predicted QoR metric and the additional predicted QoR metric, the one or more processors sort the partial circuit design runs relative to the additional partial circuit design runs; as well as The partial circuit design run, ranked higher than the additional partial circuit design run based on the predicted QoR metric and the additional predicted QoR metric, is selected by the one or more processors for the execution of the full circuit design run.

3. The method of claim 1, wherein running the ML model on the partial circuit design comprises: One or more features are extracted from the partial circuit design operation by the one or more computing devices; as well as The one or more features derived from the operation of the partial circuit design are provided as input to the ML model by the one or more computing devices. The one or more features mentioned therein include at least one of the following: netlist features, timing constraints, electrical features, or physical features of the partial circuit design operation.

4. The method of claim 1, wherein the QoR metric used for the operation of the partial circuit design comprises: The delay and margin of each timing endpoint in the circuit.

5. The method of claim 1, wherein the QoR metric used for the operation of the partial circuit design comprises: The design rules in the circuit check the severity of DRC.

6. The method of claim 5, wherein the DRC severity is represented as a heatmap, and the features extracted from the training circuit include: Training the DRC severity heatmap pattern to generate the predicted QoR metric further includes: The heatmap and the training DRC severity heatmap pattern are convolved by the one or more computing devices to generate a wiredability score.

7. The method of claim 1, wherein the QoR metric used for the operation of the partial circuit design comprises: The power per grid and the power per unit in the circuit.

8. A system for prediction based on machine learning metrics, comprising: A memory configured for storage operations; as well as One or more processors, the one or more processors being configured to perform the operation, the operation including: Generate a partial circuit design for use in the circuit. A machine learning (ML) model is executed on the partial circuit design run to generate a predicted outcome quality (QoR) metric for the partial circuit design run, wherein the ML model is trained using features extracted from the training circuit during the development phase and actual QoR metrics from the full design run of the training circuit. Based on the predicted QoR metric, it is determined whether the operation of the partial circuit design meets the constraints on the predicted QoR metric, and Based on the determination that the partial circuit design operation satisfies the constraints, the complete circuit design operation for the circuit is executed from the partial circuit design operation.

9. The system according to claim 8, wherein the operation further comprises: Generate additional circuit design for the circuit described above. By executing the ML model on the additional partial circuit design run, an additional predicted QoR metric is generated for the additional partial circuit design run. Based on the predicted QoR metric and the additional predicted QoR metric, the partial circuit design runs are ranked relative to the additional partial circuit design runs, and The partial circuit design run is selected for execution of the complete circuit design run based on the ranking of the partial circuit design run above the additional partial circuit design run based on the predicted QoR metric and the additional predicted QoR metric.

10. The system of claim 8, wherein running the ML model on the portion of the circuit design comprises: Extract one or more features from the circuit design; as well as The one or more features derived from the operation of the partial circuit design are provided as input to the ML model. The one or more features mentioned therein include at least one of the following: netlist features, timing constraints, electrical features, or physical features of the partial circuit design operation.

11. The system of claim 8, wherein the QoR metric for operating the partial circuit design includes: The delay and margin of each timing endpoint in the circuit.

12. The system of claim 8, wherein the QoR metric for operating the portion of the circuit design includes: The design rules in the circuit check the severity of DRC.

13. The system of claim 12, wherein the DRC severity is represented as a heatmap, and the features extracted from the training circuit include: Training the DRC severity heatmap pattern to generate the predicted QoR metric further includes: The heatmap and the training DRC severity heatmap pattern are convolved to generate a wiredability score.

14. The system of claim 8, wherein the QoR metric for operating the portion of the circuit design includes: The power per grid and the power per unit in the circuit.

15. A computer-readable storage device having instructions stored on the computer-readable device, the instructions being executed by one or more processing devices to cause the one or more processing devices to perform the following operations: Generate a partial circuit design for use in the circuit; A predictive outcome quality (QoR) metric for the partial circuit design run is generated by executing a machine learning (ML) model on the partial circuit design run, wherein the ML model is trained using features extracted from the training circuit during the development phase and the actual QoR metric from the full design run of the training circuit; The predicted QoR metric is used to determine whether the operation of the partial circuit design meets the constraints on the predicted QoR metric. as well as Based on the determination that the partial circuit design operation satisfies the constraints, the complete circuit design operation for the circuit is executed from the partial circuit design operation.

16. The computer-readable storage device of claim 15, wherein the operation further comprises: Generate additional circuit design components for the circuit; By executing the ML model on the additional partial circuit design run, an additional predicted QoR metric is generated for the additional partial circuit design run; Based on the predicted QoR metric and the additional predicted QoR metric, the partial circuit design runs are ranked relative to the additional partial circuit design runs; as well as The partial circuit design run is selected for execution of the complete circuit design run based on the ranking of the partial circuit design run above the additional partial circuit design run based on the predicted QoR metric and the additional predicted QoR metric.

17. The computer-readable storage device of claim 15, wherein running the ML model on the portion of the circuit design comprises: Extract one or more features from the circuit design; as well as The one or more features derived from the operation of the partial circuit design are provided as input to the ML model. The one or more features mentioned therein include at least one of the following: netlist features, timing constraints, electrical features, or physical features of the partial circuit design operation.

18. The computer-readable storage device of claim 15, wherein the QoR metric for operation of the partial circuit design comprises: The delay and margin of each timing endpoint in the circuit.

19. The computer-readable storage device of claim 15, wherein the QoR metric for operation of the partial circuit design comprises: The design rules in the circuit check the severity of DRC.

20. The computer-readable storage device of claim 19, wherein the DRC severity is represented as a heatmap, and the features extracted from the training circuitry include: Training the DRC severity heatmap pattern to generate the predicted QoR metric further includes: The heatmap and the training DRC severity heatmap pattern are convolved to generate a wiredability score.

Images