REG MSFC-STD-3663-2012 MSFC Standard For Configurable Logic Device Developments.pdf

1、 CHECK THE MASTER LIST VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/MSFC-STD-3663.pdf MSFC-STD-3663 National Aeronautics and BASELINE Space Administration EFFECTIVE DATE: April 11, 2012 George C. Marshall Space Flight Center Marshall Space F

2、light Center, Alabama 35812 ES30 MSFC TECHNICAL STANDARDS MSFC STANDARD FOR CONFIGURABLE LOGIC DEVICE DEVELOPMENTS NOT MEASUREMENT SENSITIVE Approved for Public Release; Distribution is Unlimited Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHSMSFC Techni

3、cal Standard ES30 Title: MSFC Standard for Configurable Logic Device Developments Document No.: MSFC-STD-3663 Revision: Baseline Effective Date: April 11, 2012 Page 2 of 60 CHECK THE MASTER LIST - VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram

4、/MSFC-STD-3663.pdf DOCUMENT HISTORY LOG Status (Baseline/ Revision/ Canceled) Document Revision Effective Date Description Baseline 4/11/2012 Baseline release; document authorized through MPDMS. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHSMSFC Technic

5、al Standard ES30 Title: MSFC Standard for Configurable Logic Device Developments Document No.: MSFC-STD-3663 Revision: Baseline Effective Date: April 11, 2012 Page 3 of 60 CHECK THE MASTER LIST - VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/

6、MSFC-STD-3663.pdf FOREWORD This Marshall technical standard defines the technical and managerial processes necessary to manage and develop electronic designs containing complex programmable logic devices, such as Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs

7、), and similar devices (sometimes referred to as “complex electronics.”) Throughout this document, a component from this family of devices is referred to as a Configurable Logic Device (CLD.) This Standard is recommended for all MSFC projects, but is not mandatory unless specifically imposed. Provid

8、ed by IHSNot for Resale-,-,-MSFC Technical Standard ES30 Title: MSFC Standard for Configurable Logic Device Developments Document No.: MSFC-STD-3663 Revision: Baseline Effective Date: April 11, 2012 Page 4 of 60 CHECK THE MASTER LIST - VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/rep

9、ository.msfc.nasa.gov/docs/multiprogram/MSFC-STD-3663.pdf TABLE OF CONTENTS 1.0 SCOPE8 1.1 SCOPE 8 1.2 CHANGE AUTHORITY the persons or groups with authority to authorize changes and to make changes at each level; and the steps to be followed to request authorization for changes, process Change Reque

10、sts, track changes, distribute changes, and maintain past versions. e. Prepare and maintain records of the configuration status of configuration items. f. Ensure that configuration audits are performed to determine the correct version of the configuration items and verify that they conform to the do

11、cuments that define them. g. Establish and implement procedures for the storage, handling, delivery, release, and maintenance of deliverable products. Provided by IHSNot for Resale-,-,-MSFC Technical Standard ES30 Title: MSFC Standard for Configurable Logic Device Developments Document No.: MSFC-STD

12、-3663 Revision: Baseline Effective Date: April 11, 2012 Page 18 of 60 CHECK THE MASTER LIST - VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/MSFC-STD-3663.pdf h. Provide and maintain traceability from design to hardware or CLD code. i. Track c

13、hanges, including but not limited to both design and requirements, and provide data for review. j. Track defects (a.k.a. “bugs”) and the resulting changes. The Acquiring Organization, or as delegated to lower-tier configuration control boards shall (CLD-013) control delivered products, including doc

14、umentation, Hardware Descriptor Language (HDL) source, programming files, data tables, and products used to generate CLDs. 4.2.5 Corrective Action The Developer shall (CLD-014) identify inconsistencies between requirements and design products and initiate corrective actions. The Acquiring Organizati

15、on shall (CLD-015) ensure that corrective actions are taken and managed to closure when actual results and performance deviate from the plans. 4.2.6 CLD Design Reviews Development process includes both joint management reviews and technical reviews defined in the appropriate Systems Engineering Mana

16、gement Plan (SEMP). Multiple design reviews may be planned and performed by both the Acquiring Organization and the Developer(s). Each Developer shall (CLD-016) regularly hold reviews of CLD design and development activities, test procedures, status, and results with the project stakeholders and tra

