Hardware description languages (HDLs) are used to design, integrate, develop, and synthesize integrated circuits. The languages provide a formal definition of the hardware logic and timing for both digital and analog components. The resulting IP design models play an important role in the safety analysis of chips (FMEA, FMEDA, FTA).
The chip design process distinguishes at least three abstraction levels:
Behavioral models in languages such as SystemC or C/C++
Register Transfer Level (RTL), usually in VHDL or Verilog
Netlist Level (NL) as the lowest level. It contains all basic parts and their connections
Ansys has defined an exchange format, IPD-XML, to enable the import of IP design into medini analyze. The exchange format contains information about the modules and the instance hierarchy of a design in all three levels in conjunction with all relevant attributes for qualitative assessment of the failure rates, especially die area and cell counts (if available).
During import from a hardware design tool, the importer creates a model and (if not yet available) a specific IP Design profile with the following attributes:
Table 15.5:
| Profile for SysML parts | ||
| Base Module Name (user_ipd_baseModuleName) | Base module from which the design instance was created. This information is useful for analyzing common failure modes of multiple instances. | |
| Die Area (user_ipd_area) | The estimated die area of the chip for this element. The unit of these numbers depends on the technology and/or liberty file (for example, micro square millimeters). Note that this value is the direct area only of the element itself, excluding sub-instances. | |
| Sequential Elements Count (user_ipd_sequentialElementsCount) | Number of sequential elements within the instance | |
| Abstraction Type (user_ipd_abstractionType) | Type of the instance, such as Behavior, Register Transfer Level (RTL), or Netlist (NL) | |
| Untestable Safe Fault Fraction (user_ipd_safeFaultsUntestable) | This attribute is reserved for future use. | |
| Cell Count (user_ipd_cellCount) | Number of cells used for the instance | |
| Gate Count (user_ipd_gateCount) | Equivalent number of gates used for the instance | |
| Profile for SysML Ports | ||
| Number of Bits (user_ipd_numberOfBits) | Bit width of the port | |
| Range (user_ipd_range) | Bit range of the port (only available for multi-bit ports) | |
The Import wizard provides several options to process the IPD-XML data. These are described in the following table.
Table 15.6:
| Option | Description |
|---|---|
| Configuration file | A configuration file can be used during import to streamline the instance hierarchy. Usually, not all sub-instance hierarchies are needed during analysis or as target for allocation, but only the area/gate counts are needed. The config file can list line by line the instance paths (typical "/" notation) which are pruned after import. That means that all instances below a given instance path are dropped, but their die area/gate/element counts are kept by adding them to the specified path. The config file can be optionally copied into the project for reuse at the next update of an IP design. |
| Import ports | Ports are usually only relevant when a detailed study of safety mechanism using fault injection is conducted. They are not required for failure rate aggregation based on die area as described in Failure Rate Aggregation for Chip Design Analysis. |
| Translate area into percentage for failure rate calculation | Translates the relative percentage of the die area for each element in the hierarchy and updates the "percentage of parent" field for failure rate prediction, namely percentages relative to the immediate parent. This option is useful in case a failure rate shall be distributed over the whole instance hierarchy to analyze individual failure rate contributions. |
| Add permanent faults | Option to auto-create a permanent failure mode at each instance, so that users have already a failure mode when creating a detailed failure net of the IP design. |
| Build canonical model by moving area of parents to extra elements | This option is useful if gates of an instance that only appear indirectly as element count/area (i.e. "glue logic" not represented as sub-instances) shall be addressable after import, such as for allocation. |
The second wizard page lists all instances that are not netlist instances, since
these typically do not have an associated die area. You can enter estimates for these
element which are then also stored in the "Die Area" attribute. This can be
useful in early stages of the design, when safety analysis is starting but netlist or die
area information is not yet available.
You can use medini analyze to see details of imported models. For more information, see Metadata of Imported Models.