Recommending Changes in Integrated Circuit Design Using Rule-Based Analysis of Faults.

Abstract

A computer-implemented method, system, and computer program product for recommending design changes in a digital integrated circuit design. An analysis of the digital integrated circuit being designed is performed, where results of such analysis include identifying and storing violations. Rules may then be used to analyze the stored violations, such as cross-domain violations, cross-hierarchy violations, and multi-cycle violations, to identify root causes of the violations. Such rules may be used to triage various faults in the cross-domain, cross-hierarchy, and / or multi-cycle violations of the digital integrated circuit. Design changes may then be recommended in the digital integrated circuit design based on the identified root causes of the violations. In this manner, offline analysis of cross-domain, cross-hierarchy, and / or multi-cycle violations using a rule-based approach is used to effectively identify root causes of faults in the digital integrated circuit design.

Description

[Technical Field]

[0001] The present disclosure relates generally to integrated circuit design, and more particularly to recommending changes in the design of an integrated circuit using rules-based analysis of failures (e.g., timing, noise, power, voltage). [Background technology]

[0002] Integrated circuit design, or IC design, is a subfield of electronics that encompasses the specific logic and circuit design techniques required to design integrated circuits, or ICs. ICs consist of miniature electronic components photolithographically organized into electrical networks on a monolithic semiconductor substrate.

[0003] IC design can be divided into the broad categories of digital and analog IC design. Digital IC design is used to create components such as microprocessors, FPGAs, memory (RAM, ROM, and flash), and digital ASICs. Digital IC design focuses on logic accuracy, maximizing circuit density, and arranging circuits so that clock and timing signals are efficiently routed. Compared to digital IC design, analog IC design focuses on power IC design and RF (radio frequency) IC design. Furthermore, analog IC design is used in the design of operational amplifiers, linear regulators, phase-locked loops, oscillators, and active filters. Additionally, analog IC design is more concerned with the physics of semiconductor devices, such as gain, matching, power dissipation, and resistance.

[0004] Modern ICs are highly complex. The average desktop computer chip contains over one billion transistors. The rules for what can and cannot be manufactured are also highly complex. A typical IC process has over 500 rules. Furthermore, the manufacturing process itself is not completely predictable, so designers must consider its statistical nature. The complexity of modern IC designs and market pressure to rapidly produce designs have led to the widespread use of automated design tools, such as electronic design automation (EDA) tools, in the IC design process. For example, EDA software tools may be used to design, test, and verify the instructions that an IC will execute.

[0005] In the design of digital integrated circuits, various EDA tools are used to test and analyze such designs to identify various violations, such as timing or noise impairments. A "timing impairment" is a failure of a process or part of a process in a synchronous distributed or real-time system to meet set limits on execution, message delivery, clock drift rate, or clock skew. A "noise impairment" refers to unexpected fluctuations in voltage due to various sources, such as signal transitions on adjacent wires, in electrical circuits, which can potentially cause disruption or damage.

[0006] When such simulated failures (e.g., timing and noise failures) occur, designers attempt to identify the root cause of such failures. However, such analysis (called "triaging") is time consuming and difficult.

[0007] Furthermore, such impairments (e.g., timing and noise impairments) may be correlated, however such correlations are difficult to assess, thereby making it difficult to identify the root cause of such impairments.

[0008] In addition, such failures (e.g., timing and noise failures) may involve integration-level issues between components located at different levels of an integrated circuit. For example, a multi-cycle path may extend across multiple components located at different levels of an integrated circuit. Analysis of such problems may involve analyzing each of the multiple levels of components individually, which is very difficult, thereby making it difficult to identify the root cause of such failures.

[0009] As a result, currently there is no means to effectively identify the root cause of failures, such as timing and noise failures, in the design of digital integrated circuits. Summary of the Invention

[0010] In one embodiment of the present disclosure, a computer-implemented method for recommending design changes in a design of a digital integrated circuit includes performing an analysis of the digital integrated circuit to obtain a plurality of violations as a result. The method further includes analyzing one of the plurality of violations using rules to identify a root cause of the one of the plurality of violations, including a domain crossing, a hierarchy crossing, and / or a multi-cycle violation. The method additionally includes recommending a design change in the design of the digital integrated circuit for one of the plurality of violations based on the identified root cause.

[0011] In this manner, the root causes of faults, such as timing and noise faults, in the design of a digital integrated circuit are effectively identified using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of the digital integrated circuit using a rule-based approach.

[0012] In another embodiment of the present disclosure, a computer program product for recommending design changes in a design of a digital integrated circuit, wherein the computer program product comprises one or more computer-readable storage media having program code embodied thereon, wherein the program code includes programming instructions for performing an analysis of the digital integrated circuit to obtain a plurality of violations as results. The program code further includes programming instructions for analyzing one of the plurality of violations using rules to identify a root cause of the one of the plurality of violations, the root cause including a cross-domain, cross-hierarchy, and / or multi-cycle violation. The program code additionally includes programming instructions for recommending a design change in the design of the digital integrated circuit for one of the plurality of violations based on the identified root cause.

[0013] In this manner, the root causes of faults, such as timing and noise faults, in the design of a digital integrated circuit are effectively identified using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of the digital integrated circuit using a rule-based approach.

[0014] In a further embodiment of the present disclosure, a system includes a memory for storing a computer program for recommending design changes in a design of a digital integrated circuit, and a processor coupled to the memory. The processor is configured to execute program instructions of the computer program including steps for performing an analysis of the digital integrated circuit to obtain a plurality of violations as a result. The processor is further configured to execute program instructions of the computer program including steps for analyzing one of the plurality of violations using rules to identify a root cause of one of the plurality of violations, including a domain crossing, hierarchy crossing, and / or multi-cycle violation. The processor is additionally configured to execute program instructions of the computer program including steps for recommending a design change in the design of the digital integrated circuit for one of the plurality of violations based on the identified root cause.

[0015] In this manner, the root causes of faults, such as timing and noise faults, in the design of a digital integrated circuit are effectively identified using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of the digital integrated circuit using a rule-based approach.

[0016] The foregoing has outlined rather generally the features and technical advantages of one or more embodiments of the present disclosure in order that the detailed description of the disclosure that follows may be better understood. Additional features and advantages of the present disclosure will be described hereinafter and may form the subject of the claims of the present disclosure. [Brief explanation of the drawings]

[0017] The present disclosure can be better understood from the following detailed description when considered in conjunction with the following drawings.

[0018] [Figure 1] 1 illustrates a communication system for practicing the principles of the present disclosure, according to one embodiment of the disclosure.

[0019] [Figure 2] FIG. 1 is a diagram of software components used by an integrated circuit (IC) design and development system to identify root causes of failures in the design of a digital integrated circuit using offline analysis of cross-domain, cross-hierarchy, and / or multi-cycle violations of the digital integrated circuit using a rules-based approach according to one embodiment of the present disclosure.

[0020] [Figure 3] 1 illustrates pseudocode for an example rule according to one embodiment of the present disclosure.

[0021] [Figure 4] 1 illustrates exemplary rule steps utilized to identify the root cause of a violation, such as a timing fault, according to one embodiment of the present disclosure.

[0022] [Figure 5] 1 illustrates pseudocode for example rules for identifying root causes of cross-domain, cross-hierarchy, and multi-cycle violations in digital integrated circuits, according to one embodiment of the present disclosure.

[0023] [Figure 6] 1 illustrates one embodiment of the present disclosure of a hardware configuration of an IC design and development system that represents a hardware environment for practicing the present disclosure.

[0024] [Figure 7] 1 is a flowchart of a method for recommending changes in an integrated circuit design based on effectively identifying root causes of failures in the design of a digital integrated circuit using offline analysis of cross-domain, cross-hierarchy, and / or multi-cycle violations of the digital integrated circuit using a rules-based approach, in accordance with one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0025] As mentioned in the background section, in the design of digital integrated circuits, various EDA tools are used to test and analyze such designs to identify various violations, such as timing or noise faults. A "timing fault" is a failure of a process or portion of a process in a synchronous distributed or real-time system to meet set limits on execution, message delivery, clock drift rate, or clock skew. A "noise fault" refers to unexpected fluctuations in voltage due to various sources, such as signal transitions on adjacent wires, which can potentially cause disturbances or damage in electrical circuits.

