Verification of functional security of integrated circuits

Abstract

A method for verifying the functional security of an integrated circuit (10), IC, comprises the steps of: performing a structural analysis on one or more sub-portions (11, 12) of a first group (1) of the IC (10) in order to determine a fault path coverage of one or more outputs (O1, O2) of the first group; determining at least one constraint (20, 21) defining the one or more inputs (131, 132) of the second group of sub-portions as allowed values, where the one or more outputs (O1, O2) of the first group are as inputs (13) of the one or more sub-portions (13) of the second group (2) of the IC; and performing formalized attribute verification on the second group (2) of ICs (10) based on the at least one constraint (20, 21).

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of integrated circuits and their verification. More specifically, the present disclosure relates to analysis of integrated circuits, e.g., to defect detection and / or fault propagation in integrated circuits. BACKGROUND

[0002] The use of complex integrated circuits (ICs) in safety-critical systems is now widespread in multiple industry sectors, including automotive, aerospace, power generation, defense, and medical devices. Governed by a range of regulatory standards, the development of these systems must be proven to be rigorous and / or compliant with a set of requirements. Furthermore, to improve the safe operation of these systems, safety mechanisms or redundancies are integrated that ensure a reliable and deterministic reaction of the device to random hardware faults when operating in the field. Specifically, the automotive market, governed by the ISO 26262 standard, requires a particularly rigorous development methodology. This includes the tracking of requirements from specification to verification and coverage, failure mode analysis, and risk assessment and / or mitigation techniques.

[0003] Integrated circuits are composed of multiple interconnected logic elements, such as logic gates, flip-flops, and registers. These logic elements interact with each other to perform a specific function. Formal verification is a method of verifying the correctness of an IC design using mathematical techniques.

[0004] During formal verification, a model of the IC is created in a hardware description language (HDL) that specifies the expected behavior of the IC using a set of logical properties or assertions. The model is then checked against the properties to ensure that the IC operates as intended.

[0005] When verifying a system, all possible states and transitions need to be analyzed to ensure that the system operates as intended. However, as the number of components, the number of variables, and the number of possible interactions between them increase, the number of possible states grows exponentially, making it impractical or even impossible to exhaustively verify the system.

[0006] In formal verification, the state explosion problem refers to the exponential growth in the number of states that need to be checked as the size and complexity of the system under verification increase. The state explosion problem arises because the number of possible states of an IC increases exponentially with the number of logic elements and / or the number of inputs. The state explosion problem poses a significant challenge to formal verification, and various techniques have been developed to address the problem. Some of these techniques include abstraction, model checking, and theorem proving. These methods allow verification engineers to use a simplified model or to reason about the behavior of the system by analyzing specific properties of the system. However, even with these techniques, the state explosion problem remains a significant challenge in formal verification.

[0007] Patent application publication US 2021064810 A1 describes a method to perform hardware security analysis without fault simulation. So far, a safety-specific design-structure analysis and cone-of-influence (COI) method without fault simulation has been proposed.

[0008] A detailed description of problems and techniques currently employed in verifying integrated circuits and their normal operation is provided in patent application publication US 2018 / 364298 A1, in particular with respect to safety-related electrical and / or electronic systems. SUMMARY

[0009] Therefore, in general, whether by simulation or by emulation, the preparation and injection of faults for verifying the normal operation of integrated circuits is lengthy. In addition, the analysis of fault effects is cumbersome. In particular, with respect to safety-related functions, it must be ensured that the fault injection covers the necessary range within the IC and / or includes all fault types that can occur. Furthermore, it is necessary to determine the necessary fault injection points and / or the partitioning of the IC. Therefore, it is desirable to improve the fault coverage, to speed up the verification time and to allow for fault localization.

[0010] According to a first aspect, a (preferably computer-implemented) method for verifying the functional safety of an integrated circuit (IC) is proposed. The method comprises performing a structural analysis of a first set of one or more subparts of the IC in order to determine a fault path coverage of one or more outputs of the first set. The method further comprises determining at least one constraint that limits the one or more outputs of the first set to allowed values, wherein the one or more outputs of the first set are inputs of a second set of one or more subparts of the IC. The method further comprises performing a formal property verification of the second set based on the at least one constraint.

[0011] According to a second aspect, a computer program, preferably stored on a non-transitory medium, comprising program code which, when executed, performs the method steps according to the first aspect is proposed.

[0012] According to a third aspect, an apparatus, e.g. a computer, preferably comprising a processor and a memory, is proposed that is operative to perform the method steps of the first aspect. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1 A diagram of an integrated circuit is shown.

[0014] Figure 2 A dual-core lockstep comparator and recovery are shown.

[0015] Figure 3 A general safety-critical system with hardware safety mechanisms is shown.

[0016] Figure 4 Another safety critical system is shown with hardware security mechanisms.

[0017] Figure 5 A structural analysis of a subpart is shown.

[0018] Figure 6 Another safety critical system is shown.

[0019] Figure 7 Mapping of an IC design to an IC model is shown.

[0020] Figure 8 A combination of formal property checking and deadline-based structural analysis is shown.

[0021] Figure 9 Exemplary constraints and assertions for security mechanisms are shown.

[0022] Figure 10 A system architecture diagram for verifying integrated circuits is shown.

[0023] Figure 11 Exemplary steps during design and production of integrated circuits are shown.

[0024] Figures 12 to 27 Exemplary method steps are shown. DETAILED DESCRIPTION

