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

ECSSQST6002C31July2008

Foreword

This Standard is one of the series of ECSS Standards intended to be applied together for themanagement, engineering and product assurance in space projects and applications. ECSS is acooperative effort of the European SpaceAgency, national space agencies and European industryassociationsforthepurposeofdevelopingandmaintainingcommonstandards.RequirementsinthisStandardaredefinedintermsofwhatshallbeaccomplished,ratherthanintermsofhowtoorganizeandperform thenecessarywork.Thisallows existingorganizational structures andmethods tobeappliedwheretheyareeffective,andforthestructuresandmethodstoevolveasnecessarywithoutrewritingthestandards.

This Standard has beenprepared by theECSSQST6002WorkingGroup, reviewed by theECSSExecutiveSecretariatandapprovedbytheECSSTechnicalAuthority.

Disclaimer

ECSSdoesnotprovideanywarrantywhatsoever,whetherexpressed,implied,orstatutory,including,butnotlimitedto,anywarrantyofmerchantabilityorfitnessforaparticularpurposeoranywarrantythat the contents of the item are errorfree. In no respect shall ECSS incur any liability for anydamages,including,butnotlimitedto,direct,indirect,special,orconsequentialdamagesarisingoutof,resulting from,or inanywayconnected to theuseof thisStandard,whetherornotbaseduponwarranty,businessagreement,tort,orotherwise;whetherornotinjurywassustainedbypersonsorpropertyorotherwise;andwhetherornotlosswassustainedfrom,oraroseoutof,theresultsof,theitem,oranyservicesthatmaybeprovidedbyECSS.

Publishedby: ESARequirementsandStandardsDivision ESTEC, P.O. Box 299, 2200 AG Noordwijk The Netherlands Copyright: 2008 by the European Space Agency for the members of ECSS

2


Change log

ECSSQ6002A

17July2008

Firstissue

ECSSQ6002B Neverissued

ECSSQST6002C

31July2008

Secondissue

ChangestoECSSQ6002Aare:

1 Alldocumentsrequirementshavebeenmovedinnormativeannexes.ThefollowingDRDshavebeencreated:ACP,ADP,ARS,FRA,VP,DVP,ES,DataSheetandDetailSpecification

2 SomeeditorialconversionshavebeendoneforcompliancetoECSSDraftingrulesforStandard.

3


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.3.1 ASIC and FPGA development plan ............................................................16 4.3.2 Verification plan ..........................................................................................16 4.3.3 Design validation plan ................................................................................16

4.4 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

4


5.4 Architectural design..................................................................................................23 5.4.1 General requirements.................................................................................23 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

5.5 Detailed design.........................................................................................................25 5.5.1 Introduction.................................................................................................25 5.5.2 General requirements.................................................................................26 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

5.6 Layout.......................................................................................................................30 5.6.1 General requirements.................................................................................30 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

5.7 Prototype implementation.........................................................................................33 5.7.1 Introduction.................................................................................................33 5.7.2 Production and test.....................................................................................33

5.8 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

5


7 Development documentation ..............................................................................40 7.1 General.....................................................................................................................40 7.2 Management documentation....................................................................................40 7.3 Design documentation..............................................................................................41

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

7.4 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


Introduction

Theaddedresponsibilitiesofdevelopingcustomdesigneddevices,asopposedtousingofftheshelfcomponents,makecertainmanagementactivitiescrucialtothesuccessoftheprocurementprogramme.Thiswasalreadyconsideredbythe applicable standard for Space product assurance EEE components,ECSSQST60 that classifies custom designed devices, such as ASICcomponents,underSpecific components, forwhichparticular requirementsareapplicable.

The supplier accepts requirements for the development of custom designedcomponentswithintheboundariesofthisstandardbasedontherequirementsofthesystemanditselements,andtakesintoconsiderationtheoperationalandenvironmentalrequirementsoftheprogramme.

The supplier implements those requirements into a systemwhich enables tocontrolforinstancethetechnologyselection,design,synthesisandsimulation,layoutanddesignvalidation inaschedulecompatiblewithhis requirements,andinacostefficientway.

7


1 Scope

This Standard defines a comprehensive set of requirements for the userdevelopment of digital, analog and mixed analogdigital custom designedintegratedcircuits,suchasapplicationspecific integratedcircuits (ASICs)andfield programmable gate arrays (FPGAs). The user development includes allactivities beginning with setting initial requirements and ending with thevalidationandreleaseofprototypedevices.

ThisStandardisaimedatensuringthatthecustomdesignedcomponentsusedin space projects meet their requirements in terms of functionality, quality,reliability, schedule and cost. The support of appropriate planning and riskmanagementisessentialtoensurethateachstageofthedevelopmentactivityisconsolidated before starting the subsequent one and to minimize or avoidadditional iterations. For the development of standard devices, such asapplicationspecificstandardproducts(ASSPs)andIPcores,anddeviceswhichimplementsafetyrelatedapplications,additionalrequirementscanbeincludedwhicharenotinthescopeofthisdocument.

The principal clauses of this Standard correspond to the main concurrentactivitiesofacircuitdevelopmentprogramme.Theseinclude:

ASICandFPGAprogrammemanagement, ASICandFPGAengineering, ASICandFPGAqualityassurance.Theprovisionsofthisdocumentapplytoallactorsinvolvedinalllevelsintherealizationofspacesegmenthardwareanditsinterfaces.

Thisstandardmaybetailoredforthespecificcharacteristicsandconstraintsofaspaceproject,inaccordancewithECSSSST00.

8


2 Normative references

The following normative documents contain provisions which, throughreference in this text, constitute provisions of thisECSS Standard. Fordatedreferences,subsequentamendmentsto,orrevisionsofanyofthesepublicationsdonotapply.However,partiestoagreementsbasedonthisECSSStandardareencouragedtoinvestigatethepossibilityofapplyingthemostrecenteditionsofthe normative documents indicated below. For undated references the latesteditionofthepublicationreferredtoapplies.

ECSSSST0001 ECSSsystemGlossaryofterms

ECSSQST10 SpaceproductassuranceProductassurancemanagement

ECSSQST20 SpaceproductassuranceQualityassurance

ECSSQST30 SpaceproductassuranceDependability

ECSSQST60 SpaceproductassuranceElectrical,electronicandelectromechanical(EEE)components

ECSSEST10 SpaceengineeringSystemengineeringgeneralrequirements

ECSSMST10 SpaceprojectmanagementProjectplanningandimplementation

ECSSMST1001 SpaceprojectmanagementOrganizationandconductofreviews

ECSSMST40 SpaceprojectmanagementConfigurationandinformationmanagement

9


3 Terms, definitions and abbreviated terms

3.1 Terms from other standards ForthepurposeofthisStandard,thetermsanddefinitionsfromECSSST0001apply.

3.2 Terms specific to the present standard 3.2.1 application specific integrated circuit (ASIC) fullcustomorsemicustomdesignedmonolithic integratedcircuit thatcanbedigital,analogoramixedfunctionforoneuser

3.2.2 ASIC technology totalityofallelements required for thedesign,manufactureand testofASICcomponents

NOTE Design tools and their description, cell libraries,procedures, design rules, process line and testequipment.

3.2.3 application specific standard products (ASSP) ASICsdesignedtomakestandardproductsthataremadeavailabletoabroaderrangeofapplications

NOTE ASSPsaremostoftenareprovidedwithaVHDLmodelanddisseminatedwithdocumentation.

3.2.4 block diagram abstract graphical presentation of interconnected named boxes (blocks)representinganarchitecturalorfunctionaldrawing

3.2.5 cell specificcircuitfunctionincludingdigitaloranalogbasicblocks

3.2.6 cell library collectionofallmutuallycompatiblecellswhichconformstoasetofcommonconstraints and standardized interfaces designed and characterized for aspecifiedtechnology

10


3.2.7 data sheet detailedfunctional,operationalandparametricdescriptionofacomponent

NOTE A data sheet can include, for instance, a blockdiagram, truth table, pin and signal description,environmental, electrical and performanceparameters, tolerances, timing information, andpackagedescription.

3.2.8 design flow selectionandsequenceofengineeringmethodsandtoolstobeappliedduringtheimplementationofthedesign

3.2.9 design for test (DFT) structure techniqueusedtoallowacomplexintegratedcircuit(IC)tobetested

NOTE Thiscanincludeanymechanismaimedtoprovidebetterobservabilityorcommandabilityof internalnodesof the chipnot accessible throughprimaryinputsandoutputs.

3.2.10 design iteration design changes that occur in any single phase or between two consecutivephasesasdefinedintheASICandFPGAdevelopmentplan,beforethedesignisreleasedforprototypeimplementation

