DO-254 for Dummies (7)

IP & verification process

Context
Current electronic development is becoming increasingly dependent on predefined IP blocks (more than 35% of electronic components currently in development use IP).
Lets 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 dont add value to the application, are outsourced)
Of course, IP development must focus on that which is standardized, and is therefore shareable; communication peripherals, 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
Lets 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 project (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 verification process for objects using IPs.

"This document is the property of DMAP. Only reproduction for non commercial usage is authorized DMAP an Arion company

DO-254 for Dummies (7)

IP & verification process
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 practice.
Implementation is simple and classical:
The simulation set must be iterated on several parameter combinations, until we have tested a quantity sufficient to confidently 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 Integrators 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.

"This document is the property of DMAP. Only reproduction for non commercial usage is authorized DMAP an Arion company

DO-254 for Dummies (7)

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 widespread 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 components 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 alternative, 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.

"This document is the property of DMAP. Only reproduction for non commercial usage is authorized DMAP an Arion company

DO-254 for Dummies (7)

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 consequently, 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 requirements 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 shouldnt 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 interfaces, and common mode processes linking the blocks together. The functioning at the top level, when everything is moving 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 subfunction 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.

"This document is the property of DMAP. Only reproduction for non commercial usage is authorized DMAP an Arion company

DO-254 for Dummies (7)

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 weve just discussed, it is obvious that re-producing comprehensive verification of a function at the higher-level is pointless. This is as true for IPs and components as it is at the component and board or equipment 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 implementation 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 validated as they are shared by other industrial fields with the same requirements.

James Bezamat, 2011, december

"This document is the property of DMAP. Only reproduction for non commercial usage is authorized DMAP an Arion company

DMAP

DMAP
DMAP-IP

DESIGN

www.dmap.fr

EXPERT

DMAP
Design Methods and Assurance Process
100 Route des Houillres13590 MeyreuilBP 2
04.42.61.29.13
contact@dmap.fr

DMAP is member of the cluster

They trust DMAP

"This document is the property of DMAP. Only reproduction for non commercial usage is authorized DMAP an Arion company