[0026] When such simulated failures (e.g., timing and noise failures) occur, designers attempt to identify the root cause of such failures. However, such analysis (called "triage") is time consuming and difficult.

[0027] Furthermore, there is the possibility of correlating such failures (e.g., timing failures and noise failures). However, such correlations are difficult to assess, thereby making it difficult to identify the root cause of such failures.

[0028] In addition, such failures (e.g., timing and noise failures) may involve integration-level issues between components located at different levels of an integrated circuit. For example, a multi-cycle path may extend across multiple components located at different levels of an integrated circuit. Analysis of such problems may involve analyzing each of the multiple levels of components individually, which is very difficult, thereby making it difficult to identify the root cause of such failures.

[0029] As a result, currently there is no means to effectively identify the root cause of failures, such as timing and noise failures, in the design of digital integrated circuits.

[0030] Embodiments of the present disclosure provide a means for effectively identifying the root causes of faults in the design of digital integrated circuits using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of digital integrated circuits using a rule-based approach as described in further detail below.

[0031] In some embodiments of the present disclosure, the present disclosure includes a computer-implemented method, system, and computer program product for recommending design changes in the design of a digital integrated circuit. In one embodiment of the present disclosure, an analysis of the digital integrated circuit being designed is performed, where results of such analysis include identifying and storing violations. As used herein, a "violation" refers to the performance of a component or system in the design of the digital integrated circuit that does not meet required specifications as established by the designer, resulting in a fault (e.g., a noise fault, a timing fault, a power fault, etc.). In one embodiment, such an analysis may involve verifying and simulating the design of the digital integrated circuit based on various characteristics or parameters, such as voltage transfer characteristics, noise margin, fanout, power dissipation, propagation delay time, and the interrelationships between these parameters. In one embodiment, such analysis ensures that it complies with functional or parametric specifications that may be established by the designer. The stored violations may then be analyzed using rules to identify root causes of the violations, including cross-domain, cross-hierarchy, and / or multi-cycle violations. As used herein, "cross-domain" includes multiple types of faults, such as timing and noise faults. As used herein, "cross-hierarchy" includes multiple levels of an integrated circuit design. As used herein, "multi-cycle" includes multiple-cycle paths that extend across multiple components. In one embodiment, such violations are analyzed offline using rules. In one embodiment, such rules are parameterized. In one embodiment, cross-domain, cross-hierarchy, and / or multi-cycle violations, including timing and noise faults, are identified using offline analysis of violations of a digital integrated circuit using a rule-based approach.Such rule-based approaches include rules targeted at triaging various faults, such as cross-domain, cross-hierarchy, and / or multi-cycle violations, identified based on analyzing a design of a digital integrated circuit using an electronic design automation tool (e.g., Eagle®, KiCAD®, Pulsonix, Multisim®, Altium Designer®, etc.). As used herein, “triage” refers to analyzing a fault, such as to determine the root cause of such a fault. In one embodiment, such rules address cross-domain, cross-hierarchy, and / or multi-cycle violations, such as by using parameterized thresholds involving multiple domains. Furthermore, such rules may address violations involving paths that traverse hierarchies in the design of the digital integrated circuit. As used herein, “hierarchy” refers to a level of the digital integrated circuit, where each level includes one or more components of the digital integrated circuit. In addition, such rules may address violations involving multi-cycle paths that extend across multiple components. Design changes in the design of the digital integrated circuit may then be recommended based on the identified root causes of violations, such as cross-domain violations. In one embodiment, such recommendations are based on utilizing a data structure (e.g., a table) that includes a list of design recommendations based on the identified root causes. In one embodiment, such recommendations may be generated using a model (mathematical model) trained with a machine learning algorithm to provide recommendations based on the identified root causes of violations, such as cross-domain violations. In one embodiment, the recommended design changes are implemented in the design of the digital integrated circuit. In this manner, the root causes of faults, such as timing and noise faults, in the design of a digital integrated circuit are effectively identified using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of the digital integrated circuit using a rule-based approach.

[0032] In the following description, numerous specific details are set forth to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure may be practiced without such specific details. In other instances, well-known circuits are shown in block diagram form so as not to obscure the present disclosure with unnecessary detail. For the most part, details regarding timing considerations and the like have been omitted unless such details are necessary to obtain a complete understanding of the present disclosure and are within the skill of those skilled in the relevant art.

[0033] Referring now in detail to the drawings, Figure 1 illustrates one embodiment of the present disclosure of a communication system 100 for practicing the principles of the present disclosure. Communication system 100 includes computing devices 101A-101C (identified in Figure 1 as "computing device A," "computing device B," and "computing device C," respectively) connected to an IC (integrated circuit) design and development system 102 via a network 103. Computing devices 101A-101C may each be referred to collectively or individually as computing devices 101 (computing devices 101 or computing device 101).

[0034] Computing device 101 may be any type of computing device (e.g., a portable computing unit, a personal digital assistant (PDA), a laptop computer, a mobile device, a tablet personal computer, a smartphone, a mobile telephone, a navigation device, a gaming unit, a desktop computer system, a workstation, an Internet appliance, etc.) configured to be able to connect to network 103 and thereby communicate with other computing devices 101 and IC design and development system 102. Note that both computing device 101 and the user of computing device 101 may be identified by element number 101.

[0035] Network 103 may be, for example, a local area network, a wide area network, a wireless wide area network, a circuit-switched telephone network, a Global System for Mobile Communications (GSM) network, a Wireless Application Protocol (WAP) network, a WiFi network, an IEEE 802.11 standard network, various combinations thereof, etc. Other networks, the descriptions of which are omitted here for brevity, may also be used in conjunction with system 100 of FIG. 1 without departing from the scope of this disclosure.

[0036] The IC design and development system 102 identifies root causes of faults such as timing and noise faults in the design of a digital integrated circuit using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of the digital integrated circuit using a rules-based approach as described in further detail below.

[0037] In one embodiment, IC design and development system 102 is a system utilized by a designer (e.g., a user of computing device 101) or the like in the process of designing a digital integrated circuit (e.g., a microprocessor, memory, digital ASIC (application-specific integrated circuit), FPGA (field-programmable gate array), etc.). In one embodiment, during the process of designing an integrated circuit (IC), IC design and development system 102 is configured to analyze the design for violations. As used herein, a "violation" refers to the performance of a component or system in a digital integrated circuit design that does not meet required specifications as established by the designer, resulting in a fault (e.g., a noise fault, a timing fault, a power fault, etc.). In one embodiment, such violations include "domain crossing," "hierarchy crossing," and / or "multi-cycle" violations. As used herein, "domain crossing" includes multiple types of faults, such as timing faults and noise faults. As used herein, "hierarchy crossing" includes multiple levels of an integrated circuit design. As used herein, "multi-cycle" includes a multi-cycle path that extends across multiple components. In one embodiment, such violations are stored in a database, such as database 104 connected to IC design and development system 102. Further discussion regarding analyzing designs of digital integrated circuits for violations is provided below.

[0038] As described above, in one embodiment, the IC design and development system 102 is configured to identify root causes of faults, such as timing and noise faults, in a digital integrated circuit design using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of the digital integrated circuit using a rules-based approach. Such rules-based approach, which may be provided by an expert, includes rules targeted at triaging various cross-domain, cross-hierarchy, and / or multi-cycle violation faults identified based on analyzing the digital integrated circuit design using electronic design automation tools (e.g., Eagle®, KiCAD®, Pulsonix, Multisim®, Altium Designer®, etc.). As used herein, “triage” refers to analyzing faults, such as determining the root cause of such faults. In one embodiment, such rules address cross-domain, cross-hierarchy, and / or multi-cycle violations, such as by using parameterized thresholds that involve multiple domains. For example, such rules may address cross-domain violations, cross-hierarchy violations, and multi-cycle violations using parameterized thresholds that involve both noise and timing data. For example, one of the rules may be a noise and timing rule for noise impact on function (NIOF) violations. Such rules may be used to analyze the relationship between noise and timing data, where nets (wires connecting components) that fail noise impact on function violations with a high degree of aggressor coupling (noise coupled from other sources) obtained from the noise data are classified differently based on timing slack (the margin by which the timing requirement is met or not met) obtained from the timing data using a user-defined threshold.Such cross-domain, cross-hierarchy, and multi-cycle triage is important because it allows root causes to be more effectively identified, thereby providing better recommendations for addressing such root causes. For example, a design approach for addressing noise impairments may be changed based on timing slack (timing data).

