LU100321B1 - Method for formal circuit verification - Google Patents

Abstract

A computer-implemented method for calculation and display of a fault propagation path. The method identifies with a computing device a fault location in an electrical circuit under test, identifies with the computing device an observation point in the electrical circuit under test, computes with the computing device a fault path from the fault location to the observation point, and displays in a waveform viewer all signals in the fault path from the fault location to the observation point in order of their creation.

Description

Descriptiondescription

BACKGROUND OF THE INVENTIONBACKGROUND OF THE INVENTION

Field Of The Invention [0001] The present invention relates to analysis and debugging of circuit designs, and more particularly, to formal verification of circuit designs with fault injection.Field Of The Invention [0001] The present invention relates to analysis and debugging of circuit designs, and more particularly, to formal verification of circuit designs with fault injection.

Brief Description Of The Related Art [0002] Many industries, such as the automotive industry, have incorporated sophisticated electronics into their products and services. Welcome though these advances are, it is critical to understand that the electronic systems enabling these features also present countless new opportunities for things to go wrong if they are not adequately verified. A defective headrest video screen may be an irritation to a young passenger in the back seat, but a malfunctioning corrective steering system could cost the occupants of the vehicle their lives. These risks have caused industries to adopt stringent safety-related standards for electrical or electronic systems.Brief Description Of The Related Art [0002] Many industries, such as the automotive industry, have incorporated sophisticated electronics into their products and services. They are not adequately verified. A defective headrest video screen may be subject to irritation to a young passenger in the back seat, but a malfunctioning corrective steering system could cost the occupants of the vehicle their lives. These risks have led to the adoption of stringent safety-related standards for electrical or electronic systems.

[0003] For example, the ISO 26262 standard governs the development of safety-related electrical and/or electronic (E/E) systems within road vehicles. ISO 26262 imposes stringent requirements that encompass the entire life cycle of a system, from concept phase to development, production, and decommissioning. It addresses the overall safety management process and covers relations with suppliers and interfaces for distributed development. The risk of liability is a clear driver of the adoption of the ISO 26262 standard, but there is more at stake: vehicle recalls in the millions and malfunctions leading to fatal car accidents not onl^u cause economic damage, but also diminish the brand image of the companies involved. The standard specifies two types of component faults, which must be fully verified, systematic faults and random faults.[0003] For example, the ISO 26262 standard governs the development of safety-related electrical and / or electronic (E / E) systems within road vehicles. ISO 26262 imposes stringent requirements that encompass the entire life cycle of a system, from concept phase to development, production, and decommissioning. It addresses the overall safety management process and covers relations with suppliers and interfaces for distributed development. The risk of liability is a clear driver of the adoption of the ISO 26262 standard, but there is more at stake: vehicle recalls in the millions and malfunctions leading to fatal car accidents not onl cause economic damage, but so diminish the brand image of the companies involved. The standard specifies two types of component faults, which must be verified, systematic faults and random faults.

[0004] Systematic faults are introduced during component development, either through human error or tool/methodology malfunction. Systematic faults typically are handled through rigorous verification and the careful tracking of specific device requirements. Random faults occur during the actual operation of the device due to external effects. These faults must be safely handled by the circuitry within the device. This requires the use of fault handling capabilities built into the systems, which must in turn be verified to ensure that they will catch the vast majority of possible random faults.[0004] Systematic faults are introduced during component development, either through human error or tool / methodology malfunction. Systematic faults are handled through rigorous verification and careful tracking of specific device requirements. Random faults occur during the actual operation of the device due to external effects. These faults must be handled by the circuitry within the device. They must catch the large majority of possible random faults.

[0005] Over the past several years, automotive suppliers have made substantial investments to meet ISO 26262 requirements, often leading to significant increases in development costs. Maturing the application of the standard and moving towards systematic and automated development methods is critical to achieve and sustain success.Over the past several years, automotive suppliers have made substantial investments to meet ISO 26262 requirements, often leading to significant increases in development costs. Maturing the application of the standard and moving towards systematic and automated development methods is critical to achieve and sustain success.

[0006] Thanks to ease-of-use and capacity advances, formal-based verification methodologies have achieved recent wide adoption in the industry. Formal verification is widely recognized as a powerful technique to uncover hardware design bugs that might otherwise escape simulation-based verification and lead to systematic failures. A key characteristic of formal tools is the ability to examine design behavior exhaustively, without the need for input stimuli, and prove that the design never deviates from its intended function, as specified by a property or assertion. Even for simple designs, simulation tools cannot achieve this level of precision. Formal tools have multiple applications for both systematic and random fault verification.[0006] Thanks to ease-of-use and capacity advances, formal-based verification methodologies have been recently adopted in the industry. Formal verification is widely recognized as a powerful technique to uncover hardware design. A key characteristic of formal tools is the ability to examine design behavior exhaustively, without the need for input stimuli, and that the design never deviates from its intended function, as specified by a property or assertion. Even for simple designs, simulation tools can not achieve this level of precision. Formal tools have multiple applications for both systematic and random failure verification.

[0007] Failures happen when an element of a system no longer performs its required fund-L tion. They are caused by errors, such as a hardware component not behaving as expected. Errors are caused by faults either in the design of the device, or occurring during its operation. Examples of such errors in an automotive environment and possible causes are shown in FIG. 1.[0007] Failures happen when an element of a system no longer performs its required fund-L tion. They are caused by errors, as a hardware component does not behaving as expected. Errors are caused by faults either in the design of the device, or during its operation. Examples of such errors in an automotive environment and possible causes are shown in FIG. 1.

[0008] ISO 26262 defines two categories of failures: systematic and random. Systematic failures can originate in both hardware and software, and have a deterministic relation to certain causes or faults, for example, specification or coding mistakes in software or hardware code. These faults affect all manufactured components and must be avoided. Random failures originate only in hardware and occur in an unpredictable fashion that generally follows a probability distribution. They cannot be traced back to specific problems and are expected to occur during system operation. A good example is radiation corrupting a DRAM memory during device operation. Note that random component failure might be seen as a systematic fault at the vehicle level.[0008] ISO 26262 defines two categories of failures: systematic and random. Systematic failures can originate in both hardware and software, and have a deterministic relation to certain causes or faults, for example, specification or coding mistakes in software or hardware code. These faults affect all components and must be avoided. Random failures originate only in hardware and occur in an unpredictable fashion. They can not be traced back to specific problems and are expected to occur during system operation. A good example is radiation corrupting a DRAM memory during device operation. Note that random component failure might be seen as a systematic failure at the vehicle level.

[0009] ISO 26262 prescribes the use of safety measures to avoid systematic faults and safeguard against random hardware faults. Formal tools can play a significant role in implementing safety measures efficiently, and indeed are central in many safety-critical development flows.[0009] ISO 26262 prescribes the use of safety measures to avoid systematic faults and safeguards against random hardware faults. Formal tools can play a significant role in implementing safety measures efficiently, and indeed are central to many safety-critical development flows.

