Verifying functional safety of an integrated circuit

Abstract

A method for verifying functional safety of an integrated circuit (10), IC, comprising the steps of: performing a structural analysis of a first set (1) of one or more sub-parts (11, 12) of the IC (10) in order to determine a fault path coverage of one or more outputs (01, 02) of the first set, determining at least one constraint (20, 21) that bounds the one or more inputs (131, 132) of a second set of subparts to permissible values, wherein the one or more outputs (01, 02) of the first set serve as input (13) of the second set (2) of one or more subparts (13) of the IC, and performing a formal property verification of the second set (2) of the IC (10) based on the at least one constraint (20, 21).

Description

[0001] Description

[0002] TITLE

[0003] Verifying functional safety of an integrated circuit

[0004] TECHNICAL FIELD

[0005] The present disclosure relates to the field of integrated circuits and the verification of the same. More particularly the present disclosure relates to the analysis of integrated circuits, e.g., to defect detection and / or fault propagation in an integrated circuit.

[0006] BACKGROUND

[0007] The use of complex integrated circuits, ICs, in safety- critical systems is now commonplace throughout many 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 to a set of requirements. Moreover, to improve the safe operation of these systems, safety mechanisms or redundancy are integrated that ensure a reliable, deterministic reaction to random hardware faults when the device is operating in the field. In particular the automotive market, governed by the ISO 26262 standard, demands a particularly rigorous development methodology. This includes requirements tracing from specification to verification and coverage, analysis of failure modes, and risk assessment and / or mitigation techniques.

[0008] 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 for verifying the correctness of an IC design using mathematical techniques .

[0009] During formal verification, a model of the IC is created in a hardware description language, HDL, that specifies the de- sired 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 behaves as expected .

[0010] When veri fying a system, one needs to analyze all possible states and transitions to ensure that the system behaves as expected . However, as the number of components , variables , and possible interactions between them increases , the number of possible states grows exponentially, making it impractical or even impossible to veri fy the system exhaustively .

[0011] In formal veri fication, the state explosion problem refers to the exponential growth in the number of states that need to be examined as the si ze and complexity of a system being verified increases . 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 signi ficant challenge in formal veri fication, and various techniques have been developed to address it . Some of these techniques include abstraction, model checking, and theorem proving . These approaches allow veri fication engineers to reason about the system ' s behavior using simpli fied models or by analyzing speci fic properties of the system . However, even with these techniques , the state explosion problem remains a signi ficant challenge in formal veri fication .

[0012] Patent application publication US 2021064810 Al describes a method to perform hardware safety analysis without fault simulation . Hitherto , a safety-speci fic design structural analysis and cone of influence ( COI ) that does not require fault simulation is proposed .

[0013] An exhaustive description of problems and techniques currently employed when veri fying integrated circuits and their proper functioning in particular with respect to safety- related electric and / or electronic systems is provided in patent application publication US 2018 / 364298 Al . SUMMARY

[0014] Hence , in general , it is tedious to prepare , and inj ect faults in order to veri fy the proper functioning of an integrated circuit , either by emulation or by simulation . In addition, the analysis of the faults ' ef fects is cumbersome . In particular with respect to safety-related functions , it must be ensured that the fault inj ection covers the necessary range within the IC and / or comprises all of the fault types that may occur . Furthermore , the necessary fault inj ection points and or a segmentation of the IC needs to be determined . It is thus a desire to increase the fault coverage , to speed up veri fication time and to allow for a locali zation of faults .

[0015] According to a first aspect a, preferably computer- implemented, method for veri fying functional safety of an integrated circuit , IC, is proposed . The method comprising the step of 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 comprising determining at least one constraint that bounds the one or more outputs of the first set to permissible values , wherein the one or more outputs of the first set serve as input of a second set of one or more subparts of the IC . The method further comprising performing a formal property veri fication of the second set of the IC based on the at least one constraint .

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

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

[0018] Figure 1 shows an illustration of an integrated circuit .

[0019] Figure 2 illustrates a dual-core lockstep comparator and recovery .

[0020] Figure 3 illustrates a general safety critical system having a hardware safety mechanism .

[0021] Figure 4 illustrates another safety critical system having a hardware safety mechanism .

[0022] Figure 5 illustrates a structural analysis of a subpart .

[0023] Figure 6 illustrates another safety critical system .

[0024] Figure 7 illustrates a mapping of an IC design to an IC model .

[0025] Figure 8 illustrates a combination of formal property checking with a structural analysis based on cut-of fs .

[0026] Figure 9 shows exemplary constraints and assertions for a safety mechanism .

[0027] Figure 10 illustrates a system architecture diagram of a system for veri fying an integrated circuit .

[0028] Figure 11 illustrates exemplary steps during the design and production of an integrated circuit .

[0029] Figures 12 to 27 show exemplary method steps .

[0030] DETAILED DESCRIPTION

[0031] Figure 1 shows an illustration of an integrated circuit 10 .

[0032] An integrated circuit , IC, 10 also referred to as a chip, or a microchip is a set of electronic circuits on a piece of semiconductor material , usually silicon . Large numbers of miniaturized transistors and other electronic components that perform logic operations and are referred to as logic elements are integrated together on the chip. An integrated circuit or an IC is a semiconductor hardware on which electric circuits are mounted.

[0033] An integrated circuit and / or an IC design can be considered as a hardware component, having a plurality of subparts. The subparts may be grouped into safety mechanism and intended functionality where two such groups may form a safety feature. The subparts themselves may comprise one or more blocks or cells that perform (specific) sub-functions. For example, in an IC, there may be blocks for arithmetic and logic operations, memory access, input / output (I / O) control, and clock generation. These blocks work together to perform the overall function of the integrated circuit. The blocks may themselves (and hence the subpart (s) ) comprise one or more logic elements such as one or more bits, states, ports, signals, wires, gates, e.g., in a hardware description language, HDL . One or more gates may form a so-called cell. On register transfer level, RTL, the terms states and / or bits may be used to describe the IC and / or its logic elements. On the logic- gate-level, functions are implemented in the form of gates and / or cells. In VHDL the term signal (s) is used, whereas in Verilog the term wire(s) is used for describing the IC, logic element (s) , block (s) , and / or subpart (s) .

[0034] 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 that it meets the specifications. Safety verification, on the other hand, is the process of verifying that a system or component is safe to use. This includes verifying that the system or component meets safety requirements and that it does not pose any safety risks to the user or the environment, e.g., when random faults occur. While functional verification focuses on the correct behavior of a system, safety verification serves for identifying and / or mitigating random faults in order to avoid failures. Thus, verification of the safety mechanism mitigates random faults in order to avoid random failures. Safety verification often involves rigorous testing and analysis to identify potential safety risks and to verify that the system or component is safe to use under all expected conditions.

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

[0036] Figure 2 illustrates a dual-core 11, 12 lockstep comparator 13 and / or recovery 13a. Safety-related and thus critical functions, e.g., in the automotive industry, often feature dual-core lockstep architectures. This is a technique to prevent uncontrolled failures. The two cores operate on the same input (stimuli) , denoted as core input in Figure 2, though there might be a delay 12a of a few clock cycles to achieve temporal diversity and reduce the risk of faults causing the same effects on both cores 11, 12. The cores 11, 12 may be implemented on a single IC and / or may form a first and a second subpart of the IC. A comparator 13, comprising logic elements, and also implemented on the IC, realigns the outputs of the two cores and raises an alarm should they be different. The comparator 13 may be understood as a third subpart and / or may be verified using formal verification, as proposed 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, formal connectivity checking may be used to verify that the appropriate outputs of the first and second subpart 11, 12, along with reset, clock, and / or other system-level control signals, are correctly wired to the comparator 13 inputs, while the comparator 13 alarm output is correctly wired to the safety control unit and / or fault logging registers. In case of an alarm, it may not be possible to know i f one of the subparts 11 , 12 , 13 , in particular the cores / subparts 11 , 12 , still operates correctly . A signi ficantly more complex module that can log error information, test the two cores , and multiplex 13b their outputs , could improve system availability . In case of an alarm, the recovery module 13a could select and / or run appropriate tests . I f the results identi fy a core as free from faults , the recovery module 13a can select its outputs in the multiplexer 13b and allow the system to continue operation, or at least to complete the execution of an ongoing critical program .

[0037] The veri fication of the comparator 13 , recovery module 13a and / or multiplexer 13b is a critical task, and in particular safety related and / or safety critical . All possible sequences of recovery actions must be fully speci fied and veri fied . OneSpin' s Operational SVA developed may be used to capture the operations of the recovery module in a concise , elegant way . Operational SVA leverages a library of standard Sys- temVerilog properties and sequences that , among other things , enable the use of high-level timing conditions .

[0038] The second subpart / core 12 and the comparatorl 3 , recovery module 13a and / or multiplexer 13b may be form a (hardware ) safety mechanism for the first subpart / core 11 .

[0039] Figure 3 illustrates a general safety critical system 10 having a (hardware ) safety mechanism . Safety mechanisms are a class of safety measures built into the system, intended to detect faults or control failures . ISO 26262 may require the use of safety mechanisms to detect , and possibly correct , the ef fects of one or more random hardware faults . Safety mechanisms may be implemented in both software and / or hardware , and their ultimate goal is to reduce the occurrence of random failures that could lead to violations of safety goals .

[0040] A fault is an incorrect logical value that appears on some logical element in an IC, or in the IC design either momen- tarily, due to, e.g., being hit by a high-energetic particle, or permanently, due to, e.g., material decay or permanent damage to the circuitry. Such faults can potentially alter the behavior of the electronic system. These faults can in safety critical systems lead to death, injury, or high economical losses. In any case, a fault may be understood as defined in ISO 26262-1:2018 as an abnormal condition that can cause an element or an item to fail. Similarly, an error may be defined as a discrepancy between a computed, observed or measured value or condition, and the true, specified or theoretically correct value or condition. Thus, an error can arise as a result of a fault within the system or component being considered.

[0041] For example, fault propagation analysis may be used to classify faults. The fault propagation may be performed on a IC design, e.g., on the register transfer level, of the IC but, for example according to ISO 26262 stipulations, will ultimately have to be performed on an IC model that is as close as possible to the actual hardware and that can provide good correlation not only at the logical level, but also on physical parameters, such as circuit area. Fault propagation analysis may comprise the injection of faults, e.g., into the gate level models of integrated circuits, during verification to prove that faults will be detected by a safety mechanism. These gate level models can be complex and contain numerous possible fault scenarios. In order to satisfy hardware safety goals, the number of "dangerous non-detected" faults must be minimized. Faults can be classified as propagatable and non- propagatable . Non-propagatable faults can never lead to a malfunction of the system regardless of its state. Hence, such faults are safe and can be removed from the dangerous fault list, improving the fault metric.

[0042] In the context of semiconductors, "fault path" 40 typically refers to a path through the semiconductor device, i.e., IC, that allows current to flow where it shouldn't, leading to incorrect or unintended behavior of the device. A fault path 40 can occur due to a variety of reasons, such as defects in the manufacturing process, damage to the device during use or random faults as described herein.

[0043] In semiconductor design and verification, fault path coverage refers to the degree to which a set of tests is able to detect such fault paths. It is a measure of the effectiveness of the testing process in identifying and correcting faults in a subpart. High fault path coverage is desirable as it indicates that the testing process is able to detect a large number of faults, reducing the likelihood of faulty IC designs .

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

[0045] Figure 4 illustrates another (hardware) safety mechanism.

[0046] Here, the IC 10 comprises a first subpart 11 for executing an intended function or functionality. The IC 10 may comprise a second subpart 12 for performing (at least part of) a safety mechanism for the intended functionality. The first and the second subpart 11, 12 may thus form a first set 1 of subparts .

[0047] The IC 10 may further comprise at least one third subpart 13, e.g., at least one comparator. The IC may comprise further subparts such as the recovery and / or multiplexer as described in Figure 2. Hence, the IC may comprise a second set of subparts 13, 13a, 13b.

[0048] The first subpart 11 and the second subpart 12 may be configured to obtain, preferably the same, inputs or input values II, 12. The first subpart 11 may further be configured to output a primary output 01 and / or corresponding output val- ues. Similarly, the second subpart 12 may be configured to output secondary output 02, the third subpart 13 may be configured to compare the primary output 01 and the secondary output 02 and / or the respective values in order to determine functional safety of the first subpart 11 and / or second subpart 12, i.e., first set 1. To that end, the third subpart 13 may comprise and / or obtain input (s) 131, 132 or input value (s) 13. The third subpart 12 may then output a diagnostic signal, such as an alarm or alert, in general, e.g., in case the input (s) or input value (s) deviate, i.e., do not match. As shown the hardware safety mechanism comprises the second subpart and the third subpart. Each one or more of the inputs II, 12, 131, 132, 13 and / or outputs 01, 02, 03 may be provided in the form of bitlists.

[0049] As the case may be, the IC 10, e.g., in the IC design and / or IC model, may comprise an intended functionality implemented by the first subpart 11 and a safety mechanism for the intended functionality implemented by the second subpart 12. The safety mechanism for the intended functionality may also be implemented by second subpart 12 and the third subpart 13.

[0050] Figure 5 illustrates a structural analysis of a subpart. Cone of influence analysis is a structural analysis method for analyzing the design of an IC. The idea is to take only those parts of the IC into consideration that are relevant to a specific function. When considering an IC design at the register-transfer or gate level (netlist) , and a signal in the design, the cone of influence of a signal is the set of all signals as well as modules and / or gates the considered signal depends on. These components can be obtained by a backward traversal starting from the signal. This process is also referred to as transitive fan-in analysis.

[0051] While in the example shown in Fig. 5 only a single TO element 44 is shown, more than one TO element may be present. A transitive fanin cone of influence may be determined from the TO element. A logic element such said TO element may include, for example, one or more bits, states, ports, signals, wires, gates or cells.

[0052] A second cone of influence is a transitive fanout cone of influence of FROM element 43. This second cone of influence, i.e., the transitive fanout, overlays the first cone of influence. The intersection of these two cones of influence provides a precisely defined subpart or set of logic elements between the input and the output of a subpart of the IC.

[0053] Thereupon, one or more logic elements which are in the direct fanout of the subpart and are not the TO element 44 or direct fanout of TO element 44 are identified. These read elements 41 are elements that are not in the sub-part but read other elements in the sub-part. These read elements 41 are for example not protected by a safety mechanism.

[0054] The subpart 11, 12 may also contain potential residual logic elements 42, that may influence and / or control one or more logic elements of the subpart. The logic element 42 that writes to logic elements in the subpart can be referred to as a "write bit". These write bits 42 are in the direct fanin of a logic element of the subpart.

[0055] Hence, based upon such structural analysis, e.g., cone of influence analysis the first subpart may be analyzed. In any case the subpart may be the first subpart and / or the second subpart or another subpart of the first set of subparts of the IC. Hence, only faults that structurally propagate to at least one TO element need to be included in the faults list (to be verified) . The first and / or the second subpart may be defined as the set of logic elements between the input and the output of the subpart, for example between input II and output 01 or input 12 and output 02, respectively. Hence, the input of a subpart may be given by the FROM element and the output may be given by the TO element. Structural analysis based on COI (Cone of Influence) may be used to determine one or more faults. Structural analysis may be used to classify one or more faults, i.e., whether or not they are on a path from FROM element to a TO element and preferably can be classified based accordingly, e.g., as a safe fault.

[0056] Figure 6 illustrates another safety critical system. In addition to the illustration of Figure 4 logic elements of the first subpart and of the third subpart are shown. A logic element 70 of the IC that bypasses the safety mechanism, denoted as SM bypass 0, is illustrated. Furthermore, a logic element 71 of the IC that controls the safety mechanism but that it not part of the safety mechanism is illustrated, and denoted SM control 71, in Figure 6.

[0057] Figure 7 illustrates a mapping of an IC design to an IC model. Here, the IC design 60 is given on Register Transfer Level, RTL. An HDL may be used to that end. Then an IC model for modelling the functionality of the IC, e.g., at system-level, may be determined. Thereby a first subpart, a second subpart and a third subpart may be identified. This mapping may be performed in an automated manner based on the IC design. To that end, a bitlist of the IC model may be mapped 80, 81, 82, 83, 84 to a signal in the IC design, or vice versa. The IC design 60 may comprise a first subpart, also denoted as primary in Figure 7, a second subpart, also denoted as secondary in Figure 7, and a third subpart, e.g., comprising delay elements and XOR logic element (serving as a comparator) as shown in Figure 7. The third subpart in the IC design may comprise delay elements and a logic element in the form of an XOR gate that compares the output of the first subpart and the output of the second subpart (which serve as input to the third subpart) . Again, the IC design may comprise further logic elements and / or subparts not shown. These logic elements or subparts may influence the behavior of the first, second and / or third subparts and / or the logic elements there- in. For example, a fault may propagate from or to these subparts .

[0058] Now, given the IC design 60, the first, second and / or third subpart may be identified in the IC design. For example, the input of the IC design may be mapped 80 to the input of the IC model 50. Furthermore, the output of the first subpart in the IC design may be mapped 81 to the output of the first subpart in the IC model. The same applies to the output of the second subpart and the output of the third subpart which are mapped 81 ,82, 83 to the IC model 50. Instead or additionally, the input (s) of the third subpart in the IC design may be mapped to the input (s) of the third subpart in the IC model. These elements and / or signals in the IC design may be represented as one or more bitlists in the IC model.

[0059] For example, a, e.g., safety aware, partitioning of the IC design and / or IC model may be performed. That is, the logic elements in the IC design may be mapped to intented function and / or safety mechanism in the IC model, or vice versa. This may be automated through one or more software tools such as OneSpin' s Fault Contribution Analysis (FCA) App . To that end, IC design subparts may be associated with IC model subparts, which are, e.g., delimited by key design signals, including protected outputs of the intended function, and diagnostic outputs of the safety mechanism.

[0060] Thus, the one or more IC signals and / or logic elements in the IC design may either be automatically detected based on above mentioned partitioning or may be selected, e.g., by a user. The one or more IC signals and / or logic elements in the IC design may be represented for example by one or more bitlists in the IC model. As a result, an IC model 50 may be obtained that represents the IC design on a higher abstraction level, i.e., system-level or functional-level. For example, an RTL component be converted into a SystemC model using VtoC or Verilator. The other way around, High Level Synthesis can be used to convert an IC model, e.g., in C or C++, of a subpart or component into an RTL implementation. In general, EDA tools and languages, such as SystemC, may be used to model the IC at other levels of abstraction.

[0061] Now turning to Figure 8, a combination of safety mechanism with formal property checking is described. As before, the IC is partitioned into subparts. Thereupon, one or more cut-offs are determined in order to separate the structural analysis from the formal property check. That is to say, the one or more cut-offs determine the subparts of the IC for which a structural analysis shall be performed and the subparts for which a formal property check shall be performed. Again, the cut-offs may be determined, for example automatically, e.g., as the output (signals and / or logic elements) of the first and / or second subpart. Instead, the cut-offs may be determined as the input (s) of the third subpart. That is, the input (s) of the third subpart are used as cut-off (s) . Thus, based on the IC model one or more cut-offs are determined in order to determine the subparts for which a structural analysis shall be performed and for which a formal verification, e.g., in the form of a formal property check shall be performed .

[0062] Thereupon, a structural analysis of these one or more subparts of the first set of subparts may be performed. The structural analysis may be a cone of influence analysis as described herein. The structural analysis may determine that there is no overlap amongst subparts, that there are no escape paths (bypassing the third subpart, e.g., said comparator) , and / or that there are no unknown control signals (possible influencing the intended functionality and / or the safety mechanism in the first and / or second subpart) . Thus, the structural analysis determines that when a fault propagates (through the first and / or second subpart) it must cause an error scenario. That is to say, a fault (in the first set of subparts) will propagate to the input (s) of the third subpart. This input (s) may coincide with the cut-off (s) . To put it differently, a fault (in the first set of subparts) will propagate to the output of the first and / or second subpart. These outputs may again coincide with the cut-offs. Since, it is now determined that all faults necessarily propagate to the input (s) of the third subpart (or to the outputs of the first and second subpart, respectively) , these input (s) (or outputs, as the case may be) can be used as one or more cutoffs for the remaining subparts of the IC, e.g., for the one or more subparts in a second set of subparts. In the case at hand, the third subpart which implements a comparator for comparing its inputs, as e.g., obtained from first and second subpart, is then verified by performing a formal property check. In any case, one or more further subparts may be comprised in the remaining subparts and may form a second set of subparts of the IC that are cut of from a first set of subparts. The second set may comprise additional subparts, for example such as described herein, e.g., one or more delay elements, a recovery module and / or a multiplexer.

[0063] Thus, based on the one or more cut-offs one or more IC signals and / or logic elements in the IC design and / or IC model may be determined. As mentioned, these IC signals and / or logic elements may be given in the form of one or more bitlists. The one or more cut-offs may also be understood as error scenario constraints. Based on these error scenario constraints properties for the formal property check or verification may be determined for the outputs 01, 02 of the first and the second subpart and / or the input (s) 131, 132 of the third subpart. That is, the third subpart, i.e., the comparator in this case, should generate a diagnostic output, e.g., signifying an error, in case its inputs (possibly corresponding to the output of the first subpart and the second subpart, respectively) are unequal. Similarly, the third subpart, i.e., the comparator in this case, should generate a diagnostic output, e.g., signifying an error free state, in case its inputs (corresponding to the output of the first subpart and the second subpart, respectively) are equal. The respective constraints 20, 21 and assertions 30, 31 for the outputs 01, 02 of the first and second subpart are illustrated in Figure 9. Instead or additionally, the constraints 20, 21 may be applied to the input (s) 131, 132 of the third subpart, i.e., the constraints may read I31==I32 and / or I31!=I32.

[0064] In any case, the one or more constraints can also consider the outputs of the first set of subparts and constrain the inputs of the second set (i.e. after the partitioning and / or after cut-off) , e.g., not only for the lockstep as, e.g., described in connection with Figures 2, 3 and / or 4, but for another saf ety-mechanism ( s ) or even another intended functionality which is implemented by the second set of subparts.

[0065] 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 satisfies certain requirements or specifications .

[0066] 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 typically expressed in terms of predicates, which are logical expressions that evaluate to either 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.

[0067] 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 an assertion fails, it indicates a flaw in the IC model and / or IC design that must be fixed.

