EN 16603-20-40:2023

SLOVENSKI STANDARD
01-februar-2024
Vesoljska tehnika - Inženiring ASIC, FPGA in jedra IP
Space engineering - ASIC, FPGA and IP Core engineering
Raumfahrttechnik - ASIC und FPGA Technik
Ingénierie spatiale - Ingénierie des ASIC, FPGA et noyaux de PI
Ta slovenski standard je istoveten z: EN 16603-20-40:2023
ICS:
49.140 Vesoljski sistemi in operacije Space systems and
operations
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 16603-20-40

NORME EUROPÉENNE
EUROPÄISCHE NORM
December 2023
ICS 49.140
English version
Space engineering - ASIC, FPGA and IP Core engineering
Ingénierie spatiale - Ingénierie des ASIC, FPGA et Raumfahrttechnik - Entwicklung von ASICs, FPGAs und
noyaux de PI IP-Kernen
This European Standard was approved by CEN on 3 December 2023.

CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and United Kingdom.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2023 CEN/CENELEC All rights of exploitation in any form and by any means
Ref. No. EN 16603-20-40:2023 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Table of contents
European Foreword .6
Introduction .7
1 Scope .8
2 Normative references .9
3 Terms, definitions and abbreviated terms . 10
3.1 Terms from other standards .10
3.2 Terms specific to the present standard .10
3.3 Abbreviated terms .17
3.4 Conventions .19
3.4.1 Names of DEVICE development phases and reviews . 19
3.4.2 Companies involved in the DEVICE development . 20
3.4.3 Types of DEVICEs and requirements tailoring tag notation . 20
3.5 Nomenclature .21
4 Principles . 22
4.1 DEVICE development .22
4.2 Verification methods .22
5 DEVICE engineering . 23
5.1 General requirements .23
5.1.1 Overview .23
5.1.2 Tailoring according to DEVICE type and DEVICE criticality . 23
5.1.3 DEVICE engineering development flow . 23
5.1.4 Phase Reviews .25
5.1.5 DEVICE Verification Control Document . 25
5.2 DEVICE Definition Phase .27
5.2.1 Overview .27
5.2.2 DEVICE Requirements Specification .27
5.2.3 DEVICE Development Plan .27
5.2.4 Preliminary Verification and Validation Plans . 28
5.2.5 Preliminary DEVICE Support and Maintenance Plan . 28
5.2.6 Feasibility and Risk Assessment .28
5.2.7 DEVICE Definition Phase Review .29
5.3 DEVICE Architecture Definition Phase .29
5.3.1 Overview .29
5.3.2 Architecture Definition .29
5.3.3 Updated DEVICE Verification and Validation Plans . 30
5.3.4 DEVICE Architecture Definition Phase Review. 30
5.4 DEVICE Design and Verification Phase .30
5.4.1 Overview .30
5.4.2 DEVICE Verification Plan .31
5.4.3 DEVICE Design and Verification .31
5.4.4 DEVICE Database .32
5.4.5 Preliminary DEVICE Data Sheet .33
5.4.6 DEVICE Design and Verification Phase Review . 33
5.5 DEVICE Detailed Design Phase .34
5.5.1 Overview .34
5.5.2 Netlist Generation .34
5.5.3 Netlist verification .36
5.5.4 DEVICE Data Sheet update .36
5.5.5 DEVICE Database update .36
5.5.6 DEVICE Detailed Design Phase Review . 37
5.6 DEVICE Layout Phase . 37
5.6.1 Overview .37
5.6.2 Layout generation .37
5.6.3 Layout verification .39
5.6.4 DEVICE Validation Plan .39
5.6.5 DEVICE Database update .39
5.6.6 DEVICE Data Sheet update .39
5.6.7 Preliminary ESCC Detail Specification . 39
5.6.8 DEVICE Layout Phase Review . 40
5.7 DEVICE Implementation Phase .40
5.7.1 Overview .40
5.7.2 Production and test .41
5.7.3 DEVICE Database update .41
5.7.4 DEVICE Validation Plan completion .42
5.7.5 DEVICE Implementation Phase Review . 42
5.8 DEVICE Validation, Qualification and Acceptance Phase . 42
5.8.1 Overview .42
5.8.2 DEVICE validation .43
5.8.3 DEVICE Support and Maintenance .43
5.8.4 Experience Summary Report .43
5.8.5 Final versions of application and procurement documents . 44
5.8.6 DEVICE Validation, Qualification and Acceptance Phase Review . 44
6 Pre-tailoring according to DEVICE criticality and type . 46
6.1 DEVICE criticality categories .46
6.2 Pre-tailoring Matrix .49
Annex A (normative) DEVICE Requirements Specification (DRS) - DRD . 93
Annex B (normative) DEVICE Development Plan (DDP) - DRD. 98
Annex C (normative) DEVICE Verification Plan (DVeP) - DRD . 101
Annex D (normative) DEVICE Validation Plan (DVaP) - DRD . 106
Annex E (normative) DEVICE Support and Maintenance Plan (DSMP) -
DRD . 108
Annex F (normative) DEVICE Feasibility and Risk Assessment Report
(DFRAR) - DRD. 110
Annex G (normative) DEVICE Architecture Definition Report (DADR) - DRD. 114
Annex H (normative) DEVICE Data Sheet (DDS) - DRD . 117
Annex I (normative) Experience Summary Report - DRD . 119
Annex J (informative) Generic Development Flow Variations . 120
Annex K (informative) DEVICE Development Expected Outputs . 126
Annex L (informative) Equivalence of phase and milestone terminology of
ECSS-M-ST-10 and ECSS-E-ST-20-40 . 134
Bibliography . 139