[0010] Rigorous development processes are key to reducing the risk of systematic faults in a system, introduced through human error. Advanced hardware development flows employ many tools and methods to detect issues as early as possible, plan verification activities, and track progress. ISO 26262-8 clause 6, however, demands an accurate tracing of requirements throughout the relevant development steps. The ultimate goal is to ensure that a product satisfies its safety requirements. This involves tracking a large number of bidirectional, many-to- many relationships, mapping requirements through design features to verification plan eleP-ments, and finally, to feedback test coverage data to all these documents.Rigorous development processes are key to reducing the risk of systematic faults in a system, introduced by human error. Advanced hardware development flows employing many tools and methods to detect early as possible, plan verification activities, and track progress. ISO 26262-8 clause 6, however, demands an accurate tracing of requirements throughout the relevant development steps. The ultimate goal is to ensure that a product satisfies its safety requirements. This involves tracking a large number of bidirectional, many-to-many relationships, mapping requirements through design features to verification plan.

[0011] For the functional verification of Register Transfer Language (RTL) models, engineers apply a variety of techniques, including directed and random coverage-driven simulation tests. Structural and functional coverage metrics are used to track progress and highlight gaps in the verification plan or specification documents.[0011] Register transfer language (RTL) models, engineers apply a variety of techniques, including directed and random coverage-driven simulation tests. Structural and functional coverage metrics are used to track progress and highlight gaps in the verification plan or specification documents.

[0012] Simulation-based verification environments often rely on centralized checks and thus suffer from low design observability. Even when a test activates a design feature that is not correctly implemented, the erroneous behavior could go undetected unless it propagates to an observation point (or checker). ISO 26262 specifies that requirements must be individually tested and this testing process carefully tracked, as shown in Figure 4. For simulation, typically this involves creating individual, directed tests, which can be laborious and error-prone. [0013] Assertion-based verification (ABV) is a well-established technique that addresses this issue. Assertions are flexible and can concisely express the expected design behavior at both low and abstract levels. They are distributed and always-on checkers that—crucially, in this context—may map more directly to requirements. Another key benefit of ABV is that formal tools can leverage assertions and examine them under all relevant stimuli scenarios. Moreover, with adequate tools and methodology, it is also possible to construct a set of nonoverlapping assertions capturing all design requirements. Assertions, specifically end-to-end properties, can be easier to map to requirements through the implementation and verification plan. By leveraging ABV, the entire verification tracking mechanism is simplified through direct correlations between requirements and tests.Simulation-based verification environments often rely on centralized checks and hence suffer from low design observability. Even when a test activates that is not correctly implemented, the erroneous behavior could go undetected unless it propagates to an observation point (or checker). ISO 26262 requires that it must be tested and tested carefully. Assertion-based verification (ABV) is a well-established technique that addresses this issue. Assertions are flexible and can concisely express the expected design behavior at both low and abstract levels. They are distributed and always-on checkers that-crucially, in this context-map more directly to requirements. Another key benefit of ABV is that they are able to leverage assertions and examine them under all relevant stimuli scenarios. Moreover, with adequate tools and methodology, it is possible to construct a set of nonoverlapping assertions capturing all design requirements. Assertions, specifically end-to-end properties, can be made easier to map through the implementation and verification plan. By leveraging ABV, the entire verification tracking mechanism is simplified through direct correlations between requirements and tests.

[0014] Safety mechanisms are a class of safety measures built into the device, intended to detect faults or control failures, as shown in FIG. 2. ISO 26262 may require the use of safety mechanisms to detect, and possibly correct, the effects of some random hardware faults. Safe ty mechanisms are implemented in both software and hardware, and their ultimate goal is reduce the occurrence of random failures that could lead to violations of safety goals.Safety mechanisms are a class of safety measures built into the device, intended to detect faults or control failures, as shown in FIG. 2. ISO 26262 may require the use of safety mechanisms to detect and possibly correct the effects of some random hardware faults. Safe ty mechanisms are being implemented in both software and hardware, and their ultimate goal is to reduce the occurrence of random failures.

[0015] Software-based mechanisms include routines that run periodically to detect hardware errors, mostly caused by permanent faults or latent transient faults. Another example is redundant software performing the same operation multiple times and comparing results. One of the challenges is to detect as many faults as possible, while limiting the size and run time of the code.Software-based mechanisms include routines that run periodically to detect hardware errors, often caused by permanent faults or latent transient faults. Another example is redundant software performing multiple times and comparing results. One of the challenges is as many as possible, while limiting the size and run time of the code.

[0016] Redundancy is the foundation of many hardware-based safety mechanisms. Common techniques include: having a processor core running in lockstep with a duplicate core and comparing results; duplication or even triplication of critical modules or configuration registers with the addition of majority-voting logic (triple modular redundancy); failsafe encoders and decoders to protect memories or bus transactions (EDC/ECC); detecting and correcting single-bit errors; and detecting double bit errors.Redundancy is the foundation of many hardware-based safety mechanisms. Common techniques include: having a processor core running in lockstep with a duplicate core and comparing results; duplication or even triplication of critical modules or configuration registers with the addition of majority-voting logic (triple modular redundancy); failsafe encoders and decoders to protect memories or bus transactions (EDC / ECC); detecting and correcting single-bit errors; and detecting double bit errors.

[0017] Hardware-based safety mechanisms significantly complicate all stages of development, including physical implementation, as they increase circuit area and make it harder to achieve the target clock frequency.Hardware-based safety mechanisms are increasingly complicate all stages of development, including physical implementation, as they increase circuit area and make it harder to achieve the target clock frequency.

[0018] The development of hardware safety mechanisms must follow a rigorous process to avoid systematic faults. The functional verification of the RTL model implementing a safety mechanism is a critical activity, as mistakes could lead to hardware that causes dangerous situations rather than preventing them. ISO 26262-5 addresses all hardware-specific development activities, and their requirements include a quantitative analysis of the effectiveness of safety mechanisms. Faults are classified according to the categories safe, single point, residual and multipoint. Safe faults are faults that are not in the safety relevant parts of the logic or are in the safety relevant logic but are unable to impact the design function, i.e., they cannot violate a safety goal. Single point faults are dangerous because they can violate a safety goal and there is no safety mechanism to protect against them. Residual faults also are dangerous bd-u cause they can violate a safety goal and escape the safety mechanism. Multipoint faults can violate a safety goal but are observed by a safety mechanism. The multipoint faults can be subclassified as “detected,” “perceived” and “latent.” [0019] Within the present context, multipoint faults and safe faults are not dangerous. However, identifying them is challenging. Safety-critical hardware may include a variety of safety mechanisms, and engineers must analyze the effects of several fault types on millions of potential fault locations interconnected by complex logic.[0018] The development of hardware safety mechanisms must follow a rigorous process to avoid systematic faults. The functional verification of the RTL model implementing a safety mechanism is not as critical as it might be. ISO 26262-5 addresses all hardware-specific development activities, and their requirements include a quantitative analysis of the effectiveness of safety mechanisms. Faults are classified as safe, single point, residual and multipoint. They are not in the safety relevant logic, but they can not violate a safety goal. Single point faults are dangerous because they can violate a safety goal and there is no safety mechanism to protect against them. Residual faults are therefore dangerous bd-u cause they can violate a safety goal and escape the safety mechanism. Multipoint faults can violate a safety goal but are observed by a safety mechanism. The multipoint faults can be subclassified as "detected," "perceived," and "latent." Within the present context, multipoint faults and safe faults are not dangerous. However, identifying them is challenging. Millions of potential fault locations are interconnected by complex logic.

