Ecss Q ST 60 02C

ECSS-Q-ST-60-02C
31 July 2008
Space product
assurance
ASIC and FPGA development
ECSS Secretariat
ESA-ESTEC
Requirements & Standards Division
Noordwijk, The Netherlands
ECSSQST6002C
31July2008
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
associationsforthepurposeofdevelopingandmaintainingcommonstandards.Requirementsinthis
Standardaredefinedintermsofwhatshallbeaccomplished,ratherthanintermsofhowtoorganize
and perform the necessary work. This allows existing organizational structures and methods to be
appliedwheretheyareeffective,andforthestructuresandmethodstoevolveasnecessarywithout
rewritingthestandards.
This Standard has been prepared by the ECSSQST6002 Working Group, reviewed by the ECSS
ExecutiveSecretariatandapprovedbytheECSSTechnicalAuthority.
Disclaimer
ECSSdoesnotprovideanywarrantywhatsoever,whetherexpressed,implied,orstatutory,including,
butnotlimitedto,anywarrantyofmerchantabilityorfitnessforaparticularpurposeoranywarranty
that the contents of the item are errorfree. In no respect shall ECSS incur any liability for any
damages,including,butnotlimitedto,direct,indirect,special,orconsequentialdamagesarisingout
of, resulting from, or in any way connected to the use of this Standard, whether or not based upon
warranty,businessagreement,tort,orotherwise;whetherornotinjurywassustainedbypersonsor
propertyorotherwise;andwhetherornotlosswassustainedfrom,oraroseoutof,theresultsof,the
item,oranyservicesthatmaybeprovidedbyECSS.
Publishedby:
Copyright:
ESARequirementsandStandardsDivision
ESTEC, P.O. Box 299,
2200 AG Noordwijk
The Netherlands
2008 by the European Space Agency for the members of ECSS
ECSSQST6002C
31July2008
Change log
ECSSQ6002A
Firstissue
17July2008
ECSSQ6002B
Neverissued
ECSSQST6002C
Secondissue
31July2008
ChangestoECSSQ6002Aare:
1 Alldocumentsrequirementshavebeenmovedinnormative
annexes.ThefollowingDRDshavebeencreated:ACP,ADP,ARS,
FRA,VP,DVP,ES,DataSheetandDetailSpecification
2 Someeditorialconversionshavebeendoneforcomplianceto
ECSSDraftingrulesforStandard.
ECSSQST6002C
31July2008
Table of contents
Change log .................................................................................................................3
Introduction................................................................................................................7
1 Scope.......................................................................................................................8
2 Normative references .............................................................................................9
3 Terms, definitions and abbreviated terms..........................................................10
3.1
Terms from other standards ..................................................................................... 10
3.2
Terms specific to the present standard .................................................................... 10
3.3
Abbreviated terms .................................................................................................... 13
4 ASIC and FPGA programme management .........................................................15

4.1
General..................................................................................................................... 15
4.1.1
Introduction................................................................................................. 15
4.1.2
Organization ............................................................................................... 15
4.1.3
Planning...................................................................................................... 15
4.2
ASIC and FPGA control plan.................................................................................... 15
4.3
Management planning tools ..................................................................................... 16
4.4
4.3.1
ASIC and FPGA development plan ............................................................ 16
4.3.2
Verification plan .......................................................................................... 16
4.3.3
Design validation plan ................................................................................ 16
Experience summary report ..................................................................................... 16
5 ASIC and FPGA engineering ...............................................................................17

5.1
Introduction............................................................................................................... 17
5.2
General requirements............................................................................................... 17
5.3
Definition phase........................................................................................................ 20
5.3.1
Introduction................................................................................................. 20
5.3.2
General requirements................................................................................. 20
5.3.3
Feasibility and risk assessment.................................................................. 20
5.3.4
ASIC and FPGA development plan ............................................................ 21
5.3.5
System requirements review ...................................................................... 21
ECSSQST6002C
31July2008
5.4
5.5
5.6
5.7
5.8
Architectural design.................................................................................................. 23
5.4.1
5.4.2
Architecture definition ................................................................................. 23
5.4.3
Verification plan .......................................................................................... 24
5.4.4
Architecture verification and optimization ................................................... 24
5.4.5
Preliminary data sheet................................................................................ 25
5.4.6
Preliminary design review........................................................................... 25
Detailed design......................................................................................................... 25
5.5.1
Introduction................................................................................................. 25
5.5.2
5.5.3
Design entry ............................................................................................... 26
5.5.4
Netlist generation........................................................................................ 27
5.5.5
Netlist verification ....................................................................................... 28
5.5.6
Updated data sheet .................................................................................... 29
5.5.7
Detailed design review ............................................................................... 29
Layout....................................................................................................................... 30
5.6.1
5.6.2
Layout generation....................................................................................... 30
5.6.3
Layout verification....................................................................................... 31
5.6.4
Design validation plan ................................................................................ 32
5.6.5
Updated data sheet .................................................................................... 32
5.6.6
Draft detail specification ............................................................................. 32
5.6.7
Critical design review.................................................................................. 32
Prototype implementation......................................................................................... 33
5.7.1
Introduction................................................................................................. 33
5.7.2
Production and test..................................................................................... 33
Design validation and release .................................................................................. 34

5.8.1
Design validation ........................................................................................ 34
5.8.2
Radiation test performance ........................................................................ 34
5.8.3
Design release and FM production preparation ......................................... 35
5.8.4
Experience summary report ....................................................................... 35
5.8.5
Final versions of application and procurement documents ........................ 35
5.8.6
Qualification and acceptance review .......................................................... 36
6 Quality assurance system ...................................................................................37

6.1
General..................................................................................................................... 37
6.2
Review meetings ...................................................................................................... 37
6.3
Risk assessment and risk management................................................................... 39
ECSSQST6002C
31July2008
7 Development documentation ..............................................................................40

7.1
General..................................................................................................................... 40
7.2
Management documentation .................................................................................... 40
7.3
Design documentation.............................................................................................. 41
7.4
7.3.1
General....................................................................................................... 41
7.3.2
Definition phase documentation ................................................................. 43
7.3.3
Architectural design documentation ........................................................... 43
7.3.4
Detailed design documentation .................................................................. 43
7.3.5
Layout documentation ................................................................................ 44
7.3.6
Design validation documentation................................................................ 44
Application and procurement documents ................................................................. 44

7.4.1
Data sheet .................................................................................................. 44
7.4.2
Application note .......................................................................................... 44
7.4.3
Detail specification...................................................................................... 45
8 Deliverables ..........................................................................................................46
8.1
General..................................................................................................................... 46
8.2
Deliverable items ...................................................................................................... 46
Annex A (normative) ASIC and FPGA control plan (ACP) DRD........................47

Annex B (normative) ASIC and FPGA development plan (ADP) DRD.............49
Annex C (normative) ASIC and FPGA requirements specification (ARS)
DRD ......................................................................................................................51
Annex D (normative) Feasibility and risk assessment report (FRA) - DRD .......53
Annex E (normative) Verification plan (VP) DRD ...............................................54
Annex F (normative) Design validation plan (DVP) DRD..................................55
Annex G (normative) Data sheet DRD.................................................................56
Annex H (normative) Detail specification (DS) DRD .........................................58
Annex I (normative) Experience summary report DRD ....................................60
Annex J (informative) Document requirements list and configuration items
to be delivered .....................................................................................................61
Bibliography.............................................................................................................62
Figures
Figure 5-1: Development flow (example) ............................................................................... 18
Figure 7-1: Design documentation ........................................................................................ 42
Tables
Table J-1 : Deliverables of the ASIC and FPGA development............................................... 61
6
ECSSQST6002C
31July2008
Introduction
Theaddedresponsibilitiesofdevelopingcustomdesigneddevices,asopposed
to using offtheshelf components, make certain management activities crucial
tothesuccessoftheprocurementprogramme.Thiswasalreadyconsideredby
the applicable standard for Space product assurance EEE components,
ECSSQST60 that classifies custom designed devices, such as ASIC
components, under Specific components, for which particular requirements
areapplicable.
The supplier accepts requirements for the development of custom designed
componentswithintheboundariesofthisstandardbasedontherequirements
ofthesystemanditselements,andtakesintoconsiderationtheoperationaland
environmentalrequirementsoftheprogramme.
The supplier implements those requirements into a system which enables to
controlforinstancethetechnologyselection,design,synthesisandsimulation,
layout and design validation in a schedule compatible with his requirements,
andinacostefficientway.
ECSSQST6002C
31July2008
1
Scope
This Standard defines a comprehensive set of requirements for the user
development of digital, analog and mixed analogdigital 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
validationandreleaseofprototypedevices.
ThisStandardisaimedatensuringthatthecustomdesignedcomponentsused
in space projects meet their requirements in terms of functionality, quality,
reliability, schedule and cost. The support of appropriate planning and risk
managementisessentialtoensurethateachstageofthedevelopmentactivityis
consolidated before starting the subsequent one and to minimize or avoid
additional iterations. For the development of standard devices, such as
applicationspecificstandardproducts(ASSPs)andIPcores,anddeviceswhich
implementsafetyrelatedapplications,additionalrequirementscanbeincluded
whicharenotinthescopeofthisdocument.
The principal clauses of this Standard correspond to the main concurrent
activitiesofacircuitdevelopmentprogramme.Theseinclude:
ASICandFPGAprogrammemanagement,
ASICandFPGAengineering,
ASICandFPGAqualityassurance.
Theprovisionsofthisdocumentapplytoallactorsinvolvedinalllevelsinthe
realizationofspacesegmenthardwareanditsinterfaces.
Thisstandardmaybetailoredforthespecificcharacteristicsandconstraintsofa
spaceproject,inaccordancewithECSSSST00.
ECSSQST6002C
31July2008
2
Normative references
The following normative documents contain provisions which, through
reference in this text, constitute provisions of this ECSS Standard. For dated
references,subsequentamendmentsto,orrevisionsofanyofthesepublications
donotapply.However,partiestoagreementsbasedonthisECSSStandardare
encouragedtoinvestigatethepossibilityofapplyingthemostrecenteditionsof
the normative documents indicated below. For undated references the latest
editionofthepublicationreferredtoapplies.
ECSSSST0001
ECSSsystemGlossaryofterms
ECSSQST10
SpaceproductassuranceProductassurance
management
ECSSQST20
SpaceproductassuranceQualityassurance
ECSSQST30
SpaceproductassuranceDependability
ECSSQST60
SpaceproductassuranceElectrical,electronicand
electromechanical(EEE)components
ECSSEST10
SpaceengineeringSystemengineeringgeneral
requirements
ECSSMST10
SpaceprojectmanagementProjectplanningand
implementation
ECSSMST1001
SpaceprojectmanagementOrganizationand
conductofreviews
ECSSMST40
SpaceprojectmanagementConfigurationand
informationmanagement
ECSSQST6002C
31July2008
3
Terms, definitions and abbreviated terms
3.1
Terms from other standards

