EN 16602-60-02:2014

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Raumfahrtproduktsicherung - Entwicklung von ASIG und FPGAAssurance produit des projets spatiaux - développement des ASIC et FPGASpace product assurance - ASIC and FPGA development49.140Vesoljski sistemi in operacijeSpace systems and operationsICS:Ta slovenski standard je istoveten z:EN 16602-60-02:2014SIST EN 16602-60-02:2015en,fr,de01-januar-2015SIST EN 16602-60-02:2015SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 16602-60-02
September 2014 ICS 49.140
English version
Space product assurance - ASIC and FPGA development
Assurance produit des projets spatiaux - développement des ASIC et FPGA
Raumfahrtproduktsicherung - Entwicklung von ASIG und FPGA This European Standard was approved by CEN on 13 March 2014.
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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels © 2014 CEN/CENELEC All rights of exploitation in any form and by any means reserved worldwide for CEN national Members and for CENELEC Members. Ref. No. EN 16602-60-02:2014 E SIST EN 16602-60-02:2015

ASIC and FPGA development plan (ADP) – DRD . 48 Annex C (normative) ASIC and FPGA requirements specification (ARS) – DRD . 50 Annex D (normative)
Feasibility and risk assessment report (FRA) - DRD . 52 Annex E (normative) Verification plan (VP) – DRD . 53 Annex F (normative)
Design validation plan (DVP) – DRD . 54 Annex G (normative) Data sheet – DRD. 55 Annex H (normative)
Detail specification (DS) – DRD . 57 Annex I (normative)
Experience summary report – DRD . 59 Annex J (informative) Document requirements list and configuration items to be delivered . 60 Bibliography . 61
Figures Figure 5-1: Development flow (example) . 17 Figure 7-1:
Design documentation . 41
Tables Table J-1 : Deliverables of the ASIC and FPGA development . 60 SIST EN 16602-60-02:2015

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.
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.
EN reference Reference in text Title EN 16601-00-01 ECSS-S-ST-00-01 ECSS system – Glossary of terms EN 16602-10 ECSS-Q-ST-10 Space product assurance – Product assurance management
EN 16602-20 ECSS-Q-ST-20 Space product assurance – Quality assurance EN 16602-30 ECSS-Q-ST-30 Space product assurance – Dependability
EN 16602-60 ECSS-Q-ST-60 Space product assurance – Electrical, electronic and electromechanical (EEE) components EN 16603-10 ECSS-E-ST-10 Space engineering – System engineering general requirements EN 16601-10 ECSS-M-ST-10 Space project management – Project planning and implementation EN 16601-10-01 ECSS-M-ST-10-01 Space project management – Organization and conduct of reviews EN 16601-40 ECSS-M-ST-40 Space project management – Configuration and information management
full custom or semi custom designed monolithic integrated circuit that can be digital, analog or a mixed function for one user 3.2.2 ASIC technology totality of all elements required for the design, manufacture and test of ASIC components NOTE
Design tools and their description, cell libraries, procedures, design rules, process line and test equipment. 3.2.3 application specific standard products (ASSP) ASICs designed to make standard products that are made available to a broader range of applications
NOTE
ASSPs are most often are provided with a VHDL model and disseminated with documentation. 3.2.4 block diagram abstract graphical presentation of interconnected named boxes (blocks) representing an architectural or functional drawing 3.2.5 cell specific circuit function including digital or analog basic blocks 3.2.6 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 SIST EN 16602-60-02:2015

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 flow selection and sequence of engineering methods and tools to be applied during the implementation of the design 3.2.9 design for test (DFT) structure technique used to allow a complex integrated circuit (IC) to be tested NOTE
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. 3.2.10 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 3.2.11 detail specification procurement specification according to ESCC format that defines, for instance, the maximum ratings, parameter limitations, mechanical outline, pin description and screening requirements 3.2.12 development step major step of the development flow for the ASIC and FPGA development NOTE
Definition phase, architectural design, detailed design, layout, prototype implementation and design validation. 3.2.13 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.14 field programmable gate array (FPGA) standard semiconductor device that becomes customized when programmed by the user with the FPGA specific software and hardware tools 3.2.15 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 SIST EN 16602-60-02:2015

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 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). 3.2.18 macrocell module that contains complex functions in a manufacturer’s cell library built up out of hard-wired primitive cells 3.2.19 netlist formatted list of cells (basic circuits) and their interconnections 3.2.20 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 3.2.21 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 3.2.22 stimuli input data set for simulation or test to show a specific functionality or performance of a device 3.2.23 test pattern simulation stimuli and its expected responses (considering specific constraints to meet test equipment requirements) used to show correct behaviour of a device SIST EN 16602-60-02:2015