17、ck issues to resolution. This includes formal external reviews, as well as peer reviews internal to the Developer. Specific requirements are established by systems engineering planning, and by contracts, where applicable. See Appendix B, for recommended items to review/consider at a Design Review. O

18、mitting any of the detailed design phase steps increases the likelihood of having design problems and anomalies, increasing technical and programmatic risks. Development risk increases if a robust preliminary design is not developed, documented and reviewed. Lack of a preliminary design increases th

19、e probability that requirements may be missed in the design, causing development schedule and cost impacts. Provided by IHSNot for Resale-,-,-MSFC Technical Standard ES30 Title: MSFC Standard for Configurable Logic Device Developments Document No.: MSFC-STD-3663 Revision: Baseline Effective Date: Ap

20、ril 11, 2012 Page 19 of 60 CHECK THE MASTER LIST - VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/MSFC-STD-3663.pdf 4.2.7 Acquisition Planning The Acquiring Organization shall (CLD-017) evaluate potential suppliers using the following criteria

21、: a. Compliance to the mandatory requirements of this document. b. Implementation of the best practices identified within this document. c. The use of Capability Maturity Model Integration (CMMI) or equivalent process maturity certification for development organizations. Note: This document does not

22、 impose a requirement for CMMI but does recognize that CMMI may be used by Developer to lend strength to their processes. Standard data requirements documents, including two that are directly applicable to CLD developments, are available thru the MSFC Integrated Document Library. https:/masterlist.m

23、sfc.nasa.gov/drm/ STD/DE-PDDD Programmable Devices Design Documentation STD/DE-PDDP Programmable Devices Development Plan 5.0 DETAILED REQUIREMENTS The Acquiring Organization and/or the Developer may apply additional process-based approaches to their individual developments. Of particular value is t

24、he capability maturity model/integration (CMMI) approach and certification. CMMI process certification, although not a requirement for CLD developments is a best practice and may yield value. 5.1 Definition/Planning Each Acquiring Organization shall (CLD-018) document or record the acceptance criter

25、ia and conditions for the CLD deliverables, or the CLD portion of higher-level assemblies. The Developer shall (CLD-019), produce a development plan that documents the organizations approach to design, development, test, and engineering/evaluation (DDT As part of the overall project planning for FPG

26、A/ASIC designs conducted by the same responsible organization performing PWB (and/or higher) design activities. 4. Results to be summarized at formal customer design review. 5. If performed. 6. Required if chips are delivered directly to a customer, unless all characteristics are included in the rel

27、ease report. 7. Where required by the customer: D = Document or Drawing: Either electronic or both electronic and hardcopy E = Electronic: Format of files and media must be mutually agreed upon F = Final P = Preliminary U = Update X = Required Provided by IHSNot for Resale-,-,-MSFC Technical Standar

28、d ES30 Title: MSFC Standard for Configurable Logic Device Developments Document No.: MSFC-STD-3663 Revision: Baseline Effective Date: April 11, 2012 Page 23 of 60 CHECK THE MASTER LIST - VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/MSFC-STD-

29、3663.pdf TABLE I. Generic CLD Documentation Index Type Documentation FormatDefinition Phase Preliminary Design Detailed Design LayoutDesign Baseline layout results) (4) D X 20 Design Updated design database containing: (1) Post-layout netlist (2) Corresponding parasitic Information (3) Test vectors

30、for production E X 21 Report Experience summary report D X Provided by IHSNot for Resale-,-,-MSFC Technical Standard ES30 Title: MSFC Standard for Configurable Logic Device Developments Document No.: MSFC-STD-3663 Revision: Baseline Effective Date: April 11, 2012 Page 25 of 60 CHECK THE MASTER LIST

31、- VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/MSFC-STD-3663.pdf Index Type Documentation FormatDefinition Phase Preliminary Design Detailed Design Layout Design Baseline Netlist generation report) (4) D X Provided by IHSNot for Resale-,-,-M

32、SFC Technical Standard ES30 Title: MSFC Standard for Configurable Logic Device Developments Document No.: MSFC-STD-3663 Revision: Baseline Effective Date: April 11, 2012 Page 26 of 60 CHECK THE MASTER LIST - VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/m