[0025] Figure 1 A diagram of an integrated circuit 10 is shown. An integrated circuit, IC 10, also called a chip or microchip, is a set of electronic circuits that have been miniaturized onto a semiconductor material (usually silicon). Large numbers of tiny transistors and other electronic components (called logic elements) that perform logic operations are integrated on the chip. An integrated circuit or IC is a semiconductor hardware on which circuits are mounted.

[0026] An integrated circuit and / or IC design can be considered a hardware component, having multiple subparts. The subparts can be grouped into safety mechanisms and intended functionality, where two such groups can form a safety feature. The subparts themselves can comprise one or more blocks or cells that perform a (particular) sub-function. For example, in an IC, there can be blocks for arithmetic and logical operations, memory access, input / output (I / O) control, and clock generation. These blocks work together to perform the overall functionality of the integrated circuit. The blocks themselves (and thus the subparts) can comprise one or more logic elements, such as one or more bits, states, ports, signals, wire nets, gates, e.g., in a hardware description language HDL. One or more gates can form a so-called cell. On the register transfer level (RTL), the terms state and / or bit can be used to describe the IC and / or its logic elements. On the logic gate level, the functionality is implemented in the form of gates and / or cells. The term “signal” is used in VHDL, while the term “wire net” is used in Verilog to describe the IC, logic elements, blocks, and / or subparts.

[0027] Functional verification is the process of verifying that a system, such as an IC, or component meets its functional requirements. This includes verifying that the system behaves as intended and conforms to the specification. On the other hand, safety verification is the process of verifying that a system or component can be used safely. This includes verifying that the system or component meets safety requirements and does not pose any safety risks to users or the environment, e.g., in the event of a random fault. While functional verification focuses on the correct behavior of the system, safety verification is used to identify and / or mitigate random faults in order to avoid failures. Thus, the verification of safety mechanisms mitigates random faults in order to avoid random failures. Safety verification typically involves rigorous testing and analysis to identify potential safety risks and verify that the system or component can be used safely under all expected conditions.

[0028] Both functional verification and safety verification are important aspects of the overall design and testing process of any system or component. They work together to ensure that the system meets its intended functionality while also meeting all necessary safety requirements.

[0029] Figure 2 A dual-core 11, 12 lockstep comparator 13 and / or recovery 13a is shown. Safety-related and thus critical functions, e.g., in the automotive industry, often employ a dual-core lockstep architecture. This is a technique to prevent uncontrolled failures. The two cores operate on the same input (stimulus), in lockstep, and the results are compared. If the results differ, a fault is detected. The recovery 13a can be used to recover from the fault, e.g., by switching to a redundant core. Figure 2The core 11 is indicated as the core input, but there can be a delay 12a of several clock cycles to achieve time diversity and reduce the risk that a fault affects both cores 11, 12 identically. The cores 11, 12 can be implemented on a single IC and / or can form a first sub-portion and a second sub-portion of the IC. A comparator 13, which comprises logic elements and is also implemented on the IC, realigns the outputs of the two cores and issues an alarm if they differ. The comparator 13 can be understood as a third sub-portion and / or can be verified using formal verification as presented herein. If the comparator 13 is verified as part of the IC, a fault injection technique can be applied to inject faults. At IC level, a formal connectivity check can be employed to verify that the appropriate outputs of the first sub-portion 11 and the second sub-portion 12, as well as reset signals, clock signals and / or other system-level control signals, are correctly connected to the inputs of the comparator 13, while the alarm output of the comparator 13 is correctly connected to a safety control unit and / or a fault log register.

[0030] In the case of an alarm, it can not be known whether one of the sub-portions 11, 12, 13, in particular the cores / sub-portions 11, 12, still operates correctly. Recording error information, testing both cores and a significantly more complex module that multiplexes 13b their outputs can increase system availability. In the case of an alarm, a recovery module 13a can select and / or run appropriate tests. If the result identifies one of the cores as fault-free, the recovery module 13a can select its output in the multiplexer 13b and allow the system to continue to operate, or at least complete the execution of a critical program that is in progress.

[0031] The verification of the comparator 13, the recovery module 13a and / or the multiplexer 13b is a critical task and is, in particular, safety-related and / or safety-critical. All possible sequences of recovery actions must be completely specified and verified. The operational SVA developed by OneSpin can be used to capture the operation of the recovery module in a concise, elegant way. The operational SVA makes use of the library of standard SystemVerilog properties and sequences, which in addition enables the use of high-level temporal conditions.

[0032] The second sub-portion / core 12 and the comparator 13, the recovery module 13a and / or the multiplexer 13b can form a (hardware) safety mechanism for the first sub-portion / core 11.

[0033] Figure 3A general safety critical system 10 with (hardware) safety mechanisms is shown. Safety mechanisms are a class of safety measures built into a system that are intended to detect faults or control failures. ISO 26262 can require the use of safety mechanisms to detect and possibly correct the effects of one or more random hardware faults. Safety mechanisms can be implemented in both software and / or hardware, and their ultimate goal is to reduce the occurrence of random faults that can lead to a violation of safety goals.

[0034] A fault refers to an erroneous logic value that occurs on a certain logic element in an IC or IC design, which can occur transiently (e.g. due to a high-energy particle strike) or permanently (e.g. due to material corrosion or permanent damage to the circuit). Such a fault can potentially change the behavior of an electronic system. These faults can lead to death, injury, or high economic loss in safety critical systems. In any case, a fault can be understood as an abnormal condition as defined in ISO 26262-1 :2018 that can lead to the failure of an element or item. Similarly, an error can be defined as a difference between a calculated, observed, or measured value or condition and a true, specified, or theoretically correct value or condition. Thus, an error can arise due to a fault within the system or component under consideration.