3.2.11 detail specification procurementspecificationaccordingtoESCCformatthatdefines,forinstance,the maximum ratings, parameter limitations, mechanical outline, pindescriptionandscreeningrequirements

3.2.12 development step majorstepofthedevelopmentflowfortheASICandFPGAdevelopment

NOTE Definition phase, architectural design, detaileddesign, layout, prototype implementation anddesignvalidation.

3.2.13 fault coverage measure expressed as a percentage of the proportion of actually detectablefaultsversusallpossiblefaultsinadigitalcircuit,foragivensetoftestpatternsandwithrespecttoaspecificfaultmodel

3.2.14 field programmable gate array (FPGA) standard semiconductordevice that becomes customizedwhen programmedbytheuserwiththeFPGAspecificsoftwareandhardwaretools

11


3.2.15 floorplan abstracted, scaled layout drawing of the die, outlining the form, size andposition of the major functional blocks and the pads including power andgroundlines,clockdistributionandinterconnectchannels

3.2.16 HDL model textualmodel based on a hardwaredescription language (butnot apiece ofsoftware in itself) suitable for the behavioural or structural description,simulationandbychoosingasuitablelevelofabstractionforautomaticnetlistgeneration

3.2.17 intellectual property (IP) core designelementthat implementsaselfstandingfunctionorgroupoffunctionsforwhichownershiprightsexist

NOTE1 IPcorecanbeacquiredbyacustomer,foragivenprice and under an ownerdefined licenseagreement specifying the customers acquiredrights.

NOTE2 IP core can be supplied as an HDL file (e.g.synthesizableVHDLcodeorgatelevelnetlist)andwith the essential complementary documentationthat allows the customer to successfully integrateand use it in a system (e.g. Users manual andverificationfiles).

3.2.18 macrocell modulethatcontainscomplexfunctionsinamanufacturerscelllibrarybuiltupoutofhardwiredprimitivecells

3.2.19 netlist formattedlistofcells(basiccircuits)andtheirinterconnections

3.2.20 prototype device fabricated ASIC or programmed FPGA used to validate the new design inrespect to functionality,performance,operation limitsand compatibilitywithitssystem

3.2.21 redesign designchangeswhichaffectmorethantwoconsecutivephasesoftheASICandFPGA development or design changes that are implemented after prototypeimplementation

3.2.22 stimuli input data set for simulation or test to show a specific functionality orperformanceofadevice

12


3.2.23 test pattern simulationstimuliand itsexpectedresponses (consideringspecificconstraintsto meet test equipment requirements) used to show correct behaviour of adevice

3.3 Abbreviated terms ForthepurposeofthisStandard,theabbreviatedtermsfromECSSSST0001andthefollowingapply:

Abbreviation MeaningACP 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(industrystandardgraphicsentrytool)

HDL hardwaredescriptionlanguageNote: This term used in general for the various

hardware description language which areappliedforcodingduringdesignphasesuchasVHDLandverilog.

IDMP inputdataformaskorprogrammingfilegeneration

IEEE InstituteofElectricalandElectronicsEngineers

IP intellectualproperty

MoM minutesofmeeting

P&R placeandroute

JTAG jointtestactiongroup

LVS layoutvs.schematiccheck

13


NCC netlistcomparisoncheck

QML qualifiedmanufacturerlist

RTL registertransferlogic

SEU singleeventupset

VHDL VHSIChardwaredescriptionlanguage

14


4 ASIC and FPGA programme management

4.1 General

4.1.1 Introduction a. The supplier shall establish and implement an ASIC and FPGA

development,aspartofthecomponentprogramme(inconformancewithECSSQST60), that ensures full conformancewith the requirementsoftheprojectasdefinedbythecustomerinlinewiththisstandard.

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 inECSSQST10.

c. In case of major problems, the development team, as allocated in thedevelopment plan (see 4.3.1), shall directly report to the componentadvisoryboardasdefinedinECSSQST60.

4.1.3 Planning a. Thesuppliershallensurethat:

1. the ASIC and FPGA developments that are necessary for theimplementationof the ASIC and FPGA programme are planned, documented and implemented,and

2. preventive or corrective actions are initiated whenever there isevidenceofpossiblescheduleortechnicalproblems.

4.2 ASIC and FPGA control plan a. The supplier shall prepare an ASIC and FPGA control plan (ACP) in

conformancewiththeDRDinAnnexA.

15


4.3 Management planning tools

4.3.1 ASIC and FPGA development plan a. ThesuppliershallprepareadetailedASICandFPGAdevelopmentplan

(ADP)inconformancewiththeDRDinAnnexB.

b. The supplier shallmaintain theADPafter the requirements are settledand the feasibility and risk for the ASIC and FPGA development isassessed.

4.3.2 Verification plan a. Thesuppliershallestablishaverificationplan inconformancewith the

DRDinAnnexE.

b. The verification plan shall define how the functionality and nonfunctionalrequirementsstatedinthedefinitionphasedocumentationaredemonstratedatalllevelsofmodelling.

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 theprototypes.

NOTE Those measurements allow verifying that theimplementeddevicescontainthefunctionalityandthecharacteristicstheyaredesignedfor.

4.4 Experience summary report a. At the end of the ASIC and FPGA development cycle, the supplier

shouldestablishanexperiencesummaryreportinconformancewiththeDRDinAnnexI.

NOTE Theexperiencesummaryreportcanbewritten inthe frame of the suppliers continued qualityimprovement activities in order to establisheconomic and efficient development and testrequirementsforexpectedfutureprojects.

16


5 ASIC and FPGA engineering

5.1 Introduction Clause5coverstheresponsibilitiesofASICandFPGAsuppliersanddesignersfor the tasks essential to producing highreliability circuit design and testsmeetingallcircuitfunction,testandperformancerequirements.

To consider the timely allocation of management and quality assuranceactivitiestotheengineeringtasks,theseactivitiesarealsospecifiedwithinthisclause and clearly indicated as being a management or quality assuranceactivity.

All requirements and suggested tasks to be performed and documentedthroughout the entire ASIC and FPGA engineering activity are equallyapplicable, by default and unless indicated otherwise, to either case ofintegratedcircuitoption:digital,analogormixedASIC,aswellasFPGAs.Afewrequirementsdonotapplytocertaintechnologyoptions,asindicated.

5.2 General requirements a. The ASIC and FPGA development flow shall be in conformance with

ECSSMST10.

NOTE Figure51givesanexampleoftheASICandFPGAdevelopmentflow,adaptedfromECSSMST10.

b. All inputs to the design, that are not automatically generated and arenecessary toreproduce thedesignshallbeputunderarevisioncontrolmechanismagreedbetweenthecontractors;

NOTE Examples are simulation pattern, schematics,VHDLsourcecodes,synthesisscripts.

c. Each development step using design inputs shall reflect the revisionnumbersoftheinputsinalogfiletoproveconsistency;

d. Eachdevelopmentstepshallbeverifiedbyamechanism,asimpartialaspossible,toguaranteesuccessfulcompletionofthedevelopmentstep.

NOTE Thedevelopmentstepiscompletedwhenthestepsitselfaswellasitsverificationwereperformedandanyerrororseriouswarningbeingflaggedbythetools was approved in the corresponding reviewmeeting.

17


Figure51:Developmentflow(example)

18


Figure51(contd)

Figure51:Developmentflow(example)continued

19


5.3 Definition phase

5.3.1 Introduction The aim of this development step is to establish an ASIC and FPGArequirements specification, a feasibility and risk analysis report and anASICandFPGAdevelopmentplan.

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 areused.

NOTE Thisallowssettlingoutwithoutanyambiguitythedefinitionstatusofthecollectedrequirementsandverifying that all necessary resources for thedesignactivitiesareavailable.

b. ThesuppliershallspecifythecompletesetoftraceableASICandFPGArequirementsintheASICandFPGArequirementsspecification(ARS)inconformancewiththeDRDinAnnexC.

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 requirementsspecificationandtheavailableresources.

b. Asaminimum,thefollowingtasksshallbeperformedanddocumented:

1. Estimatedesigncomplexity;

2. Estimatepowerconsumption;

3. Assess feasibilityof speed requirementsby apreliminary timinganalysis;

4. Select a radiation hardening approach that ensures compliancewithradiationtolerancerequirements.Determinearoughestimateofimpactonchipareaandcircuitspeed;

5. Select a production test approach and its feasibility against allrequirements;

6. IdentifyandevaluatethesuitabilityandqualificationstatusoftheASIC technologies or FPGA available to implement the device,fulfillingallfunctionalandnonfunctionalrequirementsincludingthespecifiedderatingfactors.Makeabaselineselection;

20


7. Identify packages, fulfilling all requirements. Make a baselineselection;