ForthepurposeofthisStandard,thetermsanddefinitionsfromECSSST0001
apply.
3.2
Terms specific to the present standard

3.2.1
application specific integrated circuit (ASIC)
full custom or semi custom designed monolithic integrated circuit that can be
digital,analogoramixedfunctionforoneuser
3.2.2
ASIC technology
totality of all elements required for the design, manufacture and test of ASIC
components
NOTE
3.2.3
Design tools and their description, cell libraries,

procedures, design rules, process line and test
equipment.
application specific standard products (ASSP)
ASICsdesignedtomakestandardproductsthataremadeavailabletoabroader
rangeofapplications
NOTE
3.2.4
ASSPs are most often are provided with a VHDL

modelanddisseminatedwithdocumentation.
block diagram
abstract graphical presentation of interconnected named boxes (blocks)

representinganarchitecturalorfunctionaldrawing
3.2.5
cell
specificcircuitfunctionincludingdigitaloranalogbasicblocks
3.2.6
cell library
collectionofallmutuallycompatiblecellswhichconformstoasetofcommon
constraints and standardized interfaces designed and characterized for a
specifiedtechnology
10
ECSSQST6002C
31July2008
3.2.7
data sheet
detailedfunctional,operationalandparametricdescriptionofacomponent
NOTE
3.2.8
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
packagedescription.
design flow
selectionandsequenceofengineeringmethodsandtoolstobeappliedduring
theimplementationofthedesign
3.2.9
design for test (DFT) structure
techniqueusedtoallowacomplexintegratedcircuit(IC)tobetested
NOTE
3.2.10
Thiscanincludeanymechanismaimedtoprovide
better observability or commandability of internal
nodes of the chip not accessible through primary
inputsandoutputs.
design iteration
design changes that occur in any single phase or between two consecutive
phasesasdefinedintheASICandFPGAdevelopmentplan,beforethedesign
isreleasedforprototypeimplementation
3.2.11
detail specification
procurementspecificationaccordingtoESCCformatthatdefines,forinstance,
the maximum ratings, parameter limitations, mechanical outline, pin
descriptionandscreeningrequirements
3.2.12
development step
majorstepofthedevelopmentflowfortheASICandFPGAdevelopment
NOTE
3.2.13
Definition phase, architectural design, detailed

design, layout, prototype implementation and
designvalidation.
fault coverage
measure expressed as a percentage of the proportion of actually detectable

faultsversusallpossiblefaultsinadigitalcircuit,foragivensetoftestpatterns
andwithrespecttoaspecificfaultmodel
3.2.14
field programmable gate array (FPGA)
standard semiconductor device that becomes customized when programmed

bytheuserwiththeFPGAspecificsoftwareandhardwaretools
11
ECSSQST6002C
31July2008
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
groundlines,clockdistributionandinterconnectchannels
3.2.16
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,
simulationandbychoosingasuitablelevelofabstractionforautomaticnetlist
generation
3.2.17
intellectual property (IP) core
designelementthatimplementsaselfstandingfunctionorgroupoffunctions
forwhichownershiprightsexist
NOTE1 IPcorecanbeacquiredbyacustomer,foragiven
price and under an ownerdefined license
agreement specifying the customers acquired
rights.
NOTE2 IP core can be supplied as an HDL file (e.g.
synthesizableVHDLcodeorgatelevelnetlist)and
with the essential complementary documentation
that allows the customer to successfully integrate
and use it in a system (e.g. Users manual and
verificationfiles).
3.2.18
macrocell
modulethatcontainscomplexfunctionsinamanufacturerscelllibrarybuiltup
outofhardwiredprimitivecells
3.2.19
netlist
formattedlistofcells(basiccircuits)andtheirinterconnections
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
itssystem
3.2.21
redesign
designchangeswhichaffectmorethantwoconsecutivephasesoftheASICand
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

performanceofadevice
12
ECSSQST6002C
31July2008
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
3.3
Abbreviated terms
ForthepurposeofthisStandard,theabbreviatedtermsfromECSSSST0001
andthefollowingapply:
Abbreviation
Meaning
ACP
ASICandFPGAcontrolplan
ADP
ASICandFPGAdevelopmentplan
ARS
ASICandFPGArequirementsspecification
ASCII
Americanstandardcodeforinformationinterchange
ASIC
applicationspecificintegratedcircuit
ASSP
applicationspecificstandardproduct
DD
designdocumentation
DDR
detaileddesignreview
DFT
designfortest
DRC
designrulecheck
DVP
designvalidationplan
EDA
electronicdesignautomation
EDIF
electronicdesigninterchangeformat
ERC
electricalrulecheck
ESCC
EuropeanSpaceComponentsCoordination
FM
flightmodulepart
FPGA
fieldprogrammablegatearray
FRA
feasibilityandriskanalysisreport
GDS
graphicdesignsystem(industrystandardgraphics
entrytool)
HDL
hardwaredescriptionlanguage
Note:
This term used in general for the various

hardware description language which are
appliedforcodingduringdesignphasesuchas
VHDLandverilog.
IDMP
inputdataformaskorprogrammingfilegeneration
IEEE
InstituteofElectricalandElectronicsEngineers
IP
intellectualproperty
MoM
minutesofmeeting
P&R
placeandroute
JTAG
jointtestactiongroup
LVS
layoutvs.schematiccheck
13
ECSSQST6002C
31July2008
NCC
netlistcomparisoncheck
QML
qualifiedmanufacturerlist
RTL
registertransferlogic
SEU
singleeventupset
VHDL
VHSIChardwaredescriptionlanguage
14
ECSSQST6002C
31July2008
4
ASIC and FPGA programme management
4.1
General
4.1.1
a.
The supplier shall establish and implement an ASIC and FPGA

development,aspartofthecomponentprogramme(inconformancewith
ECSSQST60), that ensures full conformance with the requirements of
theprojectasdefinedbythecustomerinlinewiththisstandard.
4.1.2
Organization
a.
The supplier shall establish and maintain an organization for the

managementoftheASICandFPGAprogramme.
b.
The organization shall comply with the requirements specified in

ECSSQST10.
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
advisoryboardasdefinedinECSSQST60.
4.1.3
a.
4.2
Introduction
Planning
Thesuppliershallensurethat:
1.
the ASIC and FPGA developments that are necessary for the
implementationof the ASIC and FPGA programme are planned,
documented and implemented,and
2.
preventive or corrective actions are initiated whenever there is

evidenceofpossiblescheduleortechnicalproblems.
ASIC and FPGA control plan

a.
The supplier shall prepare an ASIC and FPGA control plan (ACP) in
conformancewiththeDRDinAnnexA.
15
ECSSQST6002C
31July2008
4.3
Management planning tools

4.3.1
ASIC and FPGA development plan
a.
ThesuppliershallprepareadetailedASICandFPGAdevelopmentplan
(ADP)inconformancewiththeDRDinAnnexB.
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

DRDinAnnexE.
b.
The verification plan shall define how the functionality and non
functionalrequirementsstatedinthedefinitionphasedocumentationare
demonstratedatalllevelsofmodelling.
4.3.3
Design validation plan
a.
The supplier shall establish a design validation plan (DVP) in

conformancewiththeDRDinAnnexF.
b.
The DVP shall specify the measurements to be performed on the

prototypes.
NOTE
4.4
Those measurements allow verifying that the

implementeddevicescontainthefunctionalityand
thecharacteristicstheyaredesignedfor.
Experience summary report

a.
At the end of the ASIC and FPGA development cycle, the supplier
shouldestablishanexperiencesummaryreportinconformancewiththe
DRDinAnnexI.
NOTE
The experience summary report can be written in

the frame of the suppliers continued quality
improvement activities in order to establish
economic and efficient development and test
requirementsforexpectedfutureprojects.
16
ECSSQST6002C
31July2008
5
ASIC and FPGA engineering
5.1
Introduction
Clause5coverstheresponsibilitiesofASICandFPGAsuppliersanddesigners
for the tasks essential to producing highreliability circuit design and tests
meetingallcircuitfunction,testandperformancerequirements.
To consider the timely allocation of management and quality assurance
activitiestotheengineeringtasks,theseactivitiesarealsospecifiedwithinthis
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
fewrequirementsdonotapplytocertaintechnologyoptions,asindicated.
5.2
General requirements
a.
The ASIC and FPGA development flow shall be in conformance with

ECSSMST10.
NOTE
b.
Figure51givesanexampleoftheASICandFPGA
developmentflow,adaptedfromECSSMST10.
All inputs to the design, that are not automatically generated and are
necessary to reproduce the design shall be put under a revision control
mechanismagreedbetweenthecontractors;
NOTE
Examples are simulation pattern, schematics,