b. The organization shall comply with the requirements specified in ECSS-Q-ST-10. c. 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. 4.1.3 Planning a. The supplier shall ensure that: 1. the ASIC and FPGA developments that are necessary for the implementation of the ASIC and FPGA programme are planned, documented and implemented, and
2. preventive or corrective actions are initiated whenever there is evidence of possible schedule or technical problems. 4.2 ASIC and FPGA control plan a. The supplier shall prepare an ASIC and FPGA control plan (ACP) in conformance with the DRD in Annex A. SIST EN 16602-60-02:2015

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. 4.3.2 Verification plan a. The supplier shall establish a verification plan in conformance with the DRD in Annex E. b. 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. 4.3.3 Design validation plan a. The supplier shall establish a design validation plan (DVP) in conformance with the DRD in Annex F. b. The DVP shall specify the measurements to be performed on the prototypes. NOTE
Those measurements allow verifying that the implemented devices contain the functionality and the characteristics they are designed for. 4.4 Experience summary report a. 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. NOTE
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.
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. 5.2 General requirements
a. The ASIC and FPGA development flow shall be in conformance with ECSS-M-ST-10. NOTE
Figure 5-1 gives an example of the ASIC and FPGA development flow, adapted from ECSS-M-ST-10. b. 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; NOTE
Examples are simulation pattern, schematics, VHDL source codes, synthesis scripts. c. Each development step using design inputs shall reflect the revision numbers of the inputs in a log file to prove consistency; d. Each development step shall be verified by a mechanism, as impartial as possible, to guarantee successful completion of the development step.
NOTE
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. SIST EN 16602-60-02:2015

Figure 5-1: Development flow (example) SIST EN 16602-60-02:2015

Figure 5-1 (cont’d)
Figure 5-1: Development flow (example) – continued SIST EN 16602-60-02:2015

5.3 Definition phase 5.3.1 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. 5.3.2 General requirements
a. The supplier shall ensure that all relevant system configurations and characteristics and all issues imposing requirements on the device are used.
NOTE
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.
b. 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. 5.3.3 Feasibility and risk assessment 5.3.3.1 Feasibility study a. The feasibility of the intended ASIC and FPGA development shall be assessed against the established ASIC and FPGA requirements specification and the available resources.
b. As a minimum, the following tasks shall be performed and documented: 1. Estimate design complexity; 2. Estimate power consumption; 3. Assess feasibility of speed requirements by a preliminary timing analysis; 4. Select a radiation hardening approach that ensures compliance with radiation tolerance requirements. Determine a rough estimate of impact on chip area and circuit speed; 5. Select a production test approach and its feasibility against all requirements; 6. 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; SIST EN 16602-60-02:2015

f. The reviewers shall check that ARS and FRA include as a minimum: SIST EN 16602-60-02:2015

name, polarity, bus width and interface protocol; 17. Electrical specifications (maximum ratings, AC, DC and timing diagrams); 18. Power dissipation estimates for main functional modes; 19. Operating conditions (supply, temperature, radiation); 20. Baseline package and pin-out, if already known.
EXPECTED OUTPUTS: a. the definition phase documentation, containing: 1. ASIC and FPGA requirements specification (ARS); 2. Feasibility and risk analysis (FRA); b. ASIC and FPGA development plan (ADP); c. MoM of SRR. SIST EN 16602-60-02:2015