[0035] For example, fault propagation analysis can be used to classify faults. Fault propagation can be performed on an IC design (e.g. at register transfer level) of an IC, but ultimately must be performed on an IC model that is as close as possible to the actual hardware and provides good correlation not only at the logic level but also on physical parameters such as circuit area, for example according to ISO 26262. Fault propagation analysis can include injecting faults (e.g. into gate level models of integrated circuits) during verification to prove that the faults will be detected by the safety mechanisms. These gate level models can be complex and contain numerous possible fault scenarios. To meet the hardware safety goals, the number of “dangerous undetected” faults must be minimized. Faults can be classified as propagatable and non-propagatable. Non-propagatable faults will never lead to a system failure regardless of their state. Such faults are therefore safe and can be removed from the list of dangerous faults, improving the fault metric.

[0036] In the semiconductor context, a “fault path” 40 generally refers to a path through a semiconductor device (i.e. IC) that allows current to flow through a location that should not be conducting, resulting in an error or unintended behavior of the device. Fault paths 40 can occur for a variety of reasons, such as defects in the manufacturing process, damage to the device during use, or random faults as described herein.

[0037] In semiconductor design and verification, fault path coverage refers to the degree to which a set of tests can detect such fault paths. It is a measure of the effectiveness of the testing process in identifying and correcting faults in subparts. A high fault path coverage is desired as it indicates that the testing process can detect a large number of faults, thereby reducing the likelihood of a defective IC design.

[0038] The hardware safety mechanism can comprise a (second) subpart 12 and a (third) subpart 13. Therein, the second subpart can obtain the same input as the first subpart. The first and second subpart can be configured to perform the same function and the outputs of the subparts 11, 12 are compared by the third subpart 13.

[0039] Figure 4 Another (hardware) safety mechanism is shown. Here, the IC 10 comprises a first subpart 11 for performing an intended function or functionality. The IC 10 can comprise a second subpart 12 for performing at least part of a safety mechanism for the intended functionality. Thus, the first subpart 11 and the second subpart 12 can form a first group of subparts 1.

[0040] The IC 10 can further comprise at least one third subpart 13, e.g. at least one comparator. The IC can comprise further subparts, such as Figure 2 The restoration and / or multiplexer described in the background section. Thus, the IC can comprise a second group of subparts 13, 13a, 13b.

[0041] The first subpart 11 and the second subpart 12 can be configured to obtain, preferably the same, input or input value I1, I2. The first subpart 11 can further be configured to output a primary output O1 and / or a corresponding output value. Similarly, the second subpart 12 can be configured to output a secondary output O2 and the third subpart 13 can be configured to compare the primary output O1 with the secondary output O2 and / or the respective values in order to determine the functional safety of the first subpart 11 and / or the second subpart 12, i.e. the first group 1. To this end, the third subpart 13 can comprise and / or obtain an input I31, I32 or input value I3. The third subpart 12 can then output a diagnostic signal, such as an alarm or alert, in general, e.g. in case of a deviation, i.e. a mismatch, of the inputs or input values. As shown, the hardware safety mechanism comprises a second subpart and a third subpart. One or more of the inputs I1, I2, I31, I32, I3 and / or the outputs O1, O2, O3 can be provided in the form of a bit list.

[0042] Depending on the circumstances (e.g., in IC design and / or IC model), IC 10 may include intended functionality implemented by the first sub-part 11 and security mechanisms for the intended functionality implemented by the second sub-part 12. Security mechanisms for the intended functionality may also be implemented by the second sub-part 12 and the third sub-part 13.

[0043] Figure 5 The structural analysis of a sub-section is shown. Influence cone analysis is a structural analysis method used to analyze IC designs. Its idea is to consider only those parts of the IC that are relevant to a specific function. When considering an IC design at the register-transfer level or gate level (netlist) and the signals in the design, the influence cone of a signal is the group of all signals, modules, and / or gates that the signal under consideration depends on. These components can be obtained by traversing backwards from the signal. This process is also known as transitive fan-in analysis.

[0044] Although Figure 5 The example shown depicts only a single TO element 44, but more than one TO element may exist. The transitive fan-in effect cone can be determined from the TO element. Logic elements (such as this TO element) may include, for example, one or more bits, states, ports, signals, nets, gates, or cells.

[0045] The second influence cone is the transitive fan-out influence cone of FROM element 43. This second influence cone (i.e., the transitive fan-out influence cone) is superimposed on the first influence cone. The intersection of these two influence cones provides a precisely defined combination of sub-sections or logic elements between the inputs and outputs of the IC's sub-sections.

[0046] Therefore, one or more logic elements that are in the direct fan-out of a subsection and are not TO element 44 or a direct fan-out of TO element 44 are identified. These read elements 41 are elements that do not belong to the subsection but read other elements in the subsection. These read elements 41 are, for example, not protected by security mechanisms.

[0047] Subsections 11 and 12 may also contain potential residual logic elements 42 that can influence and / or control one or more logic elements in the subsection. Logic elements 42 written into logic elements in a subsection may be referred to as "write bits". These write bits 42 are located in the direct fan-in of the logic elements in the subsection.

[0048] Accordingly, based on such a structural analysis (e.g. influence cone analysis), the first sub-portion can be analyzed. In any case, the sub-portion can be the first sub-portion and / or the second sub-portion, or another sub-portion of the first group of sub-portions of the IC. Accordingly, only faults that include a propagation of the structure to at least one TO element are included in the list of faults (to be verified). The first sub-portion and / or the second sub-portion can be defined as a combination of logic elements that are located between the input and the output of the sub-portion (e.g. between input II and output OI or between input I2 and output O2, respectively). Accordingly, the input of the sub-portion can be given by the FROM element and the output can be given by the TO element.