[0039] Additionally, in one embodiment, IC design development system 102 recommends design changes in the design of the digital integrated circuit based on the identified root causes of the failures. For example, in one embodiment, IC design development system 102 utilizes a data structure (e.g., a table) containing a list of design recommendations based on the identified root causes. For example, if a rule indicates that the root cause of an NIOF violation is a coupling fault in a NAND logic gate identified by number 100122 in the design, IC design development system 102 may recommend replacing the NAND logic gate identified by number 100122 in the design (a small NAND logic gate) with a NAND logic gate identified by number 102233 (a large NAND logic gate) that receives digital signals identified by numbers 122233, 132343, and 122343. In one embodiment, such a data structure has been entered by an expert. In one embodiment, such a data structure resides in a storage device (e.g., memory, disk drive) of IC design development system 102.

[0040] In one embodiment, such recommendations may be generated using a model (mathematical model) trained using a machine learning algorithm to provide recommendations based on identified root causes of violations, as described in more detail below.

[0041] A description of the software components of IC design and development system 102 used to identify root causes of faults such as timing and noise faults in digital integrated circuit designs using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of digital integrated circuits using a rules-based approach is provided below in conjunction with Figure 2. A description of the hardware configuration of IC design and development system 102 is further provided below in conjunction with Figure 6.

[0042] System 100 is not limited in scope to any one particular network architecture and may include any number of computing devices 101, IC design and development systems 102, networks 103, and databases 104.

[0043] A description of software components used by IC design and development system 102 to identify root causes of faults such as timing and noise faults in the design of digital integrated circuits using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of digital integrated circuits using a rule-based approach is provided below in connection with FIG. 2 .

[0044] FIG. 2 is a diagram of software components used by IC design and development system 102 (FIG. 1) to identify root causes of faults such as timing and noise faults in the design of a digital integrated circuit using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of the digital integrated circuit using a rules-based approach, in accordance with one embodiment of the present disclosure.

[0045] 2, in conjunction with FIGURE 1, IC design and development system 102 includes analyzer 201 configured to perform analysis of a design of a digital integrated circuit. Such analysis may involve verification and simulation of the design of the digital integrated circuit based on various characteristics or parameters, such as voltage transfer characteristics, noise margin, fan-out, power dissipation, propagation delay time, and interrelationships between these parameters.

[0046] In one embodiment, analyzer 201 analyzes the design of a digital integrated circuit to ensure it conforms to functional or parametric specifications that may be provided by a designer (e.g., a user of computing device 101). For example, analyzer 201 may analyze the design of a digital integrated circuit to determine whether all logic gates function according to their truth table specifications. In another example, analyzer 201 determines whether the electrical paths in the design are identical to those in the device.

[0047] Additionally, in one embodiment, analyzer 201 performs parametric testing on the design of a digital integrated circuit based on analysis of successive circuit parameters. For example, analyzer 201 may determine whether the steady-state current requirements of a device are excessive. In another example, analyzer 201 determines whether the effects of process variations are within acceptable limits. In a further example, analyzer 201 determines whether performance requirements (e.g., delay faults) are met.

[0048] Additionally, in one embodiment, parametric testing may include analyzing continuous circuit variables such as noise margin, propagation delay, maximum clock frequency, steady-state current, transient signal behavior, etc. In one embodiment, such parameters are checked under multiple different temperatures and supply voltages.

[0049] In one embodiment, analyzer 201 utilizes various software tools (e.g., electronic design automation (EDA) tools) for performing such analysis of digital integrated circuit designs, including, but not limited to, Cadence®, Synopsys®, Mentor Graphics®, Atrenta, etc.

[0050] As a result of performing such an analysis on a digital integrated circuit design, violations may be detected. As used herein, a "violation" refers to the performance of a component or system in a digital integrated circuit design that does not meet a required specification as established by a designer, resulting in a fault (e.g., a noise fault, a timing fault, a power fault, etc.). In one embodiment, such violations include "cross-domain," "cross-hierarchy," and / or "multi-cycle" violations.

[0051] As used herein, "domain crossing" includes multiple types of faults, such as timing and noise faults. As used herein, "timing fault" refers to a failure of a process or portion of a process in a synchronous distributed or real-time system to meet set limits on execution, message delivery, clock drift rate, or clock skew. As used herein, "noise fault" refers to unexpected fluctuations in voltage due to various factors, such as signal transitions on adjacent wires, which can potentially cause disturbances or damage in electrical circuits. As used herein, "hierarchical crossing" includes multiple levels of an integrated circuit design. As used herein, "multi-cycle" includes a multi-cycle path that extends across multiple components.

[0052] In one embodiment, such violations are identified as a result of an analysis performed by a software tool (e.g., an EDA tool) as described above. For example, the EDA tool may identify faults at the logic level corresponding to timing faults, noise faults, power faults, etc.

[0053] In one embodiment, such violations are stored, such as in database 104. In one embodiment, such stored violations also include metadata, including the parameters utilized by analyzer 201 to determine that a violation occurred. Additionally, such metadata includes relevant data utilized by analyzer 201 to make the violation determination (e.g., noise margin, propagation delay, maximum clock frequency, steady-state current, transient signal behavior).

[0054] In one embodiment, IC design and development system 102 further comprises a rules engine 202 configured to analyze stored violations using a rules-based approach to identify root causes of failures of violations (e.g., cross-domain, cross-hierarchy, and / or multi-cycle violations). In one embodiment, such violations are analyzed offline using rules. In one embodiment, such rules are parameterized as described further below.

[0055] In one embodiment, the rules engine 202 identifies root causes of faults, such as timing and noise faults, in digital integrated circuit designs using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of the digital integrated circuit using a rules-based approach. Such rules-based approach, which may be provided by an expert, includes rules targeted at triaging various faults (e.g., cross-domain, cross-hierarchy, and / or multi-cycle violations) identified based on analyzing the design of the digital integrated circuit using electronic design automation tools (e.g., Eagle®, KiCAD®, Pulsonix®, Multisim®, Altium Designer®, etc.). As used herein, “triage” refers to analyzing faults, such as determining the root cause of such faults. In one embodiment, such rules address cross-domain, cross-hierarchy, and / or multi-cycle violations, such as by using parameterized thresholds that involve multiple domains. For example, such rules may address cross-domain violations, cross-hierarchy violations, and multi-cycle violations using parameterized thresholds that involve both noise and timing data. For example, one of the rules may be a noise and timing rule for Noise Impact on Function (NIOF) violations. Such rules may be used to analyze the relationship between noise and timing data, where nets (wires connecting components) that fail Noise Impact on Function violations with a high degree of aggressor coupling (noise coupled from other sources) obtained from the noise data are classified differently based on timing slack (the margin by which timing requirements are met or not met) obtained from the timing data using a user-defined threshold.Such cross-domain, cross-hierarchy, and multi-cycle triage is important because it allows root causes to be more effectively identified, thereby providing better recommendations for addressing such root causes. For example, the design approach for addressing noise impairments may be changed based on timing slack (timing data).

[0056] In one embodiment, database 104 stores a collection of rules for identifying the root cause of a violation. Such rules are associated with a particular violation. For example, one rule may be used to identify the root cause of a noise impact on function (NIOF) violation. As a result, rules engine 202 identifies rules for identifying the root cause of a violation based on the violation identified by analyzer 201. In one embodiment, such rules and their associated violations are stored in a data structure, where such data structure is stored in database 104 or in a storage device (e.g., memory, disk unit) of IC design and development system 102. In one embodiment, such data structure is input by an expert.

[0057] In one embodiment, various parameters and data may be obtained by the rules engine 202 regarding a violation in order to analyze the violation using an appropriate rule. As described above, in one embodiment, such a violation includes metadata, including the parameters used by the analyzer 201 to determine that a violation occurred and related data used by the analyzer 201 to make the violation determination (e.g., noise margin, propagation delay, maximum clock frequency, steady-state current, transient signal behavior). Such parameters and data may be used by the rules engine 202 to identify the root cause of the violation. An example of such a rule is provided in FIG. 3.

[0058] FIG. 3 illustrates pseudo-code for an example rule 300 according to one embodiment of the present disclosure.