VHDLsourcecodes,synthesisscripts.
c.
Each development step using design inputs shall reflect the revision
numbersoftheinputsinalogfiletoproveconsistency;
d.
Eachdevelopmentstepshallbeverifiedbyamechanism,asimpartialas
possible,toguaranteesuccessfulcompletionofthedevelopmentstep.
NOTE
Thedevelopmentstepiscompletedwhenthesteps
itselfaswellasitsverificationwereperformedand
anyerrororseriouswarningbeingflaggedbythe
tools was approved in the corresponding review
meeting.
17
ECSSQST6002C
31July2008
Figure51:Developmentflow(example)
18
ECSSQST6002C
31July2008
Figure51(contd)
Figure51:Developmentflow(example)continued
19
ECSSQST6002C
31July2008
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
andFPGAdevelopmentplan.
5.3.2
a.
The supplier shall ensure that all relevant system configurations and
characteristics and all issues imposing requirements on the device are
used.
NOTE
b.
Thisallowssettlingoutwithoutanyambiguitythe
definitionstatusofthecollectedrequirementsand
verifying that all necessary resources for the
designactivitiesareavailable.
ThesuppliershallspecifythecompletesetoftraceableASICandFPGA
requirementsintheASICandFPGArequirementsspecification(ARS)in
conformancewiththeDRDinAnnexC.
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
specificationandtheavailableresources.
b.
Asaminimum,thefollowingtasksshallbeperformedanddocumented:
1.
Estimatedesigncomplexity;
2.
Estimatepowerconsumption;
3.
Assess feasibility of speed requirements by a preliminary timing

analysis;
4.
Select a radiation hardening approach that ensures compliance

withradiationtolerancerequirements.Determinearoughestimate
ofimpactonchipareaandcircuitspeed;
5.
Select a production test approach and its feasibility against all

requirements;
6.
Identifyandevaluatethesuitabilityandqualificationstatusofthe
ASIC technologies or FPGA available to implement the device,
fulfillingallfunctionalandnonfunctionalrequirementsincluding
thespecifiedderatingfactors.Makeabaselineselection;
20
ECSSQST6002C
31July2008
7.
Identify packages, fulfilling all requirements. Make a baseline

selection;
8.
EnsurethatthebaselinetechnologyandpackageorFPGAhavea
remaining lifetime, so that flight and compatible prototype parts
can be manufactured and are available during the expected
procurementphase(s);
9.
Ensure that technical support for the device can be guaranteed

duringtheexpectedlifetime;
10.
Determine availability and status of the required design and test

tools(H/W&S/W)andlibraries;
11.
Determineavailabilityofthenecessaryhumanresources;
12.
Determine availability, licensing, support, legal and economical

aspectsofusingIPcoresfromthirdparties;
13.
Ensurethatnopatentsareinfringedoragreementsexistorcanbe
madewiththepatentholder.
5.3.3.2
Risk analysis
a.
Asa tool of the quality assurancesystem (see clause 6.3)a risk analysis
shall be performed that identifies potential risk items and assigns
preventivemeasuresandcontingencyplans.
b.
The risk analysis shall result in a Feasibility and risk analysis (FRA)
reportinconformancewiththeDRDinAnnexD.
5.3.4
a.
ASIC and FPGA development plan
The ADP shall ensure prospective design portability for devices with
longtermavailabilityormultipleusagerequirements.
5.3.5
System requirements review
a.
Thedefinitionphaseshallbeconcludedbyasystemrequirementsreview
(SRR)meeting(seequalityassuranceclause6.2).
b.
Thedocumentationgeneratedwithinthisphaseshallbereviewed.
c.
Thereviewersshallcheckthatthedevelopmentactivityasdefinedinthe
ADP is feasible within the limits imposed by the project requirements,
resources,scheduleandbudgetaryconstraints.
d.
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
startingtheArchitecturalDesignphase.
e.
The reviewers shall check that ARS and FRA are complete and
documented in a level of detail that avoid any ambiguity for the
ArchitecturalDesignandallsubsequentdesignwork.
f.
ThereviewersshallcheckthatARSandFRAincludeasaminimum:
21
ECSSQST6002C
31July2008
1.
Summary of the system architecture and all expected

configurationsinwhichthedevicecanbeused;
2.
Specify the external devices connected to the chip and their

interfaceprotocols;
3.
Bit numbering and naming convention (to be maintained

throughoutthedesignflow);
4.
Formatofdatastructures;
5.
Functionalityinallnominaloperationalmodes;
6.
Functionalityforerrorhandling;
7.
Functionalityinallsystemtestmodes;
8.
Internalcommunicationprotocols;
9.
Signalprocessingalgorithms;
10.
Definitions of programmable memory elements and their state

afterreset;
11.
Functionalpartitioning,establishingahighlevelblockdiagram;
12.
Preliminary architectural and hardware/software partitioning,

includingexternalandinternalmemorymapping;
13.
For components providing software programmability, associated

softwarerequirementsspecifications;
14.
Stateandbehaviourofl/Osduringandafterresetandpowerup;
15.
State functions explicitly not implemented in the design, in order

toavoidpotentialmisunderstandings;
16.
Pinlistincludingpowersupply,testpins,ifalreadyknown,name,
polarity,buswidthandinterfaceprotocol;
17.
Electrical specifications (maximum ratings, AC, DC and timing

diagrams);
18.
Powerdissipationestimatesformainfunctionalmodes;
19.
Operatingconditions(supply,temperature,radiation);
20.
Baselinepackageandpinout,ifalreadyknown.
EXPECTEDOUTPUTS:
a. thedefinitionphasedocumentation,containing:
1. ASICandFPGArequirementsspecification(ARS);
2. Feasibilityandriskanalysis(FRA);
b. ASICandFPGAdevelopmentplan(ADP);
c. MoMofSRR.
22
ECSSQST6002C
31July2008
5.4
Architectural design
5.4.1
a.
During the architectural design phase, the architecture of the chip shall
be defined, verified and documented down to the level of basic blocks
implementingallintendedfunctions,theirinterfacesandinteractions.
b.
Importantselectionsfortheimplementationofthechipshallbemadeor
confirmed.
c.
Alldefinitionsandselectionsmadeshallconformtothedefinitionphase
documentation.
d.
Anydeviationshallbejustifiedinthepreliminarydesignreview.
e.
The architecture definition and the baseline choices made during the
definitionphaseshallbesettled,frozenanddocumentedwithalevelof
detailthatallowsproceedingwiththesubsequentdetaileddesign.
5.4.2
a.
Architecture definition
Asaminimumthefollowingtasksshallbeperformedanddocumented
inanarchitecturedefinitionreport:
1.
Subdivide the chip into its fundamental functions or blocks,

identifying and thoroughly documenting their interfaces,
functionalitiesandinteractions;
2.
Define the architecture down to the level required to implement

technologyspecific,transistororgatelevelmapping;
3.
Select suitable algorithms and circuit schemes including their

parameterstoimplementtheidentifiedfunctions;
4.
Identifysubfunctions,whichcanbeusedasanindividualblockat
differentlocationsofthechiporpossiblybecompiledasacorefor
otherdesigns;
5.
Identify a suitable clocking and reset scheme assuring correct

transitions of data between clock domains and identify
asynchronouspartsofthedesign;
6.
Select(ifnotyetdone),IPcorestobeusedorpreviouslydesigned
unitstobereusedinthedesign.Procureandverifythem.
NOTE
7.
This verification can be done by test cases

provided by the IP core manufacturer, by test
benches from an independent source, or by
newlydesignedtestprograms.
Iftheverificationisaccomplishedduringpriorinstantiationsofthe
core, assess it for covering the actual system environment, and
eventually perform bugfixes and workarounds or additional
verification;
23
ECSSQST6002C
31July2008
8.
Identify and eventually procure custom cells, to be used in the

design, verify the consistency of the different models delivered
(e.g.simulationmodels,layoutandtimingview);
9.
Generate models required as an input to the subsequent detailed

designphase(e.g.synthesizableRTLmodels);
NOTE
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
toolsforfurtherverificationtasks.
b.
The architecture definition report shall include the architecture broken

down to the selected blocks, their interfaces,functionality oralgorithms
andinteractions.
c.
Even though the chip and its architecture is completely described in a

simulation model (executable specification), a detailed text specification
shallbeedited.
5.4.3
a.
The supplier shall establish a verification plan in conformance with the

DRDinAnnexE.
5.4.4
a.
Verification plan
Architecture verification and optimization
As a minimum, the following activities shall be performed and

documentedinanarchitectureverificationandoptimizationreport:
1.
Verify that the defined architecture meets the requirements by

appropriatesimulationandanalysistechniques;
2.
Verify that the models referred to in clause 5.4.2a.9 above are

complianttotheverificationplan;
3.
Performanindependentverificationinordertoavoidmaskingof
designerrors;
4.
When allocation and connectivity of hardmacro cells can be an

issue, a preliminary floorplan, assure that the expected cells are
effectivelyplaceandroutablewithinthegivenconstraints;
NOTE
ThisisnotapplicableforFPGAdesigns.
5.
Reassessthefeasibilityandrisks;
6.
Findanapplicationrelatedtradeoffforconflictingrequirements;
NOTE
7.
For example: power consumption vs. speed

andperformance,pincountvs.packagesize
andcomplexityvs.diearea.
Establishtheimplementationchoices.
24
ECSSQST6002C
31July2008
5.4.5
a.
Preliminary data sheet
A preliminary data sheet shall be established in conformance with the

DRDinAnnexG.
NOTE
5.4.6
Preliminary design review
a.
The architectural design phase shall be concluded by the preliminary

designreview(PDR)meeting(seequalityassuranceclause6.2).
b.
c.
The reviewers shall check that the selected tradeoff meets the
requirementsfixedduringthedefinitionphase.
d.
Thereviewersshallcheckthatpreventivemeasuresorcontingencyplans
existforallidentifiedriskitemsandthattheriskanalysedcanbetaken
forstartingthedetaileddesign.
e.
The reviewers shall check that the architectural design documentation

(see clause 7.3.4) together with the documentation of previous
developmentphasesiscomplete,traceableanddocumentedinalevelof
detailthatallowtoproceedwiththedetaileddesign.
f.
The reviewers shall identify, justify and approve discrepancies between

the architectural design documentation and the definition phase
documentation.
g.
Thereviewersshallcheckthattheplannedmeasures,tools,methodsand
proceduresareapplied.
EXPECTEDOUTPUTS:
5.5
The preliminary data sheet is updated and

completed at the end of the ASIC and FPGA
development.
a.
b.
c.
d.
e.
Architecturedefinitionreport;
Verificationplan;
Architectureverificationandoptimizationreport;
Preliminarydatasheet;
Designdatabase,containing:
1. Simulationmodels;
2. Verificationresults;
f. MoMofPDR.
Detailed design
5.5.1
Introduction
During this phase the highlevel architectural design is translated into a

structuraldescriptiononthelevelofelementarycellsoftheselectedtechnology
and library. Additional information is generated for the subsequent
developmentphases,suchaslayoutconstraints,floorplanning,productiontest
programsandadetailedpindescription.
25
ECSSQST6002C
31July2008
For digital designs, the above mentioned design description is the associated
technology specific, verified gatelevel prelayout netlist, whereas for analog
designs, itisa verified sized transistorlevel netlist.However, inmanyanalog
designs,thereisnoseparationbetweencircuitdesignandlayout.
5.5.2
a.
Influences from layout such as cross talk and matching shall be

accountedforduringthedesignwork.
b.
For analog designs circuit and layout are developed concurrently, and
thereviewsfordetaileddesignandlayoutphasesmaybeheldtogether.
c.
ForFPGAsandanalogdesigns,acombinedDDRandCDRmeetingmay
bejustified.
NOTE
d.
In these cases also the corresponding output