[0049] The structural analysis based on the COI (influence cone) can be used to determine one or more faults. The structural analysis can be used to classify one or more faults, i.e. whether they are located on the path from the FROM element to the TO element, and preferably can be classified accordingly, e.g. as a safety fault.

[0050] Figure 6 Another safety critical system is shown. In addition to the illustration of Figure 4 , the logic elements of the first sub-portion and the third sub-portion are shown. A logic element 70 is shown that bypasses the safety mechanism, denoted as SM bypass 0. Furthermore, a logic element 71 is shown that controls the safety mechanism of the IC but is not part of the safety mechanism, denoted as SM control 71. Figure 6

[0051] Figure 7 A mapping of the IC design to the IC model is shown. Here, the IC design 60 is given in register transfer level (RTL). For this, an HDL can be used. Then, the IC model can be determined that models the functionality of the IC, e.g. at system level. From this, the first sub-portion, the second sub-portion and the third sub-portion can be identified. The mapping can be performed in an automated manner based on the IC design. For this, a bit list of the IC model can be mapped 80, 81, 82, 83, 84 to the signals in the IC design, or vice versa. The IC design 60 can comprise: a first sub-portion, in Figure 7 , also denoted as primary; a second sub-portion, in Figure 7 , also denoted as secondary; and a third sub-portion, e.g. comprising as Figure 7 ​The illustrated delay element and XOR logic element (as a comparator). A third sub-portion in the IC design can include a delay element and a logic element in the form of an XOR gate that compares the output of the first sub-portion with the output of the second sub-portion (which is an input to the third sub-portion). The IC design can include further logic elements and / or sub-portions that are not illustrated. These logic elements or sub-portions can influence the behavior of the first, second and / or third sub-portion and / or the logic elements therein. For example, faults can propagate from or to these sub-portions.

[0052] Now, given the IC design 60, a first sub-portion, a second sub-portion and / or a third sub-portion can be identified in the IC design. For example, the inputs of the IC design can be mapped 80 to the inputs of the IC model 50. Further, the outputs of the first sub-portion in the IC design can be mapped 81 to the outputs of the first sub-portion in the IC model. The same applies to the outputs of the second sub-portion and the outputs of the third sub-portion, which are mapped 81, 82, 83 to the IC model 50. Alternatively or additionally, the inputs of the third sub-portion in the IC design can be mapped to the inputs of the third sub-portion in the IC model. These elements and / or signals in the IC design can be represented as one or more bit lists in the IC model.

[0053] For example, a (e.g., security-aware) partitioning of the IC design and / or the IC model can be performed. That is, the logic elements in the IC design can be mapped to the intended functionality and / or security mechanisms in the IC model, or vice versa. This can be automated by one or more software tools, such as the Fault Contribution Analysis (FCA) application by OneSpin. To this end, the IC design sub-portions can be associated with the IC model sub-portions, for example, delimited by key design signals, including the protected outputs of the intended functionality and the diagnostic outputs of the security mechanisms.

[0054] Hence, one or more IC signals and / or logic elements in the IC design can be automatically detected based on the above-described partitioning, or can be selected, for example, by a user. The one or more IC signals and / or logic elements in the IC design can be represented, for example, by one or more bit lists in the IC model. Hence, the IC model 50 representing the IC design at a higher abstraction level (i.e., system level or functional level) can be obtained. For example, RTL components can be converted to a SystemC model using VtoC or Verilator. Conversely, IC models (e.g., in C or C++) of sub-portions or components can be converted to RTL implementations using high-level synthesis. In general, ICs can be modeled at other abstraction levels using EDA tools and languages, such as SystemC.

[0055] Now turning to Figure 8A combination of safety mechanisms and formal property checking is described. As before, the IC is divided into a plurality of subparts. Then, one or more cutpoints are determined in order to separate the structural analysis from the formal property checking. That is, the one or more cutpoints determine the subparts of the IC for which the structural analysis should be performed and the subparts for which the formal property checking should be performed. Again, the cutpoints can be determined, e.g., automatically, e.g., as the output (signals and / or logic elements) of the first subpart and / or the second subpart. In contrast, the cutpoints can be determined as the input of the third subpart. That is, the input of the third subpart is used as a cutpoint. Thus, based on the IC model, one or more cutpoints are determined in order to determine the subparts for which the structural analysis should be performed and the subparts for which the formal verification (e.g., in the form of formal property checking) should be performed.

[0056] Then, the structural analysis can be performed on one or more of the subparts of the first group of subparts. The structural analysis can be an influence cone analysis as described herein. The structural analysis can determine that there is no overlap between the subparts; that there is no escape path (bypassing the third subpart, e.g., the comparator); and / or that there is no unknown control signal (that can affect the intended functionality and / or safety mechanisms in the first subpart and / or the second subpart). Thus, the structural analysis determines that, when a fault propagates (through the first subpart and / or the second subpart), it will necessarily lead to an error scenario. That is, a fault (in the first group of subparts) will propagate to the input of the third subpart. The input can coincide with the cutpoint. In other words, a fault (in the first group of subparts) will propagate to the output of the first subpart and / or the second subpart. These outputs can again coincide with the cutpoint. Since it is now determined that all faults necessarily propagate to the input of the third subpart (or to the output of the first subpart and the second subpart, respectively), these inputs (or outputs, as the case can be) can be used as one or more cutpoints for the remaining subparts of the IC (e.g., one or more of the subparts of the second group of subparts). In the current case, the third subpart implementing the comparator for comparing its input (e.g., the input obtained from the first subpart and the second subpart) is then verified by performing the formal property checking. In any case, one or more further subparts can be included in the remaining subparts and can form a second group of subparts of the IC, which is cut apart from the first group of subparts. The second group can include additional subparts, e.g., such as described herein, e.g., one or more delay elements, recovery modules, and / or multiplexers.