Figures
Figure 5-1: DEVICE development flow (generic case) .26
: Example of DEVICE development flow with intermediate additional reviews . 121
: Example of DEVICE development flow variation with two DEVICE modules
developed and reviewed in parallel . 122
: Example of DEVICE development flow variation where three phases have
been merged .124
: Example of DEVICE development flow where three phases are iterated . 125

Tables
Table 6-1: DEVICE criticality categories .47
Table 6-2: Pre-tailoring Matrix .50
Table K-1 : Summary of expected outputs of engineering flow . 126
Table K-2 : ECSS-E-ST-20-40 and ECSS-Q-ST-60-03 list of expected document
outputs .128
Table L-1 : Equivalence of phase and milestone terminology of ECSS-M-ST-10 and
ECSS-E-ST-20-40 . 135

European Foreword
This document (EN 16603-20-40:2023) has been prepared by Technical
Committee CEN-CENELEC/TC 5 “Space”, the secretariat of which is held by
DIN.
This standard (EN 16603-20-40:2023) originates from ECSS-E-ST-20-40C.
This European Standard shall be given the status of a national standard, either by
publication of an identical text or by endorsement, at the latest by June 2024, and
conflicting national standards shall be withdrawn at the latest by June 2024.
Attention is drawn to the possibility that some of the elements of this document
may be the subject of patent rights. CEN [and/or CENELEC] shall not be held
responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request given to CEN
by the European Commission and the European Free Trade Association.
This document has been developed to cover specifically space systems and has
therefore precedence over any EN covering the same scope but with a wider
domain of applicability (e.g. aerospace).
According to the CEN-CENELEC Internal Regulations, the national standards
organizations of the following countries are bound to implement this European
Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
Developing custom designed monolithic integrated circuits such as ASICs or
FPGAs, and developing IP Cores, as off-the-shelf Building Blocks for these
complex ICs, make certain engineering and technical management activities
crucial to the success of these developments.
ECSS-E-ST-20-40 was written in parallel and in co-ordination with the writing
ECSS-Q-ST-60-03, by the same ECSS Working Group. These two new and
complementary standards cover respectively the engineering and the product
assurance requirements to be applied when developing ASICs, FPGAs and IP
Cores, and these two new standards together supersede ECSS-Q-ST-60-02C.
The DEVICE qualification status is assessed based on the requirements from both
ECSS-E-ST-20-40 and ECSS-Q-ST-60-03. In order for a DEVICE to be qualified
and accepted according to ECSS standards, the DEVICE development reviews
specified in ECSS-E-ST-20-40 have to be declared successful by the customer
engineering and PA responsible persons and project management who
monitored the DEVICE development.
Scope
This standard specifies a comprehensive set of engineering requirements for the
successful development of digital, analogue and mixed analogue-digital signal
custom designed integrated circuits, such as application specific integrated
circuits (ASICs), field programmable gate arrays (FPGAs) and Intellectual
Property Cores (IP Cores), from now on referred to with the single and generic
term DEVICEs.
Microelectronics systems created by more than one DEVICE die but that are
interconnected and packaged together as a single DEVICE are not considered
single monolithic DEVICEs. However ECSS-ST-20-40 is to be applied to (a) the
development of each individual monolithic die, (b) also for their integration onto
a multi-die single DEVICE considering those dice as IP Cores.

