DO-254 for Dummies: IP & verification process

By James Bezamat, Silkan

Context

Current electronic development is becoming increasingly dependent on predefined IP blocks (more than 35% of elec-tronic components currently in development use IP).

Let’s briefly summarize the expected advantages of this approach:

• Shorter development times (by integrating blocks)
• Lower development costs (the cost of the IP is shared between different customers)
• Increased reliability (The IP is developed by specialists in this domain and is throughly tested by all of its users, thus avoiding the need for you to perform in-house testing)
• Focus on core business (‘standard’ peripheral functions, that don’t add value to the application, are outsourced)

Of course, IP development must focus on that which is standardized, and is therefore shareable; communication periph-erals, standard protocols, data exchange interfaces, and processor cores – all the pieces of a puzzle that we call System On Chip.

It would be very surprising if the aeronautical industry (as well as other safety critical industries) could do without this key element, which is the only solution that can guarantee time to market and sustainability compatible with current requirements.

IP andDO254 : verification

Let’s first resume the goal of IP verification; to meet the expectations of the user (as described above):

• The verification provided with the IP (in the package) is an important and usable element of the superordinate pro-ject (the component)
• The results obtained – if they conform to DO-254 - can be used as elements of the verification dossier (for example, as a result of unit verification of the IP block, or as part of the results of the entirety of code coverage)
• These will not need to be fully retested (or only very minimally)

The DO-254 literature refers only in a general fashion to the impact of the IP on the verification flow of components or on complex equipment.

We will first gather together the relevant passages, and then propose a synthetic reading of this approach to the verifi-cation process for objects using IPs.

Generic Programming and Verification

The first attribute we will look at concerns the verification of the multiple combinations associated with IP configurability. An IP is, of course, a generic product, and therefore extremely configurable (buffer size, number of channels, speed, signal polarity, optional functions, etc).

Verifying all possible combinations becomes quickly impossible, although it is possible to achieve 100% of functional and code coverage.

Some publications advise verifying the significant and representative combinations, which makes sense and is good prac-tice.

Implementation is simple and classical:

The simulation set must be iterated on several parameter combinations, until we have tested a quantity sufficient to confi-dently predict the behavior of the object.

It is, therefore, just a question of time and of tools.

However, this first analysis gives rise to certain issues that merit a closer look:

Suitability to the Integrator’s Requirements

An IP is destined to be integrated into a higher-level system that freezes the IP configuration definitively.

What happens if the particular configuration used does not correspond to any of the configurations previously tested?

Can we trust the results of the IP verification in this case?

Of course not!

In this case, it will be necessary to define a tailored verification strategy adapted to the requirements of the integrator and to perform a differential repeat of the associated activities (evolution of test plan, new verification results, verification review, etc).

The supplementary burden of work caused by requirement adaptation should be sufficiently slight relative to the generic verification of the IP, that it can be considered one of the contextual part of IP integration.

If that is the case, the integrator with, potentially, the support of the IP provider, will acquire a verification review of the IP in its specific context for minimum effort.

Unused Functions and Verification

The preceding point –genericity – has another consequence that must be taken into account when using the IP in a safety context. Unlike a function that is specifically dedicated to one single application, the IP may include functionalities that are not used in the current configuration (this is also the case when reusing a previous development).

This issue, although not specific to IPs, is particularly problematic in this context, and may act as a brake on more wide-spread introduction of IPs.

The user should:

• Demonstrate that there are no unused functions when the IP is implemented.

This can be done using verification and analysis tests.

or

• Demonstrate that the unused functions are perfectly controlled and that they cannot impact negatively on the com-ponent’s functioning (particularly relevant for SEU).

This can be done by identifying the unused functions and adding the necessary protection. Verification can then be used to back up the demonstration.

This is mentioned in the EASA memo:

COTS IP guidelines (in datasheets, user manuals and errata sheets) should be defined to identify specific constraints necessary to properly control the unused functions of the COTS IP. (EASA CM - SWCEH – 001 8.4.4)

Two remarks:

• The control of unused functions usually takes place via parameters or signals peripheral to the IP – hence the phrase above. That means that the management of the IP environment and the relevant limitations must be prioritized during implementation.
• Again, the customization of an IP, with the possibility of removing unused functions, remains an envisageable alterna-tive, if the extra cost involved remains marginal.

The verification must provide evidence that demonstrates as clearly the removal of a function (simulation, analysis) as the robustness against SEU (simulation, test, analysis).

This strategic issue in introducing IPs is manageable in most cases, although it requires a certain effort, coupled with IP customization, which leads us back to our first point.

Verification and Hierarchy

What use is the IP verification review provided with the certification package?

It inspires confidence in the integrator and the certifier.

We thus demonstrate the mastery of an object by its designer, as well as conformity with DO-254 at the IP level, and con-sequently, the guarantee of correct error-free functioning if we use the IP in an appropriate environment.

This is true whichever type of COTS is used. Whether its transparent like an IP COTS (source code provided, development file and verification complete) or black box like an “ordinary” COTS, the user expects an adequate level of verification (whether the verification review is provided with the IP or not).

The review provided with an IP that includes service experience and is “silicon-proven” meets this requirement.

Using the IP unit check

Verification strategies should be based on a hierarchical approach, as for the design approach i.e. before integration at device level, sub-functions should be verified against their respective re-quirements… Sub-functions are a set of low level hardware devices that contribute together to perform a specific function: for instance, an SDRAM memory controller. (EASA CM - SWCEH – 001 8.4.2.2 d)

This requirement set out by the EASA and by aircraft manufacturers in the CRI and further defined in the CM above, is completely satisfied by the verification set provided with a DO-254-compliant IP. It shouldn’t even be necessary for the integrator to redo the unit check if all the relevant validation data, including the verification results, are included.

Exemption from extensive verification of the higher-level function

When integration of sub-functions is complete, the verification of the overall device behaviour should be performed against the related requirements. (EASA CM - SWCEH – 001 8.4.2.2 d)

The goal is restated here: higher level (device) verification should focus on an external view of the components, the inter-faces, and common mode processes linking the blocks together. The functioning at the top level, when everything is mov-ing at the same time, is an essential component of verification after integration.

Test the robustness of the function

Functional robustness should also be assessed at isolated sub-function level. (EASA CM - SWCEH – 001 8.4.2.2 d)

As mentioned above, robustness (boundary tests, functioning improbable or impossible) must be evaluated at sub-function level.

Indeed, it is often impossible to create the local conditions necessary to evaluate the borderline behavior of a sub-block at the higher-level, or to test the efficiency of a security system that is limited by the IP environment.

Assess the quality of the verification via code coverage.

The HDL code coverage measurement at sub-function level may alleviate the HDL code coverage measurement at device level. (EASA CM - SWCEH – 001 8.4.2.1 g)

Taking into account the issues we’ve just discussed, it is obvious that re-producing comprehensive verification of a func-tion at the higher-level is pointless. This is as true for IPs and components as it is at the component and board or equip-ment levels.

At the higher (integration) level, focus is on the verification of the integration itself, and not on unit checking. Are the comprehensive tests of an ASIC (SCAN, ATPG) carried out by the ASIC manufacturer repeated by a system integrator for each ASIC on a board? No, of course not!

The code coverage obtained at local level can be entirely legitimately used as a departure point for the higher level.

Conclusion and Summary

The integration of IPs within embedded systems is inevitable. This will take place by ever simpler means as implementa-tion processes become more transparent and are shared by the community, while still conforming to the main goal of functional safety and process assurance. Some issues still in discussion relate to the role played by IP verification, which must take into account the unique characteristics of this type of open object.

It seems that nothing is impossible. On the contrary, solutions that combine common sense, efficiency, productivity gains, and increased safety levels exist.

Some of the methods of IP integration may be quite original, as described above, but these methods will be further vali-dated as they are shared by other industrial fields with the same requirements.

www.silkan.com

If you wish to download a copy of this white paper, click here