Chapter 7 of the famous saga "the DO-254 for Dummies" from James BEZAMAT director of DMAP subject : IP and verification process More : dmap.fr contact : contact@dmap.fr

1. DO-254 for Dummies (7)
IP & verification process
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.
"This document is the property of DMAP. Only reproduction for non commercial usage is authorized © DMAP an Arion company

2. 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 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.
"This document is the property of DMAP. Only reproduction for non commercial usage is authorized © DMAP an Arion company

3. 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 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.
"This document is the property of DMAP. Only reproduction for non commercial usage is authorized © DMAP an Arion company

4. 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 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.
"This document is the property of DMAP. Only reproduction for non commercial usage is authorized © DMAP an Arion company

5. 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 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.
James Bezamat, 2011, december
"This document is the property of DMAP. Only reproduction for non commercial usage is authorized © DMAP an Arion company

6. DMAP DMAP
DMAP-IP
EXPERT DESIGN
www.dmap.fr
DMAP
Design Methods and Assurance Process
100 Route des Houillères—13590 Meyreuil—BP 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