reportscanbemergedtogether.
Thescriptsusedforanautomaticandrepeatablegenerationshallbepart
ofthedesigndatabase.
NOTE1 Themainoutputofthedetaileddesignisadesign
database, which contains, or allows an automatic
andrepeatablegenerationoftheabovementioned
inputstothelayout.
NOTE2 The scripts defined for this generation are an
essentialpartofthedetaileddesign,
5.5.3
Design entry
a.
During the design entry the following tasks shall be performed and
documentedinadesignentryreport.
b.
Use the agreed design tools as specified in the ADP (see clause 5.3.4).
Checktheirmaintenancestatus.Considerknownbugs,existingpatches,
preventiveandworkaroundmeasures.
c.
Implement the specified test concept during design entry and synthesis
(e.g. scan paths, DFT logic, measurement points, test busses and
boundaryscan(JTAG,seeIEEE1149.1).
d.
Implement the specified radiation hardening concept by design and

duringsynthesis.
e.
Continuouslyverifytheresultsbytheappropriatemethods,asspecified
intheverificationplan.
f.
Determineapinoutandbondingschemewithparticularattentiontothe
technicalconstraints.
NOTE
For example, power supply pin definition and

bondabilityissues.
g.
SelectbuffersaccordingtotheI/OrequirementsdefinedintheASICand
FPGArequirementsspecification.
h.
Establishorrefinethefloorplan.
NOTE
26
ECSSQST6002C
31July2008
5.5.4
Netlist generation
NOTE
Inthisstep,thesourcedescriptionofthedesignis
translated into the netlist, and any other
information required for the layout generation,
such as floorplan or placement information and
constraintsfortimingdrivenlayoutisgenerated.
a.
Enough iterations between design entry, netlist and layout generation

shallbeperformedinordertoaccomplishthedesignrequirements.
b.
Iterationsbacktothearchitecturaldesignshallbeavoided.
c.
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
verifiedagain.
d.
inanetlistgenerationreport:
1.
Considertherequiredderatingfactors;
2.
Ensurethattheappropriatelibrarycellsareusedastofulfilallthe
requirements collected in the ASIC and FPGA requirements
specification;
3.
Selectorgenerateappropriatemodelsforparasitism(e.g.wireload
models);
NOTE
4.
Performadesignparametercentring;
NOTE
ThisisonlyapplicableforanalogASICdesigns.
5.
Ensurethattheintendedoperating(process,voltage,temperature)
and environment (radiation) conditions are used during the
translationandverificationexercise;
6.
If synthesis tools are used, generate scripts which allow

performing the fully automatic prelayout netlist generation in a
repeatableway;
7.
Ensurethatthesescripts,beingpartoftheinputstothedesign,are
compliant to the general requirements for e.g. documentation,
commentingandversioncontrol;
8.
Specify timing constraints, and supplier or manufacturerspecific

designrules;
9.
Consideroverconstrainingtoanticipateparasiticeffects.
27
ECSSQST6002C
31July2008
5.5.5
a.
Netlist verification
inanetlistverificationreport:
1.
Verifythenetlistaccordingtotheverificationplan;
2.
Verifytheestimateddataforthelayoutparasiticsanddelays;
3.
Performgatelevelsimulations,usingthecompletetestsuitefrom
the architectural design, or an equivalent set of methods, such as
formalverificationandstatictiminganalysis;
NOTE
ThisisnotapplicableforanalogASICdesigns.
4.
Verify key parameters, such as bias voltages, operating point,

frequencies, bandwidth, matching, sparameters, noise, dynamic
andlinearrangesandshapingtimes;
5.
Performafunctionalverification,includingtheinterfaces.
NOTE
6.
Ifacompletesimulationofallmodes(includingtestmodes)attop
level cannot be performed (e.g. due to runtime restrictions),
simulatearepresentativesubset;
7.
Verifybyanextrapolatinganalysis,thenotsimulatedcases;
8.
Verify that the specified test concept isimplemented through e.g.

scanpaths,DFTlogic,measurementpointsandtestbusses;
9.
Verify that the radiationhardening concept is successfully

included in the netlist. Consider e.g. netlist inspection and SEU
injectionsimulations;
10.
Verifythatthespecifiedpowerconsumptionisrespected;
11.
Update relevant parameters in the preliminary data sheet

accordingtotheresultsobtainedduringtheverification;
12.
If production tests or a pre and post burnin test are planned,

generate the test vectors and verify the requirements for fault
coverage;
13.
ForIPcoresandmacrocells:includethecorestestpatternsinthe
overallASICstestprogrammes;
14.
Verify, that the prelayout supplier or manufacturer design rules

aremetandassesstherelevanceofviolations;
NOTE
15.
Performaparametersensitivityanalysis;
NOTE
28
ECSSQST6002C
31July2008
5.5.6
a.
Updated data sheet
The supplier shall update the data sheet to incorporate the new
establishedinformationonforinstancepinoutandestimatedtiming.
NOTE
5.5.7
ForfurtherdetailsseeAnnexG.
Detailed design review
a.
The detailed design phase shall be concluded by the detailed design

review(DDR)meeting(seeclause6.2).
b.
c.
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
alongwiththecorrespondingjustificationsinalevelofdetailthatallow
toproceedwiththelayout.
d.
Thisverificationshallincludeasaminimum:
1.
Circuit implementation shows details of the implementation,

whichwerenotspecifiedduringarchitecturaldesign;
2.
Description of implemented testability and production test

methodsincludingtheachievedfaultcoveragefiguresobtained;
3.
Descriptionofimplementedradiationhardeningmeasures;
4.
Allverificationresults;
5.
Descriptionofcellsspeciallydevelopedforthedesign;
6.
Configuration and modifications applied to IP cores used in the

design;
7.
List of items with name and format provided to the foundry (i.e.
netlist,stimulifilesforproductiontestandconstraintsfiles);
NOTE
8.
Description of the design database, including the file structure,

naming conventions, version control labels, netlist generation
methodsandconstraints;
9.
AlltoolsandASIClibrariesactuallyusedduringtheentiredesign
development, including the versions and operating platforms
used;
10.
Problemsencounteredwithdesigntoolsandtheirworkarounds.
e.
procedureswereapplied;
f.
The reviewers shall check that the outputs are in conformance to the
requirementsfixedduringthedefinitionphase;
g.
In particular, when the layout is performed by another company

(foundry), the reviewers shall assess the specific foundry requirements
(netlistsignoffcriteria).
29
ECSSQST6002C
31July2008
EXPECTEDOUTPUTS:
5.6
a.
b.
c.
d.
e.
Designentryreport;
Netlistgenerationreport;
Netlistverificationreport;
Updateddatasheetwithpinout;
Updateddesigndatabase,containing:
1. Prelayoutnetlist;
2. Constraintsforlayout(i.e.floorplanandconstraintsfortiming
drivenlayout)asdefinedintheADP;
3. Testvectorsforproductiontest;
f. MoMofDDR.
Layout
5.6.1
a.
Thelayoutshallgeneratetheplacementandroutinginformationtomeet
thedesignrules,timingandotherconstraints.
b.
In addition, netlist optimization by local resynthesis or physical

synthesisshallbeapplied.
NOTE
5.6.2
a.
This provides reliable information about loads

and coupling capacitors and the final design
rule check that assures a verified netlist which
canbeforwardedtothefoundry.
Layout generation
inalayoutgenerationreport:
1.
finalizethefloorplanofthechip;
NOTE
2.
perform place and route (P&R) taking into account all layout
constraints;
3.
perform netlist optimizations (see clause 5.6.1) for timing and

designrulesifnecessary;
NOTE
ThisisonlyapplicablefordigitalASICdesigns.
4.
generatethepowerdistribution;
5.
generatetheclockdistribution(clocktreeandbuffers);
NOTE
ThisisnotapplicableforanalogASICdesigns.
6.
insert core and pad ring power distribution and possibly

additionaltestpadsinthecircuit;
7.
determinethediesize;
NOTE
30
ECSSQST6002C
31July2008
8.
generate the bonding diagram respecting bonding and package

constraints;
NOTE
9.
5.6.3
a.
generate the input data for mask or programming file generation

(IDMP).
Layout verification
inalayoutverificationreport:
1.
layoutdesignrulecheck(DRC);
2.
electricalrulecheck(ERC),checkcrosstalksensitivity,ifrequired
bycustomer;
3.
extractanetlistfromthelayoutgivenintermsofIDMP;
4.
verify that the gatelevel netlist is consistent with the layout by

performing a layout versus schematic (LVS) comparison, i.e. a
netlist comparison check (NCC) between the postlayout netlist
andthelayout(IDMP)extractednetlist;
5.
verify that the postlayout netlist is consistent in terms of

functionalitywith the prelayout netlist by simulation andformal
methods;
6.
extracttheparasiticinformation;
NOTE
7.
perform comprehensive postlayout verification according to the

verificationplan;
NOTE
8.
This delivers capacitance, resistance and

inductivity values (only deep submicron
technology), from which the actual delays are
calculatedfordigitaldesigns.
Thisismostlyaccomplishedbybackannotated
simulationsandtiminganalysis
checktheresultingclockskewandlatency;
NOTE
9.
checkrelevanttimingofI/Os;
10.
checkthepowerdistributiononthechip;
NOTE
11.
perform transition check and load check on the nets inside the
ASIC;
12.
characterizeASICandFPGAtimingperformances,
NOTE
For example: max clock frequency, clock duty

cycle, setup and hold times for all inputs and
propagationdelaysforalloutputs.
31
ECSSQST6002C
31July2008
5.6.4
a.
Thesuppliershallestablishandmaintainadesignvalidationplan(DVP)
inconformancewiththeDRDinAnnexF.
5.6.5
a.
Design validation plan
Updated data sheet
The suppliershall update the parameters in the data sheet according to

theresultsobtainedduringthelayoutverification.
NOTE
5.6.6
a.
ForfurtherdetailsseeAnnexG.
Draft detail specification
Based on the information collected in the design documentation a draft

detailspecificationshallbeestablishedinconformancewiththeDRDin
AnnexH.
5.6.7
Critical design review
a.
Thelayoutphaseshallbeconcludedbythecriticaldesignreview(CDR)
meeting(see6.2).
b.
c.
Thelayoutdocumentation(see7.3.6)togetherwiththedocumentationof
previous development phases completely documents the progress and
decisionsmadeduringthelayoutshallbechecked.
d.
Asaminimum,thereviewofthedocumentationatCDRshalladdress:
1.
Postlayout clock distribution tree and clock skew and latency

analysis;
2.
Postlayoutverificationresultsandanalysisoftimingmargins;
3.
Results from all layout checks (e.g., DRC, ERC, LVS and NCC)
Any violation of or deviations from the design rules and
justifications.
e.
procedureshavebeenapplied.
f.
The reviewers shall check that the outputs are in conformance to the
requirementsfixedduringthedefinitionphase.
g.
InthecasewherenoDDRwasheldafterthedetaileddesignphase,the
reviewersshallcheckthattheCDRencompassesalsoallreviewitemsof
theDDR.
h.
Thereviewersshallcheckthatpreventivemeasuresorcontingencyplans
existforallidentifiedriskitemsandthattheriskanalysedcanbetaken
forstartingthePrototypeImplementation.
EXPECTEDOUTPUTS:
a. Layoutgenerationreport;
b. Layoutverificationreport;
32
ECSSQST6002C
31July2008
c. Designvalidationplan;
d. Updateddatasheet;
e. Updateddesigndatabase,containing:
1. Postlayoutnetlistintheagreedformatdependingonthe
targetedtechnologicalapproach(GDSII,FPGAP&Rfilesor
other);
2. Correspondingparasiticinformation;
f. MoMofCDR.
5.7
Prototype implementation
5.7.1
Introduction
In this phase chips are manufactured and packaged, or FPGAs programmed,

andtheprototypesaretested.
5.7.2
Production and test

NOTE
Thetermproductionreferstochipmanufacturing
and packaging, or FPGA programming, whatever
is applicable. The phase is concluded by the
deliveryofthetesteddevices.
a.
Asaminimum,thefollowingtasksasdescribedin5.7.2bupto5.7.2jshall
beperformedanddocumentedintheproductiontestreport.
b.
The package shall be the same as for flight devices, if required by the
customer.
c.
The mask generation and verification shall be performed under the

foundrysconfigurationcontrolsystem.
NOTE
d.
The committed number of prototypes shall be produced and delivered,

sothatdesignvalidationcanbeperformed.
e.
The production test shall be performed on 100 % of the delivered

prototypes,usingthetestvectorsgeneratedduringthepreviousphases.
f.
The production test shall demonstrate that the device was produced
correctly.
NOTE
g.
The correctness of the FPGA programming shall be verified (checksum

test).
NOTE
ThisisonlyapplicableforFPGAdesigns.
h.
The tested parameters and conditions shall be according to the draft

detailspecification(seeclause7.4.3).
i.
Test reports shall be generated and delivered, documenting the

measuredparameters.
33
ECSSQST6002C
31July2008
j.
Testerlogfilesshallbedeliveredinelectronicformat.
EXPECTEDOUTPUTS:
5.8
a. Agreednumberoftesteddevices(ASICsorFPGAs);
b. Productiontestresultsandreports;[notapplicableforFPGA
designs];
c. Burninoranyotherproductiontestresults,specificationsand
patterns.
Design validation and release

5.8.1
Design validation
a.
Thedesignvalidationshallbeperformedtoconfirmtheachievementof
allfunctional,performance,interfaceandcompatibilityrequirements.
b.
Asaminimum,thefollowingtasksshallbeperformedanddocumented
inavalidationreport:
1.
carryoutthevalidationaccordingtheestablishedvalidationplan;
2.
designandbuildthetestsetuporsystembreadboardinorderto
representarealisticsystemapplication;
3.
use the breadboard to perform validation tests that cover full

functionalityandalloperatingmodesandconditionsofthedevice;
4.
specify,designandexecutespecificburninorotherscreeningtests
for the later test of the FM parts; if agreed by the business
agreement;
5.
document scope, sequences, setup and results of the validation

testsinthevalidationreport;
NOTE
6.
c.
The validation report becomes part of the design

validationdocumentation.
Comparespecifiedparameterswithmeasuredparameters.
The validation report shall be made available to the foundry and the
designhouse.
5.8.2
Radiation test performance
a.
The device prototypes shall undergo radiation testing according to the

requirements of the project, if the required hardening level is not yet
demonstratedforthetechnologyinvolved.
b.
Radiation testing shall be performed according to the established

radiation verification plan included in the design validation plan and
documentedinaradiationtestreport.
34
ECSSQST6002C
31July2008
5.8.3
Design release and FM production

preparation
a.
For the design release and FM production preparation, the tasks, as

describedin5.8.3bto5.8.3h,shallbeperformedanddocumentedinthe
releasereport.
b.
License agreements for the intellectual property (the design itself and
thirdpartyIPcores)containedinthedeviceshallbeestablishedtocover
thewholelifetime.
c.
The supplier shall ensure technical support of the device during the
lifetimeoftheproduct.
d.
Thiscanbeaccomplishedthroughaknowhowtransferfromthedesign
housetothefoundryorathirdparty,orbythedesignhouseitself.
e.
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.
f.
In the case of using nonQML manufacturer or foundry, an evaluation

programme(inconformancewithECSSQST60)shallbeperformedthat
includeasagreedbythecustomerthefollowingactivities:
1.
manufacturerevaluation;
2.
constructionalanalysis;
3.
evaluationtesting.
g.
On completion of the evaluation programme additional data such as

reliabilityandradiationdatashallbeavailableensuringthatthemission
requirementscanbemet.
h.
ThesuppliershallassesstheriskinvolvedfortheFMproduction.
5.8.4
a.
Experience summary report
The executive summary report shall be completed in conformance with

theDRDinAnnexI.
5.8.5
Final versions of application and

procurement documents
a.
Thedetailspecification,inconformancewithAnnexHshallbeupdated
basedonthevalidationtestresults.
b.
Ifrequestedbythecustomer,thedatasheet,inconformancewithAnnex
Gshallbeupdatedbasedonthevalidationtestresults.
c.
The data sheet, eventually transformed to the foundry specific format,

shallbeavailableduringthedevicelifetime.
d.
Anapplicationnote(seeclause7.4.2)shallbeestablished.
35
ECSSQST6002C
31July2008
5.8.6
Qualification and acceptance review
a.
Thedesignvalidationphaseshallbeconcludedbythequalificationand
acceptancereview(QR/AR)meeting(seeclause6.2).
b.
c.
The reviewer shall check that the design validation documentation (see
clause 7.3.6) together with the documentation of previous development
phasesiscomplete.
d.
The reviewer shall check that the device achieves functional,

performance, interface and compatibility characteristics satisfying the
ASICandFPGArequirementsspecification.
e.
Thereviewershallcheckthattheplannedmeasures,tools,methodsand
procedureswereapplied.
f.
Thereviewershallcheckthatpreventivemeasuresorcontingencyplans
existforallidentifiedriskitemsandthattheriskofFMproductioncan
betaken.
EXPECTEDOUTPUTS:
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
Validationreport;
Radiationtestreport(ifapplicable);
Releasereport;
Experiencesummaryreport;
Finaldatasheet;
Finaldetailspecification;
Applicationnote;
MoMofQR/AR;
Validationbreadboard;
BurninorscreeningtestboardsforFMparts.
36
ECSSQST6002C
31July2008
6
Quality assurance system
6.1
6.2
General
a.
ECSSQST20clauseQAstatusreportingshallapply.
b.
ECSSQST30clausecriticalityclassificationoffunctionsandproducts
shallapply.
c.
ECSSQST60 clauses 4.5, 5.5 and 6.5 (components quality assurance)

shallapply.
d.
The objective of the quality assurance system is to ensure the

development of reliable, manufacturable, testable and reproducible,
customdesignedcomponentsforspaceapplication.
e.
Thetoolstobeusedshallbespecifiedandapprovedbythecustomer.
f.
All technology independent CAD tools to be employed during the

developmentshallbematureandfitfortheirpurpose.
g.
All technology dependent CAD tools shall be used as approved and

supportedbytheselectedmanufacturer.
h.
Preference shall be given to the use of established international

standards,suchasVHDLasdefinedinIEEE6169111andEDIF.
Review meetings
a.
Thesuppliershallscheduleandconductdesignreviewsinconformance
withECSSMST1001.
b.
Design reviews shall be defined along with the criteria for their
successful completion in the ASIC and FPGA development plan (see
clause5.3.4).
c.
Representation, for design and quality assurance, from all relevant

organizations (customer, system supplier, design house and foundry)
shallbeensured.
d.
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.
37
ECSSQST6002C
31July2008
e.
Thefollowingreviewsshallbeperformed:
1.
Systemrequirementsreview(SRR)
NOTE
2.
Thisreviewresultsintheauthorizationtostart
the architectural design. The outputs reviewed
and the items checked are detailed in clause
5.3.5.
Preliminarydesignreview(PDR)
NOTE
3.
PDR results in the authorization to start with

the detailed design. The outputs reviewed and
theitemscheckedaredetailedinclause5.4.6.
Detaileddesignreview(DDR)(ifapplicable)
NOTE1 DDR results in the authorization to proceed
withthelayout.Theoutputsreviewedandthe
itemscheckedaredetailedinclause5.5.7.
NOTE2 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
CDRmeeting.
4.
Criticaldesignreview(CDR)
NOTE
5.
Qualificationandacceptancereview(QR/AR)
NOTE
6.
f.
CDR results in the approval of design and

layout and the release for prototype
implementation.Theoutputsreviewedandthe
itemscheckedaredetailedinclause5.6.7.
QR/AR results in the final acceptance of the

design and the release for FM production. The
outputs reviewed and the items checked are
detailedinclause5.8.6.
Additionaldesignreviewsasagreedbythesupplier.
Direct or delegated customer participation and under the responsibility

of the supplier, manufacturer or foundry participation for CDR and
QR/ARshallbemandatory.
NOTE1 The decision on a successful completion of a
review meeting can only be achieved by
consentofallparties.
NOTE2 A review identifying a limited number of only
minor discrepancies can be completed after
successful implementation of the corrective
actionsdefinedduringthereview.
g.
A review failing major acceptance criteria and resulting in a design

iterationshallberepeatedinfull.
38
ECSSQST6002C
31July2008
h.
Thecriteriaforasuccessfulreviewmeetingshallbedefinedpriortothe
relevantmeeting.
NOTE
6.3
These criteria can be defined on the preceding

reviewmeeting.
i.
Allreviewmeetingsshallbeminuted.
j.
The MoMs of the review meetings shall be added to the management

documentation.
Risk assessment and risk management

a.
The design risk for the timely and successful completion of the
development activity shall be assessed according to the items listed in
clause5.3.3.2.
b.
Riskassessmentshallbeperformedconcurrentlytothedesignactivity.
c.
Extraordinary risks shall be covered by a contingency plan identifying

alternativeorbackupsolutions.
d.
A check of the risk mitigation activities shall be a major item of the

agendaofeveryreviewmeeting.
39
ECSSQST6002C
31July2008
7
Development documentation
7.1
General
a.
At all stages of the ASIC and FPGA development, the supplier shall
produce, maintain, control and archive all related documentation as
definedanddetailedinthefollowingclauses.
b.
The documentation shall be well structured and easily readable, so that

thedesigncanbeunderstoodbyotherASICandFPGAdesignersofthe
supplierandmanufacturernotpermanentlyinvolvedinthedesignwork.
NOTE
c.
One consistent language shall be used throughout the documentation,

preferablyEnglish.
d.
Thedocumentationshallbeconsistent,e.g.thesameitemhavethesame
nameinalldocumentation.
e.
Block diagrams, control flow charts, timing diagrams and other figures
shallbeintroducedwherebeneficialfortheunderstandingofthetext.
f.
Everytimeanupdateddocumentisdelivered,itshallincludeadetailed
changelist,andallsignificantchangesmarkedusingachangebarinthe
margin.
g.
If a document is delivered before being complete, each page with

incompleteinformationshallbeclearlymarked.
NOTE
h.
7.2
For example, names of signals and blocks are

chosentoindicatetheirfunction.
Some of the information listed is better delivered

separately or in appendices, such as layout plots,
gatelevelschematicsandlistsofundetectedfaults.
Alldocumentsshallbearchivedforaminimumperiodoffiveyearsafter
completionofthedevelopmentactivityorasagreedbythecustomer.
Management documentation
a.
The management documentation shall provide the overall strategy for

the development activity including task planning and organization and
approaches,methodsandapplicableprocedures.
NOTE
Themanagementdocumentationalsoincludesthe
status reporting as MoM of the review meetings
40
ECSSQST6002C
31July2008
andanassessmentoftheexperiencegainedduring
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).
7.3
Design documentation
7.3.1
General
7.3.1.1
Purpose
The purpose of the design documentation (DD) is to record the progress

