Space product assurance

ASIC and FPGA development

Foreword

This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards. Requirements in this Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.

This Standard has been prepared by the ECSS-Q-ST-60-02 Working Group, reviewed by the ECSS Executive Secretariat and approved by the ECSS Technical Authority.

Disclaimer

ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error-free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.

Published by:     ESA Requirements and Standards Division
    ESTEC, ,
    2200 AG Noordwijk
    The
Copyright:     2008 © by the European Space Agency for the members of ECSS

Change log

ECSS-Q-60-02A

17 July 2008

First issue

ECSS-Q-60-02B

Never issued

ECSS-Q-ST-60-02C

31 July 2008

Second issue

Changes to ECSS-Q-60-02A are:

All documents requirements have been moved in normative annexes. The following DRDs have been created: ACP, ADP, ARS, FRA, VP, DVP, ES, Data Sheet and Detail Specification

Some editorial conversions have been done for compliance to ECSS-Drafting rules for Standard.

Introduction

The added responsibilities of developing custom designed devices, as opposed to using off-the-shelf components, make certain management activities crucial to the success of the procurement programme. This was already considered by the applicable standard for “Space product assurance - EEE components”, ECSSQST-60 that classifies custom designed devices, such as ASIC components, under “Specific components”, for which particular requirements are applicable.

The supplier accepts requirements for the development of custom designed components within the boundaries of this standard based on the requirements of the system and its elements, and takes into consideration the operational and environmental requirements of the programme.

The supplier implements those requirements into a system which enables to control for instance the technology selection, design, synthesis and simulation, layout and design validation in a schedule compatible with his requirements, and in a cost-efficient way.

Scope

This Standard defines a comprehensive set of requirements for the user development of digital, analog and mixed analog-digital custom designed integrated circuits, such as application specific integrated circuits (ASICs) and field programmable gate arrays (FPGAs). The user development includes all activities beginning with setting initial requirements and ending with the validation and release of prototype devices.

This Standard is aimed at ensuring that the custom designed components used in space projects meet their requirements in terms of functionality, quality, reliability, schedule and cost. The support of appropriate planning and risk management is essential to ensure that each stage of the development activity is consolidated before starting the subsequent one and to minimize or avoid additional iterations. For the development of standard devices, such as application specific standard products (ASSPs) and IP cores, and devices which implement safety related applications, additional requirements can be included which are not in the scope of this document.

The principal clauses of this Standard correspond to the main concurrent activities of a circuit development programme. These include:

ASIC and FPGA programme management,

ASIC and FPGA engineering,

ASIC and FPGA quality assurance.

The provisions of this document apply to all actors involved in all levels in the realization of space segment hardware and its interfaces.

This standard may be tailored for the specific characteristics and constraints of a space project, in accordance with ECSS-S-ST-00.

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.

ECSS-S-ST-00-01	ECSS system – Glossary of terms
ECSS-Q-ST-10	Space product assurance – Product assurance management
ECSS-Q-ST-20	Space product assurance – Quality assurance
ECSS-Q-ST-30	Space product assurance – Dependability
ECSS-Q-ST-60	Space product assurance – Electrical, electronic and electromechanical (EEE) components
ECSS-E-ST-10	Space engineering – System engineering general requirements
ECSS-M-ST-10	Space project management – Project planning and implementation
ECSS-M-ST-10-01	Space project management – Organization and conduct of reviews
ECSS-M-ST-40	Space project management – Configuration and information management

Terms, definitions and abbreviated terms

Terms from other standards

For the purpose of this Standard, the terms and definitions from ECSSST0001 apply.

Terms specific to the present standard

application specific integrated circuit (ASIC)
full custom or semi custom designed monolithic integrated circuit that can be digital, analog or a mixed function for one user

ASIC technology
totality of all elements required for the design, manufacture and test of ASIC components

Design tools and their description, cell libraries, procedures, design rules, process line and test equipment.

application specific standard products (ASSP)
ASICs designed to make standard products that are made available to a broader range of applications

ASSPs are most often are provided with a VHDL model and disseminated with documentation.

block diagram
abstract graphical presentation of interconnected named boxes (blocks) representing an architectural or functional drawing

cell
specific circuit function including digital or analog basic blocks

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

data sheet
detailed functional, operational and parametric description of a component

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.

design flow
selection and sequence of engineering methods and tools to be applied during the implementation of the design

design for test (DFT) structure
technique used to allow a complex integrated circuit (IC) to be tested

This can include any mechanism aimed to provide better observability or commandability of internal nodes of the chip not accessible through primary inputs and outputs.

design iteration
design changes that occur in any single phase or between two consecutive phases as defined in the ASIC and FPGA development plan, before the design is released for prototype implementation

detail specification
procurement specification according to ESCC format that defines, for instance, the maximum ratings, parameter limitations, mechanical outline, pin description and screening requirements

development step
major step of the development flow for the ASIC and FPGA development

Definition phase, architectural design, detailed design, layout, prototype implementation and design validation.

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

field programmable gate array (FPGA)
standard semiconductor device that becomes customized when programmed by the user with the FPGA specific software and hardware tools

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

HDL model
textual model based on a hardware description language (but not a piece of software in itself) suitable for the behavioural or structural description, simulation and by choosing a suitable level of abstraction for automatic netlist generation

