Failure modes for hardware functional block in complex electronic system and affection and model-driven methods for automated diagnostic analysis (FMEDA)
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- ARTERIS INC
- Filing Date
- 2023-04-24
- Publication Date
- 2026-07-02
Smart Images
Figure 00000000_0000_ABST
Abstract
Description
Technical Field
[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Application No. 63 / 334,665, filed Apr. 25, 2022, by Stefano LORENZINI et al., titled "SYNTHESIS TOOL FOR AUTOMATIC GENERATION OF SCALABLE AND REUSABLE FAILURE MODE, EFFECTS, AND DIAGNOSTIC ANALYSIS (FMEDA) IN COMPLEX SYSTEM - ON - CHIP (SoC)", the entire disclosure of which is incorporated herein by reference.
[0002] Technical Field This technology relates to Failure Mode, Effects, and Diagnostic Analysis (FMEDA) of hardware functional blocks (IP). FMEDA may be executed on the hardware IP of a system - on - chip (SoC) or other complex electronic systems.
Background Art
[0003] Background Failure Mode, Effects, and Diagnostic Analysis (FMEDA) refers to a systematic analysis technique for obtaining subsystem and product - level failure rates, failure modes, and diagnostic capabilities. This technique can be utilized during the design of a system - on - chip (SoC) or other complex electronic systems. For example, an initial design of an SoC can be generated by assembling many instances of hardware models or functional block (IP) blocks into a top - level hardware IP. FMEDA may be executed on the hardware IP.
[0004] FMEDA may include generating spreadsheets or other tables. Rows of failure mode information for each hardware model are manually cut and pasted into the spreadsheet. Each row corresponds to a failure mode for an instance within the hardware IP. Since each instance may have multiple failure modes, there may be multiple rows associated with a single instance. After the table is completed, algorithms can be applied to the FMEDA table to obtain the failure rate, failure modes, and diagnostic capabilities of the system and subsystems.
[0005] Hardware IP typically undergoes multiple design iterations and frequent design changes. FMEDA is also run on modified hardware IP, which means the tables are modified multiple times to reflect the changes. Furthermore, modifications or multiple FMEDA iterations may be caused by a) IP reconfiguration with hardware (e.g., Verilog) parameters, and b) derivation of new IP from RTL models reused by other IP.
[0006] Manually generating and modifying FMEDA tables is cumbersome, time-consuming, and inefficient. This is especially true for SoC designs, which are highly configurable and may undergo numerous modifications during the design process. Therefore, a system and method are needed to enable analysis of failure mode characteristics and safety data related to the hardware model, and to compile safety library components and IP hardware. [Overview of the project] [Means for solving the problem]
[0007] overview According to various embodiments and aspects of the present invention, systems, articles, and computer implementations are used to perform failure mode, impact, and diagnostic analysis (FMEDA) on hardware functional blocks (IP) of electronic systems. The analysis includes accessing a library of safety library components, each safety library component containing failure mode characteristics and safety data relating to a hardware model, and compiling the safety library components and hardware IP. Compiling includes mapping instances of the hardware model within the hardware IP to the corresponding safety library components and aggregating the characteristics and safety data of the corresponding components.
[0008] Brief explanation of the drawing To better understand the present invention, refer to the accompanying drawings. The present invention is described in accordance with the aspects and embodiments of the following description with reference to the drawings or figures (Figures), where similar numbers represent the same or similar elements. It should be understood that these drawings should not be considered as limitations within the scope of the invention, and the aspects and embodiments of the present invention, as well as the best mode currently understood, are described in further detail by using the accompanying drawings. [Brief explanation of the drawing]
[0009] [Figure 1] This figure illustrates a computer implementation method for automatically performing failure mode, impact, and diagnostic analysis (FMEDA) on hardware functional blocks of an electronic system, according to various aspects and embodiments of the present invention. [Figure 2] This is a diagram of safety library components according to various aspects and embodiments of the present invention. [Figure 3] This is a diagram of a system including a tool for performing FMEDA according to various aspects and embodiments of the present invention. [Figure 4] This diagram shows a hierarchical representation of hardware functional blocks (IP) according to various aspects and embodiments of the present invention. [Figure 5] This figure shows a computer implementation method for performing FMEDA according to various aspects and embodiments of the present invention. [Modes for carrying out the invention]
[0010] Detailed explanation The following describes various examples of the Art illustrating various aspects and embodiments of the Invention. In general, the examples can be used in any combination to illustrate aspects of the Invention. All descriptions herein that enumerate principles, aspects, and embodiments (and specific examples thereof) are intended to encompass both their structural and functional equivalents. The examples provided are intended to be non-limiting examples. Furthermore, such equivalents are intended to include both currently known equivalents and equivalents to be developed in the future, i.e., any developed elements that perform the same function regardless of their structure.
[0011] Where used herein, the singular forms “a,” “an,” and “the” refer to multiple objects unless the context clearly indicates otherwise. Throughout this specification, any reference to “one embodiment,” “embodiment,” “a particular embodiment,” “various embodiments,” or similar phrases means that a particular aspect, characteristic, structure, or feature described in relation to an embodiment is included in at least one embodiment of the present invention.
[0012] Accordingly, the occurrence of phrases such as “in one embodiment,” “in at least one embodiment,” “in an embodiment,” “in a particular embodiment,” “in several embodiments,” and similar wording in this specification may all, though not necessarily, refer to the same embodiment or similar embodiment. Furthermore, the aspects and embodiments of the invention described herein are merely illustrative and should not be construed as limiting the scope or spirit of the invention as understood by those skilled in the art. The disclosed invention may be effectively created or used in any embodiment, including any novel aspects described herein. All descriptions herein enumerating the principles, aspects, and embodiments of the invention are intended to encompass both their structural and functional equivalents. Such equivalents are intended to include both currently known equivalents and equivalents to be developed in the future. Furthermore, the terms “including,” “includes,” “having,” “has,” “with,” or variations thereof, to the extent that they are used in either the detailed description or the claims, are intended to be as comprehensive as the term “comprising.”
[0013] The terms “source,” “master,” and “initiator” refer to hardware functional block (IP) modules / blocks or units, and these terms are used interchangeably within the scope and embodiments of the present invention. As used herein, the terms “sink,” “slave,” and “target” refer to hardware IP modules or units, and these terms are used interchangeably within the scope and embodiments of the present invention. As used herein, a transaction can be a request transaction or a response transaction. Examples of request transactions include write requests and read requests.
[0014] According to various aspects and embodiments of the present invention, failure modes, impacts, and diagnostic analysis of hardware IP are automated and model-driven. Hardware IP is not limited to a specific system. However, this is particularly useful for complex electronic systems such as systems-on-a-chip (SoCs), which are highly configurable and may undergo multiple modifications during design.
[0015] As an example of a complex electronic system, a system-on-a-chip (SoC) includes a multiprocessor system that communicates via a network-on-a-chip (NoC). The hardware IP of the SoC includes instances of initiator IP and target IP. Transactions are sent from an initiator to one or more targets using industry-standard protocols. An initiator connected to a NoC sends a request transaction to one or more targets using their addresses in order to select one or more targets. The NoC decrypts the addresses and forwards the request from the initiator to the targets. The targets process the transaction and send a response transaction, which is returned to the initiator by the NoC. Thus, SoCs and NoCs involve complexity and configurability.
[0016] Refer to Figure 1, which illustrates a computer implementation model driving method for automatically performing FMEDA on hardware functional blocks according to various aspects and embodiments of the present invention.
[0017] In block 110, hardware IP is generated. The hardware IP for the SoC is considered. The requirements for the SoC are generated. The requirements may be determined by marketing, sales, customer intent, etc. The system designer generates specifications related to the requirements. This specification provides the chip definition, technology, domain, and layout of the IC system.
[0018] The IP blocks or hardware models of components (e.g., processor cores, memories, etc.) are selected from the designer's library. The IP blocks or hardware models can refer to reusable units of logic, cells, or integrated circuit layout designs. The hardware models can be described at the register transfer level (RTL) of a hardware description language such as Verilog.
[0019] Instances of the hardware models are assembled into the top-level hardware IP. The hierarchy refers to the connections of the hardware models.
[0020] To obtain the failure rates, failure modes, and diagnostic capabilities at the subsystem and system levels, model-driven FMEDA is executed on the hardware IP.
[0021] In block 120, the hardware IP is accessed. For example, the hardware IP may be downloaded from a remote storage via a network or read from a local memory.
[0022] In block 130, a library of safety library components created by users such as RTL designers or safety engineers is accessed. For example, the library may be downloaded from a remote storage device via a network and read from a local memory, etc. Each safety library component includes failure mode characteristics and safety data regarding the hardware IP block. Each safety library component also includes information that enables it to be mapped to the IP block.
[0023] In block 140, the safety library components and the hardware IP are compiled. The compilation includes mapping or linking specific safety library components in the library to corresponding instances in the hardware IP, and aggregating the characteristics and safety data included in the mapped safety library components of the corresponding components. According to various aspects and embodiments, each safety library component is mapped to an instance (similar to RTL synthesis). In other words, multiple instances can refer to the same model, but not vice versa. For example, the characteristics and safety data may be aggregated into a data structure such as an FMEDA table. When the compilation is complete, the FMEDA table has a complete set of failure modes, safety mechanisms, and related safety data. According to aspects and embodiments of the present invention, the internal format can have any format and language suitable for compiling and correctly representing the content of FMEDA. When the FMEDA is exported, it usually becomes a "table" which is an MS Excel format file. According to aspects and embodiments of the present invention, the output may be a script that allows third-party tools to generate the table and avoid or skip the synthesis step. In this example, the script is not a table, but still describes the table. For example, the failure mode can be represented as follows.
[0024] create_failure_mode <id> <description><saftey data>etc.
[0025] If there are 100 failure modes, there will be 100 of these commands. In block 150, aggregated characteristic and safety data are processed to provide a complete set of relevant safety data, including failure modes, safety mechanisms, and safety metrics. The metrics include system and component-level single-point failure metrics (SPFM), latent failure metrics (LFM), and probability metrics for hardware random failures (PMFH).
[0026] Therefore, this model-driven approach to FMEDA introduces a safety component library and compiler to generate FMEDA tables, or other structures that aggregate characteristic and safety data. The model-driven approach is far faster and more efficient than manually cutting and pasting information into FMEDA tables. This speed improvement allows for implementation at a higher level of design, which is a significant advantage.
[0027] Model-driven methods provide a way to characterize arbitrary hardware models regardless of the context of specific hardware elements. This enables out-of-context safety characterization. According to aspects and embodiments of the present invention, mode-driven methods enable the reuse of such safety components.
[0028] Model-oriented approaches offer significant advantages for highly configurable IP hardware that undergoes multiple design changes.
[0029] In block 160, hardware IP is modified. There are many possible reasons for modifying hardware IP. Requirements may be modified, rules may be violated, or the FMEDA results may be unacceptable. As a result, hardware models may be moved within the IP hardware, the functionality of hardware models may be changed, instances of different hardware models may be added, or instances of hardware models may be deleted.
[0030] According to aspects and embodiments of the present invention, IP block modification changes are implemented. For example, a new NoC version implements a more advanced arbiter (a new RTL model) for managing the switch performance of the transport matrix. The designer simply adds the safety component to the library (without considering the context in which this safety component is instantiated in FMEDA), and the FMEDA compiler updates FMEDA to remove the failure modes associated with the old switches and instantiate the failure modes from the new safety component (safety characterization) of the arbiter in the appropriate place in FMEDA.
[0031] According to aspects and embodiments of the present invention, IP reconfiguration is performed. For example, a new NoC version is generated by modifying a previous configuration, where the previous configuration connected four initiators and ten target IPs, and the new one adds two targets and changes the protocol of one initiator from AHB to AXI. This means changing the protocol of one NoC interface and instantiating two or more NoC interfaces for two additional targets. In this case, all safety components already exist in the library (they are configurable like RTL models) and are used by the FMEDA compiler to a) retrieve the safety characterization of the NoC interface implementing AXI instead of the AHB protocol from the safety library, and b) retrieve the safety characterization of the two additional NoC interfaces from the safety library. These additional failure modes from such characterizations are placed in the appropriate place in FMEDA.
[0032] In block 170, the library of safety components is updated to reflect any changes to the IP block. According to aspects and embodiments of the present invention, a new hardware model is contemplated. The library is manually updated by a safety engineer (if required by the changes) according to the new hardware specifications provided by the designer.
[0033] In block 180, the modified hardware description and updated libraries are accessed and recompiled. Recompilation involves reusing safety library components that are already mapped to instances where the hardware model has not changed in the modified description. That is, the mapping of the unchanged hardware model to its corresponding safety library component is reused. Reusing safety library components is faster and more computationally efficient than remapping all instances in the IP description.
[0034] New mappings are created for instances that have been added to the description and instances whose functionality has been changed. Mappings for instances that have been removed from the hardware IP and instances whose functionality has been changed are removed.
[0035] In block 190, if additional modifications are made to the hardware IP and an FMEDA is desired, or if an FMEDA is desired for any reason other than modifications, control returns to block 160. Once the FMEDA is complete, the final result is available (block 195). According to aspects and embodiments of the present invention, revisions may generally be FMEDA re-iterations required for a) IP changes such as added new functionality, b) IP reconfiguration, and / or c) deriving an FMEDA for the new IP derived from the RTL model of other IP. In this example, a new FMEDA can be created by reusing the safety library of other existing IP to quickly compile the new FMEDA.
[0036] The method in Figure 1 may be performed by a single party or multiple parties. Consider a system-on-a-chip example. In a first example, the system designer performs blocks 110 and 160 (e.g., generating hardware IP or RTL) and uses a tool to perform blocks 120-140 and 170-180. The library may be provided as part of the tool, or it may be maintained by a library owner and accessed remotely. In a second example, the system designer performs steps 110 and 160 and provides IP hardware to a third-party service that performs blocks 120-140 and 170-180.
[0037] Another advantage of model-driven methods is traceability. FMEDA is closely linked to the actual design. Traceability to requirements and specifications is performed at different phases (horizontal traceability). The methods described herein enable the ability to link FMEDA and other types of safety analyses such as FMEA, DFA, and FTA along with the execution of the complete SoC lifecycle (vertical traceability). In this way, safety analyses evolve along with design evolution and change management (and safety design traceability) to ensure consistency along the design process.
[0038] Here, we refer to Figure 2, which illustrates the specific characteristics of the safety library components 200. Each safety library component 200 includes attributes and safety values derived from the safety characterization of the hardware model. For example, the safety library component 200 in Figure 2 may include safety parameters 202 that are conditional on safety analysis.
[0039] According to aspects and embodiments of the present invention, safety analysis is the very first step in the logical process, and the safety library does not yet exist. Therefore, safety analysis is a separate process, performed by analyzing the IP specifications, detailing the IP specifications, and replacing the IP specifications with scalable safety characterizations implemented in the safety components. The language and semantics of the safety components enable the description of such safety characterizations in a manner that can be effectively used by FMEDA synthesis (i.e., in a scalable manner).
[0040] The safety library component 200 in Figure 2 may also include safety information 204 and safety instructions 206. The safety instructions may include the names of one or more safety mechanisms. The safety mechanisms are responsible for detecting the occurrence of their associated failure modes.
[0041] Attributes provide a description of each failure mode, the attributes of each failure mode, the safety mechanism of each failure mode, and the safety value of each failure mode. The attributes and safety values of a failure mode may be similar in type to the information found in rows of a standard FMEDA table. For example, an attribute may include a text description of the failure mode, the reason for the failure, and the consequences of the failure. An attribute may also include whether the failure mode is safety-related and whether the failure affects a particular set of metrics. An attribute may further include characteristics that guide how a particular safety value is processed to generate safety metrics.
[0042] According to aspects and embodiments of the present invention, one aspect of automation can "parameterize" or condition safety metric results according to actual hardware shown as parameters in Figure 2. According to aspects and embodiments of the present invention, the parameters determine whether a particular failure mode (row) exists. According to aspects and embodiments of the present invention, the parameters can condition the value of the diagnostic coverage (attribute) for a particular failure mode.
[0043] A safety value is a numerical probability of a given failure mode. Examples of safety values include, but are not limited to, the failure mode distribution (e.g., what percentage of the logic will fail if a failure mode occurs), the ability of a safety mechanism to detect a particular failure (e.g., the percentage of time a safety mechanism will detect a particular failure), and the percentage representing the safety of a failure (e.g., 20% if 2,000 out of 10,000 gates are safe during a particular failure).
[0044] The safety library component 200 in Figure 2 also includes safety instructions 206 that provide information enabling the library safety component 200 to be mapped to an instance of a hardware model. According to aspects and embodiments of the present invention, the instructions support automation, and in particular support the creation of a “link” between the safety component and the RTL model (the other side). According to aspects and embodiments of the present invention, the safety component includes information (instructions) that describes which RTL model the safety component is associated with. For example, the safety component ALU may be associated with the RTL model alu32bit (file alu32bits.v). This method allows the same safety component to be easily reassigned to a different implementation alu32bits_fast.
[0045] According to aspects and embodiments of the present invention, a safety component may have multiple failure modes. To automate the calculation of safety data, and therefore the final metric, each failure mode or failure metric (FM) is mapped to a specific design block (usually small). This mapping operation creates a relationship between each FM and the corresponding design block that is the "root cause of the FM," i.e., a pool of gates that generate that FM in the event of a failure. Thus, once this information enters the safety component, the mapping of a particular IP involves its re-iteration and adaptation, which are triggered by changes. This is one of the most problematic and cumbersome operations to perform manually. Therefore, the process of incorporating information into the safety component and automating the mapping is a valuable aspect of the present invention, and is performed automatically by a tool to improve the productivity of FMEDA.
[0046] The safety component 200 may also include design information estimation 208. Examples of design information include, but are not limited to, gate counts, sequential elements, and memory bits.
[0047] The safety library component may be supported by a specific safety language (semantic) that can describe safety parameters 202, safety information 204, safety instructions 206, and design information estimations 208.
[0048] Referring here to Figure 3, a system 300 is shown that includes a tool for running FMEDA on IP hardware. The tool includes a computer 310 programmed to run a compiler 320. The compiler 320 can perform the functions of blocks 120, 130, 140, 170, and 180 in Figure 1. The compiler 320 generates an FMEDA table 330. According to aspects and embodiments of the present invention, the table includes a script containing third-party commands, the script still describing the table format. This script can be consumed or used by the tool to generate an MS Excel table or a graphical user interface (GUI) representation of the table.
[0049] In some embodiments, the computer 310 may also be programmed with a safety kernel 340 that performs the functions of block 150 in Figure 1. The kernel 340 can calculate safety data and input it into the FMEDA 305 table and calculate global safety metrics.
[0050] The system 300 further includes one or more safety component libraries 350 (there may be multiple safety libraries 350) accessed by the compiler 320. The libraries 350 can be stored in a remote or local database.
[0051] System 300 may further include a hardware generator 360 for receiving hardware configurations, generating hardware hierarchical representations of instances of hardware models, and storing the hierarchical representations in a database 370. The compiler 320 also accesses the hierarchical representations from the database 370.
[0052] According to aspects and embodiments of the present invention, the database 370 is an IP RTL model, such as when a tool synthesizes an RTL design to generate gate-level information. The hierarchy is implicit in the RTL model and can be constructed by the FMEDA compiler. Hierarchies, such as those in RTL synthesis, need to understand at what point in the design the tool instantiates certain physical elements, as in the case of FM. This is because the safety data of those FMs is context-dependent; for example, the same safety component instantiated twice at different points in the design hierarchy will inherit different gate counts, thereby generating different safety data despite the FM description being the same. Gate count extraction is performed by the design data extractor 340. According to aspects and embodiments of the present invention, the extracted design data includes gate counts, sequential cell counts, and memory bits.
[0053] The computer 310 can be further programmed with the design data extractor 340. The safety component 200 may include information about the number of gates used to implement the hardware model. For example, the safety percentage may indicate the total number of gates, or the design information 208 may indicate the number of gates. The design data extractor 340 uses this information to generate better estimates of the gate count and area.
[0054] According to aspects and embodiments of the present invention, the design data (e.g., gate count) included in the safety component is a safety engineer estimate provided during library compilation and is used when the design data extractor 340 is not used. This allows the FMEDA search to determine the estimate of the count, and without the design data extractor 340, the FMEDA accuracy would be lower. When the design data extractor 340 is used to extract the gate count from the RTL file, the estimate is determined and replaced with the safety component.
[0055] According to aspects and embodiments of the present invention, the design data extractor 340 can be a gate count extractor implemented in an FMEDA compiler (rapid design synthesis) or RTL synthesis tool that can be connected to it.
[0056] Here is an example. In this example, a hierarchical hardware IP block is accessed by the compiler 320. The compiler 320 also accesses the safety component library 350 and the hierarchical representation, performs compilation, and generates the FMEDA table 320.
[0057] Referring here to Figure 4, a hierarchical representation 400 of the hardware IP 410 is shown. The hardware IP 410 is represented as a hierarchy of instances of the hardware model. Instances of the hardware model are shown in the figure with indentation of hierarchical inferences 420 (I1, I2, ... I11) mapped to hardware models 430 (MOD A, MOD B, ... MOD I) to realize complex hardware functions. Each inference is an instance that uniquely references a particular hardware model of a hardware element. The hardware model includes hardware function behavior (e.g., design specifications, SystemC, System Verilog, Verilog, VHDL). According to some aspects and embodiments of the present invention, the hardware model also includes design information (e.g., number of gates, sequential cells, and memory bits), which, if available, is used to enhance the accuracy of the safety data as described above. According to some aspects and embodiments of the present invention, the resulting design hierarchy represents a connection of hardware model instances by specific functions to be implemented, enhanced by hardware model design information when the information is available.
[0058] Further reference is made to Figure 5, which shows a process 500 for a compiler 310 executing code according to some aspects and embodiments of the present invention. In step 502, the compiler 310 imports, receives, or accesses a complete design model. In step 504, the FMEDA structure is synthesized. According to aspects and embodiments of the present invention, the structure represents a table, at which point the compiler or tool has determined its size according to the actual IP hardware (e.g., 200 rows, i.e., FM), and the tool knows which safety component should be assigned to each row. In subsequent steps, data is entered into the currently empty rows, as shown in steps 506 and 508. In step 506, the FMEDA table 330 is entered using safety information obtained from or accessed in the safety library. In step 508, the FMEDA table 330 is entered using safety data obtained from or accessed in the safety library 350. In step 510, the compiler 310 or other tool determines or calculates global metrics for the design.
[0059] Changes applied to hardware IP to modify hardware design affect the design hierarchy and are automatically reflected when the compiler is rerun. Modifications to hardware elements include both changes to the hardware configuration and the inclusion / exclusion of new / existing features (such as design reconfiguration, design enhancement, and design derivation).
[0060] Certain methods according to various aspects of the present invention can be performed by instructions stored in a non-temporary computer-readable medium. The non-temporary computer-readable medium stores code that, when executed by one or more processors, causes a system or computer to perform steps of the methods described herein. The non-temporary computer-readable medium includes rotating magnetic disks, rotating optical disks, flash random access memory (RAM) chips, and other mechanically moving or solid-state storage media. Any type of computer-readable medium is suitable for storing code that includes instructions, as illustrated by various examples.
[0061] While specific examples have been described herein, it should be noted that different combinations of different components may be possible from different examples. Notable characteristics are presented to better illustrate the examples. However, it is clear that certain characteristics can be added, modified, and / or omitted without altering the functional aspects of these examples as described.
[0062] Various examples are methods that utilize the behavior of any or a combination of machines. The examples of methods are perfect for performing most configuration steps anywhere in the world. For example, according to various aspects and embodiments of the present invention, an IP element or unit includes a processor (e.g., CPU or GPU), random access memory (RAM - e.g., off-chip dynamic RAM or DRAM), and network interfaces for wired or wireless connections such as Ethernet®, WiFi, 3G, 4G Long-Term Evolution (LTE), 5G, and other wireless interface standards. The IP may also include, as needed, various I / O interface devices for various peripheral devices such as touchscreen sensors, geolocation receivers, microphones, speakers, Bluetooth® peripherals, and USB devices (such as keyboards and mice, among others). By executing instructions stored in the RAM device, the processor performs the steps of the method described herein.
[0063] Some examples are one or more non-temporary computer-readable media configured to store such instructions for the methods described herein. Any machine that holds a non-temporary computer-readable medium containing any of the required codes can be implemented as an example. Some examples can be implemented as physical devices such as semiconductor chips, hardware description language representations of the logical or functional behavior of such devices, and one or more non-temporary computer-readable media configured to store such hardware description language representations. The descriptions herein that enumerate principles, aspects, and embodiments encompass both their structural and functional equivalents. Elements described herein as being combined have effective relationships that can be realized by direct connection or indirectly with one or more other intervening elements.
[0064] Those skilled in the art will recognize numerous modifications and variations. These modifications and variations include any relevant combination of the disclosed characteristics. The descriptions herein, enumerating principles, aspects, and embodiments, encompass both their structural and functional equivalents. Elements described herein as “coupled” or “communicatively coupled” have an effective relationship that can be realized by direct connection or by indirect connection using one or more other intervening elements. Embodiments described herein as “communicating” or “being communicated” with another device, module, or element include any form of communication or link and include an effective relationship. For example, a communication link may be established using a wired connection, a wireless protocol, a near-field protocol, or RFID.
[0065] Therefore, the scope of the present invention is not intended to be limited to the exemplary embodiments shown and described herein. Rather, the scope and spirit of the invention are embodied in the appended claims.< / description> < / id>
Claims
1. A computer implementation method for performing failure mode, impact, and diagnostic analysis (FMEDA) on hardware IP of an electronic system, wherein the method is: A step of accessing a library of safety library components, wherein each safety library component includes failure mode characteristics and safety data relating to a hardware model, a safety mechanism responsible for detecting the occurrence of a failure metric, and the name of the root cause of the failure metric. A method comprising compiling the safety library component and the hardware IP, which includes the step of mapping instances of the hardware model in the hardware IP to corresponding safety library components and aggregating the failure mode characteristics and safety data of the corresponding components.
2. The method according to claim 1, wherein each safety library component includes attributes and safety values.
3. The method according to claim 1, wherein each safety library component includes information for mapping to a hardware model, and the step of mapping the safety library component to the hardware IP includes the step of accessing the mapping information within the library component.
4. The method according to claim 1, further comprising the step of generating a global metric from the aggregated characteristics and safety data.
5. The steps include receiving the corrected hardware IP, The steps include: recompiling the safety library component and the modified hardware IP; The method according to claim 1, further comprising:
6. The method according to claim 5, wherein the recompiling step includes reusing components mapped to unchanged instances in the modified hardware IP.
7. The method according to claim 5, wherein the recompiling step includes demapping safety library components corresponding to instances removed from the modified hardware IP.
8. The method according to claim 5, wherein the recompilation step includes demapping a safety library component mapped to an instance having the modified functionality in the modified hardware IP, and mapping a new safety library component to the instance having the modified functionality.
9. The method according to claim 1, wherein each safety library component includes safety values and design data, and the method further includes the step of extracting the safety values and design data to generate estimates of the number of gates and area.
10. The method according to claim 1, wherein the hardware IP and the library are for system-on-chip use.
11. An article comprising a non-temporary electronic memory, which, when executed, causes a computing platform to perform a failure mode, impact, and diagnostic analysis (FMEDA) on hardware functional blocks (IP) of an electronic system, wherein the FMEDA is: A step of referencing a library of safety library components, wherein each safety library component includes failure mode characteristics and safety data relating to a hardware model, a safety mechanism responsible for detecting the occurrence of a failure metric, and the name of the root cause of the failure metric. An article comprising the steps of compiling the safety library component and the hardware IP, which includes the steps of mapping instances in the hardware IP to corresponding safety library components and aggregating the failure mode characteristics and safety data of the mapped components.
12. It is a synthesis tool, Memory and A processing unit is provided, The memory stores code executed by the processing unit to cause the tool to perform a failure mode, impact, and diagnostic analysis (FMEDA) on a functional block (IP), and the analysis is performed Accessing a safety component library, wherein each component in the library has failure mode characteristics and safety data relating to the model representation of the IP, and the calculation of the safety data includes a final metric included in the library, and the final metric includes a mapping to a specific design block. Compiling the safety component library and the IP, wherein the compilation is Mapping instances within the aforementioned IP to the corresponding safety library component, A synthesis tool, including compiling, which includes aggregating the failure mode characteristics and safety data of the mapped components.