achieved and the decisions made along with the corresponding justifications
duringthedevelopmentphasesofthedevice.
7.3.1.2
Requirements
a.
Alldesigninformationshallbestoredinadesigndatabasebyapplying
the revision control mechanism agreed in the business agreement (see
clause5.1).
b.
All intermediate design data shall be reproducible to assist possible

iterations.
c.
As the design database consists of electronic data that cannot be

reviewed directly, formless reports shall be established that contain a
legibleextractofthedatabase.
d.
Reports that shall be produced during the individual phases of a

developmentactivityaredetailedinclause5.
NOTE1 An example of a suitable filing of this design
documentationisgiveninFigure71.
NOTE2 Inthecasethedesignandlayoutisaconcurrentor
interdigitated activity (e.g. analog and FPGA
design) the corresponding output reports can be
mergedtogether.
41
ECSSQST6002C
31July2008
A/Frequirementsspecification
FeasibilityandRiskAnalysis
DefinitionphaseDocumentation
ArchitectureDefinitionReport
Verification and Optimization
ArchitecturalDesignDocumentation
DesignEntryReport
NetlistGenerationReport
NetlistVerificationReport
DetailedDesignDocumentation
LayoutGenerationReport
LayoutVerificationReport
LayoutDocumentation
ValidationReport
RadiationTestReport(if
applicable)
DesignValidationDocumentation
Figure71:Designdocumentation
42
ECSSQST6002C
31July2008
7.3.2
a.
Definition phase documentation
The definition phase documentation shall consist of the following

contributions:
1.
TheASICandFPGArequirementsspecification(ARS)established
duringthefirstdevelopmentphase.
2.
ARSincludingacompletesetofASICandFPGArequirements,in
conformance with the DRD in Annex C that are settled,
unambiguousandfrozen.
3.
An assessment of the feasibility and risk analysis (FRA) with

regardstothefollowingdrivers:
(a)
consistencyandqualityoftheASICandFPGA,
(b)
system requirements feasibility of the ASIC and FPGA

development,
(c)
estimateoftheriskinvolved.
NOTE
b.
FRAshallcovertheitemsdetailedinclause5.3.3.
7.3.3
a.
Architectural design documentation
The architectural design documentation shall include the following

contributionstothedefinitionphasedocumentation:
1.
The architectural definition report that includes the architecture

brokendowntotheselectedblocks,theirinterfaces,functionality,
algorithmsandinteractionsasspecifiedinclause5.4.2.
2.
The verification and optimization report that provides the

simulations performed, the results received, the tradeoffs found
andtheimplementationchoicesestablished.
NOTE
7.3.4
a.
Thefeasibilityandriskanalysis(FRA)reportisthe
secondpartofthedefinitionphasedocumentation.
Furtherdetailsaregiveninclause5.4.4.
Detailed design documentation
The detailed design documentation shall consist of the following

contributionstothearchitecturaldesigndocumentation:
1.
The design entry report providing all inputs available for the
detaileddesignphaseasdetailedinclause5.5.3.
2.
The netlist generation report describing the work performed and

thedecisionstakentogenerateanetlistasdetailedinclause5.5.4.
3.
The netlist verification report listing all steps of simulation and

verification performed (see clause 5.5.5) together with the
correspondingresults.
43
ECSSQST6002C
31July2008
7.3.5
a.
Thelayoutdocumentationshallconsistofthefollowingcontributionsto
thedetaileddesigndocumentation:
1.
The layout generation report describing the work performed and

thedecisionstakentogeneratelayoutasdetailedinclause5.6.2.
2.
The layout verification report listing all steps of verification

performed (see clause 5.6.3) together with the corresponding
results.
7.3.6
a.
7.4
Layout documentation
Design validation documentation
The design validation documentation shall consist of the following

contributionstothelayoutdocumentation:
1.
Thevalidationreportpresentingthescope,sequences,setupand
resultsofthevalidationtestsperformedasdetailedinclause5.8.1.
2.
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.
3.
The release report summarizing all activities performed to assure

that all necessary prerequisites are fulfilled to start a FM
production(seeclause5.8.3).
Application and procurement documents

7.4.1
a.
Ifrequestedbythecustomer,adatasheetthatdescribesthefunctionality
of the device so it can be used by a board or system designer shall be
establishedinconformancewiththeDRDinAnnexG.
7.4.2
a.
Data sheet
Application note
Ifrequestedbythecustomer,anapplicationnoteshallbeestablishedfor
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
voltagesandconfigurationsignalsshallbeprovided.
44
ECSSQST6002C
31July2008
7.4.3
Detail specification
a.
AlldevicesintendedforuseasFMproductsshallbeprocuredaccording
tocontrolledspecifications.
b.
All new specifications shall be designed to be totally in conformance to

oneoftheexistingEuropeanstandardizationsystems.
c.
New detail specifications shall be established in conformance with the

DRDinAnnexH.
d.
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
identifiedbythemanufacturers.
45
ECSSQST6002C
31July2008
8
Deliverables
8.1
General
a.
Uponrequest,thecustomershallreceivefreeofchargefromthesupplier
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
thedesign.
NOTE
b.
Thequantitytobedeliveredofeachindividualdeliverableitemshallbe
agreedbetweencustomerandsupplieraccordingtotherequirementsof
theactualproject.
c.
Additionalitemsshallbedefinedasnecessary.
d.
Each delivery of a design document shall be accompanied by a written