[0057] Accordingly, based on the one or more cut-offs, one or more IC signals and / or logic elements in the IC design and / or the IC model can be determined. As mentioned before, these IC signals and / or logic elements can be given in the form of one or more bit lists. The one or more cut-offs can also be understood as error scenario constraints. Based on these error scenario constraints, properties of formal property checks or verifications can be determined for the outputs Oi, O2of the first and second sub-parts and / or the inputs I31, I32of the third sub-part. That is, in case the inputs of the third sub-part (which can correspond to the outputs of the first and second sub-parts, respectively) are not equal, the third sub-part (i.e. the comparator in this case) should generate a diagnostic output (e.g. indicating an error). Similarly, in case the inputs of the third sub-part (corresponding to the outputs of the first and second sub-parts, respectively) are equal, the third sub-part (the comparator in this case) should generate a diagnostic output (e.g. indicating an error-free state). The respective constraints 20, 21 and assertions 30, 31 of the outputs Oi, O2of the first and second sub-parts as well as the inputs I31, I32of the third sub-part are shown in Figure 9 Alternatively or additionally, the constraints 20, 21 can be applied to the inputs I31, I32of the third sub-part, i.e. the constraints can read I31==I32and / or I31!=I32.

[0058] In any case, the one or more constraints can also consider the outputs of the first group of sub-parts and constrain the inputs of the second group of sub-parts (i.e. after partitioning and / or after cut-off), e.g. not only for lockstep as described, e.g. in connection with Figure 2 、 Figure 3 and / or Figure 4 another security mechanism or even another intended functionality implemented by the second group of sub-parts.

[0059] In formal verification, an assertion is a statement that specifies a property that must hold true in a given IC model or IC design. Assertions are used to check whether an IC model or IC design meets certain requirements or specifications.

[0060] Assertions are written in a formal language that can be used by automated tools to verify the correctness of an IC model and / or IC design. They are usually expressed in terms of predicates, which are logical expressions that evaluate to true or false. Assertions can be used to specify safety properties, such as the absence of certain errors or violations, or liveness properties, such as the eventual occurrence of certain events.

[0061] Formal verification tools use assertions to check whether an IC model or IC design meets its requirements or specifications. This is typically done by analyzing the IC model or IC design using mathematical models and / or logical reasoning and checking whether the assertions hold true in all possible scenarios. If the assertions fail, it indicates that there is a defect in the IC model and / or IC design that must be fixed.

[0062] As mentioned previously, one or more constraints and / or assertions can be determined based on one or more cut-offs. The constraints can be asserted by performing a formal property check or verification. This formal property check or verification then checks any number of subparts of the third subpart or second set. To this end, a number of software tools can be used, such as DV-verify by OneSpin. Formal property checking provides a proof and / or can certify that there is no vulnerability in an IC (e.g. IC design and / or IC model). To this end, a formal property check can be performed on the RTL code of the IC design (more specifically, of the third subpart), given one or more constraints and / or assertions.

[0063] As a result of the formal property check, if the formal property check proves that the third subpart satisfies the property under consideration, then the property is satisfied. It can then be concluded that the IC (e.g. design or model) is correct with respect to the property. Alternatively, if the formal property check finds a counterexample that violates the property, it can be determined that there is a property violation. This indicates that there is an issue with the IC (e.g. IC design or IC model) that needs to be addressed. In this case, a software tool for highlighting and / or displaying the state of the problem can be used. In case of a check failure, the software tool reports the violation and can generate traces that reveal the root cause of the problem for debugging. The generated traces can start from the active reset and / or can lead to the violation and thus can prove that there is an RTL problem. The check failure can be visually analyzed in OneSpin’s integrated debugging environment. Color coding, active code annotations, active driver and load traces, and dynamic synchronization between source code and waveform viewers enable users to quickly identify the root cause of the problem and fix the IC design. Furthermore, the result of the formal property check can be inconclusive, i.e. the verification tool cannot prove or disprove the property.

[0064] Figure 10A computer system architecture for verifying integrated circuits is shown, e.g. in the form of an IC design and / or an IC model. The computer system comprises a computing device 300, which can be a computer or a server having one or more processors, memory, and non-transitory storage media such as a hard disk drive or a solid state drive. The computing device 300 has a structural analysis module 310, a formal property checker module 320, a partitioning module 350, a mapping module 360, and / or a (waveform) debugger and / or viewer 340. The modules can be implemented in software using program code stored on the computing device. The modules are used to implement the steps described herein, such as partitioning an IC design, mapping the IC design to an IC model, performing structural analysis on a first set of subparts and / or performing formal property checking on a second set of subparts, and / or debugging the IC design based on the results of the structural analysis and / or the formal property checking. The computing device can have other modules or applications, such as modules for editing, loading, and storing IC designs and / or IC models. The system can also have a display 390 providing an interface for a user to interact with one or more of the modules 310, 320, 340, 350, 360.