[0020] It is not trivial to confidently mark a fault as safe. Without adequate tools, only experts with intimate knowledge of the hardware can reach this conclusion. Similarly, expert engineering effort might be required to develop simulation workloads that can demonstrate the ability of a safety mechanism to observe a fault. Hardware teams for ASIL C or ASIL D applications have to demonstrate that only an extremely low proportion of dangerous faults can have an operational effect on their designs. Consequently, the ability to identify safe and multipoint faults automatically is critical to achieve this goal efficiently.It is not trivial to confidently mark a fault as safe. Without adequate tools, only experts with intimate knowledge of the hardware can reach this conclusion. Similarly, the engineering effort may be required to develop a simulation. Hardware teams for ASIL C or ASIL D applications have to demonstrate that they have an extremely low proportion of dangerous faults. Consequently, the ability to identify and multiply faults automatically is critical to achieve this goal.

[0021] Fault injection is an established technique used to understand the effects of faults on fault-tolerant systems. ISO 26262 highly recommends the use of fault injection during the development of safety-critical hardware. To take into account operating conditions and full system interactions, fault injection should be performed on a system prototype. For example, instruments can be used to create heavy ion radiation, electromagnetic interference, power supply disturbances, or software issues that corrupt the content of memories or architecturally visible registers. Haissam Ziade, Rafic Ayoubi, and Raoul Velazco, “A Survey on Fault Injection Techniques. The International Arab Journal of Information Technology,” Vol. 1, No. 2, July 2004. However, this method is challenging in terms of cost, controllability and observability of the system, and development schedule. Model-based fault injection can be performed early in the development flow and provides finer control over the system without being invd-u sive: that is, the fault injection mechanism has no effect on the system other than the faults it injects. Ashish Darbari, Bashir A1 Hashimi, Peter Harrod and Daryl Bradley, “A New Approach for Transient Fault Injection using Symbolic Simulation,” 14th IEEE International On-Line Testing Symposium 2008.[0021] Fault injection is an established technique used to understand the effects of defects on fault-tolerant systems. ISO 26262 highly recommends the use of fault injection during the development of safety-critical hardware. It should be carried out on a system prototype. For example, the device may be subject to heavy ion radiation, electromagnetic interference, power supply disturbances, or software issues. Haissam Ziade, Rafic Ayoubi, and Raoul Velazco, "A Survey on Fault Injection Techniques. The International Arab Journal of Information Technology, Vol. 1, no. 2, July 2004. However, this method is challenging in terms of cost, controllability and observability of the system, and development schedule. Model-based Fault Injection is the result of a Fault-on-the-Mechanism of Injection. Ashish Darbari, Bashir A1 Hashimi, Peter Harrod and Daryl Bradley, "A New Approach to Transient Fault Injection Using Symbolic Simulation," 14th IEEE International On-Line Testing Symposium 2008.

[0022] The safety analysis of complex automotive SoCs including a variety of safety mechanisms poses many challenges. Precisely identifying the safety-critical implementation logic is no small matter. The number of fault locations to consider can be on the order of millions.The safety analysis of complex automotive SoCs including a variety of safety mechanisms poses many challenges. Precisely identifying the safety-critical implementation logic is no small matter. The number of fault locations can be considered on the order of millions.

Several types of permanent and transient faults can be injected in a fault location, and the effect of a number of simultaneous faults might have to be analyzed under different workloads. The number of relevant fault scenarios is huge.Several types of permanent and transient faults may be in a fault location, and the effect of a number of simultaneous faults may have been analyzed under different workloads. The number of relevant fault scenarios is huge.

[0023] In recent years, there has been progress in the availability of tools to perform fault injection on hardware models. While existing simulators can perform clumsy fault injection by using generic interface commands, the re-emergence of fault simulators, previously designed for the qualification of manufacturing tests, has brought substantial benefit to engineers in terms of enabling precise metrics and debug.In recent years, there has been a failure in hardware development. While existing simulators can perform clumsy fault injection by means of generic interface commands, the re-emergence of fault simulators, previously designed for the qualification of manufacturing tests, has been found to have substantial benefit to engineers.

[0024] Fault propagation analysis is used to classify faults and derive diagnostic coverage metrics. This task may be performed on RTL models but, according to ISO 26262 stipulations, will ultimately have to be performed on a 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. This requires running the analysis on gate-level netlists. [0025] Fault simulation is a standard approach to determine fault metrics. Fault simulators inject faults and analyze their propagation under user-defined input stimuli. Faults causing errors that are detected by a safety mechanism contribute to achieving the desired detection ratio. Faults not activated or propagated by the input stimuli consume a large proportion of the simulation cycles, while remaining in the “potentially propagatable” group. These faults arleu difficult to debug when considering stimulus improvements. In fact, a significant portion of them could be safe or “non-propagatable.” Safe faults can never lead to a malfunction of the system, regardless of its state. Engineers may use “expert judgment” arguments to mark some faults as safe, thus increasing diagnostic coverage.[0024] Fault propagation analysis is used to classify faults and derive diagnostic coverage metrics. This task may, however, be performed according to ISO 26262 stipulations, and thus ultimately requires to be performed as well as possible on physical parameters, such as circuit area. This requires the analysis on gate-level netlists. [0025] Fault simulation is a standard approach to determine fault metrics. Fault simulators inject faults and analyze their propagation under user-defined input stimuli. The desired detection ratio. Faults not activated or propagated by the input stimuli consume a large proportion of the simulation cycles, while remaining in the "potentially propagatable" group. These faults are difficult to debug when considering stimulus improvements. In fact, a significant portion of them could be safe or "non-propagatable." Safe faults can never lead to a malfunction of the system, regardless of its state. Engineers may use "expert judgment".

[0026] Even modem fault simulators, however, have inherent shortcomings. The analysis of faults is inefficient with respect to both the fault scenarios (some simulators requiring one run per scenario) and the specific workload, or input vectors, applied to the model (simulators only execute one workload at a time). Moreover, to achieve the target ASIL diagnostic coverage—the metric specifying the number of safe faults—engineers may have to manually identify safe faults, create complex tests that can activate and propagate tricky faults to safety logic, and define the boundaries of safety-critical logic. These tasks are effort-intensive, error-prone, and intrinsically incomplete.Even modem fault simulators, however, have inherent shortcomings. The analysis of faults is inefficient with respect to both the fault scenarios (some simulators requiring one run scenario) and the specific workload, or input vectors, applied to the model (simulator only execute one workload at a time). Moreover, to achieve the goal of ASIL diagnostic coverage-the metric specifying the number of safe-faults-engineers may have to manually identify faults-faults, create complex tests that can trigger and propagate faults to safety-logic, and define the boundaries of safety-critical logic. These tasks are effort-intensive, error-prone, and intrinsically incomplete.

[0027) Formal verification is widely recognized as a powerful technique to uncover hardware design bugs that might otherwise escape simulation-based verification and lead to systematic failures. A key characteristic of formal tools is the ability to examine design behavior exhaustively, without the need for input stimuli, and prove that the design never deviates from its intended function, as specified by a property or assertion. Even for simple designs, simulation tools cannot achieve this level of precision. Formal tools have multiple applications for both systematic and random fault verification.[0027] Formal verification is also widely known as a powerful technique to uncover hardware design. A key characteristic of formal tools is the ability to examine design behavior exhaustively, without the need for input stimuli, and that the design never deviates from its intended function, as specified by a property or assertion. Even for simple designs, simulation tools can not achieve this level of precision. Formal tools have multiple applications for both systematic and random failure verification.