intellectual property (IP) core
design element that implements a self-standing function or group of functions for which ownership rights exist

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.
2 IP core can be supplied as an HDL file (e.g. 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 (e.g. User's manual and verification files).
macrocell
module that contains complex functions in a manufacturer’s cell library built up out of hard-wired primitive cells

netlist
formatted list of cells (basic circuits) and their interconnections

prototype device
fabricated ASIC or programmed FPGA used to validate the new design in respect to functionality, performance, operation limits and compatibility with its system

redesign
design changes which affect more than two consecutive phases of the ASIC and FPGA development or design changes that are implemented after prototype implementation

stimuli
input data set for simulation or test to show a specific functionality or performance of a device

test pattern
simulation stimuli and its expected responses (considering specific constraints to meet test equipment requirements) used to show correct behaviour of a device

Abbreviated terms

For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01 and the following apply:

Abbreviation	Meaning
ACP	ASIC and FPGA control plan
ADP	ASIC and FPGA development plan
ARS	ASIC and FPGA requirements specification
ASCII	American standard code for information interchange
ASIC	application specific integrated circuit
ASSP	application specific standard product
DD	design documentation
DDR	detailed design review
DFT	design for test
DRC	design rule check
DVP	design validation plan
EDA	electronic design automation
EDIF	electronic design interchange format
ERC	electrical rule check
ESCC	European Space Components Coordination
FM	flight module part
FPGA	field-programmable gate array
FRA	feasibility and risk analysis report
GDS	graphic design system (industry standard graphics entry tool)
HDL	hardware description language Note: This term used in general for the various hardware description language which are applied for coding during design phase such as VHDL and verilog.
IDMP	input data for mask or programming file generation
IEEE	Institute of Electrical and Electronics Engineers
IP	intellectual property
MoM	minutes of meeting
P&R	place and route
JTAG	joint test action group
LVS	layout vs. schematic check
NCC	netlist comparison check
QML	qualified manufacturer list
RTL	register transfer logic
SEU	single event upset
VHDL	VHSIC hardware description language

ASIC and FPGA programme management

General

Introduction

The supplier shall establish and implement an ASIC and FPGA development, as part of the component programme (in conformance with ECSS-Q-ST-60), that ensures full conformance with the requirements of the project as defined by the customer in line with this standard.

Organization

The supplier shall establish and maintain an organization for the management of the ASIC and FPGA programme.
The organization shall comply with the requirements specified in ECSSQST10.
In case of major problems, the development team, as allocated in the development plan (see 4.3.1), shall directly report to the component advisory board as defined in ECSS-Q-ST-60.

Planning

The supplier shall ensure that:

the ASIC and FPGA developments that are necessary for the implementation of the ASIC and FPGA programme are planned, documented and implemented, and
preventive or corrective actions are initiated whenever there is evidence of possible schedule or technical problems.

ASIC and FPGA control plan

The supplier shall prepare an ASIC and FPGA control plan (ACP) in conformance with the DRD in Annex A.

Management planning tools

ASIC and FPGA development plan

The supplier shall prepare a detailed ASIC and FPGA development plan (ADP) in conformance with the DRD in Annex B.
The supplier shall maintain the ADP after the requirements are settled and the feasibility and risk for the ASIC and FPGA development is assessed.

Verification plan

The supplier shall establish a verification plan in conformance with the DRD in Annex E.
The verification plan shall define how the functionality and non-functional requirements stated in the definition phase documentation are demonstrated at all levels of modelling.

Design validation plan

The supplier shall establish a design validation plan (DVP) in conformance with the DRD in Annex F.
The DVP shall specify the measurements to be performed on the prototypes.

Those measurements allow verifying that the implemented devices contain the functionality and the characteristics they are designed for.

Experience summary report

At the end of the ASIC and FPGA development cycle, the supplier should establish an experience summary report in conformance with the DRD in Annex I.

The experience summary report can be written in the frame of the supplier’s continued quality improvement activities in order to establish economic and efficient development and test requirements for expected future projects.

ASIC and FPGA engineering

Introduction

Clause 5 covers the responsibilities of ASIC and FPGA suppliers and designers for the tasks essential to producing high-reliability circuit design and tests meeting all circuit function, test and performance requirements.

To consider the timely allocation of management and quality assurance activities to the engineering tasks, these activities are also specified within this clause and clearly indicated as being a management or quality assurance activity.

All requirements and suggested tasks to be performed and documented throughout the entire ASIC and FPGA engineering activity are equally applicable, by default and unless indicated otherwise, to either case of integrated circuit option: digital, analog or mixed ASIC, as well as FPGAs. A few requirements do not apply to certain technology options, as indicated.

General requirements

The ASIC and FPGA development flow shall be in conformance with ECSS-M-ST-10.

Figure 51 gives an example of the ASIC and FPGA development flow, adapted from ECSS-M-ST-10.

All inputs to the design, that are not automatically generated and are necessary to reproduce the design shall be put under a revision control mechanism agreed between the contractors;

Examples are simulation pattern, schematics, VHDL source codes, synthesis scripts.

Each development step using design inputs shall reflect the revision numbers of the inputs in a log file to prove consistency;
Each development step shall be verified by a mechanism, as impartial as possible, to guarantee successful completion of the development step.

The development step is completed when the steps itself as well as its verification were performed and any error or serious warning being flagged by the tools was approved in the corresponding review meeting.

Figure 51: Development flow (example)

Figure 51: Development flow (example) – continued

Definition phase

Introduction

The aim of this development step is to establish an ASIC and FPGA requirements specification, a feasibility and risk analysis report and an ASIC and FPGA development plan.

General requirements

The supplier shall ensure that all relevant system configurations and characteristics and all issues imposing requirements on the device are used.

This allows settling out without any ambiguity the definition status of the collected requirements and verifying that all necessary resources for the design activities are available.

The supplier shall specify the complete set of traceable ASIC and FPGA requirements in the ASIC and FPGA requirements specification (ARS) in conformance with the DRD in Annex C.

Feasibility and risk assessment

Feasibility study

The feasibility of the intended ASIC and FPGA development shall be assessed against the established ASIC and FPGA requirements specification and the available resources.
As a minimum, the following tasks shall be performed and documented:

Estimate design complexity;
Estimate power consumption;
Assess feasibility of speed requirements by a preliminary timing analysis;
Select a radiation hardening approach that ensures compliance with radiation tolerance requirements. Determine a rough estimate of impact on chip area and circuit speed;
Select a production test approach and its feasibility against all requirements;
Identify and evaluate the suitability and qualification status of the ASIC technologies or FPGA available to implement the device, fulfilling all functional and non-functional requirements including the specified derating factors. Make a baseline selection;
Identify packages, fulfilling all requirements. Make a baseline selection;
Ensure that the baseline technology and package or FPGA have a remaining lifetime, so that flight and compatible prototype parts can be manufactured and are available during the expected procurement phase(s);
Ensure that technical support for the device can be guaranteed during the expected lifetime;
Determine availability and status of the required design and test tools (H/W & S/W) and libraries;
Determine availability of the necessary human resources;
Determine availability, licensing, support, legal and economical aspects of using IP cores from third parties;
Ensure that no patents are infringed or agreements exist or can be made with the patent holder.

Risk analysis

As a tool of the quality assurance system (see clause 6.3) a risk analysis shall be performed that identifies potential risk items and assigns preventive measures and contingency plans.
The risk analysis shall result in a Feasibility and risk analysis (FRA) report in conformance with the DRD in Annex D.

ASIC and FPGA development plan

The ADP shall ensure prospective design portability for devices with long term availability or multiple usage requirements.

System requirements review

The definition phase shall be concluded by a system requirements review (SRR) meeting (see quality assurance clause 6.2).
The documentation generated within this phase shall be reviewed.
The reviewers shall check that the development activity as defined in the ADP is feasible within the limits imposed by the project requirements, resources, schedule and budgetary constraints.
The reviewers shall check that contingency plans exist for all identified open issues and risk items and that the risk analysed can be taken for starting the Architectural Design phase.
The reviewers shall check that ARS and FRA are complete and documented in a level of detail that avoid any ambiguity for the Architectural Design and all subsequent design work.
The reviewers shall check that ARS and FRA include as a minimum:

Summary of the system architecture and all expected configurations in which the device can be used;
Specify the external devices connected to the chip and their interface protocols;
Bit numbering and naming convention (to be maintained throughout the design flow);
Format of data structures;
Functionality in all nominal operational modes;
Functionality for error handling;
Functionality in all system test modes;
Internal communication protocols;
Signal processing algorithms;
Definitions of programmable memory elements and their state after reset;
Functional partitioning, establishing a high-level block diagram;
Preliminary architectural and hardware/software partitioning, including external and internal memory mapping;
For components providing software programmability, associated software requirements specifications ;
State and behaviour of l/Os during and after reset and power-up;
State functions explicitly not implemented in the design, in order to avoid potential misunderstandings;
Pin list including power supply, test pins, if already known, name, polarity, bus width and interface protocol;
Electrical specifications (maximum ratings, AC, DC and timing diagrams);
Power dissipation estimates for main functional modes;
Operating conditions (supply, temperature, radiation);
Baseline package and pin-out, if already known. EXPECTED OUTPUTS: a. the definition phase documentation, containing:ASIC and FPGA requirements specification (ARS);Feasibility and risk analysis (FRA);ASIC and FPGA development plan (ADP);MoM of SRR.### Architectural design

General requirements

During the architectural design phase, the architecture of the chip shall be defined, verified and documented down to the level of basic blocks implementing all intended functions, their interfaces and interactions.
Important selections for the implementation of the chip shall be made or confirmed.
All definitions and selections made shall conform to the definition phase documentation.
Any deviation shall be justified in the preliminary design review.
The architecture definition and the baseline choices made during the definition phase shall be settled, frozen and documented with a level of detail that allows proceeding with the subsequent detailed design.

Architecture definition

As a minimum the following tasks shall be performed and documented in an architecture definition report:

Subdivide the chip into its fundamental functions or blocks, identifying and thoroughly documenting their interfaces, functionalities and interactions;
Define the architecture down to the level required to implement technology specific, transistor- or gate-level mapping;
Select suitable algorithms and circuit schemes including their parameters to implement the identified functions;
Identify sub-functions, which can be used as an individual block at different locations of the chip or possibly be compiled as a core for other designs;
Identify a suitable clocking and reset scheme assuring correct transitions of data between clock domains and identify asynchronous parts of the design;
Select (if not yet done), IP-cores to be used or previously designed units to be re-used in the design. Procure and verify them.

This verification can be done by test cases provided by the IP core manufacturer, by test benches from an independent source, or by newly designed test programs.

If the verification is accomplished during prior instantiations of the core, assess it for covering the actual system environment, and eventually perform bug-fixes and workarounds or additional verification;
Identify and eventually procure custom cells, to be used in the design, verify the consistency of the different models delivered (e.g. simulation models, layout and timing view);
Generate models required as an input to the subsequent detailed design phase (e.g. synthesizable RTL models);

There is no firm requirement for intermediate behavioural simulations, nor for any model being coded in a particular language or a specific level of abstraction. However, the coding of behavioural models of critical functions and algorithms is strongly encouraged, since they frequently are valuable tools for further verification tasks.

The architecture definition report shall include the architecture broken down to the selected blocks, their interfaces, functionality or algorithms and interactions.
Even though the chip and its architecture is completely described in a simulation model (executable specification), a detailed text specification shall be edited.

Verification plan

The supplier shall establish a verification plan in conformance with the DRD in Annex E.

Architecture verification and optimization

As a minimum, the following activities shall be performed and documented in an architecture verification and optimization report:

Verify that the defined architecture meets the requirements by appropriate simulation and analysis techniques;
Verify that the models referred to in clause 5.4.2a.9 above are compliant to the verification plan;
Perform an independent verification in order to avoid masking of design errors;
When allocation and connectivity of hard-macro cells can be an issue, a preliminary floorplan, assure that the expected cells are effectively place- and routable within the given constraints;

This is not applicable for FPGA designs.

Re-assess the feasibility and risks;
Find an application related trade-off for conflicting requirements;

For example: power consumption vs. speed and performance, pin count vs. package size and complexity vs. die area.

Establish the implementation choices.

Preliminary data sheet

A preliminary data sheet shall be established in conformance with the DRD in Annex G.

The preliminary data sheet is updated and completed at the end of the ASIC and FPGA development.

Preliminary design review

The architectural design phase shall be concluded by the preliminary design review (PDR) meeting (see quality assurance clause 6.2).
The documentation generated within this phase shall be reviewed.
The reviewers shall check that the selected trade-off meets the requirements fixed during the definition phase.
The reviewers shall check that preventive measures or contingency plans exist for all identified risk items and that the risk analysed can be taken for starting the detailed design.
The reviewers shall check that the architectural design documentation (see clause 7.3.4) together with the documentation of previous development phases is complete, traceable and documented in a level of detail that allow to proceed with the detailed design.
The reviewers shall identify, justify and approve discrepancies between the architectural design documentation and the definition phase documentation.
The reviewers shall check that the planned measures, tools, methods and procedures are applied.
EXPECTED OUTPUTS: a. Architecture definition report;Verification plan;Architecture verification and optimization report;Preliminary data sheet;Design database, containing:Simulation models;Verification results;MoM of PDR.### Detailed design

Introduction

During this phase the high-level architectural design is translated into a structural description on the level of elementary cells of the selected technology and library. Additional information is generated for the subsequent development phases, such as layout constraints, floorplanning, production test programs and a detailed pin description.

For digital designs, the above mentioned design description is the associated technology specific, verified gate-level pre-layout netlist, whereas for analog designs, it is a verified sized transistor-level netlist. However, in many analog designs, there is no separation between circuit design and layout.

General requirements

Influences from layout such as cross talk and matching shall be accounted for during the design work.
For analog designs circuit and layout are developed concurrently, and the reviews for detailed design and layout phases may be held together.
For FPGAs and analog designs, a combined DDR and CDR meeting may be justified.

In these cases also the corresponding output reports can be merged together.

The scripts used for an automatic and repeatable generation shall be part of the design database.

1 The main output of the detailed design is a design database, which contains, or allows an automatic and repeatable generation of the above-mentioned inputs to the layout.
2 The scripts defined for this generation are an essential part of the detailed design,

Design entry

During the design entry the following tasks shall be performed and documented in a design entry report.
Use the agreed design tools as specified in the ADP (see clause 5.3.4). Check their maintenance status. Consider known bugs, existing patches, preventive and workaround measures.
Implement the specified test concept during design entry and synthesis (e.g. scan paths, DFT logic, measurement points, test busses and boundary scan (JTAG, see IEEE 1149.1).
Implement the specified radiation hardening concept by design and during synthesis.
Continuously verify the results by the appropriate methods, as specified in the verification plan.
Determine a pin-out and bonding scheme with particular attention to the technical constraints.

For example, power supply pin definition and bondability issues.

Select buffers according to the I/O requirements defined in the ASIC and FPGA requirements specification.
Establish or refine the floorplan.

This is not applicable for FPGA designs.

Netlist generation

In this step, the source description of the design is translated into the netlist, and any other information required for the layout generation, such as floorplan or placement information and constraints for timing driven layout is generated.

Enough iterations between design entry, netlist and layout generation shall be performed in order to accomplish the design requirements.
Iterations back to the architectural design shall be avoided.
If an iteration back to the architectural design is required by means of changes in the model released during the PDR, that model shall be verified again.
As a minimum the following tasks shall be performed and documented in a netlist generation report:

Consider the required derating factors;
Ensure that the appropriate library cells are used as to fulfil all the requirements collected in the ASIC and FPGA requirements specification;
Select or generate appropriate models for parasitism (e.g. wire load models);

This is not applicable for FPGA designs.

Perform a design parameter centring;

This is only applicable for analog ASIC designs.

Ensure that the intended operating (process, voltage, temperature) and environment (radiation) conditions are used during the translation and verification exercise;
If synthesis tools are used, generate scripts which allow performing the fully automatic pre-layout netlist generation in a repeatable way;
Ensure that these scripts, being part of the inputs to the design, are compliant to the general requirements for e.g. documentation, commenting and version control;
Specify timing constraints, and supplier or manufacturer-specific design rules;
Consider over-constraining to anticipate parasitic effects.

Netlist verification

As a minimum the following tasks shall be performed and documented in a netlist verification report:

Verify the netlist according to the verification plan;
Verify the estimated data for the layout parasitics and delays;
Perform gate level simulations, using the complete test suite from the architectural design, or an equivalent set of methods, such as formal verification and static timing analysis;

This is not applicable for analog ASIC designs.

Verify key parameters, such as bias voltages, operating point, frequencies, bandwidth, matching, s-parameters, noise, dynamic and linear ranges and shaping times;
Perform a functional verification, including the interfaces.

This is only applicable for analog ASIC designs.

If a complete simulation of all modes (including test modes) at top level cannot be performed (e.g. due to run-time restrictions), simulate a representative subset;
Verify by an extrapolating analysis, the not simulated cases;
Verify that the specified test concept is implemented through e.g. scan paths, DFT logic, measurement points and test busses;
Verify that the radiation-hardening concept is successfully included in the netlist. Consider e.g. netlist inspection and SEU injection simulations;
Verify that the specified power consumption is respected;
Update relevant parameters in the preliminary data sheet according to the results obtained during the verification;
If production tests or a pre- and post burn-in test are planned, generate the test vectors and verify the requirements for fault coverage;
For IP cores and macro cells: include the core's test patterns in the overall ASIC's test programmes;
Verify, that the pre-layout supplier or manufacturer design rules are met and assess the relevance of violations;

This is not applicable for FPGA designs.

Perform a parameter sensitivity analysis;

This is only applicable for analog ASIC designs.

Updated data sheet

The supplier shall update the data sheet to incorporate the new established information on for instance pinout and estimated timing.

For further details see Annex G.

Detailed design review

The detailed design phase shall be concluded by the detailed design review (DDR) meeting (see clause 6.2).
The documentation generated within this phase shall be reviewed.
The reviewers shall verify that the detailed design documentation (see clause 7.3.5) together with the documentation of previous development phases completely documents all results obtained and decisions made along with the corresponding justifications in a level of detail that allow to proceed with the layout.
This verification shall include as a minimum:

Circuit implementation shows details of the implementation, which were not specified during architectural design;
Description of implemented testability and production test methods including the achieved fault coverage figures obtained;
Description of implemented radiation hardening measures;
All verification results;
Description of cells specially developed for the design;
Configuration and modifications applied to IP cores used in the design;
List of items with name and format provided to the foundry (i.e. netlist, stimuli files for production test and constraints files);

This is not applicable for FPGA designs.

Description of the design database, including the file structure, naming conventions, version control labels, netlist generation methods and constraints;
All tools and ASIC libraries actually used during the entire design development, including the versions and operating platforms used;
Problems encountered with design tools and their workarounds. The reviewers shall check that the planned measures, tools, methods and procedures were applied;
The reviewers shall check that the outputs are in conformance to the requirements fixed during the definition phase;
In particular, when the layout is performed by another company (foundry), the reviewers shall assess the specific foundry requirements (netlist sign-off criteria).
EXPECTED OUTPUTS: a. Design entry report;Netlist generation report;Netlist verification report;Updated data sheet with pin-out;Updated design database, containing:Pre-layout netlist;Constraints for layout (i.e. floorplan and constraints for timing driven layout) as defined in the ADP;Test vectors for production test;MoM of DDR.### Layout

General requirements

The layout shall generate the placement and routing information to meet the design rules, timing and other constraints.
In addition, netlist optimization by local re-synthesis or physical synthesis shall be applied.

This provides reliable information about loads and coupling capacitors and the final design rule check that assures a verified netlist which can be forwarded to the foundry.

Layout generation

As a minimum the following tasks shall be performed and documented in a layout generation report:

finalize the floorplan of the chip;

This is not applicable for FPGA designs.

perform place and route (P&R) taking into account all layout constraints;
perform netlist optimizations (see clause 5.6.1) for timing and design rules if necessary;

This is only applicable for digital ASIC designs.

generate the power distribution;
generate the clock distribution (clock tree and buffers);

This is not applicable for analog ASIC designs.

insert core and pad ring power distribution and possibly additional test pads in the circuit;
determine the die size;

This is not applicable for FPGA designs.

generate the bonding diagram respecting bonding and package constraints;

This is not applicable for FPGA designs.

generate the input data for mask or programming file generation (IDMP).

Layout verification

As a minimum the following tasks shall be performed and documented in a layout verification report:

layout design rule check (DRC);
electrical rule check (ERC), check cross-talk sensitivity, if required by customer;
extract a netlist from the layout given in terms of IDMP;
verify that the gate-level netlist is consistent with the layout by performing a layout versus schematic (LVS) comparison, i.e. a netlist comparison check (NCC) between the post-layout netlist and the layout (IDMP) extracted netlist;
verify that the post-layout netlist is consistent in terms of functionality with the pre-layout netlist by simulation and formal methods;
extract the parasitic information;

This delivers capacitance, resistance and inductivity values (only deep sub-micron technology), from which the actual delays are calculated for digital designs.

perform comprehensive post-layout verification according to the verification plan;

This is mostly accomplished by back-annotated simulations and timing analysis

check the resulting clock skew and latency;

This is not applicable for FPGA designs.

check relevant timing of I/Os;
check the power distribution on the chip;

This is not applicable for FPGA designs.

perform transition check and load check on the nets inside the ASIC;
characterize ASIC and FPGA timing performances,

For example: max clock frequency, clock duty cycle, set-up and hold times for all inputs and propagation delays for all outputs.

Design validation plan

The supplier shall establish and maintain a design validation plan (DVP) in conformance with the DRD in Annex F.

Updated data sheet

The supplier shall update the parameters in the data sheet according to the results obtained during the layout verification.

For further details see Annex G.

Draft detail specification

Based on the information collected in the design documentation a draft detail specification shall be established in conformance with the DRD in Annex H.

Critical design review

The layout phase shall be concluded by the critical design review (CDR) meeting (see 6.2).
The documentation generated within this phase shall be reviewed.
The layout documentation (see 7.3.6) together with the documentation of previous development phases completely documents the progress and decisions made during the layout shall be checked.
As a minimum, the review of the documentation at CDR shall address:

Post-layout clock distribution tree and clock skew and latency analysis;
Post-layout verification results and analysis of timing margins;
Results from all layout checks (e.g., DRC, ERC, LVS and NCC) Any violation of or deviations from the design rules and justifications. The reviewers shall check that the planned measures, tools, methods and procedures have been applied.
The reviewers shall check that the outputs are in conformance to the requirements fixed during the definition phase.
In the case where no DDR was held after the detailed design phase, the reviewers shall check that the CDR encompasses also all review items of the DDR.
The reviewers shall check that preventive measures or contingency plans exist for all identified risk items and that the risk analysed can be taken for starting the Prototype Implementation.
EXPECTED OUTPUTS: a. Layout generation report;Layout verification report;Design validation plan;Updated data sheet;Updated design database, containing:Post-layout netlist in the agreed format depending on the targeted technological approach (GDS II, FPGA P&R files or other);Corresponding parasitic information;MoM of CDR.### Prototype implementation

Introduction

In this phase chips are manufactured and packaged, or FPGA's programmed, and the prototypes are tested.

Production and test

The term production refers to chip manufacturing and packaging, or FPGA programming, whatever is applicable. The phase is concluded by the delivery of the tested devices.

As a minimum, the following tasks as described in 5.7.2b up to 5.7.2j shall be performed and documented in the production test report.
The package shall be the same as for flight devices, if required by the customer.
The mask generation and verification shall be performed under the foundry's configuration control system.

This is not applicable for FPGA designs.

The committed number of prototypes shall be produced and delivered, so that design validation can be performed.
The production test shall be performed on 100 % of the delivered prototypes, using the test vectors generated during the previous phases.
The production test shall demonstrate that the device was produced correctly.

This is not applicable for FPGA designs.

The correctness of the FPGA programming shall be verified (checksum test).

This is only applicable for FPGA designs.

The tested parameters and conditions shall be according to the draft detail specification (see clause 7.4.3).
Test reports shall be generated and delivered, documenting the measured parameters.
Tester log files shall be delivered in electronic format.
EXPECTED OUTPUTS: a. Agreed number of tested devices (ASICs or FPGAs);Production test results and reports; [not applicable for FPGA designs] ;Burn-in or any other production test results, specifications and patterns.### Design validation and release

Design validation

The design validation shall be performed to confirm the achievement of all functional, performance, interface and compatibility requirements.
As a minimum, the following tasks shall be performed and documented in a validation report:

carry out the validation according the established validation plan;
design and build the test set-up or system breadboard in order to represent a realistic system application;
use the breadboard to perform validation tests that cover full functionality and all operating modes and conditions of the device;
specify, design and execute specific burn-in or other screening tests for the later test of the FM parts; if agreed by the business agreement;
document scope, sequences, set-up and results of the validation tests in the validation report;

The validation report becomes part of the design validation documentation.

Compare specified parameters with measured parameters. The validation report shall be made available to the foundry and the design house.

Radiation test performance

The device prototypes shall undergo radiation testing according to the requirements of the project, if the required hardening level is not yet demonstrated for the technology involved.
Radiation testing shall be performed according to the established radiation verification plan included in the design validation plan and documented in a radiation test report.

Design release and FM production preparation

For the design release and FM production preparation, the tasks, as described in 5.8.3b to 5.8.3h, shall be performed and documented in the release report.
License agreements for the intellectual property (the design itself and third party IP cores) contained in the device shall be established to cover the whole lifetime.
The supplier shall ensure technical support of the device during the lifetime of the product.
This can be accomplished through a know-how transfer from the design house to the foundry or a third party, or by the design house itself.
The suppler shall ensure the storage of the complete design database during the lifetime of the product, including associated data, documentation, pattern generation files, test program(s) and mask sets used.
In the case of using non-QML manufacturer or foundry, an evaluation programme (in conformance with ECSS-Q-ST-60) shall be performed that include as agreed by the customer the following activities:

manufacturer evaluation;
constructional analysis;
evaluation testing. On completion of the evaluation programme additional data such as reliability and radiation data shall be available ensuring that the mission requirements can be met.
The supplier shall assess the risk involved for the FM production.

Experience summary report

The executive summary report shall be completed in conformance with the DRD in Annex I.

Final versions of application and procurement documents

The detail specification, in conformance with Annex H shall be updated based on the validation test results.
If requested by the customer, the data sheet, in conformance with Annex G shall be updated based on the validation test results.
The data sheet, eventually transformed to the foundry specific format, shall be available during the device lifetime.
An application note (see clause 7.4.2) shall be established.

Qualification and acceptance review

The design validation phase shall be concluded by the qualification and acceptance review (QR/AR) meeting (see clause 6.2).
The documentation generated within this phase shall be reviewed.
The reviewer shall check that the design validation documentation (see clause 7.3.6) together with the documentation of previous development phases is complete.
The reviewer shall check that the device achieves functional, performance, interface and compatibility characteristics satisfying the ASIC and FPGA requirements specification.
The reviewer shall check that the planned measures, tools, methods and procedures were applied.
The reviewer shall check that preventive measures or contingency plans exist for all identified risk items and that the risk of FM production can be taken.
EXPECTED OUTPUTS: a. Validation report;Radiation test report (if applicable);Release report;Experience summary report;Final data sheet;Final detail specification;Application note;MoM of QR/AR;Validation breadboard;Burn-in or screening test boards for FM parts.### Quality assurance system

General

ECSS-Q-ST-20 clause “QA status reporting” shall apply.
ECSS-Q-ST-30 clause “criticality classification of functions and products” shall apply.
ECSS-Q-ST-60 clauses 4.5, 5.5 and 6.5 (components quality assurance) shall apply.
The objective of the quality assurance system is to ensure the development of reliable, manufacturable, testable and reproducible, custom designed components for space application.
The tools to be used shall be specified and approved by the customer.
All technology independent CAD tools to be employed during the development shall be mature and fit for their purpose.
All technology dependent CAD tools shall be used as approved and supported by the selected manufacturer.
Preference shall be given to the use of established international standards, such as VHDL as defined in IEEE 61691-1-1 and EDIF.

Review meetings

The supplier shall schedule and conduct design reviews in conformance with ECSSMST-1001.
Design reviews shall be defined along with the criteria for their successful completion in the ASIC and FPGA development plan (see clause 5.3.4).
Representation, for design and quality assurance, from all relevant organizations (customer, system supplier, design house and foundry) shall be ensured.
The supplier shall produce and circulate in advance of each design review a design review package containing a checklist based on the established requirements and the data necessary for the particular review.
The following reviews shall be performed:

System requirements review (SRR)

This review results in the authorization to start the architectural design. The outputs reviewed and the items checked are detailed in clause 5.3.5.

Preliminary design review (PDR)

PDR results in the authorization to start with the detailed design. The outputs reviewed and the items checked are detailed in clause 5.4.6.

Detailed design review (DDR) (if applicable)
1 DDR results in the authorization to proceed with the layout. The outputs reviewed and the items checked are detailed in clause 5.5.7.
2 In the case the design and layout is a concurrent or interdigitated activity (for instance analog or FPGA design) this review meeting can be combined with the subsequent CDR meeting.
Critical design review (CDR)

CDR results in the approval of design and layout and the release for prototype implementation. The outputs reviewed and the items checked are detailed in clause 5.6.7.

Qualification and acceptance review (QR/AR)

QR/AR results in the final acceptance of the design and the release for FM production. The outputs reviewed and the items checked are detailed in clause 5.8.6.

Additional design reviews as agreed by the supplier. Direct or delegated customer participation and under the responsibility of the supplier, manufacturer or foundry participation for CDR and QR/AR shall be mandatory.
1 The decision on a successful completion of a review meeting can only be achieved by consent of all parties.
2 A review identifying a limited number of only minor discrepancies can be completed after successful implementation of the corrective actions defined during the review.
A review failing major acceptance criteria and resulting in a design iteration shall be repeated in full.
The criteria for a successful review meeting shall be defined prior to the relevant meeting.

These criteria can be defined on the preceding review meeting.

All review meetings shall be minuted.
The MoMs of the review meetings shall be added to the management documentation.

Risk assessment and risk management

The design risk for the timely and successful completion of the development activity shall be assessed according to the items listed in clause 5.3.3.2.
Risk assessment shall be performed concurrently to the design activity.
Extraordinary risks shall be covered by a contingency plan identifying alternative or back-up solutions.
A check of the risk mitigation activities shall be a major item of the agenda of every review meeting.

Development documentation

General

At all stages of the ASIC and FPGA development, the supplier shall produce, maintain, control and archive all related documentation as defined and detailed in the following clauses.
The documentation shall be well structured and easily readable, so that the design can be understood by other ASIC and FPGA designers of the supplier and manufacturer not permanently involved in the design work.

For example, names of signals and blocks are chosen to indicate their function.

One consistent language shall be used throughout the documentation, preferably English.
The documentation shall be consistent, e.g. the same item have the same name in all documentation.
Block diagrams, control flow charts, timing diagrams and other figures shall be introduced where beneficial for the understanding of the text.
Every time an updated document is delivered, it shall include a detailed change list, and all significant changes marked using a change bar in the margin.
If a document is delivered before being complete, each page with incomplete information shall be clearly marked.

Some of the information listed is better delivered separately or in appendices, such as layout plots, gate-level schematics and lists of undetected faults.

All documents shall be archived for a minimum period of five years after completion of the development activity or as agreed by the customer.

Management documentation

The management documentation shall provide the overall strategy for the development activity including task planning and organization and approaches, methods and applicable procedures.

The management documentation also includes the status reporting as MoM of the review meetings and an assessment of the experience gained during the development activity. The management documentation is a gathering of separate documents (see clauses 4.2a, 4.4a, 4.3.2a and 4.3.3a).

Design documentation

General

Purpose

The purpose of the design documentation (DD) is to record the progress achieved and the decisions made along with the corresponding justifications during the development phases of the device.

Requirements

All design information shall be stored in a design database by applying the revision control mechanism agreed in the business agreement (see clause 5.1).
All intermediate design data shall be reproducible to assist possible iterations.
As the design database consists of electronic data that cannot be reviewed directly, formless reports shall be established that contain a legible extract of the database.
Reports that shall be produced during the individual phases of a development activity are detailed in clause 5.

1 An example of a suitable filing of this design documentation is given in Figure 71.
2 In the case the design and layout is a concurrent or interdigitated activity (e.g. analog and FPGA design) the corresponding output reports can be merged together.
Figure 71: Design documentation

Definition phase documentation

The definition phase documentation shall consist of the following contributions:

The ASIC and FPGA requirements specification (ARS) established during the first development phase.
ARS including a complete set of ASIC and FPGA requirements, in conformance with the DRD in Annex C that are settled, unambiguous and frozen.
An assessment of the feasibility and risk analysis (FRA) with regards to the following drivers:
- consistency and quality of the ASIC and FPGA,
- system requirements feasibility of the ASIC and FPGA development,
- estimate of the risk involved.

The feasibility and risk analysis (FRA) report is the second part of the definition phase documentation.

FRA shall cover the items detailed in clause 5.3.3.

Architectural design documentation

The architectural design documentation shall include the following contributions to the definition phase documentation:

The architectural definition report that includes the architecture broken down to the selected blocks, their interfaces, functionality, algorithms and interactions as specified in clause 5.4.2.
The verification and optimization report that provides the simulations performed, the results received, the trade-offs found and the implementation choices established.

Further details are given in clause 5.4.4.

Detailed design documentation

The detailed design documentation shall consist of the following contributions to the architectural design documentation:

The design entry report providing all inputs available for the detailed design phase as detailed in clause 5.5.3.
The netlist generation report describing the work performed and the decisions taken to generate a netlist as detailed in clause 5.5.4.
The netlist verification report listing all steps of simulation and verification performed (see clause 5.5.5) together with the corresponding results.

Layout documentation

The layout documentation shall consist of the following contributions to the detailed design documentation:

The layout generation report describing the work performed and the decisions taken to generate layout as detailed in clause 5.6.2.
The layout verification report listing all steps of verification performed (see clause 5.6.3) together with the corresponding results.

Design validation documentation

The design validation documentation shall consist of the following contributions to the layout documentation:

The validation report presenting the scope, sequences, set-up and results of the validation tests performed as detailed in clause 5.8.1.
The radiation test report (if applicable) providing the test board circuitry and bias conditions, the test sequence and investigated irradiation levels, the performed measurements and the resulting degradations.
The release report summarizing all activities performed to assure that all necessary prerequisites are fulfilled to start a FM production (see clause 5.8.3).

Application and procurement documents

Data sheet

If requested by the customer, a data sheet that describes the functionality of the device so it can be used by a board or system designer shall be established in conformance with the DRD in Annex G.

Application note

If requested by the customer, an application note shall be established for components that are regarded as standard parts for a variety of system applications. This note shall provide information to guide the reader through the possible configurations the device or module can be operated with examples for the corresponding bias circuitry, supply voltages and configuration signals shall be provided.

Detail specification

All devices intended for use as FM products shall be procured according to controlled specifications.
All new specifications shall be designed to be totally in conformance to one of the existing European standardization systems.
New detail specifications shall be established in conformance with the DRD in Annex H.
Specifications shall include configuration control requirements that ensure that any change of the product that refers to the qualification or that can affect performance, quality, reliability and interchangeability is identified by the manufacturers.

Deliverables

General

Upon request, the customer shall receive free of charge from the supplier the information coming from the manufacturer or foundry, for the duration of the development, a complete design kit for the selected process, including all libraries and design kit tools and their complete documentation, in order to allow the customer to independently verify the design.

This only applies if such a design kit actually exists for the design tools available at the customer.

The quantity to be delivered of each individual deliverable item shall be agreed between customer and supplier according to the requirements of the actual project.
Additional items shall be defined as necessary.
Each delivery of a design document shall be accompanied by a written statement of the status of the deliverable item.
The IP rights status shall be reported.
Paper copies shall be easily readable and suitable for subsequent photo-copying. Electronic copies shall be submitted via electronic media in an agreed format with agreed characteristics.

Search capability, printability, usage of hyperlinks, traceability and changeability.

Photos and layout plots may be part of the documentation only for promotional information with restricted details, if not specified elsewhere.

Deliverable items

The list of deliverables defined per the SoW agreed in the business agreement. shall be established , based on Table J-1.

Table J-1 is a guideline for documentation, design database deliverables and hardware deliverables that become available during the ASIC and FPGA development.

ANNEX(normative)ASIC and FPGA control plan (ACP) – DRD

DRD identification

Requirement identification and source document

This DRD is called by the ECSS-Q-ST-60-02, requirement 4.2a.

Purpose and objective

The purpose of the ACP is to initiate the ASIC and FPGA developments and to specify the organization, management tools, quality assurance system, strategy, approaches and procedures it adopts.

Expected response

Scope and content

The ACP shall include a description of the following items:

Organizational structure and management approach including the definition of organizational interfaces between different design groups and identification of the supplier organization for the product assurance of the ASIC and FPGA development;
Role, tasks and responsibilities of product assurance personnel in conformance with ECSS-Q-ST-10 and ECSS-Q-ST-20;
Management tools to be used for planning (see clause 4.3) and quality assurance system (see clause 6) of the ASIC and FPGA developments;
Intended overall schedule;
Overall strategy and general approach for the ASIC and FPGA developments;
Risk mitigation procedures to be applied (see clause 6.3);
Requirements on, and system for the control of the foundry and other subcontractors or service providers involved according to the experience available for the respective supplier. Compliance matrix to the clauses of this standard taking into account applicable tailoring.
Initiation of the definition phase for the ASIC and FPGA developments.

Special remarks

None.

ANNEX(normative) ASIC and FPGA development plan (ADP) – DRD

DRD identification

Requirement identification and source document

This DRD is called by the ECSS-Q-ST-60-02, requirement 4.3.1a.

Purpose and objective

The purpose of the ADP is to implement the proposed development strategy by identifying all phases of the ASIC and FPGA development with the major activities therein, the project external interfaces and constraints, the design flow, resources (equipment, software and personnel), the allocation of responsibilities, outputs to be produced and, finally, a schedule with milestones, decision points, type and number of design reviews.

Expected response

Scope and content

The ADP shall include the following items:

Name of the ASIC and FPGA and its basic function;
References to the design documentation and other applicable and reference documents;

Internal and external standards, procedures or coding guidelines.

Development team and assignment of major responsibilities;
The baseline FPGA device or ASIC technology including baseline radiation hardening and testability approach;
Companies involved (foundry, subcontractors, suppliers), indicating their assigned tasks, technical and administrative interfaces;
Versions and platforms of tools to be used, including the foundry or specific tools;
Statement for the availability of each design tool (at the site as well as the dedication to the particular development);
The design flow;

Design entry, synthesis, simulation and verification, layout generation and verification, production tests and validation.

Identification of a configuration management system in conformance with ECSSMST40;
Identification of a verification and validation scheme in conformance with ECSSEST10;
The subdivision of the ASIC and FPGA development into reasonably sized work packages in conformance with ECSSMST10;
The schedule of the ASIC and FPGA development, with estimated effort and duration of each work package and the planned dates of milestones and review meetings;
Identification and full description, including formats, of all relevant outputs, deliverable or not, to be produced along the ASIC and FPGA development (documentation, simulation and test results, test boards, test samples, source or generated codes and programs) and measures intended to achieve best design quality (e.g. HDL coding conformity to an appropriate set of coding rules).

Special remarks

None.

ANNEX(normative)ASIC and FPGA requirements specification (ARS) – DRD

DRD identification

Requirement identification and source document

This DRD is called by the ECSS-Q-ST-60-02, requirements 5.3.2b and 7.3.2a.2.

Purpose and objective

The purpose of the ASIC and FPGA requirement specifications (ARS) is to specify a complete set of traceable ASIC and FPGA requirements.

Expected response

Scope and content

The ARS shall include the following items:

Overall system partitioning, system configurations and operating modes;
Interfaces of the ASIC and FPGA to the system and communication protocols to external devices, including memory mapping;
Operating frequency range;
Electrical constraints (e.g. voltage and current supply, drive capabilities and external load);
Functional requirements;
Applicable algorithms;
Power-up and initialization state;
Reset and power cycling requirements;
Error handling;
Test modes: system and device tests, on ground and in flight;
Fault coverage required at production test;

This is only applicable for digital ASIC designs.

Timing of critical signals;
Radiation environment constraints;
Thermal environment constraints;
Power budget and dissipation;
Physical and mechanical constraints: pin assignment, size, encapsulation;
Reusability or additional functions for future applications;
Portability to different or newer technologies;
Intellectual property rights of the design to be developed;
Proprietary designs (IP cores) to be used as building blocks of the design to be developed, if already identified.

Special remarks

None

ANNEX(normative) Feasibility and risk assessment report (FRA) - DRD

DRD identification

Requirement identification and source document

This DRD is called by the ECSS-Q-ST-60-02, requirement 5.3.3.2b.

Purpose and objective

The purpose of the FRA is to provide a judgement on the feasibility of the ASIC and FPGA development as defined by the ASIC and FPGA requirements specification, as well as an assessment of the risks involved.

Expected response

Scope and content

The FRA shall include the following items:

Assurance that the collected ASIC and FPGA requirements are complete, settled and unambiguous;
Maturity of envisaged ASIC or FPGA manufacturers and possible technologies;
Experience and familiarity of engineering resources with the design type, tools, technology and the potential foundries;
Risk of underestimation of design and verification effort;
Risk of underestimation of debug and repair efforts;
Risk of overestimation of actual gate capacity and clocking frequency;
Risk of undetermined I/O behaviour during power-up.

Special remarks

None.

ANNEX(normative)Verification plan (VP) – DRD

DRD identification

Requirement identification and source document

This DRD is called by ECSS-Q-ST-60-02, requirements 4.3.2a and 5.4.3a.

Purpose and objective

The purpose of the verification plan is to define how the functionality and non-functional requirements stated in the definition phase documentation are demonstrated at all levels of modelling, starting from the behavioural level down to the gate level.

Expected response

Scope and content

The VP shall include a description of the following items:

In the case of complex digital ASIC developments, verification by FPGA prototyping or emulation;
Requirements for code coverage in digital designs;
Requirements for hardware-software interaction, possibly by performing co-simulation;
Application of coding rules.

Special remarks

None.

ANNEX(normative) Design validation plan (DVP) – DRD

DRD identification

Requirement identification and source document

This DRD is called by the ECSS-Q-ST-60-02, requirements 4.3.3a and 5.6.4a.

Purpose and objective

The purpose of the design validation plan is to specify the measurements that are performed on the prototypes in order to verify that the new implemented devices contain the functionality and the characteristic they are designed for.

Expected response

Scope and content

The DVP shall include the following items:

description and requirements for the test set-up or system breadboard;
operating modes and test conditions of the prototypes under test;
characteristics and functions to be validated and checked against the ASIC and FPGA requirements specification;
if a radiation test is required by the customer, the corresponding radiation verification test plan.

Special remarks

None.

ANNEX(normative)Data sheet – DRD

DRD identification

Requirement identification and source document

This DRD is called by ECSS-Q-ST-60-02, requirements 5.4.5a and 7.4.1a

Purpose and objective

The purpose of the data sheet is to gather all technical data obtained from the architectural design until the final design validation and release. It is used as an input for application and procurement.

Expected response

Scope and content

Each page shall contain the device name and number and the date of issue.

The first page contain a summary of the device functionality, a block diagram and short list of features, such as operating frequency, technology and the foundry address.

All characteristics and limitations introduced during the design shall be described, such as detailed interface descriptions, register definitions and memory maps.
The data sheet shall include a system overview of the device and a description of how to use the device in a representative system environment, including an application block diagram.
The full functionality and all operating modes shall be specified in detail.
All signal interfaces shall be described in detail including for instance a description of all signals, test and power pins, specifying e.g. the usage of the signals and the signal polarity.
The signal descriptions shall be grouped according to their function.
All electrical and mechanical data shall be specified, together with their relevant applicable conditions (e.g. temperature and capacitive load), including:

Absolute maximum ratings, including storage temperature, operating temperature, supply voltage, maximum input current for any pin, total dose, single event upset, latch-up, electrostatic discharge and reliability figures;
DC parameters, including voltage levels, leakage currents, pin capacitances and output currents;
Static and dynamic (per MHz) power dissipation, allowing the power consumption at lower operating frequencies to be calculated, if representative;
AC parameters, including e.g. set-up and hold times, cycle periods, output delays and tri-state delays, together with waveform diagrams;
Evidences that timing parameters relate to the relevant reference signal edges;
Package description, including pin assignment, package figure with pin numbers and preferably signal names, and a mechanical drawing for the package dimensions including information on the thermal characteristic of the package such as wall thickness, thermal coefficient of material or package. A preliminary data sheet shall contain all parts of a final data sheet, with the same level of detail.
When data does not exist, estimates shall be used and clearly indicated to be estimates.

Special remarks

None.

ANNEX(normative) Detail specification (DS) – DRD

DRD identification

Requirement identification and source document

This DRD is called by ECSS-Q-ST-60-02, requirements 5.6.6a and 7.4.3c.

Purpose and objective

The purpose of the detail specification is to collect all the engineering information from the layout activity (at the end of which a draft detail specification is established) to the design validation and release activity (at the end of which the final detail specification is produced). It is used as an input for application and procurement.

Expected response

Scope and content

The final detail specification shall include the following items:

relevant electrical and mechanical parameters;
screening, burn-in, and acceptance requirements;
deviations from the generic specification;
documentation and data requirements;
delta limits, when applicable;
criteria for percent defective allowable;
lot acceptance tests or quality conformance inspections;
marking;
storage requirements;
requirements for lot homogeneity;
serialization, when applicable;
protective packaging and handling requirements;
radiation verification testing requirements, when applicable.

Special remarks

None.

ANNEX(normative) Experience summary report – DRD

DRD identification

Requirement identification and source document

This DRD is called by ECSS-Q-ST-60-02, requirement 4.4a and 5.8.4a.

Purpose and objective

The purpose of the experience summary report is to collect and to evaluate any relevant information resulting from the experience gained during the execution of the ASIC and FPGA procurement programme.

Expected response

Scope and content

The experience summary report shall include the following items:

A summary of the main design objectives and constraints;
An assessment of the actual development programme with respect to the original ADP;
Controls, schedule, design iterations and communications;
An assessment of EDA tool suitability and performance;
An assessment of the manufacturer support;
A presentation of non-conformances and problem areas;
In the case of usage of existing IP cores, experiences gained in terms of product quality and suitability;
synthesis results, modelling, test stimuli, documentation, application support and problems encountered;
Recommendations and lessons learned.

Special remarks

None.

ANNEX(informative)Document requirements list and configuration items to be delivered

Table: Deliverables of the ASIC and FPGA development

Development phase	Documentation	DRD	Software	Hardware
	A/F control plan (ACP)	Annex A
Definition phase	A/F requirements specification (ARS) Feasibility and risk analysis (FRA) A/F development plan (ADP) MoM of SRR	Annex C Annex D Annex B -
Architectural design	Architecture definition report Verification plan Architecture verification and optimization report Preliminary data sheet MoM of PDR	- Annex E - Annex G -	Design database containing: Simulation models Verification results
Detailed design	Design entry report Netlist generation report Netlist verification report Updated data sheet MoM of DDR	- - - Annex G	Updated design database containing: Pre-layout netlist Constraints for layout Test vectors for production
Layout	Layout generation report Layout verification report Design validation plan (DVP) Updated data sheet Draft detail specification MoM of CDR	- - Annex F Annex G Annex H -	Updated design database containing: Post-layout netlist Corresponding parasitic information
Prototype implementation	Production test results and reports Burn-in or any other production test results, specification, pattern	- -		Agreed number of tested devices (ASICs or FPGAs)
Design validationand release	Validation report Radiation test report Release report Final data sheet Final detail specification Application note Experience summary report MoM of QR/AR	- - - Annex G Annex H - Annex I -		Validation breadboard Burn-in or screening test boards for FM parts

Bibliography

ECSS-S-ST-00	ECSS system – Description, implementation and general requirements
IEEE 61691-1-1	Behavioural languages Part 1-1: VHDL language reference manual
IEEE 1149.1	and Boundary-Scan Architecture