8. EnsurethatthebaselinetechnologyandpackageorFPGAhavearemaining lifetime, so that flight and compatibleprototypepartscan be manufactured and are available during the expectedprocurementphase(s);

9. Ensure that technical support for the device can be guaranteedduringtheexpectedlifetime;

10. Determineavailabilityand statusof the requireddesignand testtools(H/W&S/W)andlibraries;

11. Determineavailabilityofthenecessaryhumanresources;

12. Determine availability, licensing, support, legal and economicalaspectsofusingIPcoresfromthirdparties;

13. Ensurethatnopatentsareinfringedoragreementsexistorcanbemadewiththepatentholder.

5.3.3.2 Risk analysis a. Asa toolof thequalityassurancesystem (seeclause6.3)ariskanalysis

shall be performed that identifies potential risk items and assignspreventivemeasuresandcontingencyplans.

b. The risk analysis shall result in a Feasibility and risk analysis (FRA)reportinconformancewiththeDRDinAnnexD.

5.3.4 ASIC and FPGA development plan a. 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. ThereviewersshallcheckthatthedevelopmentactivityasdefinedintheADP is feasiblewithin the limits imposedby theproject requirements,resources,scheduleandbudgetaryconstraints.

d. The reviewersshallcheck thatcontingencyplansexist forall identifiedopen issues and risk items and that the risk analysed canbe taken forstartingtheArchitecturalDesignphase.

e. The reviewers shall check that ARS and FRA are complete anddocumented in a level of detail that avoid any ambiguity for theArchitecturalDesignandallsubsequentdesignwork.

f. ThereviewersshallcheckthatARSandFRAincludeasaminimum:

21


1. Summary of the system architecture and all expectedconfigurationsinwhichthedevicecanbeused;

2. Specify the external devices connected to the chip and theirinterfaceprotocols;

3. Bit numbering and naming convention (to be maintainedthroughoutthedesignflow);

4. Formatofdatastructures;

5. Functionalityinallnominaloperationalmodes;

6. Functionalityforerrorhandling;

7. Functionalityinallsystemtestmodes;

8. Internalcommunicationprotocols;

9. Signalprocessingalgorithms;

10. Definitions of programmable memory elements and their stateafterreset;

11. Functionalpartitioning,establishingahighlevelblockdiagram;

12. Preliminary architectural and hardware/software partitioning,includingexternalandinternalmemorymapping;

13. For components providing software programmability, associatedsoftwarerequirementsspecifications;

14. Stateandbehaviourofl/Osduringandafterresetandpowerup;

15. State functionsexplicitlynot implemented in thedesign, inordertoavoidpotentialmisunderstandings;

16. Pinlistincludingpowersupply,testpins,ifalreadyknown,name,polarity,buswidthandinterfaceprotocol;

17. Electrical specifications (maximum ratings, AC, DC and timingdiagrams);

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


5.4 Architectural design

5.4.1 General requirements a. During thearchitecturaldesignphase, thearchitectureof thechipshall

bedefined,verifiedanddocumenteddown to the levelofbasicblocksimplementingallintendedfunctions,theirinterfacesandinteractions.

b. Importantselectionsfortheimplementationofthechipshallbemadeorconfirmed.

c. Alldefinitionsandselectionsmadeshallconformtothedefinitionphasedocumentation.

d. Anydeviationshallbejustifiedinthepreliminarydesignreview.

e. The architecture definition and the baseline choices made during thedefinitionphaseshallbesettled,frozenanddocumentedwithalevelofdetailthatallowsproceedingwiththesubsequentdetaileddesign.

5.4.2 Architecture definition a. Asaminimumthefollowingtasksshallbeperformedanddocumented

inanarchitecturedefinitionreport:

1. Subdivide the chip into its fundamental functions or blocks,identifying and thoroughly documenting their interfaces,functionalitiesandinteractions;

2. Define the architecturedown to the level required to implementtechnologyspecific,transistororgatelevelmapping;

3. Select suitable algorithms and circuit schemes including theirparameterstoimplementtheidentifiedfunctions;

4. Identifysubfunctions,whichcanbeusedasanindividualblockatdifferentlocationsofthechiporpossiblybecompiledasacoreforotherdesigns;

5. Identify a suitable clocking and reset scheme assuring correcttransitions of data between clock domains and identifyasynchronouspartsofthedesign;

6. Select(ifnotyetdone),IPcorestobeusedorpreviouslydesignedunitstobereusedinthedesign.Procureandverifythem.

NOTE This verification can be done by test casesprovidedby the IP coremanufacturer,by testbenches from an independent source, or bynewlydesignedtestprograms.

7. Iftheverificationisaccomplishedduringpriorinstantiationsofthecore, assess it for covering the actual system environment, andeventually perform bugfixes and workarounds or additionalverification;

23


8. Identify and eventually procure custom cells, to be used in thedesign, verify the consistency of the different models delivered(e.g.simulationmodels,layoutandtimingview);

9. Generatemodels requiredasan input to thesubsequentdetaileddesignphase(e.g.synthesizableRTLmodels);

NOTE There is no firm requirement for intermediatebehavioural simulations, nor for any modelbeing coded in a particular language or aspecific level of abstraction. However, thecoding of behavioural models of criticalfunctions and algorithms is stronglyencouraged,since they frequentlyarevaluabletoolsforfurtherverificationtasks.

b. The architecturedefinition report shall include the architecture brokendown to theselectedblocks, their interfaces,functionalityoralgorithmsandinteractions.

c. Even though the chip and its architecture is completelydescribed in asimulationmodel (executablespecification),adetailed textspecificationshallbeedited.

5.4.3 Verification plan a. Thesuppliershallestablishaverificationplan inconformancewith the

DRDinAnnexE.

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

documentedinanarchitectureverificationandoptimizationreport:

1. Verify that the defined architecture meets the requirements byappropriatesimulationandanalysistechniques;

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

3. Performanindependentverificationinordertoavoidmaskingofdesignerrors;

4. When allocation and connectivity of hardmacro cells can be anissue, a preliminary floorplan, assure that the expected cells areeffectivelyplaceandroutablewithinthegivenconstraints;

NOTE ThisisnotapplicableforFPGAdesigns.

5. Reassessthefeasibilityandrisks;

6. Findanapplicationrelatedtradeoffforconflictingrequirements;

NOTE Forexample:powerconsumptionvs.speedandperformance,pincountvs.packagesizeandcomplexityvs.diearea.

7. Establishtheimplementationchoices.

24


5.4.5 Preliminary data sheet a. Apreliminarydata sheet shall be established in conformancewith the

DRDinAnnexG.

NOTE The preliminary data sheet is updated andcompleted at the end of the ASIC and FPGAdevelopment.

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

designreview(PDR)meeting(seequalityassuranceclause6.2).


c. The reviewers shall check that the selected tradeoff meets therequirementsfixedduringthedefinitionphase.

d. Thereviewersshallcheckthatpreventivemeasuresorcontingencyplansexistforallidentifiedrisk itemsandthattheriskanalysedcanbetakenforstartingthedetaileddesign.

e. The reviewers shall check that the architectural design documentation(see clause 7.3.4) together with the documentation of previousdevelopmentphasesiscomplete,traceableanddocumentedinalevelofdetailthatallowtoproceedwiththedetaileddesign.

f. Thereviewersshall identify, justifyandapprovediscrepanciesbetweenthe architectural design documentation and the definition phasedocumentation.

g. Thereviewersshallcheckthattheplannedmeasures,tools,methodsandproceduresareapplied.

EXPECTEDOUTPUTS: a. Architecturedefinitionreport;

b. Verificationplan;c. Architectureverificationandoptimizationreport;d. Preliminarydatasheet;e. Designdatabase,containing:1. Simulationmodels;2. Verificationresults;

f. MoMofPDR.

5.5 Detailed design

5.5.1 Introduction During this phase the highlevel architectural design is translated into astructuraldescriptiononthelevelofelementarycellsoftheselectedtechnologyand library. Additional information is generated for the subsequentdevelopmentphases,suchaslayoutconstraints,floorplanning,productiontestprogramsandadetailedpindescription.

25


Fordigitaldesigns, the abovementioneddesigndescription is the associatedtechnology specific, verified gatelevel prelayout netlist, whereas for analogdesigns, it isaverifiedsized transistorlevelnetlist.However, inmanyanalogdesigns,thereisnoseparationbetweencircuitdesignandlayout.

5.5.2 General requirements a. Influences from layout such as cross talk and matching shall be

accountedforduringthedesignwork.

b. For analogdesigns circuit and layout aredeveloped concurrently, andthereviewsfordetaileddesignandlayoutphasesmaybeheldtogether.

c. ForFPGAsandanalogdesigns,acombinedDDRandCDRmeetingmaybejustified.