[0065] Figure 11 Exemplary steps during design and production of an integrated circuit are shown. In a first step S70, an IC design can be created. However, first a functional specification of the IC at a higher abstraction level, i.e. an IC model, can be created or obtained. The IC specification can be created using a variety of languages and / or tools. Examples include C / C++ models, VHDL, SystemC, SystemVerilog transaction level models, Simulink, and MATLAB. The creation of the IC design can include layout design, simulation, emulation, and / or verification. The IC specification is then converted to a register transfer level (RTL) description. The RTL describes the exact behavior of the digital circuit on the IC, as well as the interconnections to inputs and outputs. Then, in step S71, a circuit design can be created by digital design synthesis. Thus, a physical IC design can be obtained. This step takes the RTL and available logic gate libraries (standard cell libraries) and creates a physical IC design. Layout design and floor planning is then done using, e.g., an IC layout editor.

[0066] Then, in step S72, physical verification can be performed. Based on the physical IC design, masks can be prepared in order to manufacture one or more wafers in step S73.

[0067] Figure 12Exemplary method steps according to an embodiment are shown. In a first step S1, a structural analysis is performed on one or more subparts of a first group of the IC. In a second step S2, at least one constraint is determined, which limits the input of a second group of subparts to allowed values. Additionally or alternatively, at least one constraint is determined, which limits one or more outputs of the first group to allowed values. Therein, the one or more outputs of the first group can serve as input for one or more subparts of the second group of the IC. In a third step S3, a formal property verification is performed on the second group of the IC based on the at least one constraint. Thus, a hybrid approach for verifying functional safety of an integrated circuit is proposed, comprising a structural analysis and a property verification. It is to be understood that of course one or more constraints (for the input of the second group and / or the output of the first group) can be determined first and the structural analysis and the formal property check are performed subsequently as appropriate.

[0068] The allowed values can be given by one or more constraints, which specify that the values shall be within a certain range or interval. A constraint is a rule imposed on a property for specifying how the property shall be used. As discussed herein, the allowed values can specify that the inputs of the third part are the same (equal) or different (unequal). The constraint definition can comprise two or three expressions separated by one of the relational operators. Thus, for example, the one or more constraints can comprise a relational operator between the inputs of the third subpart and / or an upper bound and / or a lower bound. However, the upper bound and / or the lower bound can be omitted.

[0069] Referring to Figure 13 Exemplary method steps according to an embodiment are shown. In a first step S1, a structural analysis is performed on one or more subparts of a first group of the IC. In a step S4 (which can be part of step S1), a fault path coverage of one or more outputs of the first group can be determined. Thereby it is ensured that all faults (in the first group of subparts) propagate to the outputs of the first group of subparts. Thereby it can also be ensured that all faults are present at the inputs of the second group of subparts. As a result, the verification of the IC (e.g. IC design and / or IC model) can be split into a verification of the first group of subparts and a verification of the second group of subparts.

[0070] In Figure 14 Exemplary method steps according to an embodiment are shown. In a step S1, a structural analysis is performed on one or more subparts of a first group of the IC. In a subsequent step S3, a formal property verification is performed on a second group of subparts of the IC based on at least one constraint. In a subsequent step S5, the functional safety of the first group and the second group of the IC is determined based on the structural analysis and the formal property check.

[0071] In Figure 15Further exemplary steps are shown in. In step S1, a structural analysis is performed on one or more subparts of the first group of the IC. For this, the structural analysis can comprise step S6, in which it is determined whether all fault paths are able to propagate to the output of the first group, and / or it is determined that no fault path is able to escape the first group, and / or it is determined that all fault paths are only able to propagate to the output of the first group.

[0072] Turning to Figure 16 Further method steps are shown in. In step S7, a structural analysis is performed on a first subpart and a second subpart of the first group of the IC. Additionally, a fault path coverage of one or more outputs of the first subpart and / or the second subpart can be determined in step S8.

[0073] Figure 17 Further steps are shown in. In step S9, an IC is identified or determined that comprises an expected functionality implemented by a first subpart of the IC. In step S10, a safety mechanism is identified or determined for an expected functionality implemented by a second subpart of the IC. In step S11, at least one comparator is identified or determined that is implemented by a third subpart of a second group of the IC. As described herein, the IC can comprise such subparts in the IC design, for example. These subparts can be identified or determined automatically and / or by a user. For this, an IC model can be created that maps to the IC design, or vice versa.

[0074] Referring to Figure 18 In step S18, the first subpart and the second subpart can be configured to obtain inputs and / or input values, which are preferably identical. In step S13, the first subpart can be configured to output a primary output. In step S14, the second subpart can be configured to output a secondary output. In step S15, the third subpart can be configured to obtain the primary output and / or the secondary output, and / or the third subpart can be configured to compare the primary output with the secondary output in order to determine the functional safety of the first subpart and / or the second subpart. Thus, the third subpart can be configured to compare signals present at its inputs. Thus, the third subpart can be configured to obtain the primary output and / or the secondary output at one or more of its inputs.

[0075] In Figure 19Further steps are shown in Fig. 2. In step S16, a model of the IC is determined, which model preferably comprises the first set of subparts and the second set of subparts. In step S17, at least a part of the IC design is mapped to the IC model, or an IC model representing the IC design can be created and / or mapped to the IC design. In step S18, the output of the first subpart and the output of the second subpart are mapped from the IC design to the IC model. Additionally or alternatively, the input of the third subpart in the IC design is mapped to the IC model, or vice versa. Thus, a correspondence between the IC model and the subparts in the IC design is obtained. That is, the subparts can thus only be visible as functional parts or elements of the IC model, whereas in the IC design, the subparts are identified by corresponding logic elements (e.g. of a register transfer level). The subparts can be identified based on critical signals in the IC design and / or the IC model. Thus, for this purpose, the IC design is divided into subparts, which subparts are presented as functional elements in the IC model. These functional elements can correspond to intended functionality and / or safety mechanisms.