[0028] "Formal methods" refers to mathematically rigorous techniques and tools for the specification, design, and verification of software and hardware systems. While formal property-checking tools have been available for decades, in the last ten years, thanks to advances in ease-of-use and capacity, formal-based methodologies have achieved wide adoption in the semiconductor industry. Formal verification is widely recognized as a powerful technique to uncover hardware design bugs that might otherwise escape simulation-based verification anldU lead to systematic failures.[0028] "Formal methods" refer to mathematically rigorous techniques and tools for the specification, design, and verification of software and hardware systems. While formal property-checking tools have been released for decades, in the past ten years, thanks to advances in ease-of-use and capacity, formal-based methodologies have become widely adopted in the semiconductor industry. Formal verification is widely recognized as a powerful technique to uncover hardware design.

[0029] A key characteristic of formal tools is the ability to examine design behavior exhaustively, without the need for input stimuli, and prove that the design never deviates from its intended function, as specified by a property or assertion. Even for simple designs, simulation tools cannot achieve this level of precision. A range of hardware development tasks has been improved through the use of appropriate formal-based solutions (or apps). These range from RTL design exploration and formal linting to the end-to-end verification of critical modules.A key characteristic of formal tools is the capability to examine design behavior exhaustively, without the need for input stimuli, and prove that the design never deviates from its intended function, as specified by a property or assertion. Even for simple designs, simulation tools can not achieve this level of precision. A range of hardware development tasks has been improved through the use of appropriate formal-based solutions (or apps). These range from RTL design exploration and formally linting to the end-to-end verification of critical modules.

[0030] Another key characteristic of formal tools, particularly relevant to safety-critical applications, is the ability to finely control the injection of faults into hardware models and analyze their sequential effects. Crucially, formal tools have the potential to perform this task very efficiently, in terms of both user effort and computational demands, and non-invasively (no need for code instrumentation steps).Another key characteristic of formal tools, particularly relevant to safety-critical applications, is the ability to finely control the injection of faults into hardware models and analyze their sequential effects. Crucially, formal tools have the potential to perform this task very efficiently, in terms of both user effort and computational demands, and non-invasively (no need for code instrumentation steps).

[0031] As part of the safety verification process, it often is necessary to understand how faults propagate through an integrated circuit. Examples of prior systems and methods for waveform or propagation analysis are disclose din U.S. Patent No. 8,630,824 and U.S. Patent Application Publication No. 2016/0283628.As part of the safety verification process, it is often necessary to understand how faults propagate through an integrated circuit. Examples of prior systems and methods for waveform or propagation analysis are disclose in U.S. Pat. Patent No. 8,630,824 and U.S. Pat. Patent Application Publication No. 2016/0283628.

[0032] Conventional fault propagation systems and methods often display a golden design and the faulty design next to one another, showing the value of signals in the golden design versus the design with the fault injected. Such conventional environments might be able to list all internal signals where the values are different between the golden design and the faulty design but they typically would display signals which are different, including signals that are irrelevant to the fault debug. SUMMARY OF THE INVENTION [0033] In a preferred embodiment, the present invention is a system and method for analysing faults and displaying a fault propagation path inside a waveform debugger. In the system, a computing device having processor and memory has a fault injection module or application for injecting fault into the circuit design. The computer device further has a fault propagation module or application and/or a fault detection module or application for detecting faults and tracking the propagation of the faults (e.g., signals) through the circuit design. A fault location for injecting a fault and an observation point are identified. The observation point in the circuit design is a point where errors can have a dangerous impact. The system has a display for displaying a signal path in an ordered list from the fault location to the observation point(s) whereby each signal inside the path has been impacted by the fault. “Impacted” refers to the value in the design between different than what the value would be in a golden design. Only one waveform is shown for a given signal. The impacted signals are shown in a different color (e.g., red) than the non-impacted signals. The signals are displayed in the timing domain, which results in a “stepladder” in a different color showing host the fault moves forward from one signal to the next. 10034] In another preferred embodiment, the present invention is a system and computer-implemented method for calculation and display of a fault propagation path. The method includes the steps of identifying with a computing device a fault location in an electrical circuit, identifying with said computing device an observation point in the electrical circuit, computing with said computing device a fault path from said fault location to said observation point; and displaying in a waveform viewer all signals in said fault path from said fault location to said observation point in order of their creation. The step of computing a fault path may comprise computing the shortest path of impacted signals from the fault location to the observation point. The step of computing the shortest fault path may comprise computing the shortest path in terms of the number of signals, computing the shortest path in terms of thlgL number of instances or computing the shortest path in terms of the number of registers.Conventional propagation systems and methods often display a golden design and the faulty design next to one another, showing the value of signals in the golden design versus the design with the fault injected. What are the differences between these and the faulty design? SUMMARY OF THE INVENTION In a preferred embodiment, the present invention is a system for analyzing and displaying a fault. In the system, a computing device having processor and memory has a fault injection module or application for injecting fault into the circuit design. The computer device has a fault propagation module or application and / or a fault detection module. A fault location for injecting a fault and an observation point are identified. The observation point in the circuit design is a point where errors can have a dangerous impact. The signal has been signaled in the path of the fault. "Impacted" refers to the value in the design between different than what the value would be in a golden design. Only one waveform is shown for a given signal. The impacted signals are shown in a different color (e.g., red) rather than the non-impacted signals. The signals are displayed in the timing domain, which results in a "stepladder" in a different color. The method includes the steps of the invention, which is incorporated herein by reference in its entirety Fault location to said observation point; and displaying in a fault. The shortest path of impacted signals from the fault location to the observation point. The shortest path in terms of the number of signals, the shortest path in terms of the number of instances or computing the shortest path in terms of the number of registers.

[0035] The step of computing a fault path may comprise (a) entering an observation point in a current signal list, (b) comparing each signal on the current signal list with an impacted signal list, (c) for each compared signal, if the signal is not on the impacted signal list, doing nothing with respect to that signal, (d) for each compared signal, if the signal is on the impacted signal list, checking if the signal is the fault location, (e) for each compared signal on the impacted signal list, if the signal is the fault location skipping to step (h), (f) for each compared signal on the impacted signal list, if the signal is not the fault location adding the fanin signals of the signal to a next current signal list and storing the signal as the parent of the added fanin signals, (g) making the next current signal list the current signal list and returning to step b, (h) setting the fault locations at the path signal, (i) determining if the path signal has a parent signal, (j) if the path signal has a parent signal, using the parent a new path signal, storing the new path signal in a path list, and returning to step i for the new path signal, and(k) if the path signal does not have a parent signal, outputting the path of impacted signals as the shortest fault path to the waveform viewer.[0035] (b) comparing each signal on the current signal list with an amplified signal list, (c) for each compared signal, (d) for each signaled signal, if the signal is on the impacted signal, (f) for each signal on the impacted signal list, (f) for each signal on the impacted signal list (h) setting the fault locations at the path signal , (i) determining if the path signal has a parent signal, (j) if the p ath signal has a parent signal, storing the new path signal, and returning to step signal, and (k) if the path signal does not have a parent signal , outputting the path of impacted signals as the shortest fault path to the waveform viewer.