statementofthestatusofthedeliverableitem.
e.
TheIPrightsstatusshallbereported.
f.
Papercopiesshallbeeasilyreadableandsuitableforsubsequentphoto
copying. Electronic copies shall be submitted via electronic media in an
agreedformatwithagreedcharacteristics.
NOTE
g.
8.2
Thisonlyappliesifsuchadesignkitactuallyexists
forthedesigntoolsavailableatthecustomer.
Searchcapability,printability,usageofhyperlinks,
traceabilityandchangeability.
Photos and layout plots may be part of the documentation only for
promotional information with restricted details, if not specified
elsewhere.
Deliverable items
a.
The list of deliverables defined per the SoW agreed in the business
agreement.shallbeestablished,basedonTableJ1.
NOTE
Table J1 is a guideline for documentation, design

database deliverables and hardware deliverables
thatbecomeavailableduringtheASICandFPGA
development.
46
ECSSQST6002C
31July2008
Annex A (normative)
ASIC and FPGA control plan (ACP) DRD
A.1
DRD identification
A.1.1
Requirement identification and source

document
ThisDRDiscalledbytheECSSQST6002,requirement4.2a.
A.1.2
Purpose and objective
ThepurposeoftheACPistoinitiatetheASICandFPGAdevelopmentsandto
specifytheorganization,managementtools,qualityassurancesystem,strategy,
approachesandproceduresitadopts.
A.2
Expected response
A.2.1
a.
Scope and content
TheACPshallincludeadescriptionofthefollowingitems:
1.
Organizationalstructureandmanagementapproachincludingthe
definition of organizational interfaces between different design
groups and identification of the supplier organization for the
productassuranceoftheASICandFPGAdevelopment;
2.
Role, tasks and responsibilities of product assurance personnel in

conformancewithECSSQST10andECSSQST20;
3.
Management tools to be used for planning (see clause 4.3) and

quality assurance system (see clause 6) of the ASIC and FPGA
developments;
4.
Intendedoverallschedule;
5.
Overall strategy and general approach for the ASIC and FPGA
developments;
6.
Riskmitigationprocedurestobeapplied(seeclause6.3);
47
ECSSQST6002C
31July2008
7.
Requirements on, and system for the control of the foundry and
othersubcontractorsorserviceprovidersinvolvedaccordingtothe
experienceavailablefortherespectivesupplier.
b.
Compliance matrix to the clauses of this standard taking into account

applicabletailoring.
c.
InitiationofthedefinitionphasefortheASICandFPGAdevelopments.
A.2.2
Special remarks
None.
48
ECSSQST6002C
31July2008
Annex B (normative)
ASIC and FPGA development plan (ADP)
DRD
B.1
DRD identification
B.1.1

document
ThisDRDiscalledbytheECSSQST6002,requirement4.3.1a.
B.1.2
ThepurposeoftheADPistoimplementtheproposeddevelopmentstrategyby
identifying all phases of the ASIC and FPGA development with the major
activitiestherein,theprojectexternalinterfacesandconstraints,thedesignflow,
resources (equipment, software and personnel), the allocation of
responsibilities, outputs to be produced and, finally, a schedule with
milestones,decisionpoints,typeandnumberofdesignreviews.
B.2
Expected response
B.2.1
a.
Scope and content
TheADPshallincludethefollowingitems:
1.
NameoftheASICandFPGAanditsbasicfunction;
2.
Referencestothedesigndocumentationandotherapplicableand
referencedocuments;
NOTE
Internal and external standards, procedures or

codingguidelines.
3.
Developmentteamandassignmentofmajorresponsibilities;
4.
The baseline FPGA device or ASIC technology including baseline

radiationhardeningandtestabilityapproach;
5.
Companies involved (foundry, subcontractors, suppliers),

indicating their assigned tasks, technical and administrative
interfaces;
49
ECSSQST6002C
31July2008
6.
Versionsandplatformsoftoolstobeused,includingthefoundry
orspecifictools;
7.
Statementfortheavailabilityofeachdesigntool(atthesiteaswell
asthededicationtotheparticulardevelopment);
8.
Thedesignflow;
NOTE
Design entry, synthesis, simulation and

verification,layout generation and verification,
productiontestsandvalidation.
9.
Identification of a configuration management system in

conformancewithECSSMST40;
10.
Identification of a verification and validation scheme in

conformancewithECSSEST10;
11.
The subdivision of the ASIC and FPGA development into

reasonably sized work packages in conformance with
ECSSMST10;
12.
ThescheduleoftheASICandFPGAdevelopment,withestimated
effortanddurationofeachworkpackageandtheplanneddatesof
milestonesandreviewmeetings;
13.
Identification and full description, including formats, of all

relevant outputs, deliverable or not, to be produced along the
ASICandFPGAdevelopment(documentation,simulationandtest
results, test boards, test samples, source or generated codes and
programs) and measures intended to achieve best design quality
(e.g.HDLcodingconformitytoanappropriatesetofcodingrules).
B.2.2
Special remarks
None.
50
ECSSQST6002C
31July2008
Annex C (normative)
ASIC and FPGA requirements specification
(ARS) DRD
C.1
DRD identification
C.1.1

document
ThisDRDiscalledbytheECSSQST6002,requirements5.3.2band7.3.2a.2.
C.1.2
The purpose of the ASIC and FPGA requirement specifications (ARS) is to

specifyacompletesetoftraceableASICandFPGArequirements.
C.2
Expected response
C.2.1
a.
Scope and content
TheARSshallincludethefollowingitems:
1.
Overall system partitioning, system configurations and operating

modes;
2.
Interfaces of the ASIC and FPGA to the system and

communication protocols to external devices, including memory
mapping;
3.
Operatingfrequencyrange;
4.
Electrical constraints (e.g. voltage and current supply, drive

capabilitiesandexternalload);
5.
Functionalrequirements;
6.
Applicablealgorithms;
7.
Powerupandinitializationstate;
8.
Resetandpowercyclingrequirements;
9.
Errorhandling;
51
ECSSQST6002C
31July2008
10.
Testmodes:systemanddevicetests,ongroundandinflight;
11.
Faultcoveragerequiredatproductiontest;
NOTE
ThisisonlyapplicablefordigitalASICdesigns.
12.
Timingofcriticalsignals;
13.
Radiationenvironmentconstraints;
14.
Thermalenvironmentconstraints;
15.
Powerbudgetanddissipation;
16.
Physical and mechanical constraints: pin assignment, size,

encapsulation;
17.
Reusabilityoradditionalfunctionsforfutureapplications;
18.
Portabilitytodifferentornewertechnologies;
19.
Intellectualpropertyrightsofthedesigntobedeveloped;
20.
Proprietarydesigns(IPcores)tobeusedasbuildingblocksofthe
designtobedeveloped,ifalreadyidentified.
C.2.2
Special remarks
None
52
ECSSQST6002C
31July2008
Annex D (normative)
Feasibility and risk assessment report
(FRA) - DRD
D.1
DRD identification
D.1.1

document
ThisDRDiscalledbytheECSSQST6002,requirement5.3.3.2b.
D.1.2
ThepurposeoftheFRAistoprovideajudgementonthefeasibilityoftheASIC
and FPGA development as defined by the ASIC and FPGA requirements
specification,aswellasanassessmentoftherisksinvolved.
D.2
Expected response
D.2.1
a.
Scope and content
TheFRAshallincludethefollowingitems:
1.
Assurance that the collected ASIC and FPGA requirements are

complete,settledandunambiguous;
2.
MaturityofenvisagedASICorFPGAmanufacturersandpossible
technologies;
3.
Experience and familiarity of engineering resources with the

designtype,tools,technologyandthepotentialfoundries;
4.
Riskofunderestimationofdesignandverificationeffort;
5.
Riskofunderestimationofdebugandrepairefforts;
6.
Risk of overestimation of actual gate capacity and clocking

frequency;
7.
RiskofundeterminedI/Obehaviourduringpowerup.
D.2.2
Special remarks
None.
53
ECSSQST6002C
31July2008
Annex E (normative)
Verification plan (VP) DRD
E.1
DRD identification
E.1.1

document
ThisDRDiscalledbyECSSQST6002,requirements4.3.2aand5.4.3a.
E.1.2
Thepurposeoftheverificationplanistodefinehowthefunctionalityandnon
functional requirements stated in the definition phase documentation are
demonstrated at all levels of modelling, starting from the behavioural level
downtothegatelevel.
E.2
Expected response
E.2.1
a.
Scope and content
TheVPshallincludeadescriptionofthefollowingitems:
1.
InthecaseofcomplexdigitalASICdevelopments,verificationby
FPGAprototypingoremulation;
2.
Requirementsforcodecoverageindigitaldesigns;
3.
Requirements for hardwaresoftware interaction, possibly by

performingcosimulation;
4.
Applicationofcodingrules.
E.2.2
Special remarks
None.
54
ECSSQST6002C
31July2008
Annex F (normative)
Design validation plan (DVP) DRD
F.1
DRD identification
F.1.1

document
ThisDRDiscalledbytheECSSQST6002,requirements4.3.3aand5.6.4a.
F.1.2
Thepurposeofthedesignvalidationplanistospecifythemeasurementsthat
are performed on the prototypes in order to verify that the new implemented
devicescontainthefunctionalityandthecharacteristictheyaredesignedfor.
F.2
Expected response
F.2.1
a.
Scope and content
TheDVPshallincludethefollowingitems:
1.
description and requirements for the test setup or system

breadboard;
2.
operatingmodesandtestconditionsoftheprototypesundertest;
3.
characteristics and functions to be validated and checked against

theASICandFPGArequirementsspecification;
4.
if a radiation test is required by the customer, the corresponding