[0076] In any case, based on the division and / or identification of the subparts of the first set and / or the second set, different verification techniques can be applied to the subparts of the first set and / or the second set. For this purpose, a cut-off between the subparts of the first set and / or the second set can be determined. Then, different verification techniques can be applied (e.g. sequentially) to the subparts of the first set and / or the second set. These verification techniques can then be combined in order to verify the IC, e.g. the IC design and / or the IC model.

[0077] Referring to Figure 20 For example, the step S1 of performing a structural analysis of the first subpart and / or the second subpart of the first set of subparts of the IC can comprise a step S19 of performing an influence cone analysis. The influence cone analysis can be used to determine whether one or more faults are located on a path from an input to an output of the first subpart and / or the second subpart.

[0078] Referring to Figure 21 For example, the step S1 of performing a structural analysis of the first subpart and / or the second subpart of the first set of subparts of the IC can comprise a step S19 of performing an influence cone analysis. In step S21, the influence cone analysis can be used to determine whether one or more faults are located on a path from an input to an output of the first subpart and / or the second subpart.

[0079] Referring to Figure 22For example, the step S1 of performing structural analysis on the first subpart and / or the second subpart of the first group of subparts of the IC can comprise performing a step S19 of performing an influence cone analysis. As part of or as a result of the influence cone analysis, it can be determined in a step S22 whether one or more faults have a path to one or more logic elements outside the first subpart and / or the second subpart without passing through an output of the first subpart and / or the second subpart.

[0080] Figure 23 Further steps are shown. For example, the step S1 of performing structural analysis on the first subpart and / or the second subpart of the first group of subparts of the IC can comprise performing a step S19 of performing an influence cone analysis. In a step S23, as part of or as a result of the influence cone analysis, it can be determined whether there is one or more paths of one or more faults to one or more logic elements outside the first subpart and / or the second subpart without passing through one or more inputs of the first subpart and / or the second subpart.

[0081] Turning to Figure 24 In a step S24, the input of the third subpart, which is preferably operating as and / or configured to receive the output of the first subpart and the second subpart, is set to be equal based on the first constraints. As described herein, the input of the third subpart and / or the output of the first subpart and the second subpart can be used as a cutpoint. The input of the third subpart is then modelled and / or its allowed values are expressed as constraints. These constraints can be input to a formal property check (checker). Thus, in a step S25, a first assertion is created based on the first constraints. It can then be determined based on the first assertion whether a fault in the second group is detected. In a step S26, a formal property check or verification is performed on the second group of the IC based on the at least one first constraint and / or the first assertion.

[0082] Now turning to Figure 25 In a step S27, the input of the third subpart, which is preferably operating as and / or configured to receive the output of the first subpart and the second subpart, is set to be unequal based on the second constraints. In a step S28, a second assertion is created based on the second constraints. It can then be determined based on the second assertion whether the second group is functionally correct and / or whether a fault in the first group (e.g. the first subpart and / or the second subpart) is detected. Thus, in a step S29, a formal property check or verification is performed on the second group of the IC based on the at least one second constraint and / or the second assertion.

[0083] Thus, by disconnecting or cutting the connection between the first set of subparts and the second set of subparts and constraining the inputs of the second set, different verification techniques can be employed. Thus, the inputs of the second set can be constrained to be false (first constraint), i.e. the inputs (of the third subpart, for example) are not equal. Further, the inputs of the second set can also be constrained to be true (second constraint), i.e. the inputs (of the third subpart, for example) are equal. Thus, a first assertion can be determined based on the first constraint and / or it can be determined whether the first assertion holds. Further, a second assertion can be determined based on the second constraint and / or it can be determined whether the second assertion holds.

[0084] As a result of the formal property checking, one or more properties are satisfied or violated. The IC (e.g. the IC design and / or the IC model) can be debugged accordingly (in which case the method steps herein can need to be repeated), or the IC design can continue to the next production stage.

[0085] Now turning to Figure 26 In step S30, a formal property verification is performed on the second set of the IC based on at least one of the first constraint and the first assertion and / or based on at least one of the second constraint and the second assertion. Therein, the formal property verification on the second set of the IC can be performed in step S31, wherein one or more inputs of the second set are disconnected from one or more outputs of the first set, i.e. cut off.

[0086] Thus, it is proposed to cut off the connection between the first set of subparts and the second set of subparts and to constrain the inputs of the second set. Therein, the inputs of the second set can be constrained to be false and / or can not be constrained to be false. Then, a first assertion can be created based on the first constraint and / or it can be determined whether the first assertion holds. The same applies to a second assertion that can be created based on the second constraint and / or it can be determined whether the second assertion holds.

[0087] Turning to Figure 27 In step S32, the IC design can be adjusted based on the results of the functional verification. In step S33, the IC design can be synthesized into a hardware implementation. And in step S34, a semiconductor material can be processed according to the hardware implementation. The steps of combining Figure 11 The other steps described can be performed in order to manufacture the IC and / or to control its manufacture.

Claims

