Annex F
(informative)
Techniques and measures for ASICs –
avoidance of systematic failures
F.1General
For the design of Application Specific Integrated Circuits (ASICs) the following techniques and measures for the avoidance of failures during the ASIC-development should be applied.

NOTE 1 This informative annex is referenced by 7.4.6.7.

NOTE 2 The following techniques and measures are related to digital ASICs and user programmable ICs only. For mixed-mode and analogue ASICs no general techniques and measures can be given at the moment.

a) All design activities and test arrangements, and tools used for the functional simulation and the results of the simulation, should be documented.

b) All tools, libraries and manufacturing procedures should be proven in use. This includes:
• application of the individual tool (including different versions with equivalent features) over a substantial period of time in projects of similar or greater complexity;

NOTE 3 A substantial period of time might be 2 years in this case.
• application of common or widely used tools to ensure that information about possible bugs and restrictions is known for the given tool and/or the given version, which shouldbe considered during use. Version control and monitoring should be carried out by the manufacturers to track existing faults;
• internal consistency and plausibility checks to avoid faults in the different databases created by different tools.

NOTE 4 User training is very important because of the rapid changes and progress in this field.

c) All activities and their results should be verified, for example by simulation, equivalence checks, timing analysis or checking the technology constraints.

d) Measures for the reproducibility and automation of the design implementation process (script based, automated work and design implementation flow) should be used.

e) For 3rd party soft-cores and hard-cores, only validated macro blocks should be used and these should comply with all constraints and proceedings defined by the macro core provider if practicable. Unless already proven in use, each macro block should be treated as newly written code, for example it should be fully validated.

f) For the design, a problem-oriented and abstract high-level design methodology and design description language should be used.

NOTE 5 The design description should use a hardware description language like VHDL or Verilog. This is the most common hardware description methodology used today in ASIC design. Both languages are defined by IEEE standards and are assumed to satisfy the recommendations for high level programming languages. The hardware
description language may be used both for design description and for functional models or test benches. When used for design description, only a subset of the language may be used; this synthesisable code is often referred to as RTL (register transfer level) code. Non synthesisable code, adequate for functional models and test benches is called behavioural code.

g) Adequate testability (for manufacturing test of the full and semi-custom ASIC) should be achieved.

h) Gate and interconnection (wire) delays should be considered during test and ASIC
verification steps.

i) Internal gates with tristate outputs should be avoided. If internal tristate outputs are used these outputs should be equipped with pull-ups/downs or bus-holders.

j) Before manufacturing, an adequate verification of the complete ASIC (i.e., including each verification step carried out during design and implementation to ensure correct module and chip functionality) should be carried out.

NOTE 6 The adequacy of ASIC verification depends on the test complexity of the element and the required safety integrity level.

F.2 Guidelines: Techniques and measures
An appropriate group of techniques and measures that are essential to prevent the
introduction of faults during the design and development of ASICs should be used. Depending upon the technical realisation, a differentiation between full and semi-custom digital ASICs and user programmable ICs (FPGA/PLD/CPLD) is necessary. Techniques and measures that support the achievement of relevant properties are defined in Table F.1for full and semi custom ASICs and in Table F.2 for user programmable ICs. The related ASIC development lifecycle is shown in Figure 3.
In Tables F.1and F2 recommendations are made by safety integrity level, stating firstly the importance of the technique or measure and secondly the effectiveness recommended if it is used. The importance is signified as follows:

– HR*: the technique or measure is highly recommended for this safety integrity level. No design should exclude this technique or measure;

– HR: the technique or measure is highly recommended for this safety integrity level. If this technique or measure is not used, then the rationale behind not using it should be detailed;

– R: the technique or measure is recommended for this safety integrity level. If this
technique or measure is not used or none of possible alternatives is used, then the
rationale behind not using it should be detailed;

– -: the technique or measure has no recommendation for or against being used;
– NR: the technique or measure is positively not recommended for this safety integrity level.

If this technique or measure is used, then the rationale behind using it should be detailed;
The recommended effectiveness is signified as follows.
– Low: if used, the technique or measure should be used to the extent necessary to give at least low effectiveness against systematic failures;
– Medium: if used, the technique or measure should be used to the extent necessary to give at least medium effectiveness against systematic failures;
– High: the technique or measure should be used to the extent necessary to give high effectiveness against systematic failures.
Following the guidelines in this annex does not guarantee by itself the required safety integrity. It is important to consider:
– the consistency of the chosen techniques and measures, and how well they will
complement each other;
– which techniques and measures are appropriate, for every phase of the development lifecycle; and
– which techniques and measures are most appropriate for the specific problems encountered during the development of each different E/E/PE safety-related system.