[0036] Still other aspects, features, and advantages of the present invention are readily apparent from the following detailed description, simply by illustrating a preferable embodiments and implementations. The present invention is also capable of other and different embodiments and its several details can be modified in various obvious respects, all without departing from the spirit and scope of the present invention. Accordingly, the drawings and descriptions are to be regarded as illustrative in nature, and not as restrictive. Additional objects and advantages of the invention will be set forth in part in the description which follows and in part will be obvious from the description, or may be learned by practice of the invention.Still other aspects, features, and advantages of the present invention are not apparent from the following detailed description, simply by way of illustrating a preferred embodiment and implementation. The present invention is thus capable of being varied in various respects, all without departing from the spirit and scope of the present invention. Accordingly, the drawings and descriptions are to be regarded as illustrative in nature, and not as restrictive. The invention also seeks to further clarify and further explain the invention.

BRIEF DESCRIPTION OF THE DRAWINGSLETTER OF THE DRAWINGS

[0037] For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following description and the accompanying drawings, in which: [0038] FIG. 1 is a diagram illustrating various types of faults that may occur in a safety critical system and exemplary results of such faults.For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following description and the accompanying drawings in which: FIG. 1 is a diagram of various types of faults that may occur in a safety critical system.

[0039] FIG. 2 is a diagram illustrating a general safety critical system having a hardware safety mechanism.FIG. 2 is a diagram illustrating a general safety critical system.

[0040] FIG. 3 is a system architecture diagram of a system for analyzing and displaying fault propagation in accordance with a preferred embodiment of the present invention.FIG. 3 is a system architecture diagram of a system for analyzing and displaying fault propagation in accordance with a preferred embodiment of the invention.

[0041] FIG. 4 is a flow chart of a method for analyzing and displaying fault propagation in accordance with a preferred embodiment of the present invention.FIG. 4 is a flowchart of a method for analyzing and displaying fault propagation in accordance with a preferred embodiment of the invention.

[0042] FIG. 5 is an illustration of a display of a system for analyzing and displaying fault propagation in accordance with a preferred embodiment of the present invention.FIG. Fig. 5 is an illustration of a display of a system for analyzing and displaying fault propagation in accordance with a preferred embodiment of the invention.

[0043] FIG. 6 is a flow diagram illustrating signal flow through a system for analyzing and displaying fault propagation in accordance with a preferred embodiment of the present invention.FIG. 6 is a flowchart showing signal flow through a system for analyzing and displaying fault propagation in accordance with a preferred embodiment of the invention.

[0044] FIG. 7 is a diagram illustrating a fault path calculation in accordance with a preferred embodiment of the present invention.FIG. FIG. 7 is a schematic illustration of a fault in accordance with the invention. FIG.

[0045] FIG. 8 is a flow diagram of a method for computing a fault path in accordance with a preferred embodiment of the present invention.FIG. 8 is a flowchart of a method for computing a fault path in accordance with a preferred embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTSDETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0046] Hardware safety mechanisms are necessary to guarantee determinist SoC behavior in the event of random faults. Typically, implementing hardware safety mechanisms involves some form of redundant logic that does not directly contribute to the implementation of the circuit’s mission function. In the presence of faults, this logic becomes truly active and is responsible to detect, possibly correct, and report these faults to relevant part of the system. Functional verification planning, tracking and execution of both mission and safety functions is critical to meet the strict demands of safety standards. Key aspects in the verification of safety functions are that they (1) do not interfere with the hardware functionality under normal operation, (2) detect faults and correctly route information (alarm, fault corrected, etc.) to the relevant part of the system and (3) improve system availability by correcting the effect of some faults.[0046] SoC behavior in the event of random faults. Typically, implementing hardware safety mechanisms does not directly contribute to the implementation of the circuit's mission function. In the presence of faults, this logic truly becomes active, and it is responsible for the detection of the problem demands of safety standards. Key features in the verification of safety functions are (2) detect faults and correct route information (alarm, fault corrected, etc.) to the relevant part of the system and (3) improve system availability by correcting the effect of some faults.

[0047] Safety mechanisms bring another dimension to the already complex and time-consuming task of functional verification. There are countless fault scenarios to examine and engineers often need a dedicated test environment to handle fault injection, related checkers, and coverage data.[0047] Safety mechanisms bring another dimension to the already complex and time-consuming task of functional verification. There are countless cases of damage and damage to the environment.

[0048] A general architecture for a system and method for analyzing and displaying fault propagation path in accordance with a preferred embodiment of the present invention is shown in FIG. 3. The 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 fault injection module 310, a fault propagation module 320, a fault detection module 330, and a waveform debugger 340. The computing device may have other modules or applications such as a verification module 350 or a Quantifying module 360. The system further has a display 200. The fault injection module or application 310 provides a simple and flexible interface to define and inject fault scenarios, with no need to change the design, go through complex code-instrumentation stepi,L or develop a dedicated verification environment.[0048] A general architecture for a system and method for analyzing and displaying a fault propagation path in accordance with a preferred embodiment of the invention is shown in FIG. 3. The 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, as well as a hard drive or a solid state drive. The computing device 300 has a fault injection module 310, a fault detection module 320, and a waveform debugger 340. The computing device 350 or a quantifying module 360. 200. The fault injection module or application 310 provides a simple and flexible interface to define and inject fault scenarios environment.