This standard may be tailored for the specific characteristic and constraints of a
space project in conformance with ECSS-S-ST-00. A pre-tailoring based on the
actual DEVICE type and criticality category of the DEVICE is addressed in
clause 5.1.2.
This standard does not cover requirements for the selection, control, procurement
or usage of DEVICEs for space projects nor DEVICE ESCC qualification
requirements, as those requirements are covered by ECSS-Q-ST-60C EEE
components standard and the ESCC generic specification No. 9000 respectively.
Nevertheless, this standard contemplates the possibility for the DEVICE to
undergo ESCC qualification after the DEVICE customer acceptance as an ECSS
qualified DEVICE, and thus a DEVICE ESCC Detail Specification and DEVICE
Radiation Test Plan and Report are optional expected outputs.
Normative references
The following normative documents contain provisions which, through reference
in this text, constitute provisions of this ECSS Standard. For dated references,
subsequent amendments to, or revisions of any of these publications do not
apply. However, parties to agreements based on this ECSS Standard are
encouraged to investigate the possibility of applying the most recent editions of
the normative documents indicated below. For undated references the latest
edition of the publication referred to applies.

EN reference Reference in text Title
EN 16601-00-01 ECSS-S-ST-00-01 ECSS system – Glossary of terms
EN 16602-30 ECSS-Q-ST-30 Space product assurance – Dependability
EN 16602-40 ECSS-Q-ST-40 Space product assurance – Safety
- ECSS-Q-ST-60-03 Space product assurance – ASIC, FPGA and IP Core
product assurance
Terms, definitions and abbreviated terms
3.1 Terms from other standards
a. For the purpose of this Standard, the terms and definitions from ECSS-
S-ST-00-01 apply, in particular the following terms:
1. acceptance;
2. component;
3. customer;
4. engineering model;
5. flight model;
6. informative;
7. maintenance;
8. model;
9. normative;
10. performance;
11. project;
12. requirement;
13. risk;
14. supplier.
NOTE The old term firmware is defined in
ECSS-S-ST-00-01C, and it is not used in the
context of ECSS-E-ST-20--40 because with the
emergence of new technologies it is now
ambiguous and unnecessary. It is important not
to confuse terms like FPGA, FPGA programming
file or FPGA programming bit stream with
firmware.
3.2 Terms specific to the present standard
3.2.1 Application Specific Integrated Circuit
full custom or semi custom designed monolithic integrated circuit
NOTE ASICs can be digital, analogue or a mixed
function.
3.2.2 block diagram
abstract graphical presentation of interconnected named boxes or blocks
representing an architectural or functional drawing
3.2.3 Building Block
reusable IC design element that implements a self-standing function or group of
functions for which ownership rights exist and that has been developed in the
context of a specific IC project or technology, without the intention to be shared
with third parties for its reuse in other IC projects
NOTE For example, an HDL model such as
synthesizable VHDL code, or gate-level netlist,
or an analogue function.
3.2.4 cell
specific circuit function including digital or analogue basic blocks
3.2.5 cell library
collection of all mutually compatible cells which conforms to a set of common
constraints and standardized interfaces designed and characterized for a
specified technology
3.2.6 code
string of words, numbers, letters and symbols that is used to model a DEVICE or
its verification and validation environment
NOTE For example, Hardware Description Languages
like VHDL, Verilog or SystemC are used to code
DEVICE behavioral or synthesisable models,
and code in other languages like C, Python or
Tool Command Languages (Tcl) can be used in
the DEVICE verification and validation.
3.2.7 data sheet
detailed functional, operational and parametric description of a DEVICE
NOTE A data sheet can include, for instance, a block
diagram, truth table, pin and signal description,
environmental, electrical and performance
parameters, tolerances, timing information, and
package description.
3.2.8 design for test
technique used to allow a complex integrated circuit to be tested with respect to
potential manufacturing faults or to accelerate otherwise too slow validation tests
NOTE 1 For example, any dedicated circuits aimed to
provide better observability or commandability
of internal nodes of the DEVICE not accessible
through primary inputs and outputs.
NOTE 2 Other examples of DFT are test busses, boundary
scan as in JTAG, see IEEE 1149.1-2013, built-in
self-test, and test modes for functional tests
performed at DEVICE Validation, Qualification
and Acceptance Phase.
3.2.9 design iteration
design changes that occur in any single phase or between two consecutive phases
as defined in the DEVICE Development Plan, before the final DEVICE is released
3.2.10 DEVICE
integrated circuit or an IP Core
NOTE 1 A DEVICE can be a digital, analogue or mixed-
signal ASIC, a programmed FPGA, a blank
FPGA, a microprocessor, and a model of an IC
function that is conceived for reuse as an IP Core.
NOTE 2 A DEVICE can also be a group of dice or chiplets
interconnected and integrated inside a single
package, such as a system-in-package or a multi-
chip-module.
3.2.11 DEVICE Database
set of all digital files that are needed for the development of a DEVICE
NOTE 1 Examples of files integrating this database are
behavioral and HDL models of the DEVICE,
layout description files, models of the DEVICE
system environment used to verify by
simulation the DEVICE functionality,
configuration files and SW programs used for
the automation of the verification and validation
of the DEVICE, input and output files used and
generated by the different CAD tools used, for
example files describing the resources, area,
timing and power constraints, stimuli and
expected output values files, or FPGA bit stream
binary files.
NOTE 2 This database of files is incrementally updated
throughout the DEVICE development phases,
and all necessary elements that enable support,
maintenance and a new development of the
same or a modified version of the DEVICE can
be found in the DEVICE database at the end of
the DEVICE Validation, Qualification and
Acceptance Phase.
3.2.12 DEVICE development flow
selection and sequence of engineering methods and tools applied during the
definition, design, verification, implementation and validation of the DEVICE
3.2.13 DEVICE model
textual or graphical representation of a DEVICE, or a part of it, which defines one
or several DEVICE characteristics
NOTE 1 For example, digital or analogue functional
behavior, timing performance, power
consumption, sizes and interconnections of
physical internal structures, input and output
external interfaces, environmental effects due to
temperature, radiation or aging.
NOTE 2 DEVICE models can be created graphically as
graphical design drawings or with textual
Hardware Description Languages like VHDL,
Verilog, SystemC or EDIF.
NOTE 3 DEVICE models can implement several levels of
abstraction such as behavioral, Register-
Transfer-Level, gate-level netlist or transistor-
level, and accuracy such as untimed, loosely
timed or approximately timed.
NOTE 4 DEVICE models can be generated manually,
assisted by CAD specialized IC design tools or a
mix of both.
3.2.14 DEVICE technology
totality of all elements needed for the design, physical implementation and test
of either ASIC or FPGA components
NOTE 1 For example, design tools and their description,
cell libraries, procedures, design rules,
manufacturing process, programming tools, test
equipment.
NOTE 2 Sometimes the terms ASIC technology or FPGA
technology are used when referring to the
technology of only that type of DEVICE.
3.2.15 fault coverage
measure expressed as a percentage of the proportion of actually detectable faults
versus all possible faults in a digital circuit, for a given set of test patterns and
with respect to a specific fault model
3.2.16 Field Programmable Gate Array
standard semiconductor device that becomes customized when programmed by
the user with specific software and hardware tools
3.2.17 FPGA Programming Test
test performed to validate the successful programming of an FPGA
NOTE For example, to detect inaccurate programming
procedures, incorrect programming files, poor
calibration of FPGA programmer, or material
defects in the FPGA.
3.2.18 floorplan
abstracted, scaled layout drawing of the die, outlining the form, size and position
of the major functional blocks and the pads including power and ground lines,
clock distribution and interconnect channels
3.2.19 HDL model
textual description of an integrated circuit based on a hardware description
language suitable for the behavioural or structural description and simulation
3.2.20 IP Core
integrated circuit design element that implements a self-standing function or
group of functions for which ownership rights exist and is developed for reuse
and released with comprehensive verification, validation and documentation
NOTE 1 IP core can be acquired by a customer, for a
given price and under an owner-defined license
agreement specifying the customer's acquired
rights.
NOTE 2 IP core can be supplied as an HDL model, as a
synthesizable VHDL code or gate-level netlist,
and with the essential complementary
documentation that allows the customer to
successfully integrate and use it in a system, for
example User’s Manual and verification files.
From this point of view, it can be seen as a semi-
finished product.
NOTE 3 IP Cores can be analogue functions provided by
DEVICE technology providers as macrocells.
NOTE 4 In contrast with Building Blocks, IP Cores have
gone through comprehensive verification,
validation and documentation intended for
reuse of third parties.
NOTE 5 IP Cores sometimes are referred as hard IPs if
they are already placed and routed for one
specific IC technology. For example, a macrocell
already pre-diffused inside an FPGA or an
already layouted function that is included in an
ASIC, or a netlist that cannot be modified and is
treated as a black-box.
NOTE 6 An IP Core can be composed by combination of
different IP Cores.
3.2.21 macrocell
module that contains complex functions in a given technology’s cell library built
up out of hard-wired primitive cells
NOTE Macrocells can be provided as a library
component for ASIC design, for example RAM
blocks, or be present inside pre-diffused devices
such as DSP blocks or microprocessor cores
existing inside FPGAs.
3.2.22 netlist
formatted list of cells, basic circuits, and their interconnections
NOTE 1 The term pre-layout netlist is used for DEVICE
netlists that do not contain yet the DEVICE
layout information. For example, detailed timing
behavior of the cells, timing impact of the
interconnections.
NOTE 2 For FPGA, pre-layout netlist means usually the
netlist obtained through synthesis tools.
3.2.23 phase
set of interrelated DEVICE development activities
NOTE 1 A DEVICE generic development flow usually
consists of seven phases as depicted in Figure
5-1. See Annex J for more development flow
examples.
NOTE 2 The concept of phase is equivalent to the concept
of process defined in ECSS-S-ST-00-01.
3.2.24 processing unit
function which is defined to execute software
NOTE 1 The term covers hardware functions such as
general purpose processing cores, and more
specialized Graphical Processing Unit (GPU),
Vision Processing Unit (VPU), Tensor Processing
Unit (TPU), Neural Processing Unit (NPU),
Physics Processing Unit (PPU), Digital Signal
Processor (DSP), or Image Signal Processor (ISP).
NOTE 2 In the context of SW engineering, it also covers
software processing units such as interpreters,
emulators and virtual machines.
3.2.25 production test
test performed on the manufactured DEVICEs to detect functional problems
resulting from faults or random material defects during wafer manufacturing,
die assembly and packaging
NOTE 1 Production Tests are normally performed with
test vectors generated by the DEVICE designer
and Automatic Test Equipment (ATE) by the
DEVICE manufacturer.
NOTE 2 Production Tests include for example stuck-at
faults scan tests, timing delay faults, I/O
parametric tests for digital ASICs.
NOTE 3 Analogue ASICs Production Tests examples are
reference voltage or current tests, AD/DA
converters tests or tests to catch manufacturing
defects affecting any analogue function.
NOTE 4 Production Tests are not DEVICE Validation
tests, which are tests performed on the final
DEVICE, ASIC or FPGA, to validate that all
requirements in DRS are met. Validation tests
are normally performed by the DEVICE
development team (the supplier), and not by the
DEVICE manufacturer (the foundry), and they
include functional, environmental and
mechanical tests.
3.2.26 prototype
fabricated ASIC or programmed FPGA used to verify preliminary
implementations of the DEVICE against the DEVICE Requirements Specification
3.2.27 redesign
design changes which were not planned in the DEVICE Development Plan and
which involve reopening an already closed phase
NOTE These design changes can be motivated by
unexpected changes in the DRS, wrong
interpretation of the DRS or design mistakes.
3.2.28 software
set of instructions and data executed on a processing unit
NOTE 1 A processing unit can be hardware, for example
a processor chip, or software, for example a
virtual machine or an interpreter.
NOTE 2 Some processing units only require data, for
example configuration of state machines or
configuration data of a neural network.
NOTE 3 Files using Hardware Description Languages
(VHDL, Verilog, SystemC) used to model ASICs
or bit stream files used to program FPGAs are
not software.
3.2.29 stimuli
input data set for simulation or test to show a specific functionality or
performance of a DEVICE
3.2.30 synthesis tool
tool that automatically converts a high-level textual representation of an
integrated circuit, usually coded in Hardware Description Language at register–
transfer-level, into an optimized gate-level netlist representation of the integrated
circuit
3.2.31 system requirement
functional, electrical, environmental, mechanical, test or quality requirement of
the system wherein the DEVICE is used
3.2.32 Validation