[0059] As shown in FIG. 3 , the rule 300 may be stored in a file, such as a JavaScript® Object Notation (JSON) file. Further as shown in FIG. 3 , the rule 300 includes a rule name 301, rule parameters 302, an annotation name 303, and a flag 304 for outputting information. As used herein, “rule parameters” 302 refer to parameters utilized to identify the root cause of a violation associated with such a rule. As used herein, “annotation name” 303 refers to the name of an annotation corresponding to added syntactic metadata. As used herein, “flag” 304 refers to a Boolean variable that signals when a condition (identifying the root cause of the violation) exists in a program. For example, if the flag 304 is set to true, it means that the root cause of the violation has been identified by the rule 300 and that a report (e.g., a text report) providing such information should be output. In one embodiment, such a report is output to a designer, such as the designer of the computing device 101. Conversely, if flag 304 is set to false, it means that the root cause of the violation is not identified by rule 300 and that a report providing such information should not be output.

[0060] A further illustration of rules for identifying the root cause of violations such as timing faults is provided in FIG.

[0061] FIG. 4 illustrates steps of an exemplary rule 400 utilized to identify the root cause of a violation, such as a timing fault, according to one embodiment of the present disclosure.

[0062] As shown in FIG. 4, such a rule 400 utilizes a best delay, no net delay and timing slack (BDNDS) algorithm. For example, the first step 401 includes obtaining the unit net delay (unet_dly) and the worst timing slack (slk_fastclk) for all route nets in a path. The second step 402 includes deriving a timing slack with no unit net delay (nodly_unet_slk). The third step 403 includes deriving the best delay (unet_bdly) of a net (a wire connecting components). The fourth step 404 includes deriving a timing slack (bdly_unet_slk) for the best unit net delay. The fifth step 405 includes evaluation criteria and classification of nets that can be provided by a user based on necessary actions. For example, based on the evaluation criterion 406a (whether nodly_unet_slk < 0 & slk_fastclck < 0), if such a criterion is satisfied, the circuit / logic is considered broken 407A (the root cause of the violation). In another example, based on the evaluation criterion 406b (whether unet_bdly_slk > cycle time & slk_fastclk < 0), if such a criterion is satisfied, the floorplan / logic 407b is the root cause of the violation. In a further example, based on the evaluation criterion 406c (whether unet_bdly_slk < N% cycle time & slk_fastclk < -N% cycle time), if such a criterion is satisfied, the floorplan / logic / circuit 407c is the root cause of the violation. Note that the values of the parameters M and N described above are specified by designers, etc. for the particular design under consideration.

[0063] In another example, rules may be utilized to address cross-domain violations, cross-hierarchy violations, and multi-cycle violations using parameterized thresholds that involve both noise and timing data. An example of such rules, including noise and timing rules for Noise Impact on Function (NIOF) violations, is shown in FIG. 5.

[0064] FIG. 5 illustrates pseudocode for example rules 500 for identifying root causes of cross-domain, cross-hierarchy, and multi-cycle violations in digital integrated circuits, according to one embodiment of the present disclosure.

[0065] As shown in FIG. 5 , rule 500 analyzes the relationship between noise and timing data, where nets (wires connecting components) that fail due to noise impact-on-function violations with high aggressor coupling (noise coupled from other sources) obtained from noise data (see element 501) are classified differently based on timing slack (the margin by which timing requirements are met or not met) (see element 502) obtained from timing data traversing the hierarchy using user-defined thresholds. Such cross-domain, cross-hierarchy, multi-cycle triage is important because it allows root causes to be more effectively identified, thereby providing better recommendations for further addressing such root causes. For example, the design approach for addressing noise faults may be modified based on the timing slack (timing data).

[0066] 2, as previously described, such rules associated with violations may be entered into a data structure by an expert. Alternatively, in one embodiment, such rules are generated using a model trained by a machine learning algorithm.

[0067] In one embodiment, the rules engine 202 trains a model to create appropriate rules to identify the root cause of a particular violation (e.g., an NIOF violation) based on the parameters (e.g., voltage transfer characteristics, noise margin, fanout, power dissipation, propagation delay time, and the interrelationships between these parameters) and the data (e.g., noise margin, propagation delay, maximum clock frequency, steady-state current, transient signal behavior) utilized by the analyzer 201 in making the violation determination.

[0068] In one embodiment, the rules engine 202 uses machine learning algorithms (e.g., supervised learning) to build a model to create rules to identify the root cause of a violation using a sample data set containing the rules and associated violations, including parameters (e.g., voltage transfer characteristics, noise margin, fanout, power dissipation, propagation delay time, and the interrelationships between these parameters) and data utilized by the analyzer 201 in making a violation determination (e.g., noise margin, propagation delay, maximum clock frequency, steady-state current, transient signal behavior).

[0069] Such sample data sets are referred to herein as "training data" and are used by machine learning algorithms to make predictions or decisions regarding rules that should be developed to identify the root causes of violations. The algorithm iteratively makes predictions on the training data regarding rules that should be developed to identify the root causes of violations until the predictions reach a desired accuracy as determined by an expert. Examples of such learning algorithms include nearest neighbor, naive Bayes, decision trees, linear regression, support vector machines, and neural networks.

[0070] In one embodiment, after training a model to create rules for identifying the root cause of a violation based on the violation's metadata (the violation's metadata, including parameters and data), the rules engine 202 utilizes such a model to create rules based on providing the violation's metadata (e.g., parameters and data) received from the analyzer 201 to the trained model.

[0071] Further, as shown in FIG. 2 , the IC design and development system 102 includes a recommender engine 203 configured to recommend design changes in the design of the digital integrated circuit based on the root causes of the violations identified by the rule engine 202.

[0072] For example, in one embodiment, recommender engine 203 utilizes a data structure (e.g., a table) containing a list of design recommendations based on the identified root causes. For example, if a rule indicates that the root cause of an NIOF violation is a coupling fault in a NAND logic gate identified by number 100122 in the design, recommender engine 203 may recommend replacing the NAND logic gate identified by number 100122 in the design (a small NAND logic gate) with a NAND logic gate identified by number 102233 (a large NAND logic gate) that receives digital signals identified by numbers 122233, 132343, and 122343. In one embodiment, such a data structure has been entered by an expert. In one embodiment, such a data structure resides in a storage device (e.g., memory, disk drive) of IC design and development system 102.

[0073] In one embodiment, such recommendations may be generated using a model (mathematical model) trained using a machine learning algorithm to provide recommendations based on identified root causes of violations, as described in more detail below.

[0074] In one embodiment, the recommender engine 203 trains a model to recommend appropriate design changes in the design of a digital integrated circuit based on the root causes of the violations.

[0075] In one embodiment, the recommender engine 203 uses a machine learning algorithm (e.g., supervised learning) to build a model and recommend appropriate design changes in the design of the digital integrated circuit using a sample dataset containing design changes and identified root causes of violations in the design of the digital integrated circuit. In one embodiment, such a dataset is provided by an expert.

[0076] Such sample data sets are referred to herein as "training data" and are used by machine learning algorithms to make predictions or decisions regarding design changes in the design of digital integrated circuits based on the root causes of violations. The algorithm iteratively makes predictions on the training data regarding design changes until the predictions reach a desired accuracy as determined by an expert. Examples of such learning algorithms include nearest neighbor, naive Bayes, decision trees, linear regression, support vector machines, and neural networks.

[0077] In one embodiment, after training a model to make predictions or decisions regarding design changes in the design of a digital integrated circuit based on the root causes of violations, the recommender engine 203 utilizes such model to recommend design changes to the design of the digital integrated circuit based on the root causes of violations identified by the rules engine 202.

[0078] In one embodiment, the recommender engine 203 annotates the database 104 with recommended design changes.

[0079] In one embodiment, recommender engine 203 implements design changes based on the recommendations. For example, if recommender engine 203 recommends replacing a NAND logic gate identified by number 100122 in the design (a small NAND logic gate) with a NAND logic gate identified by number 102233 (a large NAND logic gate) that receives digital signals identified by numbers 122233, 132343, and 122343, recommender engine 203 proceeds to replace the NAND logic gate identified by number 100122 in the design with the NAND logic gate identified by number 102233.

[0080] In one embodiment, recommender engine 203 simply provides such recommendations to a designer, such as a user of computing device 101, to let the designer decide whether or not to implement such design changes in the design of the digital integrated circuit. In one embodiment, such recommendations are in the format of a report (e.g., a text report).