[00491 Fault propagation analysis comprises the injection of faults 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.[00491 Fault propagation analysis in the gate level models of integrated circuits. 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.

[0050] Fault simulation is a standard approach to determine fault metrics. Faults are stimulated and propagated to observation points, to ensure detection by a safety function. Any faults not activated or not propagated by the functional stimulus consume a high proportion of the simulation cycles. They are also difficult to debug when considering stimulus improvements. Thus these faults often remain in the “not detected” group, detracting from the desired detection ratio.[0050] Fault simulation is a standard approach to determine fault metrics. Faults are stimulated and propagated to safety points. Any faults not activated or not supported by the functional stimulus consume a high proportion of the simulation cycles. They are thus difficult to debug when considering stimulus improvements. Thus these faults remain in the "not detected" group, detracting from the desired detection ratio.

[0051] A fault scenario can be seen as a set of faulty variants of the original design, the design under test (DUT). The first element of a fault scenario is the set of bit-level design signals where faults shall be injected. The other elements define when and which types of faults shall be injected. The original design corresponds to the particular fault scenario of no faults being present.A fault scenario can be seen as a set of faulty variants of the original design, the design under test (DUT). The first element of a fault scenario is the set of bit-level design signals. The other elements define when and which types of faults shall be injected. The original design is the fault scenario of no faults being present.

[0052] Users have the flexibility of defining custom fault scenarios, or pick predefined ones. A simple scenario could describe the injection of stuck-at-0 faults on all bits of a number of design signals, all the time. A custom scenario could describe the injection of a SEU fault, e.g. a bit-flip, in an arbitrary bit of a memory location, occurring only once and coinciding with some other condition, for example a memory read on a specific address. User assertions can be associated with specific fault scenarios, and powerful proof strategies are automatically setup to handle the simultaneous exhaustive verification of huge fault populations in large and complex designs. Moreover, dedicated debug features speed up the daunting task dfU examining assertion failures on fault-injected designs, where things can get quite confusing. Finally, the quantify module can measure the coverage of the overall set of assertions at the push of a button and expose both mission and safety-related functional areas that have verification gaps.[0052] Users have the flexibility of defining custom fault scenarios, or pick predefined ones. A simple scenario could describe the injection of stuck-at-0 faults on all bits and pieces of design signals, all the time. A custom scenario could describe the injection of a SEU fault, e.g. a bit-flip, in an arbitrary bit of a memory location, only once and coinciding with some other condition, for example. User assertions can be associated with specific fault scenarios, and are automatically set up to test the simultaneous exhaustive verification of large-scale fault populations in large and complex designs. Moreover, dedicated debugging features audit-driven assertions on fault-injected designs, where things can be confusing. Finally, the quantify module can cover the overall set of assertions at the push of a button and expose both mission and safety-related functional areas.

[0053] 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 they are safe and can be removed from the dangerous fault list, improving the fault metric. This is where formal technology can be effectively applied in an automated way using the Fault Propagation Module 320. The Fault Propagation Module 320 automatically identifies non-propagatable faults, allowing their safe elimination prior to simulation, thereby cutting on simulation and debug time while increasing the nominal fault coverage Any know method for identifying non-propagatable faults may be used.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. The dangerous fault list, improving the fault metric. The Fault Propagation Module 320 automatically identifies non-propagatable faults, allowing their safe elimination prior to simulation, thus cutting on simulation and debug time while increasing the nominal fault coverage Any knowing method for identifying non-propagatable faults may be used.

[0054] The Fault Propagation Module 320 is applied to the overall fault population both prior to and after fault simulation. The Fault Propagation Module 320 has a “fast mode” and a “deep mode.” Operating in a “fast mode” the Fault Propagation Module 320 is run presimulation, utilizing formal analysis to efficiently identify non-propagatable faults, thereby enabling the desired fault detection ratio to be rapidly achieved while avoiding unnecessary effort. These faults may be pruned from the fault list without the requirement for fault simulation test vectors. The entire fault-simulation process is significantly accelerated through the removal of this class of faults from those that need to be run in fault simulation.[0054] The Fault Propagation Module 320 is applied to the overall fault population both prior to and after fault simulation. The Fault Propagation Module 320 has an "almost mode" and a "deep mode." Operating in a "fast mode" the Fault Propagation Module 320 is run presimulation, utilizing formal analysis to efficiently identify non-propagatable faults avoiding unnecessary effort. These faults may be pruned from the fault list without the requirement for fault simulation test vectors. The entire fault-simulation process is greatly accelerated by the removal of this class of faults.

[0055] Operating in a “deep mode” the Fault Propagation Module 320 can be used to analyze non-propagatable faults identified during a simulation-based fault injection process to either improve the safety mechanism or to classify them as safe. This automated step greatly reduces the manual effort required post-fault simulation to identify any remaining dangerous faults. The analysis is accomplished without modification of the netlist - a requirement of thfel certification standards.[0055] Operating in a "deep mode" the Fault Propagation Module 320 can be used to analyze non-propagatable faults identified during a simulation-based fault injection process. This automated step reduces the manual effort required. The analysis is not a modification of the netlist - a requirement of thelf certification standards.

[0056] The only required input is a gate or RTL model for the circuit under test. The system identifies fault locations where it already performs optimizations such as net collapsing to avoid duplications. Alternatively, a fault list or design areas of interest indication may be provided, which is used by the tool to refine the fault list.The only required input is a gate or RTL model for the circuit under test. The system identifies fault locations where it already performs optimizations such as net collapsing to avoid duplications. Alternatively, it is used by the tool to refine the fault list.

[0057] Furthermore, an initial design state may be loaded to allow a context analysis. Such an analysis can be important to understand how faults behave when injected at a certain execution time.Furthermore, an initial design state may be loaded to allow a context analysis. Behave when injected at a certain execution time.

[0058] After fault list creation, the system performs a fully automated formal analysis to identify non-propagatable faults. After the analysis, the non-propagatable, as well as the potentially propagatable faults can be written into a simple CSV formatted text file for further processing. In addition, an analysis summary report is generated. A fast statistical analysis may also be performed where the fault list is sampled rather than analyzing all faults. 10059] In the method of a preferred embodiment of the present invention, as shown in FIG. 4, the system identifies 410 a fault location for injecting a fault and identifies 420 an observation point. The observation point in the circuit design is a point where errors can have a dangerous impact. The system computes 430 the fault path (explained later in further details with reference to Fig. 7 and 8). The system then opens 440 a viewer in the waveform debugger 340. The system 300 then displays 450 on the display 200 an impacted signal path in an ordered list from the fault location to the observation point whereby each signal inside the past has been impacted by the fault. “Impacted” refers to the value in the design between different than what the value would be in a golden design. In alternative embodiments, a plurality of observation points may be used, for example, if the fault propagates to more than one observation point.After fault list creation, the system performs a fully automated formal analysis to identify non-propagatable faults. After the analysis, the non-propagatable, as well as the potentially propagatable faults can be written in a simple CSV formatted text file for further processing. In addition, an analysis summary report is generated. A fast statistical analysis may therefore be performed rather than analyzing all faults. 10059] In the method of a preferred embodiment of the invention, as shown in FIG. 4, the system identifies 410 a fault location for injecting a fault and identifies 420 at observation point. The observation point in the circuit design is a point where errors can have a dangerous impact. The system computer 430 the fault path (explained later in further details with reference to FIGS. 7 and 8). The system then opens 440 a viewer in the waveform debugger 340. The system 300 then displays 450 on the display 200 at impacted signal path in an order list from the fault location fault. "Impacted" refers to the value in the design between different than what the value would be in a golden design. In alternative, it is used for example, if the fault propagates to more than one observation point.