process which demonstrates through the provision of objective evidence that the
DEVICE, in its final manufactured (ASIC) or programmed (FPGA) form, is able
to perform and behave as expected in the intended system, operational
environment and application scenarios
NOTE 1 DEVICE verification is normally performed
before DEVICE validation.
NOTE 2 Typical validation methods are hardware tests of
the DEVICE integrated in its intended or a
representative system, operational environment
and application scenarios.
NOTE 3 This term is defined in the present standard with
a different meaning than in ECSS-S-ST-00-01.
The term with the meaning defined herein is
applicable only to the present standard.
3.2.33 Verification

process which demonstrates through the provision of objective evidence that the
DEVICE is free of design mistakes and is designed according to its DEVICE
Requirements Specification, target technology and manufacturability
requirements, as well as any agreed deviations and waivers
NOTE 1 A waiver can arise as an output of the
verification process.
NOTE 2 DEVICE verification is normally performed
before DEVICE validation.
NOTE 3 Verification can be accomplished by one or more
of the following methods: analysis (including
similarity), simulations of DEVICE models, test
of preliminary prototypes, review of design and
inspection.
NOTE 4 This term is defined in the present standard with
a different meaning than in ECSS-S-ST-00-01.
The term with the meaning defined herein is
applicable only to the present standard.
3.3 Abbreviated terms
For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01
and the following apply:
Abbreviation Meaning
alternating current
AC
DEVICE Architecture Definition Phase Review
ADR
Application Specific Integrated Circuit
ASIC
Computer Aided Design
CAD
DEVICE Architecture Definition Report
DADR
direct current
DC
DEVICE Development Plan
DDP
DEVICE Detailed Design Phase Review
DDR
DEVICE Data Sheet
DDS
design for test
DFT
DEVICE Definition Phase Review
DPR
design rule check
DRC
document requirements definition
DRD
DEVICE Requirements Specification
DRS
DEVICE Support and Maintenance Plan
DSMP
DEVICE Validation Plan
DVaP
DEVICE Verification Plan
DVeP
DEVICE Design and Verification Phase Review
DVR
electronic design automation
EDA
electronic design interchange format
EDIF
engineering model
EM
electrical rule check
ERC
European Space Components Coordination
ESCC
electrostatic discharge
ESD
flight model
FM
field-programmable gate array
FPGA
DEVICE Feasibility and Risk Assessment Report
DFRAR
graphic design system two (industry standard graphics entry
GDSII
database file format for ASICs)
Abbreviation Meaning
hardware description language
HDL
hardware
HW
input-output
I/O
integrated circuit
IC
Institute of Electrical and Electronics Engineers
IEEE
intellectual property
IP
DEVICE Implementation Phase Review
IPR
joint test action group
JTAG
DEVICE Layout Phase Review
LPR
look up table
LUT
minutes of meeting
MoM
place and route
P&R
register-transfer level
RTL
standard delay format
SDF
single event upset
SEU
standard parasitic exchange format
SPEF
software
SW
DEVICE Validation, Qualification and Acceptance Phase
VQAR
Review
Verification Control Document
VCD
Very High Speed Integrated Circuit Hardware Description
VHDL
Language
3.4 Conventions
3.4.1 Names of DEVICE development phases and
reviews
The names of DEVICE development phases and reviews specified in ECSS-E-ST-
20-40 do not follow the naming conventions specified in ECSS-M-ST-10 in an
effort to use widely established ASIC, FPGA and IP Core engineering
terminology which is self-explanatory and commonly used by IC engineers. In
order to facilitate collaboration between IC and PA engineers ECSS-E-ST-20-40
provides a comparison between the ECSS-E-ST-20-40 phases and ECSS-M-ST-10
phases and key names in Annex L.
3.4.2 Companies involved in the DEVICE
development
In addition to supplier and customer terms used in ECSS standards, the following
other terms for other companies that can be part of the DEVICE development are
used in ECSS-E-ST-20-40:
a. FPGA technology provider;
b. ASIC technology provider;
c. ASIC manufacturer;
d. Company developing DEVICE layout.
The term technology vendor, even if widely used in the ASIC, FPGA and IP Core
community, is avoided in ECSS-E-ST-20-40 in favour of technology provider for the
sake of simplicity.
3.4.3 Types of DEVICEs and requirements
tailoring tag notation
Find below the basic notation for the different types of DEVICEs in the scope of
ECSS-E-ST-20-40 marked in blue color:
D-ASIC applicable to fully digital ASICs, or the digital part of
mixed-signal ASICs
A-ASIC applicable to fully analogue ASICs, or the analogue part
of mixed-signal ASICs
FPGA applicable to FPGAs, which can also be mixed-signal
DEVICEs
IP applicable to digital or analogue IP Cores
Every requirement in ECSS-E-ST-20-40 contains a “tailoring tag” at the end of the
last sentence of the requirement that indicates to which type of DEVICE the
requirement is applicable. The tailoring tag can contain one, two or three of the
following elements, always in the same order:
[D-ASIC, A-ASIC, FPGA, IP]
If applicable to all four DEVICE types indistinctly, the tag is a simpler
[ALL]
Whenever one of more DEVICEs types shall not be concerned by the
requirement, the expression
“--“
is found in the relevant position. For example:
• [D-ASIC, A-ASIC, FPGA, --] requirement applicable to all DEVICE
types, except for IP Cores;
• [--, A-ASIC, --, --] requirement only applicable to analogue ASICs or to
the analogue part of mixed-signal ASICs;
• [D-ASIC, --, FPGA, IP] requirement applicable to all DEVICE types,
except for analogue ASICs.
In the context of ECSS-E-ST-20-40, the development of general purpose complex
ICs such as microprocessors, microcontrollers, blank FPGAs or other
(re)programmable or extensively configurable DEVICEs commonly known as
DSP, GPU, VPU are treated as ASIC developments.
3.5 Nomenclature
The following nomenclature applies throughout this document:
a. The word “shall” is used in this Standard to express requirements. All the
requirements are expressed with the word “shall”.
b. The word “should” is used in this Standard to express recommendations.
All the recommendations are expressed with the word “should”.
NOTE It is expected that, during tailoring,
recommendations in this document are either
converted into requirements or tailored out.
c. The words “may” and “need not” are used in this Standard to express
positive and negative permissions, respectively. All the positive
permissions are expressed with the word “may”. All the negative
permissions are expressed with the words “need not”.
d. The word “can” is used in this Standard to express capabilities or
possibilities, and therefore, if not accompanied by one of the previous
words, it implies descriptive text.
NOTE In ECSS “may” and “can” have completely
different meanings: “may” is normative
(permission), and “can” is descriptive.
e. The present and past tenses are used in this Standard to express statements
of fact, and therefore they imply descriptive text.
Principles
4.1 DEVICE development
The end-to-end DEVICE development involves several phases. The DEVICE
supplier derives from the system requirements WHAT are the functional,
performance, environmental and physical requirements that the DEVICE has to
meet. The detailed process of HOW the DEVICE will be developed, which
includes detailed verification and validation plans, is incrementally specified and
implemented by the supplier and reviewed with the customer applying the
requirements of ECSS-E-ST-20-40.
The supplier derives requirements and plans of actions for the development of
the DEVICE within the boundaries of ECSS-E-ST-20-40. The DEVICE
requirements are based on the requirements of the system for which it is intended
and take into consideration the operational and environmental requirements of
the space project or programme where the DEVICE will be used.
Starting with a global development plan, the verification and validation plans are
specified and executed incrementally by the supplier as the DEVICE design
progresses through several development phases and until fully verified and
validated DEVICEs are accepted by the customer.
4.2 Verification methods
Verification methods allow to provide objective evidence that the DEVICE or
parts of it are designed according to its requirements specifications and being free
of design errors. Such methods can be grouped in five major categories:
1. ANALYSIS of documents and DEVICE models, often using
specialised IC design CAD tools for the analysis of the DEVICE
timing, power consumption, resources occupation, parasitic effects,
etc.;
2. SIMULATIONS of DEVICE models using IC design CAD tools to
perform behavioural and time-accurate simulations of DEVICE
internal and output signals obtained when stimuli are applied at
DEVICE inputs or internal DEVICE circuit nodes;
3. TEST of DEVICE hardware prototypes prior to final DEVICE
manufacturing or programming;
4. REVIEW of DEVICE models or circuit schematics performed
visually or aided by ad-hoc computer programs. This category
includes what is known as review-of-design (ROD) in
ECSS-E-ST-10-02;
5. INSPECTION of the DEVICE hardware. For example, visual
inspection of the prototypes used for verification tests in order to
check correct mounting on the board or the use of the correct part.
DEVICE engineering
5.1 General requirements
5.1.1 Overview
The development of a new DEVICE involves going through a flow of several
phases which encompass several engineering steps. It is important to agree with
the customer what is the final set of requirements in compliance with ECSS-E-ST-
20-40 that are applied and thus specify the engineering steps to go through,
taking into consideration the type of DEVICE, its criticality category and the
specific constraints of the project. In addition, several general requirements apply
when defining the DEVICE development flow, when implementing certain
recurrent steps in every phase, including the review at the end of each phase
which, if successful, implies customer authorisation to start of the next phase.
5.1.2 Tailoring according to DEVICE type and
DEVICE criticality
a. Criticality category of the DEVI
...