[0081] Further description of these and other features is provided below in connection with a description of a method for recommending changes in a design of a digital integrated circuit based on effectively identifying root causes of faults, such as timing faults and noise faults, in the design of a digital integrated circuit using offline analysis of cross-domain, cross-hierarchy, and / or multi-cycle violations of the digital integrated circuit using a rule-based approach.

[0082] Before describing a method for recommending changes in an integrated circuit design based on effectively identifying root causes of faults, such as timing faults and noise faults, in a digital integrated circuit design using offline analysis of cross-domain, cross-hierarchy, and / or multi-cycle violations of the digital integrated circuit using a rule-based approach, a description of the hardware configuration of IC design and development system 102 (FIG. 1) is provided below in conjunction with FIG. 6.

[0083] Referring now to FIG. 6 in conjunction with FIG. 1, FIG. 6 illustrates one embodiment of the present disclosure of a hardware configuration for an IC design and development system 102 that represents a hardware environment for practicing the present disclosure.

[0084] Various aspects of the present disclosure are described through narrative text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. For any flowchart, depending on the technology involved, operations may be performed in an order different from that shown in a given flowchart. For example, again depending on the technology involved, two operations shown in successive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner.

[0085] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "mediums") collectively included in a set of one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as pits / lands formed on the major surface of a punch card or disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals communicated through wires, and / or other transmission media. As will be appreciated by those skilled in the art, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not qualify a storage device as transitory since the data is not transitory while it is stored.

[0086] The computing environment 600 comprises an example of an environment for execution of at least a portion of computer code 601 involved in performing an inventive methodology, such as recommending changes in an integrated circuit design based on effectively identifying root causes of faults, such as timing and noise faults, in a digital integrated circuit design using cross-domain, cross-hierarchy, and / or offline analysis of multi-cycle violations of the digital integrated circuit using a rule-based approach. In addition to block 601, the computing environment 600 comprises, for example, an IC design and development system 102, a network 103, such as a wide area network (WAN), an end user device (EUD) 602, a remote server 603, a public cloud 604, and a private cloud 605. In this embodiment, IC design and development system 102 includes a set of processors 606 (including processing circuitry 607 and cache 608), a communications fabric 609, volatile memory 610, persistent storage 611 (including operating system 612 and block 601, as identified above), a set of peripheral devices 613 (including a set of user interface (UI) devices 614, storage 615, and a set of Internet of Things (IoT) sensors 616), and a network module 617. Remote server 603 includes a remote database 618. Public cloud 604 includes a gateway 619, a cloud orchestration module 620, a set of host physical machines 621, a set of virtual machines 622, and a set of containers 623.

[0087] IC design and development system 102 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of executing programs that access a network or query a database, such as remote database 618. As is well understood in the field of computer technology, and depending on the technology, execution of a computer-implemented method may be distributed among multiple computers and / or among multiple locations. While in this presentation of computing environment 600, the detailed description focuses on a single computer, specifically IC design and development system 102, to keep the presentation as simple as possible. Although IC design and development system 102 is not depicted in FIG. 6 within the cloud, it may be located within the cloud. However, IC design and development system 102 need not be within the cloud, except to any extent as may be expressly indicated.

[0088] Processor set 606 includes one or more computer processors of any type now known or to be developed in the future. Processing circuitry 607 may be distributed across multiple packages, e.g., multiple cooperating integrated circuit chips. Processing circuitry 607 may implement multiple processor threads and / or multiple processor cores. Cache 608 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 606. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all of the cache for a processor set may be located “off-chip.” In some computing environments, processor set 606 may be designed to operate with qubits and perform quantum computing.

[0089] Computer-readable program instructions are typically loaded onto IC design and development system 102 and cause a series of operational steps to be executed by processor set 606 of IC design and development system 102, thereby implementing a computer-implemented method such that the instructions so executed instantiate the method specified in the computer-implemented method flowcharts and / or narrative descriptions contained herein (collectively referred to as the "invention methods"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 608 and other storage media discussed below. The program instructions and associated data are accessed by processor set 606 to control and direct the execution of the inventive methods. In computing environment 600, at least some of the instructions for executing the inventive methods may be stored in block 601 in persistent storage 611.

[0090] The communications fabric 609 is the signal-conducting pathway that allows the various components of the IC design and development system 102 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as those that make up buses, bridges, physical input / output ports, etc. Other types of signal communications pathways may be used, such as fiber optic and / or wireless communications pathways.

[0091] Volatile memory 610 may be any type of volatile memory, now known or later developed. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, volatile memory is characterized by random access, although this is not required unless expressly indicated. In IC design and development system 102, volatile memory 610 is located within a single package and is internal to IC design and development system 102; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to IC design and development system 102.

[0092] Persistent storage 611 is any form of non-volatile storage for computers, now known or later developed. The non-volatility of this storage means that stored data is maintained regardless of whether power is supplied to IC design and development system 102 and / or directly to persistent storage 611. While persistent storage 611 can be read-only memory (ROM), typically at least a portion of persistent storage allows data to be written, data to be erased, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 612 may take several forms, such as various known proprietary operating systems or open-source Portable Operating System Interface-type operating systems that utilize a kernel. The code contained in block 601 typically includes at least some of the computer code involved in performing the methods of the present invention.

[0093] Peripheral device set 613 includes a set of peripheral devices of IC design and development system 102. Data communication connections between peripheral devices and other components of IC design and development system 102 may be implemented in various ways, such as Bluetooth connections, near field communication (NFC) connections, connections formed by cables (such as universal serial bus (USB)-type cables), insertion-type connections (e.g., Secure Digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, UI device set 614 may include components such as display screens, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage 615 is external storage, such as an external hard drive, or insertable storage, such as an SD card. Storage 615 may be persistent and / or volatile. In some embodiments, storage 615 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where IC design and development system 102 is required to have a large amount of storage (e.g., IC design and development system 102 stores and manages a large database locally), then this storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor set 616 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

[0094] The network module 617 is a collection of computer software, hardware, and firmware that enables the IC design and development system 102 to communicate with other computers over the WAN 103. The network module 617 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of the network module 617 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of the network module 617 are performed on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for implementing the methods of the invention can typically be downloaded to the IC design and development system 102 from an external computer or external storage device through a network adapter card or network interface included in the network module 617.

[0095] WAN 103 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances by any technology for communicating computer data now known or later developed. In some embodiments, a WAN may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include copper transmission cables, optical fiber transmissions, wireless transmissions, and computer hardware such as routers, firewalls, switches, gateway computers, and edge servers.

[0096] End-user device (EUD) 602 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating IC design and development system 102) and may take any of the forms described above in connection with IC design and development system 102. EUD 602 ​​typically receives useful and useful data from the operation of IC design and development system 102. For example, in the hypothetical case where IC design and development system 102 is designed to provide recommendations to the end user, the recommendations are typically communicated to EUD 602 ​​from network module 617 of IC design and development system 102 over WAN 103. In this manner, EUD 602 ​​can display or otherwise present the recommendations to the end user. In some embodiments, EUD 602 ​​can be a client device such as a thin client, a heavy client, a mainframe computer, a desktop computer, and the like.

[0097] Remote server 603 is any computer system that services at least some data and / or functionality to IC design and development system 102. Remote server 603 may be controlled and used by the same entity that operates IC design and development system 102. Remote server 603 represents a machine that collects and stores useful and useful data for use by other computers, such as IC design and development system 102. For example, in the hypothetical case where IC design and development system 102 is designed and programmed to provide recommendations based on historical data, then this historical data may be provided to IC design and development system 102 from remote database 618 of remote server 603.

[0098] Public cloud 604 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer functionality, particularly data storage (cloud storage) and computing power, without direct, active management by users. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct, active management of public cloud 604's computing resources is performed by computer hardware and / or software in cloud orchestration module 620. The computing resources provided by public cloud 604 are typically implemented by virtual computing environments running on various computers that comprise host physical machine set 621, the universe of physical computers within and / or available to public cloud 604. Virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine set 622 and / or containers from container set 623. It is understood that these VCEs can be stored as images and can be transferred among and between various physical machine hosts, either as images or after instantiation of the VCE. The cloud orchestration module 620 manages the transfer and storage of images, deploys new instantiations of the VCE, and manages active instantiations of VCE deployments. The gateway 619 is a collection of computer software, hardware, and firmware that enables the public cloud 604 to communicate over the WAN 103.

[0099] Some further description of virtualized computing environments (VCEs) is now provided. A VCE can be stored as an "image." A new, active instance of a VCE can be instantiated from the image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system in which the kernel allows the existence of multiple isolated user space instances, called containers. These isolated user space instances typically behave as real computers from the perspective of programs running within them. A computer program running on a typical operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and of the devices assigned to the container; this feature is known as containerization.

[0100] Private cloud 605 is similar to public cloud 604, except that the computing resources are available only for use by a single enterprise. While private cloud 605 is depicted as communicating with WAN 103 in other embodiments, a private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often each implemented by a different vendor. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both public cloud 604 and private cloud 605 are part of a larger hybrid cloud.

[0101] Block 601 further includes the software components described above in connection with FIGS. 2-5 to recommend changes in the design of a digital integrated circuit based on effectively identifying root causes of faults, such as timing and noise faults, in the design of the digital integrated circuit using cross-domain, cross-hierarchy, and / or offline analysis of multi-cycle violations of the digital integrated circuit using a rule-based approach. In one embodiment, such components may be implemented in hardware. The functions discussed above performed by such components are not general-purpose computer functions. As a result, IC design and development system 102 is a specific machine that is the result of implementing dedicated, non-general-purpose computer functions.

[0102] In one embodiment, the functionality of such software components of IC design and development system 102 may be embodied in an application specific integrated circuit, including functionality for recommending changes in the design of an integrated circuit based on effectively identifying the root causes of faults, such as timing and noise faults, in the design of a digital integrated circuit using offline analysis of cross-domain, cross-hierarchy, and / or multi-cycle violations of the digital integrated circuit using a rules-based approach.

[0103] As mentioned above, in the design of digital integrated circuits, various EDA tools are used to test and analyze such designs to identify various violations, such as timing or noise faults. A “timing fault” is a failure of a process or part of a process in a synchronous, distributed, or real-time system to meet set constraints on execution, message delivery, clock drift rate, or clock skew. A “noise fault” refers to an unexpected fluctuation in voltage due to various factors, such as signal transitions on adjacent wires, which can potentially cause disruption or damage to an electrical circuit. When such simulated faults (e.g., timing faults and noise faults) occur, designers attempt to identify the root cause of such faults. However, such analysis (referred to as “triage”) is time-consuming and difficult. Furthermore, such faults (e.g., timing faults and noise faults) may be correlated. However, such correlation is difficult to evaluate, thereby making it difficult to identify the root cause of such faults. In addition, such faults (e.g., timing faults and noise faults) may involve integration-level issues between components located at different levels of an integrated circuit. For example, a multi-cycle path may extend across multiple components located at different levels of an integrated circuit. Analyzing such problems can involve analyzing each of multiple hierarchical components individually, which is very difficult, thereby making it difficult to identify the root cause of such failures. As a result, there are currently no means to effectively identify the root cause of failures, such as timing and noise failures, in the design of digital integrated circuits.

[0104] Embodiments of the present disclosure provide a means for effectively identifying root causes of faults, such as timing and noise faults, in the design of digital integrated circuits using offline analysis of cross-domain, cross-hierarchy, and / or multi-cycle violations of digital integrated circuits using a rules-based approach as described below in connection with FIG. 7 .

[0105] FIG. 7 is a flowchart of a method 700 for recommending changes in an integrated circuit design based on effectively identifying root causes of faults, such as timing and noise faults, in a digital integrated circuit design using offline analysis of cross-domain, cross-hierarchy, and / or multi-cycle violations of the digital integrated circuit using a rules-based approach, in accordance with one embodiment of the present disclosure.

[0106] 7, in conjunction with FIGS. 1-6, during operation 701, analyzer 201 of IC design and development system 102 performs an analysis of a digital integrated circuit being designed by a designer (e.g., a user of computing device 101). In one embodiment, such analysis results in the identification of violations.

[0107] As described above, in one embodiment, such analysis may involve verification and simulation of the design of a digital integrated circuit based on various characteristics or parameters such as voltage transfer characteristics, noise margin, fan-out, power dissipation, propagation delay time, and the interrelationships between these parameters.

[0108] In one embodiment, analyzer 201 analyzes the design of a digital integrated circuit to ensure it conforms to functional or parametric specifications that may be provided by a designer (e.g., a user of computing device 101). For example, analyzer 201 may analyze the design of a digital integrated circuit to determine whether all logic gates function according to their truth table specifications. In another example, analyzer 201 determines whether the electrical paths in the design are identical to those in the device.

[0109] Additionally, in one embodiment, analyzer 201 performs parametric testing on the design of a digital integrated circuit based on analysis of successive circuit parameters. For example, analyzer 201 may determine whether the steady-state current requirements of a device are excessive. In another example, analyzer 201 determines whether the effects of process variations are within acceptable limits. In a further example, analyzer 201 determines whether performance requirements (e.g., delay faults) are met.

[0110] Additionally, in one embodiment, parametric testing may include analyzing continuous circuit variables such as noise margin, propagation delay, maximum clock frequency, steady-state current, transient signal behavior, etc. In one embodiment, such parameters are checked at several different temperatures and supply voltages.

[0111] In one embodiment, analyzer 201 utilizes various software tools (e.g., electronic design automation (EDA) tools) for performing such analysis of digital integrated circuit designs, including, but not limited to, Cadence®, Synopsys®, Mentor Graphics®, Atrenta, etc.

[0112] As a result of performing such an analysis on a digital integrated circuit design, violations may be detected. As used herein, a "violation" refers to the performance of a component or system in a digital integrated circuit design that does not meet a required specification as established by a designer, resulting in a fault (e.g., a noise fault, a timing fault, a power fault, etc.). In one embodiment, such violations include "cross-domain," "cross-hierarchy," and / or "multi-cycle" violations.

[0113] As used herein, "domain crossing" includes multiple types of faults, such as timing and noise faults. As used herein, "timing fault" refers to a failure of a process or portion of a process in a synchronous distributed or real-time system to meet set limits on execution, message delivery, clock drift rate, or clock skew. As used herein, "noise fault" refers to unexpected fluctuations in voltage due to various factors, such as signal transitions on adjacent wires, which can potentially cause disturbances or damage in electrical circuits. As used herein, "hierarchical crossing" includes multiple levels of an integrated circuit design. As used herein, "multi-cycle" includes a multi-cycle path that extends across multiple components.

[0114] In one embodiment, such violations are identified as a result of an analysis performed by a software tool (e.g., an EDA tool) as described above. For example, the EDA tool may identify faults at the logic level corresponding to timing faults, noise faults, power faults, etc.

[0115] In one embodiment, such violations are stored, such as in database 104. In one embodiment, such stored violations also include metadata, including the parameters utilized by analyzer 201 to determine that a violation occurred. Additionally, such metadata includes relevant data utilized by analyzer 201 to make the violation determination (e.g., noise margin, propagation delay, maximum clock frequency, steady-state current, transient signal behavior).

[0116] During operation 702, the analyzer 201 of the IC design and development system 102 stores the violations in a database 104 or the like.

[0117] As noted above, such stored violations also include metadata, including the parameters utilized by analyzer 201 to determine that a violation occurred. Additionally, such metadata includes relevant data (e.g., noise margin, propagation delay, maximum clock frequency, steady-state current, transient signal behavior) utilized by analyzer 201 to make the violation determination.

[0118] During operation 703, the rules engine 202 of the IC design and development system 102 uses the rules to analyze the stored violations and identify the root causes of the violations.

[0119] As explained above, in one embodiment, such violations are analyzed offline using rules, and in one embodiment, such rules are parameterized as explained further below.

[0120] In one embodiment, the rules engine 202 identifies root causes of faults, such as timing and noise faults, in digital integrated circuit designs using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of the digital integrated circuit using a rules-based approach. Such rules-based approach, which may be provided by an expert, includes rules targeted at triaging various faults (e.g., cross-domain, cross-hierarchy, and / or multi-cycle violations) identified based on analyzing the design of the digital integrated circuit using electronic design automation tools (e.g., Eagle®, KiCAD®, Pulsonix®, Multisim®, Altium Designer®, etc.). As used herein, “triage” refers to analyzing faults, such as determining the root cause of such faults. In one embodiment, such rules address cross-domain, cross-hierarchy, and / or multi-cycle violations, such as by using parameterized thresholds that involve multiple domains. For example, such rules may address cross-domain violations, cross-hierarchy violations, and multi-cycle violations using parameterized thresholds that involve both noise and timing data. For example, one of the rules may be a noise and timing rule for Noise Impact on Function (NIOF) violations. Such rules may be used to analyze the relationship between noise and timing data, where nets (wires connecting components) that fail Noise Impact on Function violations with a high degree of aggressor coupling (noise coupled from other sources) obtained from the noise data are classified differently based on timing slack (the margin by which timing requirements are met or not met) obtained from the timing data using a user-defined threshold.Such cross-domain, cross-hierarchy, and multi-cycle triage is important because it allows root causes to be more effectively identified, thereby providing better recommendations for addressing such root causes. For example, the design approach for addressing noise impairments may be changed based on timing slack (timing data).

[0121] In one embodiment, database 104 stores a collection of rules for identifying the root cause of a violation. Such rules are associated with a particular violation. For example, one rule may be used to identify the root cause of a noise impact on function (NIOF) violation. As a result, rules engine 202 identifies rules for identifying the root cause of a violation based on the violation identified by analyzer 201. In one embodiment, such rules and their associated violations are stored in a data structure, where such data structure is stored in database 104 or in a storage device (e.g., storage devices 611, 615) of IC design and development system 102. In one embodiment, such data structure is entered by an expert.

[0122] In one embodiment, various parameters and data may be obtained by the rules engine 202 regarding a violation in order to analyze the violation using an appropriate rule. As described above, in one embodiment, such a violation includes metadata, including the parameters used by the analyzer 201 to determine that a violation occurred and related data used by the analyzer 201 to make the violation determination (e.g., noise margin, propagation delay, maximum clock frequency, steady-state current, transient signal behavior). Such parameters and data may be used by the rules engine 202 to identify the root cause of the violation. An example of such a rule is provided in FIG. 3.

[0123] A further illustration of rules for identifying the root cause of violations such as timing faults is provided in FIG.

[0124] In another example, rules may be utilized to address cross-domain, cross-hierarchy, and multi-cycle violations using parameterized thresholds that involve both noise and timing data. An example of such rules, including noise and timing rules for Noise Impact on Function (NIOF) violations, is shown in FIG.

[0125] Moreover, as previously described, such rules associated with violations may be entered into the data structure by an expert. Alternatively, in one embodiment, such rules are generated using a model trained by a machine learning algorithm.

[0126] In one embodiment, the rules engine 202 trains a model to create appropriate rules to identify the root cause of a particular violation (e.g., an NIOF violation) based on the parameters (e.g., voltage transfer characteristics, noise margin, fanout, power dissipation, propagation delay time, and the interrelationships between these parameters) and the data (e.g., noise margin, propagation delay, maximum clock frequency, steady-state current, transient signal behavior) utilized by the analyzer 201 in making the violation determination.

[0127] In one embodiment, the rules engine 202 uses machine learning algorithms (e.g., supervised learning) to build a model to create rules to identify the root cause of a violation using a sample data set containing the rules and associated violations, including parameters (e.g., voltage transfer characteristics, noise margin, fanout, power dissipation, propagation delay time, and the interrelationships between these parameters) and data utilized by the analyzer 201 in making a violation determination (e.g., noise margin, propagation delay, maximum clock frequency, steady-state current, transient signal behavior).

[0128] Such sample data sets are referred to herein as "training data" and are used by machine learning algorithms to make predictions or decisions regarding rules that should be developed to identify the root causes of violations. The algorithm iteratively makes predictions on the training data regarding rules that should be developed to identify the root causes of violations until the predictions reach a desired accuracy as determined by an expert. Examples of such learning algorithms include nearest neighbor, naive Bayes, decision trees, linear regression, support vector machines, and neural networks.

[0129] In one embodiment, after training a model to create rules for identifying the root cause of a violation based on the violation's metadata (the violation's metadata, including parameters and data), the rules engine 202 utilizes such a model to create rules based on providing the violation's metadata (e.g., parameters and data) received from the analyzer 201 to the trained model.

[0130] During operation 704 , the recommender engine 203 of the IC design and development system 102 recommends design changes in the design of the digital integrated circuit based on the root causes of the violations identified by the rule engine 202 .

[0131] For example, as described above, in one embodiment, recommender engine 203 utilizes a data structure (e.g., a table) containing a list of design recommendations based on the identified root causes. For example, if a rule indicates that the root cause of an NIOF violation is a coupling fault in a NAND logic gate identified by number 100122 in the design, recommender engine 203 may recommend replacing the NAND logic gate identified by number 100122 in the design (a small NAND logic gate) with a NAND logic gate identified by number 102233 (a large NAND logic gate) that receives digital signals identified by numbers 122233, 132343, and 122343. In one embodiment, such a data structure is entered by an expert. In one embodiment, such a data structure resides in a storage device (e.g., storage devices 611, 615) of IC design and development system 102.

[0132] In one embodiment, such recommendations may be generated using a model (mathematical model) trained using a machine learning algorithm to provide recommendations based on the identified root causes of the violation.

[0133] In one embodiment, the recommender engine 203 trains a model to recommend appropriate design changes in the design of a digital integrated circuit based on the root causes of the violations.

[0134] In one embodiment, the recommender engine 203 uses a machine learning algorithm (e.g., supervised learning) to build a model and recommend appropriate design changes in the design of the digital integrated circuit using a sample dataset containing design changes and identified root causes of violations in the design of the digital integrated circuit. In one embodiment, such a dataset is provided by an expert.

[0135] Such sample data sets are referred to herein as "training data" and are used by machine learning algorithms to make predictions or decisions regarding design changes in the design of digital integrated circuits based on the root causes of violations. The algorithm iteratively makes predictions on the training data regarding design changes until the predictions reach a desired accuracy as determined by an expert. Examples of such learning algorithms include nearest neighbor, naive Bayes, decision trees, linear regression, support vector machines, and neural networks.

[0136] In one embodiment, after training a model to make predictions or decisions regarding design changes in the design of a digital integrated circuit based on the root causes of violations, the recommender engine 203 utilizes such model to recommend design changes to the design of the digital integrated circuit based on the root causes of violations identified by the rules engine 202.

[0137] In one embodiment, the recommender engine 203 annotates the database 104 with recommended design changes.

[0138] During operation 705, the recommender engine 203 of the IC design and development system 102 implements design changes based on the recommendations. For example, if the recommender engine 203 recommends replacing a NAND logic gate identified by number 100122 in the design (a small NAND logic gate) with a NAND logic gate identified by number 102233 (a large NAND logic gate) that receives digital signals identified by numbers 122233, 132343, and 122343, the recommender engine 203 proceeds to replace the NAND logic gate identified by number 100122 in the design with the NAND logic gate identified by number 102233.

[0139] In one embodiment, recommender engine 203 simply provides such recommendations to a designer, such as a user of computing device 101, to let the designer decide whether or not to implement such design changes in the design of the digital integrated circuit. In one embodiment, such recommendations are in the format of a report (e.g., a text report).

[0140] As a result of the foregoing, the principles of the present disclosure provide a means for effectively identifying root causes of faults, such as timing and noise faults, in digital integrated circuit designs using offline analysis of cross-domain, cross-hierarchy, and / or multi-cycle violations of digital integrated circuits using a rules-based approach.

[0141] Furthermore, the principles of the present disclosure improve techniques or technical fields involved in integrated circuit design. As described above, in the design of digital integrated circuits, various EDA tools are used to test and analyze such designs to identify various violations, such as timing or noise faults. A "timing fault" is a failure of a process or portion of a process in a synchronous distributed or real-time system to meet set constraints on execution, message delivery, clock drift rate, or clock skew. As used herein, a "noise fault" refers to an unexpected random fluctuation in voltage that can potentially cause disruption or damage in an electrical circuit. When such simulated faults (e.g., timing faults and noise faults) occur, designers attempt to identify the root cause of such faults. However, such analysis (referred to as "triage") is time-consuming and difficult. Furthermore, such faults (e.g., timing faults and noise faults) may be correlated. However, such correlation is difficult to evaluate, thereby making it difficult to identify the root cause of such faults. In addition, such faults (e.g., timing faults and noise faults) may involve integration-level issues between components located at different levels of an integrated circuit. For example, a multi-cycle path may extend across multiple components located at different levels of an integrated circuit. Analyzing such a problem may involve individually analyzing each of the multiple levels of components, which is very difficult, thereby making it difficult to identify the root cause of such a failure. As a result, currently, there is no means to effectively identify the root cause of failures, such as timing and noise failures, in the design of digital integrated circuits.