[0060J As shown in FIG. 5, only one waveform is shown for a given signal. The imkl pacted signals are shown in a different color (e.g., red) than the non-impacted signals. Indicators other than color, such as line thickness or the type of line (e.g., dashed, dotted, etc.) or any other visual indicator, may be used. Preferably, the signals are shown in a different color only when the value of the golden and faulty signal is different. Also, as an alternative to the display shown in FIG. 5, the values of the golden and fault signals could be placed next to each other onto a given single wave. Displaying two values can be particular useful when the displayed signal is not a single bit. The signals are displayed in the timing domain, which results in a “stepladder” in a different color showing host the fault moves forward from one signal to the next. Different colors may be used in the display to show how the fault moves forward from one signal to the next. As also shown in FIG. 5, it may be beneficial to display the inputs of the device before the signal and the outputs of the device after the signal. In the alternate embodiment having multiple observation points, data and graphs for a plurality of observation points can be shown on the display or waveform viewer.[0060J As shown in FIG. 5, only one waveform is shown for a given signal. The imkl pacted signals are shown in a different color (e.g., red) rather than the non-impacted signals. Indicators other than color, such as line thickness or the type of line (e.g., dashed, dotted, etc.) or any other visual indicator, may be used. Preferably, the signals are shown in a different color only when the value of the golden and faulty signal is different. So, as an alternative to the display shown in FIG. 5, the values of the golden and fault signals could be placed next to each other. Displaying two values can be useful when the displayed signal is not a single bit. The signals are displayed in the timing domain, which results in a "stepladder" in a different color. Different colors may be used in the display to show the fault moves forward from one signal to the next. As shown in FIG. 5, it may be to the signal before the signal and the outputs of the device after the signal. In the alternate embodiment, multiple observation points, data and graphs for a plurality of observation points can be shown on the display or waveform viewer.

[0061] An exemplary architecture 600 for verification of hardware safety mechanisms is shown in FIG. 6. The system has a parity encoder 610, read/write 620, write pointer 630, memory 640, read pointer 650, parity coder 660 and full/empty 670.An exemplary architecture 600 for verification of hardware safety mechanisms is shown in FIG. 6. The system has a parity encoder 610, read / write 620, write pointer 630, memory 640, read pointer 650, parity coder 660 and full / empty 670.

[0062] As shown in FIG. 7, the inputs for the fault path calculation 700 are start point (fault location) and end point (observation point), a list of signals that were impacted by the fault as calculated from a counterexample (the complete list of impacted signals), and the fan-in/fanout relation of each single signal in the design. The output of the fault path calculation is the shortest path from the start point to the end point. The shortest path can be in terms of the number of signals, the number of instances or a number of registers/states. Instances can have different numbers of signals attached to them. An instance is typically a cell (like an AND call or FlipFlop cell). The shortest path from the start point to the end point may not be the absolute shortest path but may include any deviations or alterations between the start poiritt and the end point. Deviations or alterations may added by any means such as FlipFlop and the like.As shown in FIG. 7, the inputs for the Fault location are the Fault Location and the Fault Point, and the Fault Point and the Fault Point are measured, respectively the fan-in / fanout relation of each single signal in the design. The output of the fault path is the shortest path from the start point to the end point. The shortest path can be found in terms of the number of instances, the number of instances or a number of registers / states. Instances can have different numbers of signals attached to them. An instance is typically a cell (like an AND call or flip-flop cell). The shortest path from the start point to the end point may not be the absolute shortest path but may include any deviations or alterations between the start poiritt and the end point. Deviations or alterations may be added by any means such as FlipFlop and the like.

[0063] An exemplary method for computing a fault path in accordance with a preferred embodiment of the present invention is described with reference to FIG. 8. The inputs for the calculation are shown in FIG. 7. An Observation Point is entered into a Current Signal List at 802. If this is the first iteration, the Current Signal List may have only one signal (the Observation Point). If it is a later iteration, the Current Signal List will have a plurality of signals. At 810, if the Current Signal List is empty, the system knows there is an error and appropriate error notification is undertaken at step 812. If the Current Signal List is not empty at 810, the system determines at 820 for each signal in the Current Signal List whether that signal is on the Impacted Signal List. If a particular signal is not on the Impacted Signal List, the system does nothing at 822 with respect to that signal. If a particular signal is on the Impacted Signal List, the system checks at 830 whether the signal is the Fault Location. If it is not the Fault Location, the system adds the fanin of this signal to a Next Current Signal List and stores the signal as the parent of those fanin signals at 834. Once all signals on the Current Signal List have been checked, the system makes the Next Current Signal List the Current Signal List at 836 and then returns to 810. If a signal is the fault location at step 830, the system sets the fault location as the path signal at 840. The system than determines at 850 whether the path signal has a parent. If yes, the system sues that parent as a new Path Signal and stores that Path Signal in the Path List at 852. The system then returns to step 850. If the Path Signal does not have a parent, the system displays the path in creation order in a waveform viewer at 860. In this way, the shortest path from the fault location to the observation point is determined and displayed.An exemplary method for computing a fault path in accordance with a preferred embodiment of the invention is described with reference to FIG. 8. The inputs for the calculation are shown in FIG. 7. An Observation Point is entered into a Current Signal List at 802. If this is the first iteration, the Current Signal List may have only one signal (the Observation Point). If it is a later iteration, the Current Signal List At 810, if the Current Signal List is empty, the system is at 812. If the Current Signal List is not at 810, the system determines at 820 for each signal in the current Signal List is signaled on the Impacted Signal List. If a particular signal is not on the Impacted Signal List, the system does nothing at 822 with respect to that signal. If a particular signal is on the Impacted Signal List, the system checks at 830 whether the signal is the fault location. If it is not the Fault Location, the system adds the signal to the signal makes the Current Signal List at 836. If the signal is the faulty location at step 830, the system sets the signal at 840 path signal has a parent. If yes, the system sues that parent as a new path signal and stores that Path Signal in the Path List at 852. The system then returns to step 850. If the path signal does not have a parent, the system displays the path in creation order in a waveform viewer at 860. In this way, the shortest path from the fault location is determined and displayed.

[0064] The foregoing description of the preferred embodiment of the invention has beehll presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The embodiment was chosen and described in order to explain the principles of the invention and its practical application to enable one skilled in the art to utilize the invention in various embodiments as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto, and their equivalents. The entirety of each of the aforementioned documents is incorporated by reference herein.[0064] The description of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit itself to the precise form disclosed, and "modifications and variations are possible in light of the above teachings. The embodiment of the invention is characterized by the fact that it is used in a particular way. It is intended that the scope of the invention be appended hereto, and their equivalents. The entirety of each of the aforementioned documents is incorporated by reference.

Claims (10)

1. Procédé mis en œuvre par ordinateur pour calculer et afficher un chemin de propagation d’anomalie comprenant : Identifier, avec un dispositif informatique, un emplacement d’anomalie dans un circuit électrique ; Identifier, avec ledit dispositif informatique, un point d'observation dans le circuit électrique ; Calculer, avec ledit dispositif informatique, un chemin d’anomalie depuis ledit emplacement d’anomalie vers ledit point d’observation ; et Afficher dans un visualiseur de forme d'onde tous les signaux dans ledit chemin d’anomalie depuis ledit emplacement d’anomalie vers ledit point d'observation dans l'ordre de leur création.A computer-implemented method for calculating and displaying an anomaly propagation path comprising: identifying, with a computing device, an abnormality location in an electrical circuit; Identify, with said computing device, a point of observation in the electrical circuit; Calculating, with said computing device, an anomaly path from said anomaly location to said observation point; and displaying in a waveform viewer all signals in said abnormal path from said anomaly location to said observation point in the order of their creation. 2. Procédé mis en œuvre par ordinateur pour calculer et afficher un chemin de propagation d’anomalie selon la revendication 1, dans lequel l'étape consistant à calculer un chemin d’anomalie comprend : Calculer le chemin le plus court des signaux impactés depuis l'emplacement de l’anomalie jusqu’au point d'observation.A computer-implemented method for calculating and displaying an anomaly propagation path according to claim 1, wherein the step of calculating an abnormality path comprises: calculating the shortest path of the signals impacted since the the location of the anomaly to the point of observation. 3. Procédé mis en œuvre par ordinateur pour calculer et afficher un chemin d'agacement d’anomalie selon la revendication 1 ou 2, dans lequel l'étape consistant à calculer le chemin d’anomalie le plus court comprend : Calculer le chemin le plus court en termes de nombre de signaux.A computer-implemented method for calculating and displaying an anomaly annoyance path according to claim 1 or 2, wherein the step of calculating the shortest fault path comprises: calculating the most short in terms of number of signals. 4. Procédé mis en œuvre par ordinateur pour calculer et afficher un chemin de propagation d’anomalie selon la revendication 2 ou 3, dans lequel l'étape consistant à calculer le chemin d’anomalie le plus court comprend : Calculer le chemin le plus court en termes de nombre d'instances.A computer-implemented method for calculating and displaying an anomaly propagation path according to claim 2 or 3, wherein the step of calculating the shortest fault path comprises: calculating the shortest path in terms of the number of instances. 5. Procédé mis en œuvre par ordinateur pour calculer et afficher un chemin de propaga------ tion d’anomalie selon l'une quelconque des revendications 2 à 4, dans lequel l'étape consistant à calculer du chemin d’anomalie le plus court comprend : Calculer le chemin le plus court en termes de nombre de registres.A computer-implemented method for calculating and displaying an anomaly propagation path according to any one of claims 2 to 4, wherein the step of calculating an abnormality path the shortest includes: Calculate the shortest path in terms of the number of registers. 6. Procédé mis en œuvre par ordinateur pour calculer et afficher un chemin de propagation d’anomalie selon l'une quelconque des revendications 2 à 5, dans lequel l'étape consistant à calculer le chemin d’anomalie le plus court comprend : ajouter un écart ou une altération par rapport au chemin le plus court.A computer-implemented method for calculating and displaying an anomaly propagation path according to any one of claims 2 to 5, wherein the step of calculating the shortest anomaly path comprises: adding a deviation or alteration from the shortest path. 7. Procédé mis en œuvre par ordinateur pour calculer et afficher un chemin de propagation d’anomalie selon l'une quelconque des revendications 1 à 6, dans lequel l'étape consistant à calculer le chemin d’anomalie comprend : a. Entrer un point d'observation dans une liste de signaux en cours ; b. Comparer chaque signal sur la liste de signaux en cours avec une liste de signaux impactés ; c. Pour chaque signal comparé, si le signal n'est pas sur la liste de signaux impactés, ne rien faire à l'égard de ce signal ; d. Pour chaque signal comparé, si le signal est sur la liste de signaux impactés, vérifier si le signal est l'emplacement de l’anomalie ; e. Pour chaque signal comparé sur la liste de signaux impactés, si le signal est l'emplacement de l’anomalie, passer à l'étape h; f. Pour chaque signal comparé sur la liste de signaux impactés, si le signal n'est pas l'emplacement d’anomalie, ajoutant les signaux de fanin du signal à une liste de signaux en cours suivante et mémoriser le signal en tant que parent des signaux de fanin ajoutés ; g. Faire en sorte que la liste des signaux en cours suivante devienne la liste de signaux en cours et retourner à l'étape b ; h. Définir les emplacements d’anomalie au niveau du signal de trajet ; i. Déterminer si le signal de cheminement a un signal parent ; j. Si le signal de chemin a un signal parent, utiliser le parent en tant que nouveau signal de chemin, stocker le nouveau signal de chemin dans une liste de chemin, et revenir à l'étape i pour le nouveau signal de chemin ; k. Si le signal de trajet n'a pas de signal parent, sortir le chemin de signaux impactés éif tant que chemin d’anomalie le plus court vers le visualiseur de forme d'onde.A computer-implemented method for calculating and displaying an anomaly propagation path according to any one of claims 1 to 6, wherein the step of calculating the abnormality path comprises: a. Enter a point of observation in a list of current signals; b. Compare each signal on the current signal list with a list of impacted signals; vs. For each compared signal, if the signal is not on the list of impacted signals, do nothing with respect to that signal; d. For each signal compared, if the signal is on the list of impacted signals, check if the signal is the location of the anomaly; e. For each signal compared on the list of impacted signals, if the signal is the location of the anomaly, go to step h; f. For each signal compared on the impacted signal list, if the signal is not the fault location, adding the signal fanin signals to a next current signal list and storing the signal as the signal's parent added fanin; boy Wut. Make the next current signal list the current signal list and return to step b; h. Define anomaly locations at the path signal; i. Determine if the routing signal has a parent signal; j. If the path signal has a parent signal, use the parent as a new path signal, store the new path signal in a path list, and return to step i for the new path signal; k. If the path signal has no parent signal, output the impacted signal path as the shortest fault path to the waveform viewer. 8. Procédé mis en œuvre par ordinateur pour calculer et afficher un chemin de propagation d’anomalie selon l'une quelconque des revendications 1 à 7, dans lequel l'étape consistant à afficher dans un visualiseur de forme d'onde tous les signaux dans ledit chemin d’anomalie depuis ledit emplacement d’anomalie jusqu'audit point d’observation point par ordre de leur création comprend : Afficher les signaux dans le domaine de temps, selon une "échelle" d'une couleur différente dans l'affichage pour montrer comment l’anomalie se déplace d'un signal à l'autre.A computer-implemented method for calculating and displaying an anomaly propagation path according to any one of claims 1 to 7, wherein the step of displaying in a waveform viewer all the signals in said anomaly path from said anomaly location to said point-of-view point of their creation comprises: Displaying the time-domain signals according to a "scale" of a different color in the display for show how the anomaly moves from one signal to another. 9. Procédé mis en œuvre par ordinateur pour calculer et afficher un trajet de propagation d’anomalie selon l'une quelconque des revendications 1 à 8, dans lequel l'étape consistant à afficher dans un visualiseur de forme d'onde tous les signaux dans ledit chemin d’anomalie depuis ledit emplacement d’anomalie jusqu'audit point d'observation dans l'ordre de leur création utiliser des indicateurs visuels comprenant au moins un parmi une couleur différente, une épaisseur de ligne différente ou un autre type de ligne ou tout autre indicateur visuel.A computer-implemented method for calculating and displaying an anomaly propagation path according to any one of claims 1 to 8, wherein the step of displaying in a waveform viewer all the signals in said anomaly path from said anomaly location to said observation point in the order of their creation using visual indicators comprising at least one of a different color, a different line thickness or another type of line or any other visual indicator. 10. Procédé mis en œuvre par ordinateur pour calculer et afficher un chemin de propagation d’anomalie selon l'une quelconque des revendications 1 à 9, comprenant Identifier, avec ledit dispositif informatique, une pluralité de points d'observation dans le circuit électrique ; Calculer, avec ledit dispositif informatique, une pluralité de chemins d’anomalie depuis ledit emplacement d’anomalie jusqu’à ladite pluralité de points d'observation; et afficher dans un visualiseur de forme d'onde, pour chaque chemin d’anomalie de la pluralité de chemins d’anomalie, tous les signaux dans ledit chemin d’anomalie depuis ledit emplacement d’anomalie jusqu’audit point d'observation par ordre de leur création, dans lequel des données et des graphiques pour la pluralité de points d'observation sont affichés.A computer-implemented method for calculating and displaying an anomaly propagation path according to any of claims 1 to 9, comprising identifying, with said computing device, a plurality of observation points in the electrical circuit; Calculating, with said computing device, a plurality of anomaly paths from said anomaly location to said plurality of observation points; and displaying in a waveform viewer, for each fault path of the plurality of fault paths, all signals in said fault path from said fault location to said observation point in order of their creation, in which data and graphs for the plurality of observation points are displayed.