1. A method for verifying the functional safety of an integrated circuit (10), IC, comprising the steps of: performing a structural analysis of one or more subparts (11, 12) of a first group (1) of the IC (10) in order to determine a fault path coverage of one or more outputs (01, 02) of the first group; determining at least one constraint (20, 21) that limits one or more inputs (I31, I32) of a subpart of a second group to allowed values, wherein the one or more outputs (01, 02) of the first group are inputs (I3) of one or more subparts (13) of the second group (2) of the IC; and performing a formal property verification of the second group (2) of the IC (10) based on the at least one constraint (20, 21).

2. The method of the preceding claim, further comprising: determining the functional safety of the first and second groups (1, 2) of the IC (10) based on the structural analysis and formal property check.

3. The method according to any of the preceding claims, wherein, The step of performing a structural analysis of the first group (1) comprises determining whether all fault paths (40) are able to propagate to the outputs of the first group (1) and / or determining that no fault path (40) is able to escape the first group (1) and / or determining that all fault paths (40) are only able to propagate to the outputs of the first group.

4. The method according to any of the preceding claims, further comprising the step of: performing a structural analysis of a first subpart (11) and a second subpart (12) of the first group (1) of the IC (10) in order to determine a fault path coverage of one or more outputs (01, 02) of the first subpart (11) and the second subpart (12).

5. The method according to any one of the preceding claims, the IC (10) comprising an intended functionality implemented by the first subpart (11) and a safety mechanism for the intended functionality implemented by the second subpart (12); and / or the IC comprises at least one comparator implemented by a third subpart (13) of the second group (2); wherein the first subpart (11) and the second subpart (12) are configured to obtain input values (II, 12) that are preferably identical; the first subpart (11) is configured to output a primary output (01); the second subpart (12) is configured to output a secondary output (02); the third subpart (13) is configured to compare the primary output (01) with the secondary output (02) in order to determine the functional safety of the first subpart (11) and / or the second subpart (12), i.e. the functional safety of the first group (1).

6. The method according to any of the preceding claims, further comprising the step of: determining a model (50) of the IC (10), the model (50) comprising a representation of the first group (1) and the second group (2).

7. The method according to any of the preceding claims, further comprising the step of: mapping at least a part of an IC design (60), e.g. in the form of a register transfer level description and / or a gate level, e.g. a netlist, to an IC model (50) of preferably a higher abstraction level, e.g. as the IC design.

8. The method according to any of the preceding claims, mapping the output (01) of the first subpart (11) and the output (02) of the second subpart (12) and / or one or more inputs (I31, I32) of the third subpart (13), preferably in the form of bits, states, ports, signals, nets, gates and / or cells, from the IC design (60) to the IC model (50) or vice versa.

9. The method of any of the preceding claims, wherein, Performing the structural analysis comprises performing an influence cone analysis in order to determine whether one or more faults are located on a path (40) of the output of the first subpart (11) and / or of the second subpart (12).

10. The method of any of the preceding claims, wherein, Performing the structural analysis comprises performing an influence cone analysis in order to determine whether one or more faults are located on a path (40) from the input (11, 12) to the output (01, 02) of the first subpart (11) and / or of the second subpart (12).

11. The method of any of the preceding claims, wherein, Performing the structural analysis comprises performing an influence cone analysis in order to determine whether one or more faults have a path (40) to one or more logic elements (41) outside the first and / or the second subpart (11, 12) while the path does not pass through the output (01, 02) of the first and / or the second subpart (11, 12).

12. The method of any of the preceding claims, wherein, Performing the structural analysis comprises performing an influence cone analysis in order to determine whether there is one or more path (40) of one or more faults to one or more logic elements (42) outside the first and / or the second subpart (11, 12) which does not pass through one or more inputs of the first and / or the second subpart (11, 12).

13. The method according to any of the preceding claims, setting one or more outputs (01) of the first subpart (11) equal to one or more outputs (02) of the second subpart (12) based on a first constraint (20).

14. The method according to any one of the preceding claims, creating a first assertion (30) based on the first constraint (20) and / or determining based on the first constraint whether the second set, e.g. the third sub-portion, is functionally correct and / or determining based on the first assertion (20) that the third sub-portion does not raise an alarm, wherein, The first constraint and / or assertion indicates a faultless scenario.

15. The method according to any of the preceding claims, setting one or more outputs (01) of the first subpart (11) not equal to one or more outputs (02) of the second subpart (12) based on a second constraint (21).

16. The method according to any one of the preceding claims, creating a second assertion (31) based on the second constraint (21) and / or determining based on the second constraint whether the second set, e.g. the third subpart, is functionally correct and / or determining based on the second assertion (31) that the third subpart raises an alarm, wherein, The second constraint and / or assertion indicates a faulty scenario.

17. The method according to any of the preceding claims, performing a formal property verification of the second group (2) of the IC (10) based on at least one of the first constraint (20) and the first assertion (30) and / or based on at least one of the second constraint (21) and the second assertion (31), e.g. by a formal verification tool.

18. The method according to any of the preceding claims, performing formal property verification on the second group (2) of ICs (10), wherein, One or more inputs (13) of the second group (2) are disconnected from one or more outputs of the first group (1).

19. The method according to any of the preceding claims, adjusting the IC design (60) based on the results of the formal property check and / or the functional verification.

20. The method according to any of the preceding claims, synthesizing the IC design (50) into a hardware implementation, e.g. in the form of a hardware implementation file, e.g. for ASIC and / or FPGA.

21. The method according to any of the preceding claims, processing semiconductor material according to the hardware implementation.

22. A computer program, preferably stored on a non-transitory medium, comprising program code which, when executed, performs the steps of the method according to any of the preceding claims.

23. An apparatus, preferably comprising a processor and a memory, operative to perform the steps of the method according to any of the preceding claims 1-21.

Images