Attachment_A_-_HPSC_SOW.pdf
PDF 458 KB Posted
- Attached to
- High Performance Spaceflight Computing (HPSC) Processor Chiplet Federal contract opportunity
- Solicitation number
- NNG16574410R
About this file
Attachment A - HPSC Statement of Work (SOW)
View the file
Other files for this federal contract opportunity
| File | Type | Posted |
|---|---|---|
| Attachment_C_-_Organizational_Conflicts_of_Interest_(OCI)_Avoidance_Plan.pdf | ||
| Exhibit_12_-_Past_Performance_Questionnaire_Instructions.pdf | ||
| Amendment__1.pdf | ||
| Attachment_B_-_Contractor_Proposed_Enhancements.pdf | ||
| Attachment_D_-_Small_Business_Subcontracting_Plan.pdf | ||
| Attachment_A-1_-_Requirements_Document.pdf | ||
| HPSC_Cover_Letter.pdf | ||
| HPSC_-_Cost_Exhibits_.pdf | ||
| Attachment_A-1_HPSC_Requirements.pdf | ||
| HPSC_PastPerfQues.pdf | ||
| HPSC_RFP_Sections_B_-_M.pdf | ||
| HPSC_RFP_Cover_Page_-_SF33.pdf | ||
| Attachment_E_-_Financial_Management_Reporting_Requirement.pdf |
Show all 13
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Attachment A Statement of Work (SOW) for the Development of the High Performance
Spaceflight Computing (HPSC) Processor Chiplet
6/17/2016
1.0 Introduction/Background
The National Aeronautics and Space Administration (NASA) and the United States Air Force (USAF) require High Performance Spaceflight Computing (HPSC) capabilities for multiple mission applications associated with both robotic and human space exploration. Traditionally, spacecraft onboard computing systems are single processor systems based on existing commercial or military computers that are radiation hardened. The systems are implemented and operated at maximum required mission performance point, where the term “performance point” includes throughput, fault tolerance and power levels. As NASA and USAF consider advanced missions that require both an increase in throughput and wider variations in these operating points, the development of a new processor is needed. This processor, termed “the Chiplet” herein, is needed to provide orders of magnitude improvement in performance and performance-to-power ratio as well as the ability to dynamically set the power-throughput-fault tolerance operating point. The purpose of this Statement of Work (SOW) is to solicit proposals for the development of this new processor. A separate Requirements Document accompanies this SOW and lists the specific requirements for HPSC program.
This project will consist of a preliminary design phase culminating in a Preliminary Design Review (PDR), a detailed design phase culminating in a Critical Design Review (CDR), a fabrication phase, and a test and characterization phase. The project duration is baselined at four years.
This project will deliver: a Chiplet behavioral model, prototype Chiplets (including packaged parts that have been functionally tested at ambient temperature and bare die), Chiplet Evaluation Boards, and System Software. Technical requirements for these deliverables are defined in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
1.1 Background
NASA has conducted an HPSC study defining future spacecraft onboard computing needs. Several HPSC use cases were identified, broadly addressing both human spaceflight missions and robotic science. As shown in Table 1 below, these were categorized into (a) vision-based algorithms with real-time requirements, (b) model-based reasoning techniques for autonomy, and (c) high rate instrument data processing.
Table 1 -- Space Computing Use Cases for Basing the HPSC Requirements.
Computation Category
Mission Need Objective of Computation
Flight Architecture Attribute
Vision-based Algorithms with Real-Time Requirements
• Terrain Relative Navigation (TRN)
• Hazard Avoidance
• Entry, Descent & Landing (EDL)
• Pinpoint Landing
• Conduct safe proximity operations around primitive bodies
• Land safely and accurately
• Achieve robust results within available timeframe as input to control decisions
• Severe fault tolerance and real-time requirements
• Fail-operational
• High peak power needs
Model-Based Reasoning Techniques for Autonomy
• Mission planning, scheduling & resource management
• Fault management in uncertain environments
• Contingency planning to mitigate execution failures
• Detect, diagnose and recover from faults
• High computational complexity
• Graceful degradation
• Memory usage (data movement) impacts energy management
High Rate Instrument Data Processing
• High resolution sensors, e.g., SAR, Hyper-spectral
• Downlink images and products rather than raw data
• Opportunistic science
• Distributed, dedicated processors at sensors
• Less stringent fault tolerance
Approximately 60 application variants were classified into a set of ten “eigen applications”, each of which defines the processing requirements and characteristics of a subset of the mission applications. Based on these requirements and other key performance parameters (including power/energy management, fault tolerance, programmability, interoperability, evolvability/extensibility, and cost), candidate computing architectures were evaluated. This evaluation established that a radiation-hardened, general-purpose, multi-core processor is best suited to address NASA’s future onboard computing needs.
Collaborative discussions with the Air Force Research Laboratory (AFRL) determined that many of NASA’s future onboard computing needs have commonality with the USAF’s future needs, and that a radiation-hardened, general purpose multi-core processor of the kind envisioned by NASA would also be relevant to the USAF. Based on these shared interests, NASA partnered with AFRL on a Next Generation Space Processor (NGSP) study. This study, led by AFRL, engaged industry to assess, in greater detail, USAF’s requirements, compare USAF’s requirements with NASA’s previously defined detailed requirements, develop processor architectures that would satisfy the superset of NASA/USAF requirements and evaluate these architectures against a set of government provided benchmarks.
The NGSP study provided the government team valuable guidance regarding the optimal architecture for a future spaceflight processing device:
- The use of COTS IP (specifically ARM based IP) provides optimal power-to-performance, extensibility, evolvability, software availability, ease of use, and cost.
- The use of Radiation Hard By Design (RHBD) standard cell libraries provides required radiation tolerance.
- The augmentation of RHBD with higher-level fault tolerance techniques improves reliability.
- The use of the ARM A53 processor with its internal NEON Single Instruction, Multiple Data (SIMD) is sufficient for most near term applications.
- Heterogeneous multi-core architectures using multiple processor core types do not provide the optimum return on investment at this time.
- Architectural flexibility such as the ability to turn on/off cache coherency and use of L3 cache, as well as the ability to dynamically depower unused cores, including memory and Input/Output (I/O) interfaces, is useful to enable setting of optimal power:performance:fault tolerance operating point.
Based on these findings, the government team has devised the HPSC “Chiplet” concept that (a) meets the NASA/USAF future onboard computing needs, and (b) can be developed within the available funding profile. As illustrated in Figure 1 below, the Chiplet concept leverages the COTS ARM A53 IP along with other COTS peripheral IP, and can meet the NASA/USAF performance, power, and radiation tolerance needs when implemented with existing RHBD technology. The Chiplet includes multiple Serial RapidIO (SRIO) for high bandwidth communication, and multiple interfaces to high speed off-chip memory. The SRIO interfaces can also be used as Advanced Microcontroller Bus Architecture (AMBA)-bus bridges allowing multiple Chiplets to be tiled or cascaded to increase bandwidth or to improve fault tolerance.
The government team defined the ARM based hardware and companion Linaro System Software as the baseline architecture. The hardware architecture is shown in Figure 1 for reference and to provide architectural context. Offerors opting to propose solutions that do not utilize the processor IP shown in the above diagram must provide analysis indicating that their proposed design meets or exceeds the requirements listed in the HPSC Requirements document and rationale as to why the proposed approach is superior to that shown above.
1.2 System Context
The Chiplet, as defined herein and in the companion requirements document, provides the performance to satisfy the majority of the NASA/USAF onboard processing applications when implemented as a discrete packaged part. It will also provide extensibility (via SRIO) to allow the most demanding applications to be satisfied with “multiple-Chiplet” systems (see Figure 2 below), implemented either on a multi-chip module (MCM) or on a printed wiring board with multiple discrete Chiplets. Multiple-Chiplet systems can satisfy needs for increased processing bandwidth, and/or needs for increased fault tolerance (i.e. multiple Chiplets as separate fault containment regions).
Figure 1 - Architectural block diagram for the HPSC "Chiplet"
Figure 2 - Potential architectural configuration for a "multi-Chiplet" realization
The SRIO interface also allows extensibility to other SRIO-enabled processing devices such as FPGAs, GPUs, and in the future to other ASICs serving as application specific coprocessors.
Viewed as an individual Chiplet or as a system of multiple Chiplets, a key objective for HPSC is to provide the flexibility to dynamically trade between processing throughput, power consumption, and fault tolerance to meet varying demands and priorities across multiple candidate missions and mission phases.
The mission applications for the HPSC Chiplet range from human rated spacecraft, habitats, and vehicles to robotic science and exploration platforms, to military surveillance and weapons systems. System applications range from smallsats to large flagship class missions, and can include:
- Command and data handling, guidance navigation and control, and communications (e.g. software defined radio)
- Human assist, data representation, and cloud computing
- High rate, real time sensor data processing
- Autonomy and science processing
In many of these applications, the HPSC Chiplet (or multiple Chiplets) will be implemented within a dedicated spaceflight computer. Alternatively, the Chiplet(s) may be embedded within a science instrument or spaceflight subsystem. The range of these applications can be from robotic science data processing to human rated applications employing ARINC-653 time space partitioning.
The software infrastructure for the HPSC Chiplet is envisioned to support both symmetric and asymmetric processing, and support both real-time operating systems and Unix/Linux based parallel processing. This infrastructure is also envisioned to support hierarchical fault tolerance, ranging from single Chiplet missions to multi-Chiplet highly redundant human missions. This software infrastructure is a contract deliverable (detailed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document).
The HPSC Chiplet will provide increased processing bandwidth, power efficiency, and fault tolerance for onboard processing applications. However, these advantages could come at the cost of increased hardware and software complexity.
As software development and verification is a major cost driver for missions, this increased complexity has the potential to significantly increase cost for future NASA/USAF missions. To address this risk, NASA will separately develop (i.e. not part of this contract) middleware software providing machine management for multicore processing devices. This middleware software layer resides between the application layer and the Chiplet System Software to provide intelligent resource, fault, and power management.
As an example for the power management middleware, the middleware will need the ability via the Chiplet to implement high level power management decisions for anticipated needs such as:
- Specific application executions
- Real time throughput objectives
- Mission mode
- Available or allocated power/energy
Similarly, the fault tolerance management middleware will need the ability via the Chiplet to:
- Detect and log errors
- Remove services (e.g. processor cores and external memories) that are likely to experience a hard failure in the near future (increasing rate of soft errors is typical of circuitry that will fail hard in the near future)
- Determine the appropriate course of action, based on mission mode and application criticality, when uncorrectable errors are encountered (roll forward, roll back, reconstruct, substitute previous iteration result, etc.)
- Implement (possibly software implemented) n-modular redundancy, checkpoint/rollback, or other high level fault tolerance strategy
The resource allocation middleware, meanwhile, will utilize all of the above information to implement system level policies for allocation of processing
By providing these middleware functions, application software can be largely agnostic to the underlying hardware and system operating modes, thereby reducing development complexity, risk and cost. Details of the interfaces between middleware and hardware and System Software will be jointly defined by the government and vendor prior to PDR and documented in the System Software Specification Document.
2.0 Scope of Work
The HPSC project will design and deliver radiation hardened Chiplet devices, associated System Software, the software development environment, and the evaluation hardware and software to test the full functionality of the Chiplets.
2.1 Project Phases
The project will consist of four phases of work: a Preliminary Design Phase culminating in a Preliminary Design Review (PDR), a detailed design phase culminating in a Critical Design Review (CDR), a fabrication phase, and a test and characterization phase. During each phase, the selected vendor and the government team will interact through various meetings, reviews, and status reports.
Deliverables during each phase are listed in Section 5. Figure 3 shows the 45 month project schedule and milestones.
The goals of the Preliminary Design Phase are to develop the architecture for the Chiplet, System Software, and Evaluation Board, develop the Chiplet emulator, perform Chiplet IP integration and functional simulation, and develop Chiplet floor plan and perform preliminary timing, power, and radiation analysis.
The goals for Detail Design Phase are to synthesize the Chiplet and perform full chip simulation, perform final timing, power, and radiation analysis, design the Chiplet package, detailed design of the System Software, and design the Evaluation Board.
The goals of the Fabrication Phase are to, fabricate and package Chiplet die, code and test (in simulation environment) the System Software, and layout, fabricate and assemble the Evaluation Board.
The goals of the Test and Characterization Phase are to test the complete Chiplet, Evaluation Board and System Software functionality. Upon completion of this phase, the final deliverables are due.
Figure 3 - Schedule
2.2 Work Breakdown Structure (WBS)
The following work breakdown structure defines task organization for the HPSC development work on this contract. This WBS shall be used as the basis for the proposal development. After award, the contractor may submit an updated WBS for use in project execution.
HPSC Development (WBS Level 1)
1. Management
2. System Engineering
2.1. HPSC Conceptual Design
2.2. HPSC Documentation Development
2.3. Test Plan and Procedure Development
3. Chiplet Development
3.1. Chiplet Preliminary Design
3.2. Chiplet Detailed Design
3.3. Chiplet Fabrication
4. System Software Development
4.1. System Software Preliminary Design
4.2. System Software Detailed Design
4.3. System Software Code/Test
5. Evaluation Board Development
5.1. Evaluation Board Preliminary Design
5.2. Evaluation Board Schematic Capture and Layout
5.3. Evaluation Board Fabrication and Assembly
6. Test and Characterization
6.1. Test Execution
6.2. Test Report Development
2.3 Options
The government team has defined the following options for which funding has not yet been secured, but which are highly desireable. Offerors shall include these options in their proposal. There is no interdependency between these options options, and any combination may be exercised. The contractor will be notified of any options to be exercised prior to the Preliminary Design Review.
1. The inclusion of level 3 cache
2. The addition of dual lock-step real-time processors for system management and real time critical computation
3. The provision of dual-port Time-Triggered Ethernet (TTE) interface
4. The provision of dual-port Spacewire interfaces with RMAP compatibility
5. The provision of packaging that is amenable to space qualification
Technical requirements for the options are provided in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
3.0 Applicable Documents/Background
The following is a list of appropriate specifications, standards and other reference documents that are applicable to this document and the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
3.1 Standards
- NASA Form (NF) 533 for Monthly (M) and Quarterly (Q) Reports
- Standard for Earned Value Management Systems - ANSI/EIA-748-A
- Requirements for Packaging, Handling, and Transportation for Aeronautical and
Space Systems, Equipment, and Associated Components - NPR 6000.1H
- NASA Systems Engineering Processes and Requirements – NPR 7123.1B
- NASA FAR Supplement Part 1852 - NFS 1852
3.2 I/O specifications:
- Serial RapidIO - SRIO 3.1
- Ethernet (IEEE 802.3 10/100)
- X Attachment User Interface (XAUI) - IEEE 802.3ae
- ESA SpaceWire Standard - ECSS-E-ST-50-12C
- ESA Remote Memory Access Protocol (RMAP) Standard - ECSS-E-ST-50-52C
- Time Triggered Ethernet (TTE) Standard, SAE AS6802
- Joint Electron Device Engineering Council (JEDEC) Standard DDR3 and DDR4
Specifications
3.3 Reference Documents
The following list of reference documents provides context for the architecture in Figure 1:
- ARM Documents – http://www.arm.com/products/index.php
- Linaro Documents - http://www.linaro.org/
- GEM5 Documents - http://www.gem5.org/ http://www.arm.com/products/index.php http://www.linaro.org/ http://www.gem5.org/
4.0 Description of Work to be performed:
The following is a description of work to be performed under the contract:
4.1 Management
4.1.1 Project Management
- The Contractor shall appoint a dedicated Project Manager at contract award that will continue through completion to direct and manage the HPSC project.
- The Contractor's Project Manager shall have responsibility for the overall technical performance, resource management, and schedule management of the contractual effort and all subcontracts.
- The Contractor's Project Manager shall report to a level of company management appropriate to ensure prompt resolution of all problems.
- The Contractor shall provide a Project Management Plan as specified in 5.1 at project kickoff and shall provide updates to the plan at PDR and CDR.
4.1.2 Schedule Management
- The Contractor shall establish, implement, and maintain an integrated scheduling system consistent with their corporate procedures and documented in the Project Management Plan.
- The Contractor shall provide and maintain an Integrated Master Schedule (IMS).
- The Contractor shall obtain approval from the Government prior to making any non-administrative changes to the IMS baseline.
4.1.3 Earned Value Management
- The Contractor shall apply the principles and processes of EVM (at a minimum of
WBS level 2) to provide effective and objective technical, schedule, and cost performance measurement.
- The Contractor shall implement an Earned Value Management System (EVMS) that complies with the Industry Guidelines for Earned Value Management Systems (ANSI/EIA-748-A), including for the NASA Solicitation and Contract Clause the following: NFS 1852.234-1 and NFS 1852.234-2 with Alternate 1.
Validation of the contractor’s EVMS is not required.
- In the event that requirements written in this SOW conflict with requirements in ANSI/EIA-748-A, the contractor shall give precedence to ANSI/EIA-748-A.
- The Contractor shall prepare an EVMS Plan which shall be incorporated into the Project Management Plan.
- The Contractor shall establish the initial Performance Measurement Baseline (PMB) as soon as possible after contract award, but no later than 180 calendar days thereafter.
- The PMB shall cover the entire technical scope of the work on the contract and shall include realistic schedules integrated with the appropriate resources required to accomplish all of the related tasks. The PMB shall be presented and reviewed at the Integrated Baseline Review (IBR).
- The Contractor shall provide monthly Contractor Performance Report CPR describing current status versus the established baseline in accordance with the contractor’s standard EVMS format (consistent with ANSI/EIA-748-A).
4.1.4 Risk Management
- The contractor shall perform project risk management consistent with the contractor’s internal risk management processes.
- The contractor shall provide a Risk Management Plan as a section of the Project
Management Plan.
- The Risk Management Plan shall maintain a list of possible descope options.
4.1.5 Configuration Management
- The contractor shall perform project configuration management consistent with the contractor’s internal configuration management processes.
- The contractor shall provide a Configuration Management Plan as a section of the Project Management Plan.
4.1.6 System Engineering
- The contractor shall perform project system engineering in accordance with NPR
7123.1B that specifies the contractor's systems engineering approach for requirements development; technical solution definition; design realization;
product evaluation; product transition; and technical planning, control, assessment, and decision analysis.
- The contractor shall provide a System Engineering Management Plan (SEMP) as a section of the Project Management Plan.
4.1.7 Software Engineering
- The contractor shall perform project software engineering consistent with the contractor’s internal software engineering processes.
- The contractor shall provide a Software Management Plan as a section of the
Project Management Plan.
4.1.8 Commercialization
- The contractor shall provide a Commercialization Plan, addressing the Chiplet and
System Software, as a section of the Project Management Plan. This plan shall identify the anticipated vendor of the HPSC Chiplets, which may be an operating division within the proposer’s organization or an external partner.
If external partner is identified, the Commercialization Plan shall identify the responsibilities of each party and expected key contractual issues between parties.
This plan shall identify the approach to be utilized to market and sell chiplets, development systems, and development assistance services. The plan shall also identify expected minimum quantity buys and handling of low quantity orders with respect to minimum foundry run and packaging lot sizes. The plan shall address how the contractor will meet market needs for bare die, non-space qualified packaged parts, space qualified packaged parts, and custom packaging requests (including hermetic, non-hermetic and multi-chip module packages).
4.1.9 Project Kick-Off
- The contractor shall initiate the project by conducting a Kick-Off Review providing an overview of the content provided in the Project Management Plan, and delivering an Initial Financial Report. The Contractor shall prepare a presentation package to the COR one week prior to the review. A copy shall also be delivered to the CO (via email) not later than a week after the presentation. Format:
Contractor format is acceptable. MS Word or PDF shall be used for text documents, MS Excel or PDF shall be used for spreadsheet and graphic data, and MS PowerPoint or PDF shall be used for presentation material.
- The Contractor shall provide a Project Management Plan as specified in 5.1 one week prior to the project Kick-Off Review. The Plan shall be updated as needed and delivered no later than one week prior to review meetings and/or technical interchange meetings as designated by the government.
4.1.10 Monthly Reporting
On a monthly basis throughout the execution of the contract, the contractor shall conduct a Monthly Project Status Meeting, and deliver a Monthly Project Status Report, a Monthly Financial Report, and a Contract Performance Report (CPR) (as stated in 4.1.3).
- The Contractor shall provide Monthly Project Status Reports as specified in 5.2.
- The Contractor shall conduct Monthly Project Status Review teleconferences, and shall facilitate this by providing a presentation package providing an overview of the material in the Monthly Project Status Reports.
4.1.11 Quarterly Reporting
On a quarterly basis throughout the execution of the contract, the contractor shall conduct a Quarterly Project Status Review, and deliver a Quarterly Project Status Report and a Quarterly Financial Report.
- The Contractor shall provide Quarterly Project Status Reports as specified in
5.2. The Quarterly Project Status Report replaces the Monthly Project Status Report for that month.
- The Contractor shall conduct Quarterly Project Status Review meetings at the Contractor facilities, and shall facilitate this by providing a presentation package providing an in-depth view of the material in the Quarterly Project Status Reports.
- The Quarterly Project Status Review replaces the Monthly Project Status Review teleconference for that month.
4.2 Preliminary Design Phase
This phase encompasses the initial design as described in the Kick-Off Review.
Deliverables during this phase include preliminary specifications and a preliminary Chiplet emulator (listed in Table 5.3). This phase culminates with the Preliminary Design Review (PDR).
4.2.1 Chiplet Preliminary Design
- The contractor shall perform the preliminary design of the Chiplet consistent with the requirements listed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
- As documentation of the Chiplet preliminary design, the contractor shall provide a Preliminary Chiplet Specification as specified in 5.3.1 no later than one week prior to the PDR. The Preliminary Chiplet Specification shall be updated as needed and delivered no later than one week prior to review meetings and/or technical interchange meetings as designated by the government.
4.2.2 System Software Preliminary Design
- The contractor shall perform the preliminary design of the System Software consistent with the requirements listed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
- As documentation of the System Software preliminary design, the contractor shall provide a Preliminary System Software Specification as specified in 5.4.1 no later than one week prior to the PDR. The Preliminary System Software Specification shall be updated as needed and delivered no later than one week prior to review meetings and/or technical interchange meetings as designated by the government.
4.2.3 Evaluation Board Preliminary Design
- The contractor shall perform the preliminary design of the Evaluation Board consistent with the requirements listed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
- As documentation of the Evaluation Board preliminary design, the contractor shall provide a Preliminary Evaluation Board Specification as specified in 5.5.1 no later than one week prior to the PDR. The Preliminary Evaluation Board Specification shall be updated as needed and delivered no later than one week prior to review meetings and/or technical interchange meetings as designated by the government.
4.2.4 Preliminary Chiplet Emulator
- The contractor shall provide a Chiplet Emulator (with user’s guide) consistent with the requirements listed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
4.2.5 Preliminary Design Review
- At the PDR, the contractor shall present the content of the Preliminary Chiplet
Specification, the Preliminary System Software Specification, and the Preliminary Evaluation Board Specification as specified in 5.3.1, 5.4.1, and 5.5.1.
- The Contractor shall prepare a presentation package in an appropriate electronic format no later than seven (7) calendar days prior to the scheduled review.
- Format: Contractor format is acceptable. MS Word or PDF shall be used for text documents, MS Excel or PDF shall be used for spreadsheet and graphic data, and MS PowerPoint or PDF shall be used for presentation material.
4.3 Detailed Design Phase
This phase encompasses finalization of the Chiplet design, the associated System Software design, and the Evaluation Board. Deliverables during this phase include interim specifications and the final Chiplet emulator (listed in Table 6.4). This phase culminates with the Critical Design Review (CDR).
4.3.1 Chiplet Detailed Design
- The contractor shall perform the detailed design of the Chiplet consistent with the requirements listed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
- As documentation of the Chiplet detailed design, the contractor shall provide a Interim Chiplet Specification as specified in 5.3.2 no later than one week prior to the CDR. The Interim Chiplet Specification shall be updated as needed and delivered no later than one week prior to review meetings and/or technical
4.3.2 System Software Detailed Design
- The contractor shall perform the detailed design of the System Software consistent with the requirements listed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
- As documentation of the System Software detailed design, the contractor shall provide a Interim System Software Specification as specified in 5.4.2 no later than one week prior to the CDR. The Interim System Software Specification shall be updated as needed and delivered no later than one week prior to review meetings and/or technical interchange meetings as designated by the government.
4.3.3 Evaluation Board Detailed Design
- The contractor shall perform the detailed design of the Evaluation Board consistent with the requirements listed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
- As documentation of the Evaluation Board detailed design, the contractor shall provide a Interim Evaluation Board Specification as specified in 5.5.2 no later than one week prior to the CDR. The Interim Evaluation Board Specification shall be updated as needed and delivered no later than one week prior to review government.
4.3.4 Final Chiplet Emulator
- The contractor shall provide an updated Chiplet Emulator (with user’s guide updates) consistent to incorporate any changes in the Chiplet design that occur during the Detailed Design Phase.
4.3.5 HPSC Test Plan
- The contractor shall provide an HPSC Test Plan as specified in 5.6 that documents how Chiplet, System Software, and Evaluation Boards will be verified against their requirements.
- The test plan shall address acceptance testing of delivered Evaluation Boards integrated with System Software.
- The HPSC Test Plan shall be provided no later than one week prior to the CDR.
The interim Chiplet Specification Document shall be updated as needed and delivered no later than one week prior to review meetings and/or technical
4.3.6 Fabrication Plan
- The contractor shall deliver a Fabrication Plan as specified in 5.7 no later than one week prior to the CDR.
4.3.7 Critical Design Review
- At the CDR, the contractor shall present the content of the Interim Chiplet
Specification, the Interim System Software Specification, the Interim Evaluation Board Specification, HPSC Test Plan and Chiplet Fabrication Plan as specified in 5.3.2, 5.4.2, 5.5.2, 5.6 and 5.7.
- The Contractor shall prepare a presentation package in an appropriate electronic format no later than seven (7) calendar days prior to the scheduled review.
- Format: Contractor format is acceptable. MS Word or PDF shall be used for text
4.4 Fabrication Phase
This phase encompasses fabrication of the Chiplet and Evaluation Board, implementation of the System Software, and development of test procedures. This phase culminates with the completion of Chiplet devices, completed System Software, and fabricated and assembled Evaluation Boards.
4.4.1 Chiplet Fabrication
- The contractor shall fabricate the Chiplet consistent with the requirements listed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
4.4.2 System Software Implementation
- The contractor shall implement the System Software consistent with the requirements listed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
4.4.3 Evaluation Board Fabrication
- The contractor shall fabricate and assemble the Evaluation Board consistent with the requirements listed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
4.4.4 HPSC Test Procedures
- The contractor shall provide HPSC Test Procedures as specified in 5.8 that documents the test that will be performed to verify the Chiplet, System Software, and Evaluation Boards against the requirements listed in the “Requirements for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document.
- The HPSC Test Procedures shall be provided no later than five (15) days prior to the execution of tests.
4.5 Test and Characterization Phase
This phase encompasses comprehensive testing and characterization of the Chiplet hardware (in ambient conditions), the System Software, and Evaluation Boards.
This is the final phase of the program and culminates in a Final Presentation and the delivery of Chiplets, Evaluation Boards, System Software, and final documentation (listed in Table 5.6).
4.5.1 Chiplet Test and Characterization
- The contractor shall test and characterize the Chiplet using test procedures as specified in 5.8.
- The contractor shall provide Chiplet test reports as specified in 5.9 no later than one week prior to the Final Review.
4.5.2 System Software Test and Characterization
- The contractor shall test and characterize the System Software using test procedures as specified in 5.8.
- The contractor shall provide System Software test reports as specified in 5.9 no later than one week prior to the Final Review.
4.5.3 Evaluation Board Test and Characterization
- The contractor shall test and characterize the Evaluation Board using test procedures as specified in 5.8.
- The contractor shall provide Evaluation Board test reports as specified in 5.9 no later than one week prior to the Final Review.
4.5.4 Final Documentation
- As documentation of the completed Chiplet design, the contractor shall provide a
Final Chiplet Specification as specified in 5.3.3 no later than one week prior to Final Review. The Final Chiplet Specification shall be updated as needed and delivered no later than one week prior to review meetings and/or technical interchange meetings as designated by the government.
- As documentation of the completed System Software design, the contractor shall provide a Final System Software Specification as specified in 5.4.3 no later than one week prior to Final Review. The Final System Software Specification shall be updated as needed and delivered no later than one week prior to review meetings and/or technical interchange meetings as designated by the government.
- As documentation of the completed Evaluation Board design, the contractor shall provide a Final Evaluation Board Specification as specified in 5.5.3 no later than one week prior to Final Review. The Final Evaluation Board Specification shall be updated as needed and delivered no later than one week prior to review government.
- As document of the completed project, the contractor shall provide an HPSC Final Project Report as specified in 5.10 no later than one week prior to the Final Review
4.5.5 HPSC Final Review
- At the HPSC Final Review, the contractor shall present the content of the HPSC
Final Project Report as specified in 5.10.
- The contractor shall prepare a presentation package in an appropriate electronic format seven (7) calendar days prior to the scheduled review.
- Format: Contractor format is acceptable. MS Word or PDF shall be used for text
Table 4.1 The following shows the planned meetings, and its frequency/timeframe, duration, and location for this project:
Meeting Frequency / Date Duration Location
Project Status Meetings
Monthly 4 Hrs Via Telecon or Visit to Contractor
Site
Integrated Baseline Review
6 months after award 1 Day Contractor
Preliminary Design Review
6 months after award 2 Days Contractor
Quarterly Status Review
Quarterly every 3 months. 1 Day Contractor
Critical Design Review
27 months after award 2 Days Contractor
Final Review 45 months after award 2 Days Contractor
5.0 Data Requirements
The following provides data requirements for project deliverables.
5.1 Project Management Plan
The Project Management Plan establishes the guidelines and processes with which the HPSC project will be executes. This plan shall include, but not be limited to, the following:
- Project Scope
- Program Management Approach
- Work Breakdown Structure (to 4 levels)
- System Engineering Management Plan (in accordance with NPR 7123.1B)
- Software Management Plan (including software classification)
- Earned Value Management System (EVMS) Plan and Cost Baseline
- Option Implementation Plan (providing description of how options would be incorporated into the project scope if exercised)
- Schedule Management Plan
- Schedule Baseline
- Milestone List
- Risk Management Plan (with risk list)
- Descope Plan (including key decision dates for implementation)
- Commercialization Plan
Format: Contractor format is acceptable. MS Word or PDF shall be used for text documents, MS Excel or PDF shall be used for spreadsheet and graphic data, and MS PowerPoint or PDF shall be used for presentation material.
5.2 Project Status Reports
The contractor monthly and quarterly Project Status Reports provide the government insight into the technical, schedule, and cost status of the project. Project Status Reports shall include, but not be limited to, the following:
- Technical progress during the previous month
- Major procurement/subcontract status
- Project schedule status
- Project financial status
- Risk status
- Issues and concerns
- Planned activities for the following month (or quarter) Format: Contractor format is acceptable. MS Word or PDF shall be used for text documents, MS Excel or PDF shall be used for spreadsheet and graphic data, and MS PowerPoint or PDF shall be used for presentation material.
5.3 Chiplet Specification
5.3.1 Preliminary Chiplet Specification
The Preliminary Chiplet Specification shall include, but not be limited to, the following:
- Chiplet Requirements and Verification Matrix
- Chiplet Conceptual Design o Block diagrams o List and description of memory and I/O interfaces provided o Listing of the intellectual property (IP) cores to be utilized o Description of how IP cores within the HPSC Chiplet are to be interconnected o Description of any custom-designed cores and modifications to existing IP cores o Description of boot and configuration manager o Description of the debug and trace capabilities for the HPSC Chiplet o Description of power scaling capabilities o Description of hardware implemented fault tolerance capabilities o Description of timing and synchronization capabilities o Description of the foundry process and cell libraries proposed for the development of the HPSC Chiplet o Expected die size and floor plan
- Theory of Operation o Boot process o Configuration control o Time synchronization o Interrupt handling o Power management o Fault management operation, including fault tree and mitigation for each fault type o Time and space partitioning per ARINC-653 o Symmetric and asymmetric parallel processing
- Analysis o Expected upset rate (for each functional block within the Chiplet) o Expected failure rate o Timing (showing sufficient margin at process/temperature corners) o Power and signal integrity o Fault detection and correction
- Package Concepts (with consideration to the high speed interfaces)
- Assured Integrity Strategy
- Chiplet Emulator Design and Operation Format: Contractor format is acceptable. MS Word or PDF shall be used for text documents, MS Excel or PDF shall be used for spreadsheet and graphic data, and MS PowerPoint or PDF shall be used for presentation material.
5.3.2 Interim Chiplet Specification
The Interim Chiplet Specification shall include updates to the Preliminary Chiplet Specification, as well as Chiplet datasheet information the addition of the following including, but not limited to the following:
- Package Pinouts
- Signal Names and Descriptions/Specifications
- Package Drawings
- Electrical Characteristics o Signal Level Maximum, Minimum, Typical o Signal Timing Specifications and Diagrams o Clock Frequency Specifications o Power Dissipation Specifications o Decoupling Scheme
- Power up Sequence
- Resets Format: Contractor format is acceptable. MS Word or PDF shall be used for text
5.3.3 Final Chiplet Specification
The Final Chiplet Specification shall include all final revisions to the Interim Chiplet Specification, including the following, but not be limited to, Chiplet User’s Guide information:
- Boot-up
- Software load
- Clock Settings
- Power Settings
- Memory (internal and external)
- On-Chip Bus
- Timers
- DRAM Controller
- High-Speed Serial Interface Controller
- External Interface Connections
- Debug Port Format: Contractor format is acceptable. MS Word or PDF shall be used for text
5.4 System Software Specification
5.4.1 Preliminary System Software Specification
The Preliminary System Software Specification shall include, but not be limited to, the following:
- System Software Requirements and Verification Matrix
- System Software Conceptual Design o Boot and configuration controller software o Operating systems o Board support packages for operating systems o Trace and debug capabilities o Software development environments o Description of software implemented fault management capabilities
- List of 3rd party software that will be used
- List of any modifications, settings, and/or configuration parameters for 3rd party software
- User’s Guide for 3rd party software Format: Contractor format is acceptable. MS Word or PDF shall be used for text
5.4.2 Interim System Software Specification
The Interim System Software Specification shall include updates to the Interim System Software Specification, including:
- Detailed design of custom software
- User’s Guide for custom software
- Description of board support package
- Description of boot software Format: Contractor format is acceptable. MS Word or PDF shall be used for text
5.4.3 Final System Software Specification
The Final System Software Specification shall include all final revisions to the Interim System Software Specification.
Format: Contractor format is acceptable. MS Word or PDF shall be used for text
5.5 Evaluation Board Specification
5.5.1 Preliminary Evaluation Board Specification
The Preliminary Evaluation Board Specification shall include, but not be limited to, the following:
- Evaluation Board Requirements and Verification Matrix
- Detailed block diagram
- Description of I/O interfaces
- Concept of operation Format: Contractor format is acceptable. MS Word or PDF shall be used for text
5.5.2 Interim Evaluation Board Specification
The Interim Evaluation Board Specification shall include updates to the Interim Evaluation Board Specification Document, including:
- Schematic
- Layout and assembly drawings Format: Contractor format is acceptable. MS Word or PDF shall be used for text
5.5.3 Final Evaluation Board Specification
The Final Evaluation Board Specification shall include all final revisions to the Interim Evaluation Board Specification. Additionally, the Final Evaluation Board Specification Document shall include, but not be limited to, the following sections comprising User’s Guide information:
- Board Introduction/Overview
- Block Diagram
- On-board Features
- Connectors
- Connector Pinouts
- Signal Names and Descriptions
- Power Supply Specifications
- Boot Instructions
- Debug Support
- Interface Specifications Format: Contractor format is acceptable. MS Word or PDF shall be used for text documents, MS Excel or PDF shall be used for spreadsheet and graphic data, and MS PowerPoint or PDF shall be used for presentation material.
5.6 HPSC Test Plan
The HPSC Test Plan shall include, but not be limited to, the following:
- Overview of the Design of the Chiplet, System Software, and Evaluation Boards
- Overview of the Chiplet and System Software Theory of Operation
- Description of the verification process of the Chiplet and System Software o List of tests (traceable to verification matrix), parameters, and acceptable margins o Test configurations o Test flow
Format: Contractor format is acceptable. MS Word or PDF shall be used for text documents, MS Excel or PDF shall be used for spreadsheet and graphic data, and MS PowerPoint or PDF shall be used for presentation material.
5.7 Fabrication Plan
The Fabrication Plan shall include, but not be limited to, the following:
- Overview of the design of the Chiplet
- Overview of the floor plan of the Chiplet
- Description of the fabrication process for the Chiplet, including tolerances and expected yields
- Description of the packaging process for the Chiplet
- Description of the fabrication plans and processes for the Evaluation Board
- Fabrication Schedule with interim reviews, milestones, and decision points
- Fabrication risks and risk management
- Deliverables Format: Contractor format is acceptable. MS Word or PDF shall be used for text
5.8 HPSC Test Procedures
The HPSC Test Procedures for the Chiplet, System Software, and Evaluation Boards shall be traceable to the HPSC Test Plan specified in 5.6, and shall include, but not be limited to, the following:
- Description of test objectives
- Description and illustration of test configurations
- Test steps
- Pass/fail criteria
- Data to be captured Format: Contractor format is acceptable. MS Word or PDF shall be used for text documents, MS Excel or PDF shall be used for spreadsheet and graphic data, and MS PowerPoint or PDF shall be used for presentation material.
5.9 HPSC Test Reports
The HPSC Test Reports for the Chiplet, System Software, and Evaluation Boards shall document the results of the test conducted based on the HPSC Test procedures specified in 5.8. Test reports shall include, but not be limited to, the following:
- As run test procedures
- Test data collected
- Assessment of test results
- List and description of any test failures
- Lessons learned Format: Contractor format is acceptable. MS Word or PDF shall be used for text
5.10 HPSC Final Report
The HPSC Final Report shall provide a summary of the technical, schedule, and cost performance of the completed project, The Final Report shall include, but not be limited to, the following:
- Program summary
- Overview of the design of the Chiplet, System Software, Evaluation Board
- Overview of test plans and procedures
- Chiplet test results
- System Software test results
- Evaluation Board test results
- Schedule summary
- Completed milestone list
- Program cost breakdown
- Lessons learned Format: Contractor format is acceptable. MS Word or PDF shall be used for text
6.0 Deliverables
The following provides data requirements for project deliverables.
Table 6.1 The Contractor shall provide NASA with the following report/review deliverables:
Item No.
Task Ref.
Deliverable Description Qty. Due Date Delivery
Instructions
NPR 6000.1
Class
6.1 5.2 Monthly Project Status Report 1
1 Week prior to Monthly
Project Status Review
Electronically (via email)
Not Applicable
6.2 4.1.3 Integrated Baseline Review
Presentation
1 Week prior to IBR
Electronically (via email)
Not Applicable
6.3 4.2.5 Preliminary Design Review
Presentation
1 Week prior to PDR
Electronically (via email).
Not Applicable
6.4 5.2 Quarterly Project Status
Report
1 Week prior to Quarterly
Project Status Review
Electronically (via email)
Not Applicable
6.5 4.3.7 Critical Design Review
Presentation
1week prior to
CDR
Electronically (via email)
Not Applicable
6.6 4.5.5 Final Presentation 1 1 week prior to final deliveries
Electronically (via email)
Not Applicable
6.7 5.1 Project Management Plan 1 1 week prior to
Kick-Off Review
Delivered to COR and CO electronically
(via email)
Not Applicable
6.8 4.1.9 Kick-Off Review Presentation 1 Within 1 month after contract award
Electronically (via email)
Not Applicable
6.9 5.3.1
Preliminary Chiplet Specification Document (Including preliminary
Analyses/Plans)
1 PDR
Electronically
(via email) Not
Applicable
6.10 5.4.1 Preliminary System Software
Specification Document
1 PDR
Electronically (via email)
Not Applicable
6.11 5.5.1 Preliminary Evaluation Board
Specification Document
1 PDR
Electronically (via email)
Not Applicable
6.12 4.2.5 Detailed Block Diagrams of the Chiplet Evaluation Board Design
1 PDR
Electronically
(via email) Not
Applicable
6.13 4.2.4 Preliminary Chiplet Emulator and User’s Guide
1 PDR
Electronically (via email)
Not Applicable
Task Ref.
Deliverable Description Qty. Due Date Delivery
Instructions
NPR 6000.1
Class
6.14 5.3.2 Interim Chiplet Specification
Document (Including Updated Analyses/Plans)
1 CDR
Electronically
(via email) Not
Applicable
6.15 5.4.2 Interim System Software Specification Document 1 CDR
Electronically (via email)
Not Applicable
6.16 5.5.2 Interim Evaluation Board Specification Document 1 CDR
Electronically (via email)
Not Applicable
6.17 5.6 Chiplet Test Plan 1 CDR Electronically
(via email) Not
Applicable
6.18 5.7 Fabrication Plan 1 CDR Electronically
(via email) Not
Applicable
6.19 4.3.4 Final Chiplet Emulator and
User’s Guide 2
9 months after the start of the
Detailed Design Phase
Electronically (via email)
Not Applicable
6.20 4.3.7 Chiplet Evaluation Board
Schematics 1 CDR Electronically
(via email) Not
Applicable
6.21 5.8 Test Procedures for Chiplet, System Software and Evaluation Boards
1 ea
15 days prior to the execution of tests
Electronically (via email)
Not Applicable
6.22 5.3.3 Final Chiplet Specification Document (Including final
Analyses/Plans)
45 months after contract award
Electronically (via email) Not
Applicable
6.23 5.4.3 Final System Software…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .