Time control for fail function verification

Abstract

The invention relates to a system and method for time control for fail function verification. In some embodiments, a method includes determining, in a nominal function test of a circuit, that an output of a first component has a first value at a first point in time, the output of the first component being connected by a wire to an input of a second component; determining that the output of the first component has a second value different from the first value at the first point in time in a fault function test of the circuit; determining the wire pass-through barrier based on a runtime input; and setting the value of the input of the second component to the first value at the first point in time in the fail function test.

Description

Technical Field

[0001] The present disclosure relates to functional verification of digital circuits. Background Art

[0002] In the design of digital circuits, functional tests may be performed to determine whether the circuit will perform as required once it is fabricated. Such functional tests may include fault functional tests, in which the effects of various kinds of faults may be simulated. Summary of the invention

[0003] According to an embodiment of the present disclosure, a method is provided, the method comprising: determining in a nominal function test of a circuit that an output of a first component has a first value at a first time point, the output of the first component being connected to an input of a second component through a wire; determining in a fault function test of the circuit that the output of the first component has a second value different from the first value at the first time point; determining that the wire passes through a potential barrier based on a runtime input; and setting the value of the input of the second component to the first value at the first time point in the fault function test.

[0004] In some embodiments, the potential barrier is a potential barrier surrounding a first design cell, the first design cell containing the first component.

[0005] In some embodiments: the first design unit is contained in a second design unit, the second design unit is a higher level in the design hierarchy, and the barrier is inherited by the first design unit from the second design unit.

[0006] In some embodiments, the method further includes: determining that the first time point belongs to a first time interval, the first time interval being a time interval in which the barrier is enabled, wherein the setting of the value of the input of the second component includes setting the value of the input of the second component based on the determination that the first time point belongs to the first time interval.

[0007] In some embodiments, the method further includes: determining that the second value is associated with a first fault; and determining that the barrier is associated with the first fault, wherein the setting of the value of the input of the second component includes setting the value of the input of the second component based on: the determination that the second value is associated with the first fault; and the determination that the barrier is associated with the first fault.

[0008] In some embodiments, the method further includes: determining that the second value is associated with a fault of a first fault type; and determining that the barrier is associated with the first fault type, wherein the setting of the value of the input of the second component includes setting the value of the input of the second component based on: the determining that the second value is associated with a fault of the first fault type; and the determining that the barrier is associated with the first fault type.

[0009] According to an embodiment of the present disclosure, a system is provided, the system comprising: a processing circuit; and a non-transitory computer-readable medium connected to the processing circuit, the non-transitory computer-readable medium storing instructions, which when executed by the processing circuit causes the processing circuit to perform a method, the method comprising: determining in a nominal function test of a circuit that an output of a first component has a first value at a first time point, the output of the first component being connected to an input of a second component through a wire; determining in a fault function test of the circuit that the output of the first component has a second value different from the first value at the first time point; determining that the wire passes through a potential barrier; determining that the second value is associated with a fault of a first fault type; determining that the potential barrier is associated with the first fault type; and setting the value of the input of the second component to the first value at the first time point in the fault function test based on the following items: the determination that the second value is associated with a fault of the first fault type; and the determination that the potential barrier is associated with the first fault type.

[0010] In some embodiments, the potential barrier is a potential barrier surrounding a first design cell, the first design cell containing the first component.

[0011] In some embodiments: the first design unit is contained in a second design unit, the second design unit is a higher level in the design hierarchy, and the barrier is inherited by the first design unit from the second design unit.

[0012] In some embodiments, the determining that the wire crosses the potential barrier includes determining that the wire crosses the potential barrier based on a runtime input.

[0013] In some embodiments, the method further includes: determining that the first time point belongs to a first time interval, the first time interval is a time interval in which the barrier is enabled, wherein the setting of the value of the input of the second component includes setting the value of the input of the second component based on the determination that the first time point belongs to the first time interval.

[0014] In some embodiments, the method further includes: determining that the second value is associated with a first fault; and determining that the barrier is associated with the first fault, wherein the setting of the value of the input of the second component includes setting the value of the input of the second component based on: the determination that the second value is associated with the first fault; and the determination that the barrier is associated with the first fault.

[0015] In some embodiments, the determining that the wire crosses the potential barrier includes determining that the wire crosses the potential barrier based on a runtime input.

[0016] According to an embodiment of the present disclosure, a system is provided, the system comprising: a processing circuit; and a memory connected to the processing circuit, the memory storing instructions, which, when executed by the processing circuit, causes the processing circuit to perform a method, the method comprising: determining in a nominal function test of a circuit that an output of a first component has a first value at a first time point, the output of the first component being connected to an input of a second component through a wire; determining in a fault function test of the circuit that the output of the first component has a second value different from the first value at the first time point; determining that the wire passes through a potential barrier based on a runtime input; and setting the value of the input of the second component to the first value at the first time point in the fault function test.

[0017] In some embodiments, the potential barrier is a potential barrier surrounding a first design cell, the first design cell containing the first component.

[0018] In some embodiments: the first design unit is contained in a second design unit, the second design unit is a higher level in the design hierarchy, and the barrier is inherited by the first design unit from the second design unit.

[0019] In some embodiments, the method further includes: determining that the first time point belongs to a first time interval, the first time interval is a time interval in which the barrier is enabled, wherein the setting of the value of the input of the second component includes setting the value of the input of the second component based on the determination that the first time point belongs to the first time interval.

[0020] In some embodiments, the method further includes: determining that the second value is associated with a first fault; and determining that the barrier is associated with the first fault, wherein the setting of the value of the input of the second component includes setting the value of the input of the second component based on: the determination that the second value is associated with the first fault; and the determination that the barrier is associated with the first fault.

[0021] In some embodiments, the method further includes: determining that the second value is associated with a fault of a first fault type; and determining that the barrier is associated with the first fault type, wherein the setting of the value of the input of the second component includes setting the value of the input of the second component based on: the determining that the second value is associated with a fault of the first fault type; and the determining that the barrier is associated with the first fault type.

[0022] In some embodiments, the barrier is a barrier surrounding a first design unit, wherein the first design unit contains the first component BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The present disclosure will be more fully understood from the detailed description given below and the accompanying drawings of the embodiments of the present disclosure. The drawings are used to provide knowledge and understanding of the embodiments of the present disclosure, and the scope of the present disclosure is not limited to these specific embodiments. In addition, the drawings are not necessarily drawn to scale.

[0024] Figure 1 is a flowchart of a compilation process according to some embodiments of the present disclosure.

[0025] Figure 2 is a flowchart of a runtime process according to some embodiments of the present disclosure.

[0026] Figure 3 Flowcharts depicting various processes used during the design and fabrication of integrated circuits according to some embodiments of the present disclosure.

[0027] Figure 4 A diagram depicting an exemplary computer system in which embodiments of the present disclosure may operate. DETAILED DESCRIPTION

[0028] Aspects of the present disclosure relate to timing control during fail-safe function verification runtime.

[0029] In a computer system running software for performing functional testing of digital circuits, a faulty functional test may be performed by simultaneously executing two functional tests, which may be referred to as a good machine (GM) functional test (or as a "nominal" functional test) and a faulty functional test, respectively. A faulty functional test may be a functional test of a digital circuit that has been modified to introduce an artificial fault, such as a conductor intended to be separated that becomes shorted together due to a manufacturing defect. A good machine functional test is a similar functional test without the introduction of an artificial fault. It may be advantageous to limit the breadth of the circuit through which the signal of the faulty functional test propagates; this can be achieved using a feature called a barrier. Each barrier may be applied to one or more conductors (or wires) in a circuit; when a barrier is applied to a conductor, the input (of a component of the circuit) to which a signal is fed by the conductor is fed with a value generated by the good machine functional test (regardless of whether this value is the same as the value of the faulty functional test of the conductor). In some functional testers (or simulators), such barriers are only specified at compile time; therefore, in order to change the barriers, the design may need to be recompiled. This may be cumbersome and time-consuming, especially for large circuits.

[0030] Thus, in some embodiments, the functional checker is configured to be able to modify the barrier at runtime. For example, the functional checker may receive a command in a unified command line interface (UCLI) file to set a barrier at a first point in time in the functional check and remove the barrier at a second point in time. Such a feature may be useful, for example, to avoid propagation across circuit conditions of a circuit at startup or reset, which would be abnormal during normal operation and considered a fault. As another example, a barrier may be created at runtime that operates as a barrier only for certain kinds of faults (e.g., transient faults) or specific faults (each of which may be identified by a corresponding fault identifier).

[0031] Technical advantages and technical benefits of the present disclosure include, but are not limited to, streamlining functional testing of faults, which can improve the functionality of a computer system that performs functional testing according to some embodiments. Some embodiments make it possible to run a fault functional test using a first set of barriers, and then run a second fault functional test using a different set of barriers without recompiling the design. This makes it possible to systematically seek an understanding of undesirable circuit behavior (e.g., exhibited in a first fault functional test) without incurring the burden (to the user and the system) of recompiling the design before performing the second fault functional test, and thereby improve the functionality of the computer system that runs the functional test. Some embodiments make it possible to configure one or more barriers so that certain faults are blocked at the barriers, while other faults propagate through the barriers. This makes it possible to generate additional information about faults that are of particular concern in fault functional testing without potentially generating large amounts of data related to faults of relatively less concern.

[0032] Failure functional testing is the process of simulating the effects of faults or failures in digital circuits. This is used to evaluate the reliability of complex circuits and the ability of the system to react to faults in the design when a fault occurs. Failure functional testing plays a vital role in the safety-critical world of automotive circuits.

[0033] Fault functional verification testing places additional requirements on design verification testing. In fault functional verification, the user can specify at which input / output (I / O) pin the fault is observed (by the functional verifier) ​​and during which time interval the fault should be observed (by the functional verifier). There may be delays because there is a limited time window when the functional verification will capture data to compare with the expected good circuit behavior. If the fault functional verifier is allowed to observe all the time, it will be impractical for the fault functional verifier to detect faults that only affect the observation point briefly.

[0034] Model-based fault injection can be used to quantify the number of faults within a design that can cause a device to fail, causing it to violate a safety goal or the ability of a safety mechanism to correct, react, or signal a violation of a safety goal. Faults are injected, and the results of the functional verification are specific to the workload provided. Such workloads may include application code, software test libraries, diagnostics, or even functional test types. Faults during the operation of a device can range from open circuits (broken wires) or simple short circuits to complex behaviors. Different fault models closely reflect different defects. Some software provides several models identified in the International Organization for Standardization (ISO)-26262:2011 standard. The direct result of fault injection is a report on the number and percentage of faults detected by one or a group of workloads. In a verification environment, fault functional verification identifies design areas that have not been tested and require test improvements. This information can be used to improve the quality of workloads and safety mechanisms.

[0035] Workload validation helps to: (i) determine the quality of the workload by determining the faults detected by each test; (ii) determine areas of the design that require additional workload or modified workload; and (iii) find tests that improve the quality of the test suite.

[0036] In some instances, faulty functional verification can detect areas of low testability due to design flaws. If functional testing does not cause observable behavior in a portion of a chip during faulty functional verification, then there may be a design problem in that portion of the chip.

[0037] Fault injection testing places additional requirements on design verification testing. For fault functional verification, it is possible to define where and when the functional verifier should observe the fault. This includes observing where the fault may cause the device to fail and when and where the safety mechanism can detect the failure.

[0038] One embodiment is a computer implemented method for verifying fault functional testing where faults flow through the entire design and sometimes the user may require that fault propagation within a specific portion of the design or hierarchy be disabled at a specific functional testing time. For example, when the system is in a reset state and the system may be in a corrupted state, propagating a fault during this time may result in a false detection because this may be an acceptable state when the system just comes out of reset. The fault may propagate through a portion of the design where it is assumed that fault functional testing is not required during that stage of the design.

[0039] Related art functional verification systems only provide compile-time static compilation instructions, such as `begin_faultfree`end_faultfree, to encapsulate the hierarchy of designs that allow faults. Another option is `begin_faultprevent`end_faultprevent, where faults are not allowed to propagate. These are compile-time instructions and cannot be switched back and forth during functional verification according to design needs.

[0040] Compile-time pragmas are restrictive, where changing the scope of fault functional testing always requires recompiling and functional testing, which may incur significant overhead in the case of large system-on-chip (SOC) designs. Related art functional testing systems may not provide methods to control specific fault types in specific areas of the design, and all types of faults may be affected by compile-time exclusion. The following is a list of various fault models defined in ISO-26262:

[0041] - Stuck-at faults, which are s@0 and s@1 faults (corresponding to conductors stuck at logic 0 or logic 1, respectively) on raw input and output terminals, module ports and nets, registers, arrays, continuous assignments and expressions

[0042] - Transition type faults, which are slow rising and slow falling faults on the raw input and output terminals and module ports

[0043] - Bridging type faults, which are wire, wand, wor, X-dominant and Y-dominant faults between any two nets

[0044] - IDDQ (Quiescent Supply Current) faults, which are pseudo-stuck, toggled, and adjacent bridge faults

[0045] - Expression faults, which are faults injected into expressions in procedural code

[0046] - Transient faults, which are faults that occur once and then disappear

[0047] Some embodiments relate to providing dynamic control techniques for fault functional verification in electronic design automation. Fault functional verification is critical to evaluating the reliability of complex circuits, especially in the safety-critical automotive field. Some embodiments provide system calls that enable users to control the scope of fault propagation and its effects at different functional verification times during the design verification cycle. The method also allows users to control the type of faults in specific parts of the design. Related art solutions provide compile-time indications that are not switchable during functional verification, resulting in recompilation and functional verification of large SOC designs. Some embodiments are intended to address these limitations and provide greater flexibility and efficiency in fault functional verification. In some embodiments, the system combines circuit design with fault control tasks so that the type of fault and the scope of fault functional verification can be controlled.

[0048] The approach of defining new system calls that can be executed at runtime attempts to address all the limitations of existing approaches to controlling fault propagation. This approach attempts to enable users to control the scope of fault propagation and its effects in the design at different functional verification times in the design verification cycle.

[0049] Some embodiments also enable the user to control the types of failures that are specified for selected portions of the design, giving the user an unlimited number of ways to configure fault functional testing verification, and giving the user the ability to utilize power fault functional testing to the broadest possible extent.

[0050] Users can control the effects of faults in certain areas at different time intervals using control system task calls, which may be called $faultcontrol(...). $faultcontrol can handle various combinations of fault categories, fault identifiers (IDs), levels, and instance lists.

[0051] Listed below are several different use cases where some embodiments may provide benefits.

[0052] The first category of use cases is to prevent unrelated fault propagation: using $faultcontrol during a phase to enhance SOC testing. This category includes the following use cases:

[0053] -The design may go through a reset phase or multiple functional modes after fault injection, potentially leading to an unstable good machine (GM) state.

[0054] - Fault function verification testing may not be necessary or important during this phase or in this functional mode.

[0055] -Isolate the fault from test to test site to a certain part of the design, because the focus area of ​​design verification may change from test to test site depending on the stimulus.

[0056] - The $faultcontrol feature can be used to intentionally disable fault propagation during certain phases of the design (e.g. reset phase / functional mode).

[0057] -Once the reset phase is complete, $faultcontrol can be re-enabled to allow the design to run against the fault.

[0058] This approach ensures that fault functional verification is performed when it is most needed and improves the accuracy of fault detection.

[0059] The second category of use cases is selective fault propagation: maximizing test efficiency and accuracy during certain phases. This category includes the following use cases:

[0060] - During the reset phase, some types of faults (eg stuck-at faults) may not be of concern, while other types of faults (eg transitional faults) may still be critical to detect.

[0061] The -$faultcontrol feature can be used to intentionally disable the propagation of certain types of faults during the reset phase.

[0062] -Once the reset phase is complete, $faultcontrol can be re-enabled to allow detection of the expected type of faults.

[0063] The third category of use cases is selective fault propagation: limiting the scope of certain features. This category includes the following use cases:

[0064] The $faultcontrol feature enables the selective use of certain techniques in fault functional verification design.

[0065] - Use the $faultcontrol feature to limit fault functional checking to assert on a subset of the design for fault propagation.

[0066] The fourth category of use cases is ease of debugging and performance. This category includes the following use cases:

[0067] The -$faultcontrol feature can be used during functional verification of faults to limit the scope of fault propagation, making it easier to debug faults in specific areas of the design.

[0068] - This approach reduces the size of FM crash dumps (fsdb files) and speeds up the process of identifying different failures.

[0069] - By limiting the effect of a fault to a portion of the design, users can speed up functional verification of faults.

[0070] The fifth category of use cases is dynamic fault control: flexible and efficient fault propagation management for complex SOC testing. This category includes the following use cases:

[0071] -In complex SoCs, integrators may disable portions of the intellectual property (IP) to prevent failures from affecting test results.

[0072] -During testing, only certain parts of the design may need to be tested, and the scope of the test may vary from test to test site.

[0073] -The dynamic $faultcontrol feature can be used to control fault propagation during functional verification, providing greater flexibility without recompiling the design.

[0074] - By enabling the integrator to selectively disable certain parts of the design during testing, this approach can help reduce the number of irrelevant faults detected, thereby improving the efficiency and accuracy of the testing process. The process may also involve controlling certain scopes of fault classification.

[0075] The sixth category of use cases is Dynamic Fault Control: Controlling the classification of faults. This category includes the following use cases:

[0076] - In a design, the $faultcontrol call can be used to control certain categories of faults to specific levels.

[0077] - For example, transitional / momentary faults may be appropriate for some modules but not others; user controllable range of specific fault classifications.

[0078] In summary, some embodiments provide an improved fault functional verification method with selective control of fault scope and instances. Some embodiments involve combining a design with a fault control task to control the scope of instances and the type of faults to perform effective fault functional verification. Some embodiments enable the selection of fault types, instances, and functional verification cycles to perform verification of designs with the ability to enable or disable the effects of fault functional verification. Fault control tasks can be dynamically added at runtime via a unified command line interface (UCLI) file or via separate module bindings without modifying the design. During functional verification, different hierarchies with different fault types can coexist in a fault functional verification environment. The method can be easily integrated into some functional verification tools. The advantages of some embodiments include the ability to control the impact of faults at specific times, and the ability to select certain faults to be simulated at different stages of the design, all of which do not require modifications to the design.

[0079] Effective fault functional verification of designs has been a challenge for many years. Using fault functional verification to verify the intent of the design is not simple because there may be disconnects between the register transfer level (RTL) and the fault scope objects. Users may not be able to access and manipulate the fault functional verification scope in the same way as generating or placing faults. The fault functional verification points generated by various tools allow fault propagation to be abandoned at compile time. Typically, the abandonment generated by these tools does not meet the needs of users, and an additional method is required to control the fault effect at runtime. Users also use various methods to abandon certain faults by manipulating the fault condition to keep the fault from persisting outside the detection point by downgrading the fault or using various existing system tasks to change the condition.

[0080] In some related art fault functional verification tools, there are provisions for permanently closing the directional scope of the design fault functional verification during functional verification, for example, using `begin_faultfree and `end_faultfree to limit faults to a given scope, and `begin_faultprevent and `end_faultprevent to limit faults to not propagate within the scope. However, these provisions do not provide the flexibility to control individual scopes during functional verification. Another way to stop discarding faults at the detection point instead of controlling fault propagation is to use a fault definition file or to use a runtime switch to convert the fault to a different state. Runtime switching based on features such as maxpot may be non-deterministic because the feature may be controlled only based on the number of detections to be avoided. The number of detections may vary for different tests and may depend on each individual functional verification path adopted by each test.

[0081] In each of these approaches, the user may be required to use these techniques at compile time because the controls are included as part of the design, thereby limiting the user's ability to experiment. As such, changing the controls may involve recompiling the design, and for large SOC designs, such recompiling may take multiple hours. Therefore, some related art approaches severely limit the user's ability to experiment with the design and limit the scope of the fault functional verification. Changing the scope and re-spinning the design can be a long and arduous task. Even simple tasks, such as adding more compilation instructions, may involve re-iteration of the entire fault functional verification process, which is very inefficient in terms of time, especially when running functional verification on larger systems on a chip (SOC).

[0082] The present disclosure relates to a method and system for performing effective fault functional verification by selectively enabling or disabling portions of a hierarchy of a design. The method includes combining a design with a fault control task that can control the scope of instances and types of faults. In the case of using the disclosed method, a user (e.g., a verification engineer) can select the type, instance, or functional verification cycle of a fault, and enable or disable the fault functional verification effect to perform effective verification of the design. In one embodiment, a UCLI file or a separate module can be used to add a fault control task, and the user can bind the module to the design to effectively develop a flow without modifying the design. Binding instructions can be specified in a module, interface, or compilation unit. Fault activity can include various faults, block-level devices under test (DUTs), and top-level DUT faults under test.

[0083] Advantages of some embodiments include, but are not limited to, the ability to selectively enable (or disable) specific hierarchies at compile time. A user can selectively disable (or enable) a designed hierarchy at runtime.

[0084] Additionally, one or more specific types of faults (e.g., stuck-at faults or transient or transitional faults) can be controlled along the design hierarchy of interest. These hierarchies can be disabled or enabled while the rest of the design hierarchy continues to simulate faults.

[0085] Other advantages include the ability to select a type of fault hierarchy and specify different hierarchies with different fault types; both can coexist in the fault functional verification environment during the functional verification cycle, and the user can selectively enable or disable the hierarchy to perform effective verification of the fault functional verification. The methods and systems disclosed herein can be integrated into various functional verification tools. These fault functional verification system tasks provide a mechanism for the user to dynamically control the propagation of faults and their functional verification at runtime and provide time control at runtime. The mechanism enables the user to experiment with controlling different types of faults at different hierarchies.

[0086] Thus, some advantages of some embodiments are as follows:

[0087] - The user does not need to modify the design; the fail-safe functional verification effect can be controlled only at runtime (eg, temporarily).

[0088] - The user may select specific times when the effects of a control fault may be suppressed, such as during design state when the GM state may be unstable and performing a fault function check may not make sense.

[0089] -Users can select certain faults to be simulated during specific phases of the design. For example, stuck-at faults may not be appropriate during the reset phase of the design, but transient faults may make sense.

[0090] The system task ($faultcontrol) specified below can meet all user needs for dynamic fault management. The task can be defined as $fault_control_task with the following parameters.

[0091] $faultcontrol([levels],[control_type],[fault_type],[fault id],[list_of_modules_or_instances]);

[0092] list_of_module_or_instances::=module_or_instance{,module_or_instance}

[0093] module_or_instance::=module_identifier|name_of_instance

[0094] name_of_instance::=instance_identifier{unpacked_dimension}

[0095] unpacked_dimension::=

[0096] [constant_range]

[0097] |[constant_expression]

[0098] module_identifier::=identifier

[0099] instance_identifier::=identifier

[0100] The following table shows the values ​​for the control_type parameter. This parameter controls the fault type for the $faultcontrol system task. This parameter can be an integer expression.

[0101] control_type Effect 0 No fault, that is, faults below the specified level are allowed 1 Fault prevention, i.e. ignoring faults below a specified level

[0102] The following table shows the values ​​for the fault_type parameter. This parameter controls the fault type for the $faultcontrol system task. This parameter can be an integer expression.

[0103] fault_type Effect 0 All fault types 1 Fixed WIRE failure 2 Fixed VARI fault 3 Fixed PORT failure 4 Fixed PRIM failure 5 Transient fault 6 Transitional Failure 7 Bridging Fault 8 IDDQ Failure 9 Bridging Fault 10 Expression failure 11 Unit sense failure

[0104] The fault_id parameter controls a specific fault in the $faultcontrol system task by its ID. This parameter can be an integer expression.

[0105] The levels parameter specifies the hierarchy levels, consistent with the corresponding parameter of the $dumpvars system task. If this parameter is not specified, it may default to 0. This parameter can be an integer expression.

[0106] The list_of_module_or_instances parameter is one or more module_identifiers or instance_identifiers. Only modules or instances are allowed. If more than one module_identifier or instance_identifier is specified, then the module_identifiers or instance_identifiers may be separated by commas. Instance names of modules may be used in this parameter in case a period level separator is used. String literals may not be used for module_identifier or instance_identifier. If no scope_list value is provided, then the scope may be the module that called the $faultcontrol task.

[0107] Figure 1 Describes the compilation flow (and illustrates the compilation actions) of the system task $faultcontrol, which is written into the design or bound as a separate module. Figure 1 As illustrated in , in some embodiments, at 105, design reading and analysis are performed ($faultcontrol task can be read as part of design reading); at 110, design refinement is performed; at 115, parallel modules are bound to the design when needed; at 120, the fault task sytntInstrumentation is implemented; at 125, fault control compilation instruction instrumentation is implemented ($faultcontrol task can also be provided at runtime via $ucli call, such as system task call); at 130, debug dump is performed; at 135, back-end code generation is performed ($faultcontrol can be bound as a separate module together with the design transmitted to the runtime); and at 140, design rewrite is performed.

[0108] Figure 2 Describe the runtime flow of system task handling (and illustrate runtime actions). Figure 2As illustrated in FIG. 2 , at 205, the system may iterate through the $faultcontrol task parameters; at 210, the system may go from the scope path to the target instance; at 215, the system may iterate through all fault types of the target instance; at 220, the system may check the status of the current instance and apply the fault control attributes; at 225, the system may track all types of faults under the instance and the status of the faults for reference during simulation; at 230, when control reaches these instances, the system may check whether the fault to be propagated is out of scope; and at 235, the system may recursively apply to the lower level based on the level mentioned in the task. Then, at 240, the system may continue to process the next task.

[0109] The call to $faultcontrol can also be triggered at runtime by including this call in the standard UCLI file supplied to functional inspection. In this case, no design modification is required.

[0110] In another embodiment, when performing fault functional verification on a design, the functional verification may include functions of multiple fault types of the chip, which may be divided by performance characteristics (for example, one block may be high performance, while the rest of the chip may be lower performance). In order to achieve the goal of high performance blocks, transient faults may be used to verify the transient nature of faults in the design. Other parts of the design may be more suitable for different types of fault coverage, such as stuck-at faults. Therefore, it may not make sense for faults to propagate outside of certain areas. Thus, in some embodiments, the user can control the fault types of a specific hierarchy.

[0111] Since various faults exist in the design, it is complicated to capture the fault type and abandon the system for its design.A typical central processing unit (CPU) system may be best suited for a certain type of fault, while other modules (e.g., power modules) may be better suited for other types of faults.

[0112] System tasks can also be called at runtime via $ucli calls, which provides flexibility for the user to vary the scope of fault propagation from test to test, and gives some embodiments greater flexibility than embedded system calls defined at compile time. This makes the process flexible, allowing the user to fully control the fault function verification environment at runtime. This opens up unlimited possibilities for fault function verification control. $ucli calls can be a method provided by the debugging environment to drive or check the design at runtime via interactive mode.

[0113] In dynamic power verification, several aspects can be checked. First, the design may go through a reset phase, during which the state may be deterministic, and the user may wish to abandon the fault functional verification of some of the faulty blocks or the entire fault functional verification. Later, the user may wish to enable full fault functional verification. This makes it possible to (i) check fault detection in the correct context within the design RTL, and (ii) check the fault functional verification together to ensure that the design functions properly and no false negatives are marked. Next, the waveform type and fault activity seen in the design can determine the dynamic nature of fault propagation and functional verification, because the dynamic nature depends on activity factors. The higher the activity coefficient, the greater the breadth of the fault impact propagation. Therefore, observing faults in the correct stage and context makes it possible to accurately estimate the effectiveness of fault functional verification.

[0114] In order to avoid false positives via dynamic runtime control, users can potentially discover the next set of defects or failures that may have been masked by false negatives, for example, due to the detection of failures in irrelevant time or hierarchy sections of the design. In related art systems, realizing at a late stage in testing that an error has been masked by a false negative may adversely affect the verification plan and may result in expensive re-compilation involving design modifications and the need to go through a full error functional verification cycle.

[0115] Another advantage of using a runtime control task over the compiler-based pragma of the related art is that when the control task is triggered via a UCLI file, the pragma gives the user the ability to apply exclusions without requiring modifications to the design. Thus, the user can exercise time control at runtime.

[0116] In some cases, users may be using third-party verification IP (VIP) or libraries, which may lack the ability to change the design and may therefore be limited because the IP or library may be subject to related technical exclusions. In contrast, the way exclusions are implemented in some embodiments can empower users to take advantage of unique runtime methods to exercise time control at runtime and bypass this process limitation, and more verification paths can be achieved.

[0117] In some embodiments, the fault control task with design intent can be written as a pseudo-independent module and bound to the language binding structure. SystemVerilog provides a powerful binding structure that can be used to specify one or more instances of a module, interface, program or checker without modifying the code of the target. Therefore, for example, the fault control task encapsulated in the module, interface, program or checker can be instantiated in the target module or module instance in a non-invasive manner. Nevertheless, the custom fault function inspection control can be kept separate, not only separated from the design code, but also separated from the functional environment.

[0118] The user may also take advantage of the partial refinement feature to replace at runtime a dummy module instantiated at compile time with a new body of the module that may define a set of exclusion rules, thereby enabling the user to change behavior at runtime.

[0119] The following example merely illustrates the functionality of the above parameters in the example code for finer control of the fault function checking.

[0120] Example 1: Disable and enable the entire hierarchy below the specified instance

[0121] Details: At time 0, all instances below the fault that exist in the design scope are disabled, and then at time 10, all instances below the tb.top.inst scope are enabled.

[0122]

[0123] Example 2: Using hierarchy control to disable different depths from a given hierarchy.

[0124] Details: At time 0, all instances at depth 3 below tb.top.inst are disabled to find faults that exist within the design scope tb.top.inst, and then at time 10, instances at depth 2 are re-enabled.

[0125]

[0126] Example 3: Controlling the type of failure

[0127] Details: In this case, port failure specific propagation is controlled below the hierarchy; in the example below, the hierarchy controls port failure (3) to be disabled at time 0 and enabled at time 10.

[0128]

[0129] Example 4: Control based on fault ID

[0130] Details: At time 0, all instances under tb.top.inst that exist within the design scope are disabled for fault ID 4 and later re-enabled at time 10.

[0131]

[0132] Alternatively, the user can use this system to call $faultcontrol in the Verilog design file with any behavioral logic.

[0133] Example 1: Disable and enable the entire hierarchy below the specified instance

[0134] Details: At time 0, all instances below the fault that exist in the design scope are disabled, and then at time 10, all instances below the tb.top.inst scope are enabled.

[0135]

[0136] Example 2: Using level control to disable at different depths from tb.top.inst in a given hierarchy.

[0137] Details: At time 0, all instances with a depth of 3 below tb.top.inst are disabled to find faults that exist inside the design scope tb.top.inst, and then instances with a depth of 2 are re-enabled at time 10.

[0138]

[0139] Example 3: Controlling the type of failure

[0140] Details: In this case, port failure specific propagation is controlled below the hierarchy; in the example below, the hierarchy controls port failure (3) to be disabled at time 0 and enabled at time 10.

[0141]

[0142] Example 4: Control by fault ID

[0143] Details: At time 0, all instances present within the design scope under tb.top.inst are deactivated for fault ID 4, and later at time 10, all instances are re-enabled.

[0144]

[0145] In operation, as mentioned above, the functional checker of some embodiments may run a good machine function check of the circuit and a faulty function check of the circuit. The circuit may include a first component and a second component connected by a wire, and the wire may connect the output of the first component to the input of the second component. Two functional checks may be run simultaneously. In the good machine function check, the functional checker may determine that the output of the first component has a first value at a first point in time, and in the faulty function check of the circuit, the functional checker may determine that the output of the first component has a second value different from the first value at the first point in time. The functional checker may determine that the wire crosses such a barrier based on a runtime input (e.g., based on a call to $faultcontrol to enable a barrier on the wire); and set the value of the input of the second component to the first value at the first point in time in the faulty function check. As used herein, "runtime" refers to a point in time during a functional check, and "compile time" refers to a point in time during the compilation of a digital circuit (e.g., from a hardware description language such as Verilog).

[0146] In some embodiments, barriers on wires may only apply to certain kinds of faults or certain specific faults because runtime input received by the functional checker (e.g., due to a call to $faultcontrol) enables barriers on wires for certain kinds of faults or for certain specific faults (identified by a fault ID). In some embodiments, the runtime input may identify the wires to which barriers are to be applied by specifying a design unit (e.g., in a hierarchical design specified using a hardware description language such as Verilog) and a set of levels of the hierarchy, and the functional checker may set barriers on all wires that cross design unit boundaries at any of the specified levels of the hierarchy. The functional checker may maintain a Boolean variable for each wire in the circuit, the value of which indicates whether a barrier exists on the circuit (or one or more arrays of Boolean variables, each element of which indicates whether a barrier exists for a corresponding fault or for a corresponding fault type).

[0147] The present disclosure also relates to an apparatus for performing the operations described herein. This apparatus may be specifically constructed for the intended purpose, or the apparatus may include a computer that is selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk (including floppy disks, optical disks, CD-ROMs, and magnetic optical disks), read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of medium suitable for storing electronic instructions, each of which is coupled to a computer system bus.

[0148] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various other systems may be used in conjunction with the programs according to the teachings herein, or it may prove convenient to construct more specialized devices to perform the methods. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that the teachings of the present disclosure as described herein may be implemented using a variety of programming languages.

[0149] The present disclosure may be provided as a computer program product or software, which may include a machine-readable medium having instructions stored thereon, which may be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium, such as a read-only memory ("ROM"), a random access memory ("RAM"), a magnetic disk storage medium, an optical storage medium, a flash memory device, etc.

[0150] In the foregoing disclosure, embodiments of the present disclosure have been described with reference to specific exemplary embodiments of the present disclosure. It will be apparent that various modifications may be made to the present disclosure without departing from the broader spirit and scope of the embodiments of the present disclosure as set forth in the following claims. Where the present disclosure refers to some elements in the singular, more than one element may be depicted in each figure, and similar elements are marked with similar numbers. Therefore, the present disclosure and the drawings are to be regarded as illustrative rather than restrictive.

[0151] As used herein, "a portion" of something means "at least some" of that thing, and thus can mean less than all or all of that thing. Thus, "a portion" of a thing includes the entire thing as a specific case, i.e., an example of a portion of the thing. As used herein, the word "or" is inclusive, such that, for example, "A or B" means any of (i) A, (ii) B, and (iii) A and B.

[0152] Each of the terms "processing circuit" and "means for processing" is used herein to mean any combination of hardware, firmware, and software for processing data or digital signals. Processing circuit hardware may include, for example, an application-specific integrated circuit (ASIC), a general or special-purpose central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), and a programmable logic device such as a field programmable gate array (FPGA). As used herein, in a processing circuit, each function is either performed by hardware configured to (i.e., hardwired) perform that function, or by more general hardware (such as a CPU) configured to execute instructions stored in a non-transitory storage medium. The processing circuit may be fabricated on a single printed circuit board (PCB) or distributed over several interconnected PCBs. The processing circuit may contain other processing circuits; for example, the processing circuit may include two processing circuits FPGA and CPU interconnected on a PCB.

[0153] As used herein, when a method (e.g., an adjustment) or a first quantity (e.g., a first variable) is referred to as being “based on” a second quantity (e.g., a second variable), this means that the second quantity is an input to the method or affects the first quantity, for example, the second quantity may be an input (e.g., the only input, or one of several inputs) to a function that calculates the first quantity, or the first quantity may be equal to the second quantity, or the first quantity may be the same as the second quantity (e.g., stored in the same one or more locations in memory as the second quantity).

[0154] It should be understood that although the terms "first", "second", "third", etc. may be used herein to describe various elements, components, regions, layers and / or sections, these elements, components, regions, layers and / or sections should not be limited by these terms. These terms are only used to distinguish one element, component, region, layer or section from another element, component, region, layer or section. Therefore, without departing from the spirit and scope of the present inventive concept, the first element, component, region, layer or section discussed herein may be referred to as a second element, component, region, layer or section.

[0155] As used herein, the singular forms "a" and "an" are also intended to include the plural forms, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising" when used in this specification specify the presence of stated features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items. When preceding a list of elements, expressions such as "at least one of..." modify the entire list of elements and do not modify the individual elements of the list. In addition, when describing embodiments of the inventive concept, "may" is used to refer to "one or more embodiments of the present disclosure." Moreover, the term "exemplary" is intended to refer to an example or illustration. As used herein, the terms "use," "using," and "used" may be considered synonymous with the terms "utilize," "utilizing," and "utilized," respectively.

[0156] It should be understood that when an element or layer is referred to as being "on," "connected to," "coupled to," or "adjacent to" another element or layer, the element or layer may be directly on, directly connected to, directly coupled to, or immediately adjacent to the other element or layer, or one or more intervening elements or layers may be present. In contrast, when an element or layer is referred to as being "directly on," "directly connected to," "directly coupled to," or "immediately adjacent to" another element or layer, there are no intervening elements or layers.

[0157] Figure 3 The diagram illustrates an exemplary set of processes 700 for transforming and verifying design data and instructions representing an integrated circuit during the design, verification, and fabrication of an article of manufacture such as an integrated circuit. Each of these processes may be structured and implemented as multiple modules or operations. The term "EDA" stands for the term "electronic design automation." These processes begin with the creation of a product concept 710 using information provided by a designer, which is transformed to create an article of manufacture using a set of EDA processes 712. When the design is finalized, the design is taped out 734, which is when the artwork (e.g., geometric pattern) of the integrated circuit is sent to a fabrication facility to produce a mask set, which is then used to fabricate the integrated circuit. After tapeout, semiconductor die are fabricated 736, and packaging and assembly processes 738 are performed to produce a finished integrated circuit 740.

[0158] The specification of a circuit or electronic structure can range from low-level transistor material layout to high-level description languages. When using a hardware description language ("HDL") such as VHDL, Verilog, SystemVerilog, SystemC, MyHDL, or OpenVera, a high-level representation can be used to design circuits and systems. The HDL description can be transformed into a logic level register transfer level ("RTL") description, a gate level description, a layout level description, or a mask level description. Each lower level of representation that is described in more detail adds more useful detail to the design description, for example, more detail of the modules that contain the description. The lower level representation that is described in more detail can be computer generated, derived from a design library, or created by another design automation process. An example of a specification language for specifying a more detailed lower level representation language is SPICE, which is used for detailed descriptions of circuits with many analog components. The description at each level of representation can be used by the corresponding system (e.g., a formal verification system) at that level. The design process can use Figure 3 The sequence depicted in . The described process can be implemented by an EDA product (or EDA system).

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

[0160] During logic design and functional verification 716, modules or components in the circuit are specified in one or more description languages, and the functional accuracy of the specifications is checked. For example, the components of the circuit can be checked to generate outputs that match the requirements of the specifications of the designed circuit or system. Functional verification can use functional checkers and other programs, such as test bench generators, static HDL checkers, and formal checkers. In some embodiments, a specific component system called a "simulator" or "prototype system" is used to speed up functional verification.

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

[0162] During netlist verification 720, the netlist is checked for consistency with timing constraints and for correspondence with the HDL code. During design planning 722, the overall floor plan of the integrated circuit is constructed and analyzed for timing and top-level routing.

[0163] During layout or physical implementation 724, physical placement (positioning of circuit components such as transistors or capacitors) and routing (connecting circuit components through multiple conductors) occur, and selection of cells from the library may be performed to implement a specific logic function. As used herein, the term "cell" may specify a group of transistors, other components, and interconnects that provide a Boolean logic function (e.g., AND, OR, NOT, XOR) or a storage function (e.g., a flip-flop or latch). As used herein, a circuit "block" may refer to two or more cells. Both cells and circuit blocks may be referred to as modules or components, and may be implemented as physical structures and functional checks. Parameters such as size are specified for the selected cells (based on "standard cells") and accessed in a database for use by EDA products.

[0164] During analysis and extraction 726, circuit functionality is verified at the layout level, which permits refinement of the layout design. During physical verification 728, the layout design is checked to ensure that manufacturing constraints such as DRC constraints, electrical constraints, lithography constraints, etc. are correct and that the circuit system functionality matches the HDL design specifications. During resolution enhancement 730, the geometry of the layout is transformed to improve how the circuit design is manufactured.

[0165] During tape-out, data is created for use in producing lithography masks (after applying lithography enhancements if appropriate). During mask data preparation 732, the "tape-out" data is used to produce lithography masks, which are used to produce finished integrated circuits.

[0166] Figure 4 An exemplary machine of a computer system 400 is illustrated within which a set of instructions may be executed to cause the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

[0167] The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a web appliance, a server, a network router, a switch or a bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions for performing any one or more of the methodologies discussed herein.

[0168] The exemplary computer system 400 includes a processing device 402, a main memory 404 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM)), a static memory 406 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 418, which communicate with each other via a bus 430.

[0169] The processing device 402 represents one or more processors, such as a microprocessor, a central processing unit, and the like. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets or a processor that implements a combination of instruction sets. The processing device 402 may also be one or more special purpose processing devices (e.g., a special application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, and the like). The processing device 402 may be configured to execute instructions 426 for performing the operations and steps discussed herein.

[0170] The computer system 400 may further include a network interface device 408 to communicate over a network 420. The computer system 400 may also include a video display unit 410 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 412 (e.g., a keyboard), a cursor control device 414 (e.g., a mouse), a graphics processing unit 422, a signal generating device 416 (e.g., a speaker), a graphics processing unit 422, a video processing unit 428, and an audio processing unit 432.

[0171] The data storage device 418 may include a machine-readable storage medium 424 (also referred to as a computer-readable medium) having stored thereon one or more sets of instructions 426 or software embodying any one or more of the methodologies or functions described herein. The instructions 426 may also reside completely or at least partially within the main memory 402 and / or the processing device 400 during execution thereof by the computer system 404, the main memory 404 and the processing device 402 also constituting machine-readable storage media.

[0172] In some embodiments, the instructions 426 include instructions that implement functionality corresponding to the present disclosure. Although the machine-readable storage medium 424 is shown as a single medium in the exemplary embodiment, the term "machine-readable storage medium" should be considered to include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) that store one or more sets of instructions. The term "machine-readable storage medium" should also be considered to include any medium that can store or encode a set of instructions for execution by a machine and cause the machine and processing device 402 to perform any one or more of the methods of the present disclosure. Therefore, the term "machine-readable storage medium" should be considered to include, but not limited to, solid-state memory, optical media, and magnetic media.

[0173] Certain portions of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are methods used by those skilled in the art to most effectively convey the substance of their work to other skilled in the art. An algorithm may be a series of operations leading to a desired result. The operations are those that require physical manipulation of physical quantities. Such quantities may take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Such signals may be referred to as bits, values, elements, symbols, characters, terms, numbers, and the like.

[0174] It should be remembered, however, that all of these terms and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise specifically stated, it should be apparent from this disclosure that throughout this specification, it should be understood that certain terms refer to actions and processes of computer systems or similar electronic computing devices that manipulate and transform data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage devices.

[0175] The present disclosure also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the intended purpose, or the apparatus may include a computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory computer-readable storage medium, such as, but not limited to, any type of disk (including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks), read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of medium suitable for storing electronic instructions, each of which is coupled to a computer system bus.

[0176] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various other systems may be used in conjunction with programs according to the teachings herein, or various other systems may prove convenient to construct more specialized devices to perform the methods. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that various programming languages ​​may be used to implement the teachings of the present disclosure as described herein.

[0177] The present disclosure may be provided as a computer program product or software, which may include a machine-readable medium having instructions stored thereon, which may be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium, such as a read-only memory ("ROM"), a random access memory ("RAM"), a magnetic disk storage medium, an optical storage medium, a flash memory device, etc.

[0178] In the foregoing disclosure, embodiments of the present disclosure have been described with reference to specific exemplary embodiments of the present disclosure. It will be apparent that various modifications may be made to the present disclosure without departing from the broader spirit and scope of the embodiments of the present disclosure as set forth in the following claims. Where the present disclosure refers to some elements in the singular, more than one element may be depicted in each figure, and similar elements are marked with similar numbers. Therefore, the present disclosure and the drawings should be regarded as illustrative rather than restrictive.

Claims

1. A method comprising: determining, during a nominal function test of the circuit, that an output of a first component has a first value at a first point in time, the output of the first component being connected to an input of a second component via a conductor; determining in a fault-functional test of the circuit that the output of the first component has a second value different from the first value at the first point in time; determining, based on runtime input, that the wire crosses a potential barrier; and During the fail-safe test, at the first point in time the value of the input of the second component is set to the first value. 2 . The method of claim 1 , wherein the potential barrier is a potential barrier surrounding a first design cell, the first design cell containing the first component.

3. The method according to claim 2, wherein: The first design unit is contained in a second design unit, the second design unit is a higher level in the design hierarchy, and The potential barrier is inherited by the first design unit from the second design unit.

4. The method according to claim 1, further comprising: determining that the first time point belongs to a first time interval, the first time interval being a time interval during which the potential barrier is enabled, Wherein setting the value of the input of the second component includes setting the value of the input of the second component based on determining that the first time point belongs to the first time interval.

5. The method according to claim 1, further comprising: determining that the second value is associated with a first fault; as well as determining that the barrier is associated with the first fault, wherein setting the value of the input of the second component comprises setting the value of the input of the second component based on: said determining that said second value is associated with said first fault; and The determining the barrier is associated with the first fault.

6. The method according to claim 1, further comprising: determining that the second value is associated with a fault of a first fault type; as well as determining that the barrier is associated with the first fault type, wherein setting the value of the input of the second component comprises setting the value of the input of the second component based on: said determining that said second value is associated with a fault of said first fault type; and The determining the barrier is associated with the first fault type.

7. A system comprising: Processing circuit; as well as a non-transitory computer-readable medium connected to the processing circuit, the non-transitory computer-readable medium storing instructions that, when executed by the processing circuit, cause the processing circuit to perform a method comprising: determining, during a nominal function test of the circuit, that an output of a first component has a first value at a first point in time, the output of the first component being connected to an input of a second component via a conductor; determining in a fault-functional test of the circuit that the output of the first component has a second value different from the first value at the first point in time; determining that the wire passes through a potential barrier; determining that the second value is associated with a fault of a first fault type; determining that the barrier is associated with the first fault type; and In the fail-safe function test, at the first point in time, the value of the input of the second component is set to the first value based on: said determining that said second value is associated with a fault of said first fault type; and The determining the barrier is associated with the first fault type.

8. The system of claim 7, wherein the potential barrier is a potential barrier surrounding a first design unit, the first design unit containing the first component.

9. The system of claim 8, wherein: The first design unit is contained in a second design unit, the second design unit is a higher level in the design hierarchy, and The potential barrier is inherited by the first design unit from the second design unit. 10 . The system of claim 9 , wherein the determining that the wire crosses the potential barrier comprises determining that the wire crosses the potential barrier based on a runtime input.

11. The system of claim 7, wherein the method further comprises: determining that the first time point belongs to a first time interval, the first time interval being a time interval during which the potential barrier is enabled, Wherein setting the value of the input of the second component includes setting the value of the input of the second component based on determining that the first time point belongs to the first time interval.

12. The system of claim 7, wherein the method further comprises: determining that the second value is associated with a first fault; as well as determining that the barrier is associated with the first fault, wherein setting the value of the input of the second component comprises setting the value of the input of the second component based on: said determining that said second value is associated with said first fault; and The determining the barrier is associated with the first fault. 13 . The system of claim 12 , wherein the determining that the wire crosses the potential barrier comprises determining that the wire crosses the potential barrier based on a runtime input.

14. A system comprising: Processing circuit; as well as a memory connected to the processing circuit, the memory storing instructions which, when executed by the processing circuit, cause the processing circuit to perform a method comprising: determining, during a nominal function test of the circuit, that an output of a first component has a first value at a first point in time, the output of the first component being connected to an input of a second component via a conductor; determining in a fault-functional test of the circuit that the output of the first component has a second value different from the first value at the first point in time; determining, based on runtime input, that the wire crosses the potential barrier; and During the fail-safe test, at the first point in time the value of the input of the second component is set to the first value.

15. The system of claim 14, wherein the potential barrier is a potential barrier surrounding a first design cell, the first design cell containing the first component.

16. The system of claim 15, wherein: The first design unit is contained in a second design unit, the second design unit is a higher level in the design hierarchy, and The potential barrier is inherited by the first design unit from the second design unit.

17. The system of claim 14, wherein the method further comprises: determining that the first time point belongs to a first time interval, the first time interval being a time interval during which the potential barrier is enabled, Wherein setting the value of the input of the second component includes setting the value of the input of the second component based on determining that the first time point belongs to the first time interval.

18. The system of claim 14, wherein the method further comprises: determining that the second value is associated with a first fault; as well as determining that the barrier is associated with the first fault, wherein setting the value of the input of the second component comprises setting the value of the input of the second component based on: said determining that said second value is associated with said first fault; and The determining the barrier is associated with the first fault.

19. The system of claim 14, wherein the method further comprises: determining that the second value is associated with a fault of a first fault type; as well as determining that the barrier is associated with the first fault type, wherein setting the value of the input of the second component comprises setting the value of the input of the second component based on: said determining that said second value is associated with a fault of said first fault type; and The determining the barrier is associated with the first fault type.

20. The system of claim 19, wherein the barrier is a barrier surrounding a first design cell, the first design cell containing the first component.

Images