[0068] As mentioned, the one or more constraints and / assertions may be determined based on the one or more cut-offs. The constraints may be asserted by performing a formal property check or verification. This formal property check or verification then checks the third subpart or any number of subparts of a second set. To that end, a plurality of software tools such as Oncespin' s DV-verify may be used. The formal property check provides a proof and / or can demonstrate the absence of bugs in the IC, e.g., IC design and / or IC model. To that end, a formal property check may be performed on the IC design's (more particularly, the third subpart's) RTL code given the one or more constraints and / or assertions.

[0069] As a result of the formal property check the property is satisfied if the formal property check proves that the third subpart satisfies the property under consideration. Then it can be concluded that the IC, e.g. design or model, is correct with respect to that property. Alternatively, a property violation may be determined if the formal property check finds a counterexample that violates the property. This indicates a problem with the IC, e.g. IC design or IC model, that needs to be addressed. In that case, a software tool for highlighting and / or displaying problem states may be used. In case of a failing check, the software tool reports a violation, and may generate a trace for debugging that reveals the source of the problem. The generated trace may start with an active reset and / or may lead to the violation, and may thus demonstrate the presence of an RTL issue. Failing checks can intuitively be analyzed in the OneSpin' s integrated debugging environment. Color coding, active code annotation, active driver and load tracing, and dynamic synchronization between source code and waveform viewers, enable users to quickly identify the root cause of the issue and fix the IC design. Furthermore, the result of the formal property check may be inconclusive, i.e., the verification tool cannot prove or disprove the property.

[0070] Figure 10 illustrates a computer system architecture for verifying an integrated circuit, e.g., in the form of an IC design and / or IC model. The computer system includes a computing device 300, which may be a computer or server having one or more processors, a memory and a non-transitory storage medium such as a hard drive or 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 may be implemented in software using program code that is stored on the computing device. The modules serve for implementing the steps described herein, such as partitioning the IC design, mapping the IC design to an IC model, performing a structural analysis on a first set of subparts and / or performing a formal property check on a second set of subparts, and / or debugging the IC design based on the result of the structural analysis and / or the formal property check. The computing device may have other modules or applications such as modules for editing, loading and storing an IC design and / or IC model. The system further may have a display 390 providing a user an interface for interacting with the one or more modules 310, 320, 340, 350, 360.

[0071] Figure 11 illustrates exemplary steps during the design and production of an integrated circuit. In a first step S70 an IC design may be created. However, at first a functional specification of the IC on a higher abstraction layer, i.e., an IC model, may be created or obtained. A variety of languages and / or tools to create the IC specification may be used. Examples include a C / C++ model, VHDL, SystemC, Sys- temVerilog Transaction Level Models, Simulink, and MATLAB. The creation of the IC design may comprise layout, simulation, emulation and / or verification. Then the IC specification is converted into a register transfer level (RTL) description. The RTL describes the exact behavior of the digital circuits on the IC, as well as the interconnections to inputs and outputs. Thereupon, a circuit design may be created by a digital design synthesis in a step S71. As a result, a physical IC design may be obtained. This step takes the RTL, and a library of available logic gates (standard cell library) , and creates a physical IC design. Then using, e.g., an IC layout editor, layout and floor planning is done. Thereupon physical veri fication may be performed in a step S72 . Based on the physical IC design a mask may be prepared in order to fabricate the one or more wafers in a step S73 .

[0072] Figure 12 shows exemplary method steps according to an embodiment . In a first step S I a structural analysis of a first set of one or more subparts of an IC is performed . In a second step S2 at least one constraint that bounds the input ( s ) of a second set of subparts to permissible values is determined . Additionally or instead, at least one constraint that bounds the one or more outputs of the first set to permissible values is determined . Therein, the one or more outputs of the first set may serve as an input of a second set of one or more subparts of the IC . In a third step S3 a formal property veri fication of the second set of the IC based on the at least one constraint is performed . Hence , a hybrid method for veri fying functional safety of an integrated circuit comprising a structural analysis and a property veri fication is proposed . It should be understood that of course at first the one or more constraints ( for the input ( s ) of the second set and / or the output ( s ) of the first set ) may be determined and that subsequently the structural analysis and the formal property check is performed, as the case may be .

[0073] The permissible values may be given by one or more constraints that speci fy that values should be within a certain range or interval . Constraints are rules on properties that speci fy how properties should be used . As discussed herein the permissible values may speci fy that the inputs of the third part are the identical ( equal ) or di f ferent (unequal ) . Constraint definitions may comprise of two or three expressions separated by one of the relational operators . Thus , for example the one or more constraints may comprise a relational operator between the inputs of the third subpart and / or an upper and / or lower bound . However, the upper and / or lower bound may be omitted . Turning to Figure 13 exemplary method steps according to an embodiment are shown . In a first step S I a structural analysis of a first set of one or more subparts of an IC is performed . In a step S4 , which may be part of step S I , a fault path coverage of one or more outputs of the first set may be determined . Thereby it is ensured that all faults ( in the first set of subparts ) propagate to the outputs of the first set of subparts . Thereby it may also be ensured that all faults are present at the input ( s ) of the second set of subparts . As a result , the veri fication of the IC, e . g . , IC design and / or IC model , may be split into a veri fication of the first set of subparts and into a veri fication of the second set of subparts .

[0074] In Figure 14 exemplary method steps according to an embodiment are shown . In a step S I a structural analysis of a first set of one or more subparts of an IC is performed . In a subsequent step S3 a formal property veri fication of the second set of subparts of the IC based on the at least one constraint is performed . In a subsequent step S5 , functional safety of the first and second set of the IC based on the structural analysis and the formal property check is determined .

[0075] Further exemplary steps are shown in Figure 15 . In a step S I a structural analysis of a first set of one or more subparts of the IC is performed . To that end, the structural analysis may comprise a step S 6 in which it is determined whether all fault paths can propagate to the outputs of the first set , and / or that no fault paths can escape the first set , and / or all fault paths can only propagate to the outputs of the first set .

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

[0077] Further steps are shown in Figure 17. In a step S9 the IC comprising an intended functionality implemented by the first subpart of the IC is identified or determined. In a step S10 a safety mechanism for the intended functionality implemented by the second subpart of the IC is identified or determined. In a step Sil at least one comparator implemented by a third subpart of the second set of the IC is identified or determined. As described herein the IC may comprise such subparts, e.g., in the IC design. These subparts may be identified or determined automatically and / or by a user. To that end, an IC model may be created that is mapped to the IC design, or vice versa .

[0078] Turning to Figure 18, in a step S18 the first subpart and the second subpart may be configured to obtain, preferably the same, input and / or input values. In a step S13, the first subpart may be configured to output primary output. In a step S14, the second subpart may be configured to output secondary output. In a step S15, the third subpart may be configured to obtain the primary output and / or the secondary output, and / or the third subpart may be configured to compare the primary output and the secondary output in order to determine functional safety of the first subpart and / or second subpart. The third subpart may thus be configured to compare signals present at its input (s) . The third subpart may thus be configured to obtain the primary output and / or the secondary output at its input ( s ) .

[0079] In Figure 19 further steps are shown. In a step S16, a model of the IC, the model preferably comprising the first set and the second set of subparts, is determined. In a step S17, at least part of an IC design is mapped to an IC model or an IC model representing the IC design may be created and / or mapped to the IC design. In a step S18 an output of the first subpart and an output of the second subpart is mapped from the IC design to the IC model. Additionally or instead, the input (s) of a third subpart in the IC design is mapped to the IC model, or vice versa. Hence, a correspondence between the subparts in the IC model and the IC design is obtained. That is, the subparts may as such only be visible or elements of the IC model whereas in the IC design the subparts are identified by the corresponding logic elements, e.g., on the register transfer level. The subparts may be identified base don on key signals in the IC design and / or IC model. Thus, to that end the IC design is partitioned into subparts which are presented as functional elements in the IC model. These functional elements may correspond to the intended functionality and / or the safety mechanism.

[0080] In any case, based on the partitioning and / or identification of the subparts of the first and / or second set, different verification techniques may be applied to the subparts in the first and / or second set. To that end, a cut-off between the subparts of the first and / or second set may be determined. Thereupon, different verification techniques may be applied, e.g., successively, to the subparts of the first and / or second set. The verification techniques may then be combined in order to verify the IC, e.g., the IC design and / or IC model.

[0081] Turning to Figure 20, the step SI of performing a structural analysis, e.g., of a first and / or second subpart of a first set of subparts of the IC, may comprise a step S19 of performing a cone of influence analysis. The cone of influence analysis may be used to determine whether one or more faults are on a path of the output of the first subpart and / or of the second subpart. Thus, based on the cone of influence analysis it may be determined whether one or more faults propagate to the input (s) of the second set of subparts, in particular the third subpart.

[0082] Turning to Figure 21, the step SI of performing a structural analysis, e.g., of a first and / or second subpart of a first set of subparts of the IC, may comprise a step S19 of per- forming a cone of influence analysis . The cone of influence analysis may serve for determining whether one or more faults are on a path from an input to the output of the first subpart and / or the second subpart in a step S21 .

[0083] Turning to Figure 22 , the step S I of performing a structural analysis , e . g . , of a first and / or second subpart of a first set of subparts of the IC, may comprise a step S 19 of performing a cone of influence analysis . As part or as a result of the cone of influence analysis it may be determined in a step S22 whether one or more faults have a path to one or more one or more logic elements outside of the first and / or second subpart while the path is not going through the output of the first and / or second subpart .

[0084] Figure 23 shows further steps . The step S I of performing a structural analysis , e . g . , of a first and / or second subpart of a first set of subparts of the IC, may comprise a step S 19 of performing a cone of influence analysis . In a step S23 , as a result of or as part of the cone of influence analysis , it may be determined whether there are one or more paths to one or more faults from one or more logic elements outside of the first and / or second subpart which are not going through the one or more inputs of the first and / or second subpart .

[0085] Turning to Figure 24 , in a step S24 the inputs of the third subpart , which preferably are operative and / or configured to receive the outputs of the first and the second subpart , are set to be equal based on a first constraint . As described herein the input ( s ) of the third subpart and / or the outputs of the first and second subpart may serve as a cut-of f . The input ( s ) of the third subpart are then modeled and / or their permissible values formulated as constraints . These constrains may serve as an input for a formal property check ( er ) . Thus , in a step S25 a first assertion is created based on the first constraint . Then it may be determined whether a fault in the second set is detected based on the first assertion . In as step S26 a formal property check or verification of the second set of the IC based on the at least one first constraint and / or first assertion.

[0086] Now turning to Figure 25, in a step S27 the inputs of the third subpart, which preferably are operative and / or configured to receive the outputs of the first and the second subpart, are set to be un-equal based on a second constraint. In a step S28, a second assertion is created based on the second constraint. Then it may be determined based on the second assertion whether the second set is functionally correct and / or a fault in the first set, e.g., first and / or second subpart, is detected. Thus, in a step S29 a formal property check or verification of the second set of the IC is performed based on the at least one second constraint and / or second assertion .

[0087] Thus, by disconnecting or cutting the connection between first set and second set of subparts and constraining the inputs of the second set different verification techniques may be employed. It is thus possible to constrain the input (s) of second set to be erroneous (first constraint) , i.e., the inputs, e.g., to the third subpart, are un-equal. It is furthermore possible to constrain the input (s) of the second set not to be erroneous (second constraint) , i.e., the inputs, e.g., to the third subpart, are equal. Hence, a first assertion may be determined based on the first constraint and / or it may be determined whether the fist assertion holds. Furthermore, a second assertion may be determined based on the second constraint and / or it may be determined whether the second assertion holds.

[0088] As a result of the formal property check the property or properties are satisfied or violated. The IC, e.g., IC design and / or IC model, may accordingly be debugged (in that case the method steps herein may need to be repeated) or the IC design may continue to the next stage of production. Now turning to Figure 26 , in a step S30 a formal property veri fication of the second set of the IC is performed 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, a formal property veri fication of the second set of the IC may be performed in a step S31 , wherein the one or more inputs of the second set are disconnected from the one or more outputs of the first set , i . e . , cut-of f .

[0089] Thus , it is proposed to cut the connection between first set and second set of subparts and constrain the input ( s ) of the second set . Therein, the input ( s ) of second set can be constraint to be erroneous and / or can be constraint no to be erroneous . Thereupon, 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 for a second assertion that can be created based on the second constraint , and / or it can be determined whether the second assertion holds .

[0090] Turning to Figure 27 , in a step S32 the IC design may be adapted based on a result of the functional veri fication . In a step S33 , the IC design may be synthesi zed into a hardware implementation . And in a step S34 , a semiconducting material may be processed according to the hardware implementation . Further steps as described in connection with Figure 11 may be performed in order to fabricate and / or control the fabrication of the IC .

Claims

CLAIMS1. A method for verifying functional safety of an integrated circuit (10) , IC, comprising the steps of: performing a structural analysis of a first set (1) of one or more subparts (11, 12) of the IC (10) in order to determine a fault path coverage of one or more outputs (01, 02) of the first set, determining at least one constraint (20, 21) that bounds the one or more inputs (131, 132) of a second set of subparts to permissible values, wherein the one or more outputs (01, 02) of the first set serve as input (13) of the second set (2) of one or more subparts (13) of the IC, and performing a formal property verification of the second set(2) of the IC (10) based on the at least one constraint (20, 21) .

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

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

4. The method according to any one 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 set (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 comprising at least one comparator implemented by a third subpart (13) of the second set (2) , wherein the first subpart (11) and the second subpart (12) are configured to obtain, preferably the same, input values (II, 12) , the first subpart (11) configured to output primary output (01) , the second subpart (12) configured to output secondary output (02) , the third subpart (13) configured to compare the primary output (01) and the secondary output (02) in order to determine functional safety of the first subpart (11) and / or second subpart (12) , i.e., first set (1) .

6. The method according to any one 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 set (1) and the second set (2) .

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

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

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

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

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

12. The method according to any one of the preceding claims, wherein performing a structural analysis comprises a cone of influence analysis in order to determine whether there are one or more paths (40) to one or more faults from one or more logic elements (42) outside of the first and / or second subpart (11, 12) which are not going through the one or more inputs of the first and / or second subpart (11, 12) .

13. The method according to any one of the preceding claims, setting the one or more outputs (01) of the first subpart (11) to be equal to the 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 subpart, is functionallycorrect and / or that no alarm is issued by the third subpart based on the first assertion (20) , wherein the first constraint and / or assertion indicates a no-fault scenario.

15. The method according to any one of the preceding claims, setting the one or more outputs (01) of the first subpart (11) to be unequal to the 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 that an alarm is issued by the third subpart based on the second assertion (31) , wherein the second constraint and / or assertion indicates a fault scenario .

17. The method according to any one of the preceding claims, performing a formal property verification, e.g., by a formal verification tool, of the second set (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) .

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

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

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

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

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

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

Images