33、ultiprogram/MSFC-STD-3663.pdf 5.1.3 Organizational Approach Each developing organization shall (CLD-023) define the organizational approach utilized for CLD developments, to include: a. Management, assurance, and control functions. b. Data management and configuration management. c. Plans for proces

34、s improvement and process institutionalization. d. Roles and responsibilities for SR or b. Include specific requirements for the CLD device in subsections of specifications at either the board level or higher assembly. The Developer or the Acquiring Organization may as a best-practice implement this

35、 requirement for noncritical CLDs that are highly complex. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHSMSFC Technical Standard ES30 Title: MSFC Standard for Configurable Logic Device Developments Document No.: MSFC-STD-3663 Revision: Baseline Effectiv

36、e Date: April 11, 2012 Page 29 of 60 CHECK THE MASTER LIST - VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/MSFC-STD-3663.pdf 5.3 Preliminary and Detailed Design A typical design process is divided into a Preliminary Design Phase and a Detaile

37、d Design Phase (often called the Critical Design Phase.) During the Preliminary Design, requirements are translated into an architecture, block diagrams, data flows, and preliminary resource estimates (e.g. gate counts, pin counts, etc.) Critical modules of the design may be prototyped or developed

38、in detail to prove feasibility, refine resource estimates, or as risk mitigation. This phase normally culminates with a Preliminary Design Review (PDR). During the Detailed Design Phase, the preliminary design is updated and expanded to fully address all requirements. Simulation test benches will al

39、so be developed and used to confirm the functionality of the design. Prior to entering the Implementation phase, a peer review is normally held. See Appendix C for a list of best practices to consider during design. 5.3.1 Configurable Logic Device Identification The developing organization shall (CL

40、D-038) generate a list of CLDs to be developed and identify whether each device implements critical functions. 5.3.2 Parts Selection The parts to be used for the filed implementation CLDs shall (CLD-039) be selected and documented, along with the criteria used for making the selection. The part used

41、 for the flight FPGA implementations should be selected as early in the development cycle as feasible. This will allow for the long procurement cycles normally associated with flight FPGA devices. In addition to the mandatory requirements of the program EEE Parts Management and Control Requirements,

42、 and MSFC-STD-3012, the following factors should be taken into consideration in selecting a device family and specific part number: a. Package style. b. Reliability/flight qualification status/heritage. c. Radiation specs (total dose and single event effects). d. Estimate of utilization: 1. Use prio

43、r experience. 2. Find similar design and get gate count for target technology. 3. Overestimate if a guess is necessary. Provided by IHSNot for Resale-,-,-MSFC Technical Standard ES30 Title: MSFC Standard for Configurable Logic Device Developments Document No.: MSFC-STD-3663 Revision: Baseline Effect

44、ive Date: April 11, 2012 Page 30 of 60 CHECK THE MASTER LIST - VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/MSFC-STD-3663.pdf 4. Quantity needed. e. Speed rating. f. The long procurement cycles normally associated with flight grade devices.

45、g. The availability of equivalent commercial grade devices that may be desirable in the development of breadboards and test boards. For cost reasons, equivalent commercial devices may be considered for the development of breadboards and test beds. 5.3.3 Incorporation of Off-The-Shelf or Nondevelopme

46、nt Items The Developer of CLDs that include nondevelopment items (i.e., design elements that are reused from another application, or that are procured or obtained from a source outside their developmental control such as intellectual property (IP) shall (CLD-040) ensure that the inclusion of non-dev

47、elopment items have identifiable and bounded impacts upon the overall function and reliability of the CLD, and the overall circuit design, including the identification and management of any appropriate risks, in accordance with the Developers risk management processes. The Developer shall (CLD-041)

48、ensure that when a heritage or non-developmental product is to be acquired by the Developer, the following conditions are satisfied: a. The requirements that are to be met by the non-developmental item are identified. b. The non-developmental item includes documentation to fulfill its intended purpo

49、se (e.g., usage instructions). c. Proprietary, usage, ownership, warranty, licensing rights, and transfer are addressed. d. Future support for the off-the-shelf product is planned. e. Off-the-shelf item is validated to the same level of confidence as would be required of the developed items, although this validation may take place as part of the validati