a. 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.
b. Important selections for the implementation of the chip shall be made or confirmed.
c. All definitions and selections made shall conform to the definition phase documentation.
d. Any deviation shall be justified in the preliminary design review. e. 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. 5.4.2 Architecture definition a. As a minimum the following tasks shall be performed and documented in an architecture definition report: 1. Subdivide the chip into its fundamental functions or blocks, identifying and thoroughly documenting their interfaces, functionalities and interactions; 2. Define the architecture down to the level required to implement technology specific, transistor- or gate-level mapping; 3. Select suitable algorithms and circuit schemes including their parameters to implement the identified functions; 4. 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; 5. Identify a suitable clocking and reset scheme assuring correct transitions of data between clock domains and identify asynchronous parts of the design; 6. 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.
NOTE
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. 7. 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; SIST EN 16602-60-02:2015

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. b. The architecture definition report shall include the architecture broken down to the selected blocks, their interfaces, functionality or algorithms and interactions.
c. Even though the chip and its architecture is completely described in a simulation model (executable specification), a detailed text specification shall be edited. 5.4.3 Verification plan a. The supplier shall establish a verification plan in conformance with the DRD in Annex E. 5.4.4 Architecture verification and optimization a. As a minimum, the following activities shall be performed and documented in an architecture verification and optimization report: 1. Verify that the defined architecture meets the requirements by appropriate simulation and analysis techniques; 2. Verify that the models referred to in clause 5.4.2a.9 above are compliant to the verification plan; 3. Perform an independent verification in order to avoid masking of design errors; 4. 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;
NOTE
This is not applicable for FPGA designs. 5. Re-assess the feasibility and risks; 6. Find an application related trade-off for conflicting requirements; NOTE
For example: power consumption vs. speed and performance, pin count vs. package size and complexity vs. die area.
7. Establish the implementation choices. SIST EN 16602-60-02:2015

The preliminary data sheet is updated and completed at the end of the ASIC and FPGA development.
5.4.6 Preliminary design review a. The architectural design phase shall be concluded by the preliminary design review (PDR) meeting (see quality assurance clause 6.2). b. The documentation generated within this phase shall be reviewed.
c. The reviewers shall check that the selected trade-off meets the requirements fixed during the definition phase. d. 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. e. 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. f. The reviewers shall identify, justify and approve discrepancies between the architectural design documentation and the definition phase documentation. g. The reviewers shall check that the planned measures, tools, methods and procedures are applied.
EXPECTED OUTPUTS: a. Architecture definition report; b. Verification plan; c. Architecture verification and optimization report; d. Preliminary data sheet; e. Design database, containing: 1. Simulation models; 2. Verification results; f. MoM of PDR. 5.5 Detailed design 5.5.1 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. SIST EN 16602-60-02:2015

b. For analog designs circuit and layout are developed concurrently, and the reviews for detailed design and layout phases may be held together.
c. For FPGAs and analog designs, a combined DDR and CDR meeting may be justified.
NOTE
In these cases also the corresponding output reports can be merged together. d. The scripts used for an automatic and repeatable generation shall be part of the design database. NOTE 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. NOTE 2 The scripts defined for this generation are an essential part of the detailed design,
5.5.3 Design entry a. During the design entry the following tasks shall be performed and documented in a design entry report. b. 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. c. 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). d. Implement the specified radiation hardening concept by design and during synthesis. e. Continuously verify the results by the appropriate methods, as specified in the verification plan. f. Determine a pin-out and bonding scheme with particular attention to the technical constraints.
NOTE
For example, power supply pin definition and bondability issues. g. Select buffers according to the I/O requirements defined in the ASIC and FPGA requirements specification. h. Establish or refine the floorplan. NOTE
This is not applicable for FPGA designs.
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
...