radiationverificationtestplan.
F.2.2
Special remarks
None.
55
ECSSQST6002C
31July2008
Annex G (normative)
Data sheet DRD
G.1
DRD identification
G.1.1

document
ThisDRDiscalledbyECSSQST6002,requirements5.4.5aand7.4.1a
G.1.2
Thepurposeofthedatasheetistogatheralltechnicaldataobtainedfromthe
architecturaldesignuntilthefinaldesignvalidationandrelease.Itisusedasan
inputforapplicationandprocurement.
G.2
Expected response
G.2.1
a.
Scope and content
Each page shall contain the device name and number and the date of
issue.
NOTE
The first page contain a summary of the device

functionality, a block diagram and short list of
features, such as operating frequency, technology
andthefoundryaddress.
b.
Allcharacteristicsandlimitationsintroducedduringthedesignshallbe
described,suchasdetailedinterfacedescriptions,registerdefinitionsand
memorymaps.
c.
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,includinganapplicationblockdiagram.
d.
Thefullfunctionalityandalloperatingmodesshallbespecifiedindetail.
e.
Allsignal interfaces shallbe describedin detail including for instance a

descriptionofallsignals,testandpowerpins,specifyinge.g.theusageof
thesignalsandthesignalpolarity.
f.
Thesignaldescriptionsshallbegroupedaccordingtotheirfunction.
56
ECSSQST6002C
31July2008
g.
All electricaland mechanical datashall be specified, together with their

relevant applicable conditions (e.g. temperature and capacitive load),
including:
1.
Absolute maximum ratings, including storage temperature,

operating temperature, supply voltage, maximum input current
for any pin, total dose, single event upset, latchup, electrostatic
dischargeandreliabilityfigures;
2.
DC parameters, including voltage levels, leakage currents, pin

capacitancesandoutputcurrents;
3.
Static and dynamic (per MHz) power dissipation, allowing the

power consumption at lower operating frequencies to be
calculated,ifrepresentative;
4.
ACparameters,includinge.g.setupandholdtimes,cycleperiods,
output delays and tristate delays, together with waveform
diagrams;
5.
Evidences that timing parameters relate to the relevant reference

signaledges;
6.
Package description, including pin assignment, package figure

withpinnumbersandpreferablysignalnames,andamechanical
drawingforthepackagedimensionsincludinginformationonthe
thermal characteristic of the package such as wall thickness,
thermalcoefficientofmaterialorpackage.
h.
Apreliminarydatasheetshallcontainallpartsofafinaldatasheet,with
thesamelevelofdetail.
i.
Whendatadoesnotexist,estimatesshallbeusedandclearlyindicatedto
beestimates.
G.2.2
Special remarks
None.
57
ECSSQST6002C
31July2008
Annex H (normative)
Detail specification (DS) DRD
H.1
DRD identification
H.1.1

document
ThisDRDiscalledbyECSSQST6002,requirements5.6.6aand7.4.3c.
H.1.2
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
specificationisestablished)tothedesignvalidationandreleaseactivity(atthe
endofwhichthefinaldetailspecificationisproduced).Itisusedasaninputfor
applicationandprocurement.
H.2
Expected response
H.2.1
a.
Scope and content
Thefinaldetailspecificationshallincludethefollowingitems:
1.
relevantelectricalandmechanicalparameters;
2.
screening,burnin,andacceptancerequirements;
3.
deviationsfromthegenericspecification;
4.
documentationanddatarequirements;
5.
deltalimits,whenapplicable;
6.
criteriaforpercentdefectiveallowable;
7.
lotacceptancetestsorqualityconformanceinspections;
8.
marking;
9.
storagerequirements;
10.
requirementsforlothomogeneity;
11.
serialization,whenapplicable;
58
ECSSQST6002C
31July2008
12.
protectivepackagingandhandlingrequirements;
13.
radiationverificationtestingrequirements,whenapplicable.
H.2.2
Special remarks
None.
59
ECSSQST6002C
31July2008
Annex I (normative)
Experience summary report DRD
I.1
DRD identification
I.1.1

document
ThisDRDiscalledbyECSSQST6002,requirement4.4aand5.8.4a.
I.1.2
Thepurposeoftheexperiencesummaryreportistocollectandtoevaluateany
relevantinformationresultingfromtheexperiencegainedduringtheexecution
oftheASICandFPGAprocurementprogramme.
I.2
Expected response
I.2.1
a.
Scope and content

Theexperiencesummaryreportshallincludethefollowingitems:
1.
Asummaryofthemaindesignobjectivesandconstraints;
2.
Anassessmentoftheactualdevelopmentprogrammewithrespect
totheoriginalADP;
3.
Controls,schedule,designiterationsandcommunications;
4.
AnassessmentofEDAtoolsuitabilityandperformance;
5.
Anassessmentofthemanufacturersupport;
6.
Apresentationofnonconformancesandproblemareas;
7.
In the case of usage of existing IP cores, experiences gained in

termsofproductqualityandsuitability;
8.
synthesis results, modelling, test stimuli, documentation,

applicationsupportandproblemsencountered;
9.
Recommendationsandlessonslearned.
I.2.2
Special remarks
None.
60
ECSSQST6002C
31July2008
Annex J (informative)
Document requirements list and
configuration items to be delivered
TableJ1:DeliverablesoftheASICandFPGAdevelopment
Development
phase
Definition
phase
Architectural
design
Documentation
Hardware
AnnexA
Designdatabase
containing:
Simulationmodels
A/Frequirementsspecification(ARS)
AnnexC
Feasibilityandriskanalysis(FRA)
AnnexD
A/Fdevelopmentplan(ADP)
AnnexB
MoMofSRR
Architecturedefinitionreport
Verificationplan
AnnexE
Architectureverificationand
optimizationreport
MoMofPDR
Detaileddesign Designentryreport
Verificationresults
AnnexG
Updateddesign
databasecontaining:
Netlistgenerationreport
Netlistverificationreport
Updateddatasheet
AnnexG
Constraintsforlayout
MoMofDDR
Testvectorsfor
production
Layoutgenerationreport
Layoutverificationreport
Designvalidationplan(DVP)
AnnexF
Updateddatasheet
AnnexG
Draftdetailspecification
AnnexH
MoMofCDR
Prototype
Productiontestresultsandreports
implementation
Burninoranyotherproductiontest
results,specification,pattern
Design
validation
andrelease
Validationreport
Radiationtestreport
Releasereport
Finaldatasheet
AnnexG
Finaldetailspecification
AnnexH
Applicationnote
Experiencesummaryreport
AnnexI
MoMofQR/AR
Software
A/Fcontrolplan(ACP)
Preliminarydatasheet
Layout
DRD
Prelayoutnetlist
Updateddesign
databasecontaining:
Postlayoutnetlist
Corresponding
parasiticinformation
Agreednumberof
testeddevices
(ASICsorFPGAs)
Validation
breadboard
Burninorscreening
testboardsforFM
parts
61
ECSSQST6002C
31July2008
Bibliography
ECSSSST00
ECSSsystemDescription,implementationand
generalrequirements
IEEE6169111
BehaviourallanguagesPart11:VHDLlanguage
referencemanual
IEEE1149.1
Standard Test Access Port and BoundaryScan

Architecture
62

Ecss Q ST 60 02C

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ecss Q ST 60 02C

Caricato da

Copyright:

Formati disponibili

ECSS-Q-ST-60-02C

Terms from other standards ..................................................................................... 10

Terms specific to the present standard .................................................................... 10

Abbreviated terms .................................................................................................... 13

4 ASIC and FPGA programme management .........................................................15

ASIC and FPGA control plan.................................................................................... 15

Management planning tools ..................................................................................... 16

ASIC and FPGA development plan ............................................................ 16

Verification plan .......................................................................................... 16

Design validation plan ................................................................................ 16

Experience summary report ..................................................................................... 16

5 ASIC and FPGA engineering ...............................................................................17

Feasibility and risk assessment.................................................................. 20

ASIC and FPGA development plan ............................................................ 21

System requirements review ...................................................................... 21

Architecture definition ................................................................................. 23

Verification plan .......................................................................................... 24

Architecture verification and optimization ................................................... 24

Preliminary data sheet................................................................................ 25

Preliminary design review........................................................................... 25

Design entry ............................................................................................... 26

Netlist verification ....................................................................................... 28

Updated data sheet .................................................................................... 29

Detailed design review ............................................................................... 29

Design validation plan ................................................................................ 32

Updated data sheet .................................................................................... 32

Draft detail specification ............................................................................. 32

Critical design review.................................................................................. 32

Production and test..................................................................................... 33

Design validation and release .................................................................................. 34

Design validation ........................................................................................ 34

Radiation test performance ........................................................................ 34

Design release and FM production preparation ......................................... 35

Experience summary report ....................................................................... 35

Final versions of application and procurement documents ........................ 35

Qualification and acceptance review .......................................................... 36

6 Quality assurance system ...................................................................................37

Review meetings ...................................................................................................... 37

Risk assessment and risk management................................................................... 39

7 Development documentation ..............................................................................40

Management documentation .................................................................................... 40

Definition phase documentation ................................................................. 43

Architectural design documentation ........................................................... 43

Detailed design documentation .................................................................. 43

Layout documentation ................................................................................ 44

Design validation documentation................................................................ 44

Application and procurement documents ................................................................. 44

Data sheet .................................................................................................. 44

Application note .......................................................................................... 44

Deliverable items ...................................................................................................... 46

Annex A (normative) ASIC and FPGA control plan (ACP) DRD........................47

Terms from other standards

Terms specific to the present standard

application specific integrated circuit (ASIC)

Design tools and their description, cell libraries,

application specific standard products (ASSP)

ASSPs are most often are provided with a VHDL

abstract graphical presentation of interconnected named boxes (blocks)

A data sheet can include, for instance, a block

design for test (DFT) structure

Definition phase, architectural design, detailed

measure expressed as a percentage of the proportion of actually detectable

field programmable gate array (FPGA)