NOTE In these cases also the corresponding outputreportscanbemergedtogether.

d. Thescriptsusedforanautomaticandrepeatablegenerationshallbepartofthedesigndatabase.

NOTE1 Themainoutputofthedetaileddesignisadesigndatabase,which contains,or allows an automaticandrepeatablegenerationoftheabovementionedinputstothelayout.

NOTE2 The scripts defined for this generation are anessentialpartofthedetaileddesign,

5.5.3 Design entry a. During the design entry the following tasks shall be performed and

documentedinadesignentryreport.

b. Use the agreeddesign tools as specified in theADP (see clause 5.3.4).Checktheirmaintenancestatus.Considerknownbugs,existingpatches,preventiveandworkaroundmeasures.

c. Implement thespecified testconceptduringdesignentryandsynthesis(e.g. scan paths, DFT logic, measurement points, test busses andboundaryscan(JTAG,seeIEEE1149.1).

d. Implement the specified radiation hardening concept by design andduringsynthesis.

e. Continuouslyverifytheresultsbytheappropriatemethods,asspecifiedintheverificationplan.

f. Determineapinoutandbondingschemewithparticularattentiontothetechnicalconstraints.

NOTE For example, power supply pin definition andbondabilityissues.

g. SelectbuffersaccordingtotheI/OrequirementsdefinedintheASICandFPGArequirementsspecification.

h. Establishorrefinethefloorplan.NOTE ThisisnotapplicableforFPGAdesigns.

26


5.5.4 Netlist generation NOTE Inthisstep,thesourcedescriptionofthedesignis

translated into the netlist, and any otherinformation required for the layout generation,such as floorplan or placement information andconstraintsfortimingdrivenlayoutisgenerated.

a. Enough iterations between design entry, netlist and layout generationshallbeperformedinordertoaccomplishthedesignrequirements.

b. Iterationsbacktothearchitecturaldesignshallbeavoided.

c. If an iterationback to the architecturaldesign is requiredbymeansofchanges in the model released during the PDR, that model shall beverifiedagain.

d. Asaminimumthefollowingtasksshallbeperformedanddocumentedinanetlistgenerationreport:

1. Considertherequiredderatingfactors;

2. Ensurethattheappropriatelibrarycellsareusedastofulfilalltherequirements collected in the ASIC and FPGA requirementsspecification;

3. Selectorgenerateappropriatemodelsforparasitism(e.g.wireloadmodels);


4. Performadesignparametercentring;

NOTE ThisisonlyapplicableforanalogASICdesigns.

5. Ensurethattheintendedoperating(process,voltage,temperature)and environment (radiation) conditions are used during thetranslationandverificationexercise;

6. If synthesis tools are used, generate scripts which allowperforming the fully automaticprelayoutnetlistgeneration in arepeatableway;

7. Ensurethatthesescripts,beingpartoftheinputstothedesign,arecompliant to the general requirements for e.g. documentation,commentingandversioncontrol;

8. Specify timing constraints, and supplier ormanufacturerspecificdesignrules;

9. Consideroverconstrainingtoanticipateparasiticeffects.

27


5.5.5 Netlist verification a. Asaminimumthefollowingtasksshallbeperformedanddocumented

inanetlistverificationreport:

1. Verifythenetlistaccordingtotheverificationplan;

2. Verifytheestimateddataforthelayoutparasiticsanddelays;

3. Performgatelevelsimulations,usingthecompletetestsuitefromthearchitecturaldesign,oranequivalentsetofmethods,suchasformalverificationandstatictiminganalysis;

NOTE ThisisnotapplicableforanalogASICdesigns.

4. Verify key parameters, such as bias voltages, operating point,frequencies, bandwidth, matching, sparameters, noise, dynamicandlinearrangesandshapingtimes;

5. Performafunctionalverification,includingtheinterfaces.


6. Ifacompletesimulationofallmodes(includingtestmodes)attoplevel cannot be performed (e.g. due to runtime restrictions),simulatearepresentativesubset;

7. Verifybyanextrapolatinganalysis,thenotsimulatedcases;

8. Verify that thespecified testconcept is implemented throughe.g.scanpaths,DFTlogic,measurementpointsandtestbusses;

9. Verify that the radiationhardening concept is successfullyincluded in the netlist. Consider e.g. netlist inspection and SEUinjectionsimulations;

10. Verifythatthespecifiedpowerconsumptionisrespected;

11. Update relevant parameters in the preliminary data sheetaccordingtotheresultsobtainedduringtheverification;

12. If production tests or a pre and post burnin test are planned,generate the test vectors and verify the requirements for faultcoverage;

13. ForIPcoresandmacrocells:includethecorestestpatternsintheoverallASICstestprogrammes;

14. Verify, that theprelayout supplierormanufacturerdesign rulesaremetandassesstherelevanceofviolations;


15. Performaparametersensitivityanalysis;


28


5.5.6 Updated data sheet a. The supplier shall update the data sheet to incorporate the new

establishedinformationonforinstancepinoutandestimatedtiming.

NOTE ForfurtherdetailsseeAnnexG.

5.5.7 Detailed design review a. The detailed design phase shall be concluded by the detailed design

review(DDR)meeting(seeclause6.2).


c. The reviewers shallverify that thedetaileddesigndocumentation (seeclause7.3.5) togetherwith thedocumentationofpreviousdevelopmentphases completely documents all results obtained and decisionsmadealongwiththecorresponding justificationsinalevelofdetailthatallowtoproceedwiththelayout.

d. Thisverificationshallincludeasaminimum:

1. Circuit implementation shows details of the implementation,whichwerenotspecifiedduringarchitecturaldesign;

2. Description of implemented testability and production testmethodsincludingtheachievedfaultcoveragefiguresobtained;

3. Descriptionofimplementedradiationhardeningmeasures;

4. Allverificationresults;

5. Descriptionofcellsspeciallydevelopedforthedesign;

6. Configuration andmodifications applied to IP cores used in thedesign;

7. Listof itemswithnameand formatprovided to the foundry (i.e.netlist,stimulifilesforproductiontestandconstraintsfiles);


8. Description of the design database, including the file structure,naming conventions, version control labels, netlist generationmethodsandconstraints;

9. AlltoolsandASIClibrariesactuallyusedduringtheentiredesigndevelopment, including the versions and operating platformsused;

10. Problemsencounteredwithdesigntoolsandtheirworkarounds.

e. Thereviewersshallcheckthattheplannedmeasures,tools,methodsandprocedureswereapplied;

f. The reviewers shall check that the outputs are in conformance to therequirementsfixedduringthedefinitionphase;

g. In particular, when the layout is performed by another company(foundry), the reviewers shall assess the specific foundry requirements(netlistsignoffcriteria).

29


EXPECTEDOUTPUTS: a. Designentryreport;

b. Netlistgenerationreport;c. Netlistverificationreport;d. Updateddatasheetwithpinout;e. Updateddesigndatabase,containing:1. Prelayoutnetlist;2. Constraintsforlayout(i.e.floorplanandconstraintsfortimingdrivenlayout)asdefinedintheADP;

3. Testvectorsforproductiontest;f. MoMofDDR.

5.6 Layout

5.6.1 General requirements a. Thelayoutshallgeneratetheplacementandroutinginformationtomeet

thedesignrules,timingandotherconstraints.

b. In addition, netlist optimization by local resynthesis or physicalsynthesisshallbeapplied.

NOTE Thisprovides reliable informationabout loadsand coupling capacitors and the final designrulecheck thatassuresaverifiednetlistwhichcanbeforwardedtothefoundry.

5.6.2 Layout generation a. Asaminimumthefollowingtasksshallbeperformedanddocumented

inalayoutgenerationreport:

1. finalizethefloorplanofthechip;


2. perform place and route (P&R) taking into account all layoutconstraints;

3. perform netlist optimizations (see clause 5.6.1) for timing anddesignrulesifnecessary;

NOTE ThisisonlyapplicablefordigitalASICdesigns.

4. generatethepowerdistribution;

5. generatetheclockdistribution(clocktreeandbuffers);

NOTE ThisisnotapplicableforanalogASICdesigns.

6. insert core and pad ring power distribution and possiblyadditionaltestpadsinthecircuit;

7. determinethediesize;


30


8. generate the bonding diagram respecting bonding and packageconstraints;


9. generate the inputdata formaskorprogramming filegeneration(IDMP).

5.6.3 Layout verification a. Asaminimumthefollowingtasksshallbeperformedanddocumented

inalayoutverificationreport:

1. layoutdesignrulecheck(DRC);

2. electricalrulecheck(ERC),checkcrosstalksensitivity,ifrequiredbycustomer;

3. extractanetlistfromthelayoutgivenintermsofIDMP;

4. verify that the gatelevel netlist is consistentwith the layout byperforming a layout versus schematic (LVS) comparison, i.e. anetlist comparison check (NCC) between the postlayout netlistandthelayout(IDMP)extractednetlist;

5. verify that the postlayout netlist is consistent in terms offunctionalitywith theprelayoutnetlistbysimulationandformalmethods;

6. extracttheparasiticinformation;

NOTE This delivers capacitance, resistance andinductivity values (only deep submicrontechnology), fromwhich the actualdelays arecalculatedfordigitaldesigns.

7. perform comprehensive postlayout verification according to theverificationplan;

NOTE Thisismostlyaccomplishedbybackannotatedsimulationsandtiminganalysis

8. checktheresultingclockskewandlatency;


9. checkrelevanttimingofI/Os;

10. checkthepowerdistributiononthechip;


11. perform transition check and load check on the nets inside theASIC;

12. characterizeASICandFPGAtimingperformances,

NOTE For example:max clock frequency, clockdutycycle,setupandhold times forall inputsandpropagationdelaysforalloutputs.

31


5.6.4 Design validation plan a. Thesuppliershallestablishandmaintainadesignvalidationplan(DVP)

inconformancewiththeDRDinAnnexF.

5.6.5 Updated data sheet a. Thesuppliershallupdate theparameters in thedatasheetaccording to

theresultsobtainedduringthelayoutverification.

NOTE ForfurtherdetailsseeAnnexG.

5.6.6 Draft detail specification a. Basedon the informationcollected in thedesigndocumentationadraft

detailspecificationshallbeestablishedinconformancewiththeDRDinAnnexH.

5.6.7 Critical design review a. Thelayoutphaseshallbeconcludedbythecriticaldesignreview(CDR)

meeting(see6.2).


c. Thelayoutdocumentation(see7.3.6)togetherwiththedocumentationofprevious development phases completely documents the progress anddecisionsmadeduringthelayoutshallbechecked.

d. Asaminimum,thereviewofthedocumentationatCDRshalladdress:

1. Postlayout clock distribution tree and clock skew and latencyanalysis;

2. Postlayoutverificationresultsandanalysisoftimingmargins;

3. Results from all layout checks (e.g., DRC, ERC, LVS and NCC)Any violation of or deviations from the design rules andjustifications.

e. Thereviewersshallcheckthattheplannedmeasures,tools,methodsandprocedureshavebeenapplied.

f. The reviewers shall check that the outputs are in conformance to therequirementsfixedduringthedefinitionphase.

g. InthecasewherenoDDRwasheldafterthedetaileddesignphase,thereviewersshallcheckthattheCDRencompassesalsoallreviewitemsoftheDDR.

h. Thereviewersshallcheckthatpreventivemeasuresorcontingencyplansexistforallidentifiedrisk itemsandthattheriskanalysedcanbetakenforstartingthePrototypeImplementation.

EXPECTEDOUTPUTS: a. Layoutgenerationreport;

b. Layoutverificationreport;

32


c. Designvalidationplan;d. Updateddatasheet;e. Updateddesigndatabase,containing:1. Postlayoutnetlistintheagreedformatdependingonthetargetedtechnologicalapproach(GDSII,FPGAP&Rfilesorother);

2. Correspondingparasiticinformation;f. MoMofCDR.

5.7 Prototype implementation

5.7.1 Introduction In thisphasechipsaremanufacturedandpackaged,orFPGAsprogrammed,andtheprototypesaretested.

5.7.2 Production and test NOTE Thetermproductionreferstochipmanufacturing

andpackaging,orFPGAprogramming,whateveris applicable. The phase is concluded by thedeliveryofthetesteddevices.

a. Asaminimum,thefollowingtasksasdescribedin5.7.2bupto5.7.2jshallbeperformedanddocumentedintheproductiontestreport.

b. Thepackage shall be the same as for flightdevices, if required by thecustomer.

c. The mask generation and verification shall be performed under thefoundrysconfigurationcontrolsystem.


d. Thecommittednumberofprototypesshallbeproducedanddelivered,sothatdesignvalidationcanbeperformed.

e. The production test shall be performed on 100 % of the deliveredprototypes,usingthetestvectorsgeneratedduringthepreviousphases.

f. The production test shall demonstrate that the device was producedcorrectly.


g. The correctnessof theFPGAprogramming shallbeverified (checksumtest).

NOTE ThisisonlyapplicableforFPGAdesigns.

h. The tested parameters and conditions shall be according to the draftdetailspecification(seeclause7.4.3).

i. Test reports shall be generated and delivered, documenting themeasuredparameters.

33


j. Testerlogfilesshallbedeliveredinelectronicformat.

EXPECTEDOUTPUTS: a. Agreednumberoftesteddevices(ASICsorFPGAs);

b. Productiontestresultsandreports;[notapplicableforFPGAdesigns];

c. Burninoranyotherproductiontestresults,specificationsandpatterns.

5.8 Design validation and release

5.8.1 Design validation a. Thedesignvalidationshallbeperformedtoconfirmtheachievementof

allfunctional,performance,interfaceandcompatibilityrequirements.

b. Asaminimum,thefollowingtasksshallbeperformedanddocumentedinavalidationreport:

1. carryoutthevalidationaccordingtheestablishedvalidationplan;

2. designandbuildthetestsetuporsystembreadboardinordertorepresentarealisticsystemapplication;

3. use the breadboard to perform validation tests that cover fullfunctionalityandalloperatingmodesandconditionsofthedevice;

4. specify,designandexecutespecificburninorotherscreeningtestsfor the later test of the FM parts; if agreed by the businessagreement;

5. document scope, sequences, setup and results of the validationtestsinthevalidationreport;

NOTE Thevalidation reportbecomespartof thedesignvalidationdocumentation.

6. Comparespecifiedparameterswithmeasuredparameters.

c. The validation report shall be made available to the foundry and thedesignhouse.

5.8.2 Radiation test performance a. Thedeviceprototypes shallundergo radiation testing according to the

requirements of the project, if the required hardening level is not yetdemonstratedforthetechnologyinvolved.

b. Radiation testing shall be performed according to the establishedradiation verification plan included in the design validation plan anddocumentedinaradiationtestreport.

34


5.8.3 Design release and FM production preparation

a. For the design release and FM production preparation, the tasks, asdescribed in5.8.3bto5.8.3h,shallbeperformedanddocumented inthereleasereport.

b. License agreements for the intellectual property (the design itself andthirdpartyIPcores)containedinthedeviceshallbeestablishedtocoverthewholelifetime.

c. The supplier shall ensure technical support of the device during thelifetimeoftheproduct.

d. Thiscanbeaccomplishedthroughaknowhowtransferfromthedesignhousetothefoundryorathirdparty,orbythedesignhouseitself.

e. The suppler shall ensure the storage of the complete design databaseduring the lifetime of the product, including associated data,documentation,pattern generation files, testprogram(s) andmask setsused.

f. In the caseofusingnonQMLmanufactureror foundry, an evaluationprogramme(inconformancewithECSSQST60)shallbeperformedthatincludeasagreedbythecustomerthefollowingactivities:

1. manufacturerevaluation;

2. constructionalanalysis;

3. evaluationtesting.

g. On completion of the evaluation programme additional data such asreliabilityandradiationdatashallbeavailableensuringthatthemissionrequirementscanbemet.

h. ThesuppliershallassesstheriskinvolvedfortheFMproduction.

5.8.4 Experience summary report a. Theexecutivesummary reportshallbecompleted inconformancewith

theDRDinAnnexI.

5.8.5 Final versions of application and procurement documents

a. Thedetailspecification,inconformancewithAnnexHshallbeupdatedbasedonthevalidationtestresults.

b. Ifrequestedbythecustomer,thedatasheet,inconformancewithAnnexGshallbeupdatedbasedonthevalidationtestresults.

c. Thedata sheet, eventually transformed to the foundry specific format,shallbeavailableduringthedevicelifetime.

d. Anapplicationnote(seeclause7.4.2)shallbeestablished.

35


5.8.6 Qualification and acceptance review a. Thedesignvalidationphaseshallbeconcludedbythequalificationand

acceptancereview(QR/AR)meeting(seeclause6.2).


c. The reviewershallcheck that thedesignvalidationdocumentation (seeclause7.3.6) togetherwith thedocumentationofpreviousdevelopmentphasesiscomplete.

d. The reviewer shall check that the device achieves functional,performance, interface and compatibility characteristics satisfying theASICandFPGArequirementsspecification.

e. Thereviewershallcheckthattheplannedmeasures,tools,methodsandprocedureswereapplied.

f. Thereviewershallcheckthatpreventivemeasuresorcontingencyplansexistforall identifiedrisk itemsandthattheriskofFMproductioncanbetaken.

EXPECTEDOUTPUTS: a. Validationreport;

b. Radiationtestreport(ifapplicable);c. Releasereport;d. Experiencesummaryreport;e. Finaldatasheet;f. Finaldetailspecification;g. Applicationnote;h. MoMofQR/AR;i. Validationbreadboard;j. BurninorscreeningtestboardsforFMparts.

36


6 Quality assurance system

6.1 General a. ECSSQST20clauseQAstatusreportingshallapply.

b. ECSSQST30clausecriticalityclassificationoffunctionsandproductsshallapply.

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 thedevelopment of reliable, manufacturable, testable and reproducible,customdesignedcomponentsforspaceapplication.

e. Thetoolstobeusedshallbespecifiedandapprovedbythecustomer.

f. All technology independent CAD tools to be employed during thedevelopmentshallbematureandfitfortheirpurpose.

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

h. Preference shall be given to the use of established internationalstandards,suchasVHDLasdefinedinIEEE6169111andEDIF.

6.2 Review meetings a. Thesuppliershallscheduleandconductdesignreviewsinconformance

withECSSMST1001.

b. Design reviews shall be defined along with the criteria for theirsuccessful completion in the ASIC and FPGA development plan (seeclause5.3.4).

c. Representation, for design and quality assurance, from all relevantorganizations (customer, system supplier, design house and foundry)shallbeensured.

d. The supplier shall produce and circulate in advance of each designreview a design review package containing a checklist based on theestablished requirements and the data necessary for the particularreview.

37


e. Thefollowingreviewsshallbeperformed:

1. Systemrequirementsreview(SRR)

NOTE Thisreviewresultsintheauthorizationtostartthearchitecturaldesign.Theoutputsreviewedand the items checked are detailed in clause5.3.5.

2. Preliminarydesignreview(PDR)

NOTE PDR results in the authorization to startwiththedetaileddesign.Theoutputsreviewedandtheitemscheckedaredetailedinclause5.4.6.

3. Detaileddesignreview(DDR)(ifapplicable) NOTE1 DDR results in the authorization to proceed

withthe layout.Theoutputsreviewedandtheitemscheckedaredetailedinclause5.5.7.

NOTE2 In the case the design and layout is aconcurrent or interdigitated activity (forinstance analog or FPGA design) this reviewmeetingcanbecombinedwith thesubsequentCDRmeeting.

4. Criticaldesignreview(CDR)

NOTE CDR results in the approval of design andlayout and the release for prototypeimplementation.Theoutputsreviewedandtheitemscheckedaredetailedinclause5.6.7.

5. Qualificationandacceptancereview(QR/AR)

NOTE QR/AR results in the final acceptance of thedesignand therelease forFMproduction.Theoutputs reviewed and the items checked aredetailedinclause5.8.6.

6. Additionaldesignreviewsasagreedbythesupplier.

f. Directordelegatedcustomerparticipationandunder the responsibilityof the supplier, manufacturer or foundry participation for CDR andQR/ARshallbemandatory.

NOTE1 The decision on a successful completion of areview meeting can only be achieved byconsentofallparties.

NOTE2 Areview identifyinga limitednumberofonlyminor discrepancies can be completed aftersuccessful implementation of the correctiveactionsdefinedduringthereview.

g. A review failing major acceptance criteria and resulting in a designiterationshallberepeatedinfull.

38


h. Thecriteriaforasuccessfulreviewmeetingshallbedefinedpriortotherelevantmeeting.

NOTE Thesecriteriacanbedefinedon theprecedingreviewmeeting.

i. Allreviewmeetingsshallbeminuted.

j. TheMoMs of the reviewmeetings shall be added to themanagementdocumentation.

6.3 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 inclause5.3.3.2.

b. Riskassessmentshallbeperformedconcurrentlytothedesignactivity.

c. Extraordinary risks shallbe covered by a contingencyplan identifyingalternativeorbackupsolutions.

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

39


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 asdefinedanddetailedinthefollowingclauses.

b. Thedocumentationshallbewellstructuredandeasilyreadable,so thatthedesigncanbeunderstoodbyotherASICandFPGAdesignersofthesupplierandmanufacturernotpermanentlyinvolvedinthedesignwork.

NOTE For example, names of signals and blocks arechosentoindicatetheirfunction.

c. One consistent language shall be used throughout the documentation,preferablyEnglish.

d. Thedocumentationshallbeconsistent,e.g.thesameitemhavethesamenameinalldocumentation.

e. Blockdiagrams, control flow charts, timingdiagramsandother figuresshallbeintroducedwherebeneficialfortheunderstandingofthetext.

f. Everytimeanupdateddocumentisdelivered,itshallincludeadetailedchangelist,andallsignificantchangesmarkedusingachangebarinthemargin.

g. If a document is delivered before being complete, each page withincompleteinformationshallbeclearlymarked.

NOTE Someof the information listed isbetterdeliveredseparatelyor inappendices, suchas layoutplots,gatelevelschematicsandlistsofundetectedfaults.

h. Alldocumentsshallbearchivedforaminimumperiodoffiveyearsaftercompletionofthedevelopmentactivityorasagreedbythecustomer.

7.2 Management documentation a. Themanagement documentation shall provide the overall strategy for

thedevelopmentactivity including taskplanningandorganizationandapproaches,methodsandapplicableprocedures.

NOTE Themanagementdocumentationalsoincludesthestatus reporting as MoM of the review meetings

40


andanassessmentoftheexperiencegainedduringthe development activity. The managementdocumentation is a gathering of separatedocuments (see clauses 4.2a, 4.4a, 4.3.2a and4.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 progressachieved and thedecisionsmade alongwith the corresponding justificationsduringthedevelopmentphasesofthedevice.

7.3.1.2 Requirements a. Alldesign informationshallbestored inadesigndatabasebyapplying

the revision controlmechanism agreed in the business agreement (seeclause5.1).

b. All intermediate design data shall be reproducible to assist possibleiterations.

c. As the design database consists of electronic data that cannot bereviewed directly, formless reports shall be established that contain alegibleextractofthedatabase.

d. Reports that shall be produced during the individual phases of adevelopmentactivityaredetailedinclause5.

NOTE1 An example of a suitable filing of this designdocumentationisgiveninFigure71.

NOTE2 Inthecasethedesignandlayoutisaconcurrentorinterdigitated activity (e.g. analog and FPGAdesign) the corresponding output reports can bemergedtogether.

41


ValidationReportRadiationTestReport(if

applicable)

DesignValidationDocumentation

LayoutGenerationReportLayoutVerificationReport

LayoutDocumentation

DesignEntryReportNetlistGenerationReportNetlistVerificationReport

DetailedDesignDocumentation

ArchitectureDefinitionReportVerification and Optimization

ArchitecturalDesignDocumentation

A/FrequirementsspecificationFeasibilityandRiskAnalysis

DefinitionphaseDocumentation

Figure71:Designdocumentation

42


7.3.2 Definition phase documentation a. The definition phase documentation shall consist of the following

contributions:

1. TheASICandFPGArequirementsspecification(ARS)establishedduringthefirstdevelopmentphase.

2. ARSincludingacompletesetofASICandFPGArequirements,inconformance with the DRD in Annex C that are settled,unambiguousandfrozen.

3. An assessment of the feasibility and risk analysis (FRA) withregardstothefollowingdrivers:

(a) consistencyandqualityoftheASICandFPGA,

(b) system requirements feasibility of the ASIC and FPGAdevelopment,

(c) estimateoftheriskinvolved.

NOTE Thefeasibilityandriskanalysis(FRA)reportisthesecondpartofthedefinitionphasedocumentation.

b. FRAshallcovertheitemsdetailedinclause5.3.3.

7.3.3 Architectural design documentation a. The architectural design documentation shall include the following

contributionstothedefinitionphasedocumentation:

1. The architectural definition report that includes the architecturebrokendowntotheselectedblocks,theirinterfaces,functionality,algorithmsandinteractionsasspecifiedinclause5.4.2.

2. The verification and optimization report that provides thesimulationsperformed, the results received, the tradeoffs foundandtheimplementationchoicesestablished.

NOTE Furtherdetailsaregiveninclause5.4.4.

7.3.4 Detailed design documentation a. The detailed design documentation shall consist of the following

contributionstothearchitecturaldesigndocumentation:

1. The design entry report providing all inputs available for thedetaileddesignphaseasdetailedinclause5.5.3.

2. Thenetlistgeneration reportdescribing theworkperformedandthedecisionstakentogenerateanetlistasdetailedinclause5.5.4.

3. The netlist verification report listing all steps of simulation andverification performed (see clause 5.5.5) together with thecorrespondingresults.

43


7.3.5 Layout documentation a. Thelayoutdocumentationshallconsistofthefollowingcontributionsto

thedetaileddesigndocumentation:

1. The layoutgeneration reportdescribing theworkperformedandthedecisionstakentogeneratelayoutasdetailedinclause5.6.2.

2. The layout verification report listing all steps of verificationperformed (see clause 5.6.3) together with the correspondingresults.

7.3.6 Design validation documentation a. The design validation documentation shall consist of the following

contributionstothelayoutdocumentation:

1. Thevalidationreportpresentingthescope,sequences,setupandresultsofthevalidationtestsperformedasdetailedinclause5.8.1.

2. The radiation test report (if applicable) providing the test boardcircuitry and bias conditions, the test sequence and investigatedirradiation levels, theperformedmeasurementsand the resultingdegradations.

3. Thereleasereportsummarizingallactivitiesperformed toassurethat all necessary prerequisites are fulfilled to start a FMproduction(seeclause5.8.3).

7.4 Application and procurement documents

7.4.1 Data sheet a. Ifrequestedbythecustomer,adatasheetthatdescribesthefunctionality

of thedevice so it canbeusedbyaboardor systemdesigner shallbeestablishedinconformancewiththeDRDinAnnexG.

7.4.2 Application note a. Ifrequestedbythecustomer,anapplicationnoteshallbeestablishedfor

components thatare regardedasstandardparts foravarietyofsystemapplications. This note shall provide information to guide the readerthrough the possible configurations the device or module can beoperated with examples for the corresponding bias circuitry, supplyvoltagesandconfigurationsignalsshallbeprovided.

44


7.4.3 Detail specification a. AlldevicesintendedforuseasFMproductsshallbeprocuredaccording

tocontrolledspecifications.

b. Allnewspecificationsshallbedesigned tobe totally inconformance tooneoftheexistingEuropeanstandardizationsystems.

c. Newdetail specifications shall be established in conformancewith theDRDinAnnexH.

d. Specifications shall include configuration control requirements thatensure thatanychangeof theproduct thatrefers to thequalificationorthatcanaffectperformance,quality, reliabilityand interchangeability isidentifiedbythemanufacturers.

45


8 Deliverables

8.1 General a. Uponrequest,thecustomershallreceivefreeofchargefromthesupplier

the information coming from the manufacturer or foundry, for theduration of the development, a complete design kit for the selectedprocess, including all libraries anddesign kit tools and their completedocumentation, inorder toallow the customer to independentlyverifythedesign.

NOTE Thisonlyappliesifsuchadesignkitactuallyexistsforthedesigntoolsavailableatthecustomer.

b. Thequantitytobedeliveredofeachindividualdeliverableitemshallbeagreedbetweencustomerandsupplieraccordingtotherequirementsoftheactualproject.

c. Additionalitemsshallbedefinedasnecessary.

d. Eachdeliveryofadesigndocumentshallbeaccompaniedbyawrittenstatementofthestatusofthedeliverableitem.

e. TheIPrightsstatusshallbereported.

f. Papercopiesshallbeeasilyreadableandsuitableforsubsequentphotocopying.Electroniccopiesshallbesubmittedviaelectronicmedia inanagreedformatwithagreedcharacteristics.

NOTE Searchcapability,printability,usageofhyperlinks,traceabilityandchangeability.

g. Photos and layout plots may be part of the documentation only forpromotional information with restricted details, if not specifiedelsewhere.

8.2 Deliverable items a. The list of deliverables defined per the SoW agreed in the business

agreement.shallbeestablished,basedonTableJ1.

NOTE Table J1 isaguideline fordocumentation,designdatabase deliverables and hardware deliverablesthatbecomeavailableduringtheASICandFPGAdevelopment.

46


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 ThepurposeoftheACPistoinitiatetheASICandFPGAdevelopmentsandtospecifytheorganization,managementtools,qualityassurancesystem,strategy,approachesandproceduresitadopts.

A.2 Expected response

A.2.1 Scope and content a. TheACPshallincludeadescriptionofthefollowingitems:

1. Organizationalstructureandmanagementapproachincludingthedefinition of organizational interfaces between different designgroups and identification of the supplier organization for theproductassuranceoftheASICandFPGAdevelopment;

2. Role, tasksandresponsibilitiesofproductassurancepersonnel inconformancewithECSSQST10andECSSQST20;

3. Management tools to be used for planning (see clause 4.3) andquality assurance system (see clause 6) of the ASIC and FPGAdevelopments;

4. Intendedoverallschedule;

5. Overall strategy and general approach for the ASIC and FPGAdevelopments;

6. Riskmitigationprocedurestobeapplied(seeclause6.3);

47


7. Requirementson, and system for the controlof the foundry andothersubcontractorsorserviceprovidersinvolvedaccordingtotheexperienceavailablefortherespectivesupplier.

b. Compliancematrix to the clauses of this standard taking into accountapplicabletailoring.

c. InitiationofthedefinitionphasefortheASICandFPGAdevelopments.

A.2.2 Special remarks None.

48


Annex B (normative) ASIC and FPGA development plan (ADP)

DRD

B.1 DRD identification

B.1.1 Requirement identification and source document

ThisDRDiscalledbytheECSSQST6002,requirement4.3.1a.

B.1.2 Purpose and objective ThepurposeoftheADPistoimplementtheproposeddevelopmentstrategybyidentifying all phases of the ASIC and FPGA development with the majoractivitiestherein,theprojectexternalinterfacesandconstraints,thedesignflow,resources (equipment, software and personnel), the allocation ofresponsibilities, outputs to be produced and, finally, a schedule withmilestones,decisionpoints,typeandnumberofdesignreviews.

B.2 Expected response

B.2.1 Scope and content a. TheADPshallincludethefollowingitems:

1. NameoftheASICandFPGAanditsbasicfunction;

2. Referencestothedesigndocumentationandotherapplicableandreferencedocuments;

NOTE Internalandexternal standards,proceduresorcodingguidelines.

3. Developmentteamandassignmentofmajorresponsibilities;

4. ThebaselineFPGAdeviceorASIC technology includingbaselineradiationhardeningandtestabilityapproach;

5. Companies involved (foundry, subcontractors, suppliers),indicating their assigned tasks, technical and administrativeinterfaces;

49


6. Versionsandplatformsoftoolstobeused,includingthefoundryorspecifictools;

7. Statementfortheavailabilityofeachdesigntool(atthesiteaswellasthededicationtotheparticulardevelopment);

8. Thedesignflow;

NOTE Design entry, synthesis, simulation andverification, layoutgenerationandverification,productiontestsandvalidation.

9. Identification of a configuration management system inconformancewithECSSMST40;

10. Identification of a verification and validation scheme inconformancewithECSSEST10;

11. The subdivision of the ASIC and FPGA development intoreasonably sized work packages in conformance withECSSMST10;

12. ThescheduleoftheASICandFPGAdevelopment,withestimatedeffortanddurationofeachworkpackageandtheplanneddatesofmilestonesandreviewmeetings;

13. Identification and full description, including formats, of allrelevant outputs, deliverable or not, to be produced along theASICandFPGAdevelopment(documentation,simulationandtestresults, test boards, test samples, source or generated codes andprograms)andmeasures intended to achievebestdesignquality(e.g.HDLcodingconformitytoanappropriatesetofcodingrules).

B.2.2 Special remarks None.

50


Annex C (normative) ASIC and FPGA requirements specification

(ARS) DRD

C.1 DRD identification

C.1.1 Requirement identification and source document

ThisDRDiscalledbytheECSSQST6002,requirements5.3.2band7.3.2a.2.

C.1.2 Purpose and objective The purpose of the ASIC and FPGA requirement specifications (ARS) is tospecifyacompletesetoftraceableASICandFPGArequirements.

C.2 Expected response

C.2.1 Scope and content a. TheARSshallincludethefollowingitems:

1. Overall systempartitioning, system configurationsandoperatingmodes;

2. Interfaces of the ASIC and FPGA to the system andcommunication protocols to external devices, including memorymapping;

3. Operatingfrequencyrange;

4. Electrical constraints (e.g. voltage and current supply, drivecapabilitiesandexternalload);

5. Functionalrequirements;

6. Applicablealgorithms;

7. Powerupandinitializationstate;

8. Resetandpowercyclingrequirements;

9. Errorhandling;

51


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)tobeusedasbuildingblocksofthedesigntobedeveloped,ifalreadyidentified.

C.2.2 Special remarks None

52


Annex D (normative) Feasibility and risk assessment report

(FRA) - DRD

D.1 DRD identification

D.1.1 Requirement identification and source document

ThisDRDiscalledbytheECSSQST6002,requirement5.3.3.2b.

D.1.2 Purpose and objective ThepurposeoftheFRAistoprovideajudgementonthefeasibilityoftheASICand FPGA development as defined by the ASIC and FPGA requirementsspecification,aswellasanassessmentoftherisksinvolved.

D.2 Expected response

D.2.1 Scope and content a. TheFRAshallincludethefollowingitems:

1. Assurance that the collected ASIC and FPGA requirements arecomplete,settledandunambiguous;

2. MaturityofenvisagedASICorFPGAmanufacturersandpossibletechnologies;

3. Experience and familiarity of engineering resources with thedesigntype,tools,technologyandthepotentialfoundries;

4. Riskofunderestimationofdesignandverificationeffort;

5. Riskofunderestimationofdebugandrepairefforts;

6. Risk of overestimation of actual gate capacity and clockingfrequency;

7. RiskofundeterminedI/Obehaviourduringpowerup.

D.2.2 Special remarks None.

53


Annex E (normative) Verification plan (VP) DRD

E.1 DRD identification

E.1.1 Requirement identification and source document

ThisDRDiscalledbyECSSQST6002,requirements4.3.2aand5.4.3a.

E.1.2 Purpose and objective Thepurposeoftheverificationplanistodefinehowthefunctionalityandnonfunctional requirements stated in the definition phase documentation aredemonstrated at all levels of modelling, starting from the behavioural leveldowntothegatelevel.

E.2 Expected response

E.2.1 Scope and content a. TheVPshallincludeadescriptionofthefollowingitems:

1. InthecaseofcomplexdigitalASICdevelopments,verificationbyFPGAprototypingoremulation;

2. Requirementsforcodecoverageindigitaldesigns;

3. Requirements for hardwaresoftware interaction, possibly byperformingcosimulation;

4. Applicationofcodingrules.

E.2.2 Special remarks None.

54


Annex F (normative) Design validation plan (DVP) DRD

F.1 DRD identification

F.1.1 Requirement identification and source document

ThisDRDiscalledbytheECSSQST6002,requirements4.3.3aand5.6.4a.

F.1.2 Purpose and objective Thepurposeofthedesignvalidationplan istospecifythemeasurementsthatareperformedon theprototypes inorder toverify that thenew implementeddevicescontainthefunctionalityandthecharacteristictheyaredesignedfor.

F.2 Expected response

F.2.1 Scope and content a. TheDVPshallincludethefollowingitems:

1. description and requirements for the test setup or systembreadboard;

2. operatingmodesandtestconditionsoftheprototypesundertest;

3. characteristicsand functions tobevalidatedand checkedagainsttheASICandFPGArequirementsspecification;

4. ifa radiation test is requiredby thecustomer, thecorrespondingradiationverificationtestplan.

F.2.2 Special remarks None.

55


Annex G (normative) Data sheet DRD

G.1 DRD identification

G.1.1 Requirement identification and source document

ThisDRDiscalledbyECSSQST6002,requirements5.4.5aand7.4.1a

G.1.2 Purpose and objective Thepurposeofthedatasheet istogatheralltechnicaldataobtainedfromthearchitecturaldesignuntilthefinaldesignvalidationandrelease.Itisusedasaninputforapplicationandprocurement.

G.2 Expected response

G.2.1 Scope and content a. Each page shall contain thedevice name and number and thedate of

issue.

NOTE The first page contain a summary of the devicefunctionality, a block diagram and short list offeatures, such asoperating frequency, technologyandthefoundryaddress.

b. Allcharacteristicsand limitations introducedduringthedesignshallbedescribed,suchasdetailedinterfacedescriptions,registerdefinitionsandmemorymaps.

c. The data sheet shall include a system overview of the device and adescription of how to use the device in a representative systemenvironment,includinganapplicationblockdiagram.

d. Thefullfunctionalityandalloperatingmodesshallbespecifiedindetail.

e. Allsignal interfacesshallbedescribed indetail including for instanceadescriptionofallsignals,testandpowerpins,specifyinge.g.theusageofthesignalsandthesignalpolarity.

f. Thesignaldescriptionsshallbegroupedaccordingtotheirfunction.

56


g. Allelectricalandmechanicaldatashallbespecified, togetherwith theirrelevant applicable conditions (e.g. temperature and capacitive load),including:

1. Absolute maximum ratings, including storage temperature,operating temperature, supply voltage, maximum input currentfor any pin, totaldose, single eventupset, latchup, electrostaticdischargeandreliabilityfigures;

2. DC parameters, including voltage levels, leakage currents, pincapacitancesandoutputcurrents;

3. Static and dynamic (per MHz) power dissipation, allowing thepower consumption at lower operating frequencies to becalculated,ifrepresentative;

4. ACparameters,includinge.g.setupandholdtimes,cycleperiods,output delays and tristate delays, together with waveformdiagrams;

5. Evidences that timingparameters relate to the relevant referencesignaledges;

6. Package description, including pin assignment, package figurewithpinnumbersandpreferablysignalnames,andamechanicaldrawingforthepackagedimensionsincludinginformationonthethermal characteristic of the package such as wall thickness,thermalcoefficientofmaterialorpackage.

h. Apreliminarydatasheetshallcontainallpartsofafinaldatasheet,withthesamelevelofdetail.

i. Whendatadoesnotexist,estimatesshallbeusedandclearlyindicatedtobeestimates.

G.2.2 Special remarks None.

57


Annex H (normative) Detail specification (DS) DRD

H.1 DRD identification

H.1.1 Requirement identification and source document

ThisDRDiscalledbyECSSQST6002,requirements5.6.6aand7.4.3c.

H.1.2 Purpose and objective The purpose of the detail specification is to collect all the engineeringinformation from the layout activity (at the end of which a draft detailspecificationisestablished)tothedesignvalidationandreleaseactivity(attheendofwhichthefinaldetailspecificationisproduced).Itisusedasaninputforapplicationandprocurement.

H.2 Expected response

H.2.1 Scope and content a. 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


12. protectivepackagingandhandlingrequirements;

13. radiationverificationtestingrequirements,whenapplicable.

H.2.2 Special remarks None.

59


Annex I (normative) Experience summary report DRD

I.1 DRD identification

I.1.1 Requirement identification and source document

ThisDRDiscalledbyECSSQST6002,requirement4.4aand5.8.4a.

I.1.2 Purpose and objective ThepurposeoftheexperiencesummaryreportistocollectandtoevaluateanyrelevantinformationresultingfromtheexperiencegainedduringtheexecutionoftheASICandFPGAprocurementprogramme.

I.2 Expected response

I.2.1 Scope and content a. Theexperiencesummaryreportshallincludethefollowingitems:

1. Asummaryofthemaindesignobjectivesandconstraints;

2. AnassessmentoftheactualdevelopmentprogrammewithrespecttotheoriginalADP;

3. Controls,schedule,designiterationsandcommunications;

4. AnassessmentofEDAtoolsuitabilityandperformance;

5. Anassessmentofthemanufacturersupport;

6. Apresentationofnonconformancesandproblemareas;

7. In the case of usage of existing IP cores, experiences gained intermsofproductqualityandsuitability;

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

9. Recommendationsandlessonslearned.

I.2.2 Special remarks None.

60


Annex J (informative) Document requirements list and

configuration items to be delivered TableJ1:DeliverablesoftheASICandFPGAdevelopment

Developmentphase Documentation DRD Software Hardware

A/Fcontrolplan(ACP) AnnexA

Definitionphase

A/Frequirementsspecification(ARS)

Feasibilityandriskanalysis(FRA)

A/Fdevelopmentplan(ADP)

MoMofSRR

AnnexC

AnnexD

AnnexB

Architecturaldesign

Architecturedefinitionreport

Verificationplan

Architectureverificationandoptimizationreport

Preliminarydatasheet

MoMofPDR

AnnexE

AnnexG

Designdatabasecontaining:Simulationmodels

Verificationresults

Detaileddesign Designentryreport

Netlistgenerationreport

Netlistverificationreport

Updateddatasheet

MoMofDDR

AnnexG

Updateddesigndatabasecontaining:

Prelayoutnetlist

Constraintsforlayout

Testvectorsforproduction

Layout Layoutgenerationreport

Layoutverificationreport

Designvalidationplan(DVP)

Updateddatasheet

Draftdetailspecification

MoMofCDR

AnnexF

AnnexG

AnnexH

Updateddesigndatabasecontaining:

Postlayoutnetlist

Correspondingparasiticinformation

Prototypeimplementation

Productiontestresultsandreports

Burninoranyotherproductiontestresults,specification,pattern

Agreednumberoftested

Documents

ECSS-Q-ST-60-02C