[0142] Embodiments of the present disclosure improve such techniques by performing an analysis of a digital integrated circuit being designed, where the results of such analysis include identifying and storing violations. As used herein, a “violation” refers to the performance of a component or system in a digital integrated circuit design that does not meet required specifications as established by the designer, resulting in a fault (e.g., a noise fault, a timing fault, a power fault, etc.). In one embodiment, such an analysis may involve verifying and simulating the design of the digital integrated circuit based on various characteristics or parameters, such as voltage transfer characteristics, noise margin, fanout, power dissipation, propagation delay time, and the interrelationships between these parameters. In one embodiment, such analysis ensures that it complies with functional or parametric specifications that may be established by the designer. Rules may then be used to analyze the stored violations to identify root causes of the violations, including cross-domain, cross-hierarchy, and / or multi-cycle violations. As used herein, “cross-domain” includes multiple types of faults, such as timing faults and noise faults. As used herein, “cross-hierarchy” includes multiple levels of the integrated circuit design. As used herein, "multi-cycle" includes multi-cycle paths that extend across multiple components. In one embodiment, such violations are analyzed offline using rules. In one embodiment, such rules are parameterized. In one embodiment, cross-domain, cross-hierarchy, and / or multi-cycle violations, including timing and noise faults, are identified using offline analysis of violations of digital integrated circuits using a rules-based approach. Such rules-based approaches include rules targeted at triaging various faults of cross-domain, cross-hierarchy, and / or multi-cycle violations identified based on analyzing designs of digital integrated circuits using electronic design automation tools (e.g., Eagle®, KiCAD®, Pulsonix, Multisim®, Altium Designer®, etc.).As used herein, "triage" refers to analyzing failures, such as determining the root cause of such failures. In one embodiment, such rules address cross-domain, cross-hierarchy, and / or multi-cycle violations, such as by using parameterized thresholds that involve multiple domains. Furthermore, such rules may address violations involving paths that cross hierarchies in the design of the digital integrated circuit. As used herein, "hierarchy" refers to a level of the digital integrated circuit, where each level includes one or more components of the digital integrated circuit. In addition, such rules may address violations involving multi-cycle paths that extend across multiple components. Design changes in the design of the digital integrated circuit may then be recommended based on the identified root causes of violations, such as cross-domain violations. In one embodiment, such recommendations are based on utilizing a data structure (e.g., a table) that includes a list of design recommendations based on the identified root causes. In one embodiment, such recommendations may be generated using a model (mathematical model) trained using a machine learning algorithm to provide recommendations based on the identified root causes of violations, such as cross-domain violations. In one embodiment, the recommended design changes are implemented in the design of the digital integrated circuit. In this manner, the root causes of faults, such as timing and noise faults, in the design of a digital integrated circuit are effectively identified using offline analysis of cross-domain (e.g., timing and noise faults), cross-hierarchy (multiple levels of an integrated circuit design), and / or multi-cycle (multi-cycle paths extending across multiple components) violations of the digital integrated circuit using a rule-based approach, thereby further improving the technical fields involved in integrated circuit design.

[0143] The technical solutions provided by the present disclosure cannot be implemented in the human mind or by a human using pen and paper, i.e., the technical solutions provided by the present disclosure cannot be realized in the human mind or by a human using pen and paper in any reasonable amount of time and with any reasonable expectation of accuracy without the use of a computer.

[0144] In one embodiment of the present disclosure, a computer-implemented method for recommending design changes in a design of a digital integrated circuit includes performing an analysis of the digital integrated circuit to obtain a plurality of violations as a result. The method further includes analyzing one of the plurality of violations using rules to identify a root cause of the one of the plurality of violations, including a domain crossing, a hierarchy crossing, and / or a multi-cycle violation. The method additionally includes recommending a design change in the design of the digital integrated circuit for one of the plurality of violations based on the identified root cause.

[0145] Furthermore, in one embodiment of the present disclosure, the method additionally includes the rule addressing violations using parameterized thresholds that account for both noise and timing data.

[0146] Additionally, in one embodiment of the present disclosure, the method further includes addressing violations where the rules involve paths that traverse a hierarchy in the design of the digital integrated circuit.

[0147] Furthermore, in one embodiment of the present disclosure, the method additionally includes that the rules are parameterized.

[0148] Additionally, in one embodiment of the present disclosure, the method further includes analyzing one of the plurality of violations using the rule offline.

[0149] Furthermore, in one embodiment of the present disclosure, the method additionally includes the plurality of violations including timing and noise faults discovered using an electronic design automation tool.

[0150] Additionally, in one embodiment of the present disclosure, the method further includes implementing design changes based on the recommendations.

[0151] Other aspects of the embodiments of the computer-implemented methods described above are systems and computer program products.

[0152] The description of various embodiments of the present disclosure has been presented for purposes of illustration and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been selected to best explain the principles of the embodiments, practical applications, or technical improvements to technology found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A computer-implemented method for recommending design changes in a digital integrated circuit design, the method comprising: performing an analysis of the digital integrated circuit to obtain a plurality of violations as a result; analyzing one of the plurality of violations using rules to identify a root cause of the one of the plurality of violations, including a cross-domain, cross-hierarchy, and / or multi-cycle violation; and recommending a design change in the design of the digital integrated circuit for the one of the plurality of violations based on the identified root cause. A method for providing

2. The method of claim 1 , wherein the rules address the violations using parameterized thresholds that account for both noise and timing data.

3. The method of claim 1 , wherein the rules address the violations involving paths that traverse a hierarchy in the design of the digital integrated circuit.

4. The method of claim 1 , wherein the rules are parameterized.

5. The method of claim 1 , wherein the one of the plurality of violations is analyzed offline using the rule.

6. The method of claim 1 , wherein the plurality of violations includes timing and noise faults discovered using electronic design automation tools.

7. implementing the design changes based on the recommendations. The method of claim 1 further comprising:

8. 1. A computer program product for recommending design changes in the design of a digital integrated circuit, the computer program product comprising one or more computer readable storage media having program code embodied thereon, the program code comprising: performing an analysis of said digital integrated circuit to obtain a plurality of violations as a result; analyzing one of the plurality of violations using rules to identify a root cause of the one of the plurality of violations, including a cross-domain, cross-hierarchy, and / or multi-cycle violation; and recommending a design change in the design of the digital integrated circuit for the one of the plurality of violations based on the identified root cause. a computer program product, comprising programming instructions for

9. 10. The computer program product of claim 8, wherein the rules address the violations using parameterized thresholds that account for both noise and timing data.

10. 10. The computer program product of claim 8, wherein the rules address the violations involving paths that traverse a hierarchy in the design of the digital integrated circuit.

11. The computer program product of claim 8 , wherein the rules are parameterized.

12. The computer program product of claim 8 , wherein the one of the plurality of violations is analyzed offline using the rule.

13. 9. The computer program product of claim 8, wherein the plurality of violations comprises timing and noise faults discovered using electronic design automation tools.

14. The program code implementing said design changes based on said recommendations; 9. The computer program product of claim 8, further comprising the programming instructions for:

15. a memory for storing a computer program for recommending design changes in the design of a digital integrated circuit; and a processor coupled to said memory, said processor comprising: performing an analysis of said digital integrated circuit to obtain a plurality of violations as a result; analyzing one of the plurality of violations using rules to identify a root cause of the one of the plurality of violations, including a cross-domain, cross-hierarchy, and / or multi-cycle violation; and recommending a design change in the design of the digital integrated circuit for the one of the plurality of violations based on the identified root cause. configured to execute program instructions of the computer program including A system comprising:

16. The system of claim 15 , wherein the rules address the violations using parameterized thresholds that account for both noise and timing data.

17. 16. The system of claim 15, wherein the rules address the violations involving paths that traverse a hierarchy in the design of the digital integrated circuit.

18. The system of claim 15 , wherein the rules are parameterized.

19. The system of claim 15 , wherein the one of the plurality of violations is analyzed offline using the rule.

20. 16. The system of claim 15, wherein the plurality of violations comprises timing and noise faults discovered using electronic design automation tools.

Images