HPSC_DRFP_Requirements.pdf

Attachment A-1 Requirements for the High Performance Spaceflight Computing (HPSC) Processor

Chiplet

4/19/2016

The government team has devised the HPSC “Chiplet” concept that (a) meets the National Aeronautics and Space Administration (NASA) and United States Air Force (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 AMBA-bus bridges allowing multiple Chiplets to be tiled or cascaded to increase bandwidth or to improve fault tolerance.

As described in the “Statement of Work (SOW) for the Development of the High Performance Spaceflight Computing (HPSC) Processor Chiplet” document, the government desires to procure:

1. The Chiplet, as described above, in both bare die and packaged forms

2. An emulator of the Chiplet design.

3. Evaluation Boards containing the Chiplet, memory and peripheral circuitry as required to develop codes, test and evaluate the Chiplet, and

4. A System Software suite and software development environment as required to support software development.

This document provides the technical requirements (as illustrated in Figure 1) for these deliverables.

Figure 1 – HPSC Technical Requirements

The ARM architecture, shown below in Figure 2, illustrates the desired Chiplet topology but is not meant to prescribe the architecture used by the contractor.

Figure 2 - Architectural block diagram for the HPSC "Chiplet."

The requirements below are assigned a rank as follows:

Level 1 – Mandatory requirements. Offerors must meet these requirements.

Level 2 – Flexible requirements. Where offerors determine that a requirement is inconsistent with good design practice, incompatible with other requirements, or incurs excessive penalties in power, cost complexity or real estate, the offeror must provide an explanation and must offer alternatives that are consistent with the intent or rationale of the requirement.

Level 3 – Desired features. Where offerors determine that a requirement is inconsistent with good design practice, incompatible with other requirements, or incurs excessive penalties in power, cost complexity or real estate, the offeror must provide an explanation and may optionally offer alternatives that are consistent with the intent or rationale of the requirement.

This document will be modified at contract award to incorporate any changes necessary based on the successful offeror’s approach and commitment to meeting the Flexible Requirements (Level 2) and Desirable Features (Level 3). This may result in some of these requirements changing to Mandatory (Level 1) requirements in the awarded contract.

1 Chiplet

1.1 General Processing

1.1.1 General Architecture and Performance

Identifier Requirement Rank Rationale

1.1.1.1 The Chiplet shall be based on

commercially available hardware and software IP (processing cores, external I/O and memory interfaces, software stack and development environment).

Level 1 Technologies from an active development ecosystem can be leveraged.

1.1.1.2 The Chiplet shall be capable of

executing multiple concurrent applications and support parallel processing across the set of processing cores.

Level 1 The Chiplet will readily support both symmetric and asymmetric parallel processing.

1.1.1.3 The Chiplet shall support ARINC-

653 time and space partitioning.

Level 1 Needed for human rated systems and potentially for future robotic systems.

1.1.1.4 The Chiplet shall have a

minimum of 8 general-purpose processor cores, which are 64 bits wide with full IEEE 754 floating-point capability (including double precision) and have a 128 bits wide SIMD capability.

Level 1 Provide multiple processing cores in order to support highly parallel applications, accelerate high-throughput kernels and provide a high degree of granularity for power management, and fault tolerance. Cores may be grouped into clusters in order to optimize inter-core communication and interactions as well as cache accesses.

1.1.1.4.1 The Chiplet general-purpose

processor cores shall have L1 instruction and data caches that are a minimum of 32 KB.

Level 1 It is not possible to optimize cache size for a specific application as this is intended to be a general purpose computer, so typically larger is better within real estate, access speed and power constraints.

1.1.1.4.2 The Chiplet processor cores, shall have access to a combined L2 cache that is a minimum of

256 KB.

Level 1 Shared L2 cache is desired, but it is typically non-optimal to share an L2 cache across a large number of processor cores, so clustering is generally desirable and is acceptable for this machine. It is not possible to optimize cache size for a specific application, so larger is generally better within power, speed, and real estate constraints.

1.1.1.4.3 The Chiplet shall provide cache

coherency across cache memories within the Chiplet while also providing the capability for the coherency to be dynamically and selectively disabled.

Level 1 Some applications require cache coherency for optimal performance. However, cache coherency in other applications is problematic for fault tolerance reasons. Cache coherency is not required across multiple Chiplets.

1.1.1.5 The Chiplet shall have a

performance threshold of 9 GOPS and goal of 15 GOPS.

Level 1

1.1.1.5.1 The Chiplet shall have a power

consumption threshold of 10W and a goal of 7 W under the following conditions: 9 to 15 GOPS throughput and 50% utilization of memory and I/O ports.

Level 1

1.1.1.5.2 The Chiplet shall have a power

consumption threshold of 1 W and a goal 0.5 W when operating under the following conditions:

0.3 to 1.0 GOPS throughput and 10% utilization of memory and I/O ports.

Level 2

1.1.1.6 The Chiplet shall have the

capability of seamlessly tiling or cascading multiple Chiplets.

Level 1 Provides the ability to implement a multi-Chiplet system (with no external hardware) for redundancy and/or increasing processing capability. It is anticipated that the SRIO I/O ports, working as a bridge across multiple Chiplet-internal networks, (e.g., AMBA busses in an ARM based system) will provide this function. Note that hardware mediated cache coherency between Chiplets in a multi-Chiplet system is not required.

1.1.1.7 The Chiplet shall have built-in

self-tests for all Chiplet functions.

Level 2 Provides ability to detect faulty IP cores during boot or application execution.

1.1.2 Timers and Interrupts

1.1.2.1 The Chiplet shall have a system

clock from which all other Chiplet clocks and timers are derived.

Level 1

1.1.2.1.1 The system clock shall support

underclocking (e.g. factor of 2, 4, 8 and 16) for power and performance management.

Level 2 This allows scaling of Chiplet power consumption based on the MIPS/MHz required for the given user application.

1.1.2.2 The Chiplet shall have an

elapsed timer that increments on the system clock for maintaining time knowledge across all processor cores in the system

Level 1 This provides a monotonically increasing timer that can be used as mission time (e.g. MET, SCT, etc.) and can also be used to time tag events is required for most space applications.

1.1.2.2.1 The elapsed timer shall have a

minimum resolution of 32 bits for seconds and 32 bits for subseconds that are read-accessible from all processor cores. Least significant bits that are not clocked shall be set to 0.

Level 2 This provides consistency with CCSDS time formats and allows for future upgrades.

1.1.2.2.2 The elapsed timer shall

synchronize on the external time pulse with a maximum latency of 10 nsec.

Level 2 A highly stable oscillator that is external to the Chiplet will provide regular synchronization pulses (e.g. 1 PPS) to reduce the elapsed timer clock errors.

1.1.2.2.3 The elapsed timer shall free run

in the absence of the external time pulse.

Level 2 Time is maintained in absence of external pulse.

1.1.2.2.4 The elapsed timer shall be

settable from software, in a fault tolerant manner.

Level 2 Rogue software cannot simply make a single write operation and change the elapsed timer.

1.1.2.2.5 The elapsed timer shall produce

a sync pulse that can be sent to its neighboring Chiplet(s).

Level 2 A Chiplet can generate the system sync pulse for the other Chiplets in the tiled or cascaded system (see 1.1.1.6.

1.1.2.2.6 The elapse timer shall continue

to update when the Chiplet is in a sleep/standby mode.

Level 2 Elapsed time must be maintained regardless of processor state.

1.1.2.3 The Chiplet shall have a real-

time interrupt timer for each processor core with a resolution

Level 1 This defines a base rate group for a time partitioned real-time control system.

of 32 bits for seconds and 32 bits for subseconds. Least significant bits that are not clocked shall be set to 0.

1.1.2.3.1 The real-time interrupt timer shall

increment on the Chiplet system clock and maintain phase with the elapsed timer.

Level 2 This enables a deterministic execution time for rate groups in a real-time control system.

1.1.2.3.2 The real-time interrupt timer shall

generate an interrupt and reload the programmed value at each expiration of the timer.

Level 2 This is required for rate group operation.

1.1.2.3.3 The real-time interrupt timer shall

be maskable.

Level 2 This allows for periods of operation when interrupts cannot be accommodated.

1.1.2.4 The Chiplet shall have a

watchdog timer for each processor core.

Level 1 This provides a mechanism to verify critical software health on processor core.

1.1.2.4.1 The watchdog timer shall be a 40

bit (minimum) timer, incremented on the system clock.

Level 2 This allows a long period of execution between watchdog updates.

1.1.2.4.2 The watchdog timer shall be

disabled at POR.

Level 2 This prevents the boot process from being interrupted by the watchdog.

1.1.2.4.3 Upon expiration, the watchdog

timer shall update its status register to indicate that it expired, notify the boot & configuration manager that its processor core is unhealthy and then disable itself.

Level 2 The boot and configuration manager will be responsible for rebooting or powering off the processor core with the faulty software.

1.1.2.4.4 The watchdog timer shall have

enable/disable control registers that are accessible in a fault tolerant manner.

Level 2 Software can disable the watchdog, through some fault tolerant mechanism, so that lower criticality software can execute on a processor core without requiring timely resetting of the watchdog.

1.1.2.4.5 The watchdog timer status

register shall be accessible to the boot and configuration manager.

Level 2 A watchdog expiration would be monitored by a health and configuration manager.

1.1.2.4.6 The watchdog timer shall have a

programmable expiration value.

Level 2 This allows flexibility in setting the maximum time before the processor is determined to be faulty.

1.1.2.5 Each processor core shall have

a minimum of 2 general-purpose software programmable timers, with a goal of 4 timers per processor core.

Level 2 This provides a mechanism to support time-critical, aperiodic functions.

1.1.2.5.1 Each general purpose

programmable timer shall a minimum of 40 bits, shall be clocked by the system clock, and shall generate a maskable interrupt upon expiration to its associate processor core.

Level 2 This allows a long period of execution between programmable timer interrupts.

1.1.2.5.2 The general purpose software

programmable timer shall have a programmable expiration value

Level 2 This allows flexibility in setting events asynchronous to the real-time interrupt timers.

1.1.2.6

The Chiplet shall have a minimum of 8 external interrupt inputs to the Chiplet.

Level 1

1.1.2.7

Each processor core shall have a minimum of 8 general-purpose interrupts.

Level 2 Any processor core can be assigned to handle all external interrupts.

1.1.3 Chiplet Configuration Control

1.1.3.1 The Chiplet shall have a Power

on Reset (PoR) pin which has asynchronous assert and synchronous de-assert.

Level 1 An external reset for the Chiplet will cause the entire Chiplet to reset in a prescribed, synchronous manner.

1.1.3.2 The Chiplet shall have a Chiplet

configuration controller that manages the POR and booting of each processor core.

Level 1

1.1.3.2.1 The Chiplet configuration

controller shall manage, in a fault tolerant manner, the configuration of the Chiplet including routing of interrupts, control of status and configuration registers, and management of fault responses.

Level 2 This provides a single fault tolerant entity to control chiplet configuration.

1.1.3.2.2 The Chiplet configuration

controller shall be capable of running the built-in self tests of all IP cores in the Chiplet.

Level 2 Knowledge of chiplet status is necessary for configuration management.

1.1.3.2,3 The Chiplet configuration controller shall access nonvolatile external memory to determine what Chiplet functions are enabled at power on, the boot time out, the boot image location, the resources allocated to each processor core, the connectivity of the general-purpose processor interrupts with the external interrupt sources, the system clock rate and the bad memory block map.

Level 2 Data in this memory specifies the Chiplet devices and resources that will be enabled at power on to enable booting into a user-specified configuration.

1.1.3.2.4 The Chiplet configuration

controller shall monitor the boot of each processor core and verify that it completes before the boot timeout.

Level 2 This provides a mechanism to verify a healthy Chiplet boot.

1.1.3.2.5 The Chiplet configuration

controller shall halt the boot of a processor core and mark that processor core as unhealthy when a processor core’s boot time exceeds the boot timeout value.

Level 2 This prevents a faulty core from compromising the boot of the chiplet.

1.1.3.2.6 The Chiplet configuration

controller shall receive processor core watchdog timer expiration notifications and manage the reboot of that processor core.

Level 2 This prevents a faulty core from compromising the operation of the chiplet.

1.1.3.2.7 The Chiplet configuration

controller shall manage the boot sequence of each processor core and the Chiplet as a whole to ensure it boots up in a known good state for the devices and resources that were configured to be available at power on.

Level 2 The “known good state” of the Chiplet is specified by the boot configuration management function. It is application or mission specific, and will generally be the minimum set of hardware required to execute the minimum software suite. A generic minimum ‘known good state”, for instance, could be a single processor core, DRAM controller, SRAM controller, NVM controller and an I/O channel, e.g., an SRIO port with at least 2 functioning lanes.

1.1.3.3 The Chiplet shall provide a user

interface to the nonvolatile storage that specifies the devices and resources available at Chiplet power on, the boot timeout and the location of the boot image.

Level 2 Provides a user interface to control the configuration of the chiplet boot process and read configuration status.

1.1.4 Boot Sequence

1.1.4.1 The boot sequence shall allow

user image selection at start up based on external pins.

Level 1 Allows an external entity such as the communication subsystem or a spacecraft configuration manager to select from multiple boot or flight software images – required by many space missions for fault management and software upgrade integration.

1.1.4.2 The boot sequence shall verify

the integrity of the selected user image.

Level 1 Verify will determine that there is no data corruption in the user image.

1.1.4.3 The boot sequence shall include

verification of the health of the following devices: processor cores, on-chip network, DDR memory interface, Flash memory device interface/controller, peripheral device I/O interfaces, etc.

Level 2 This verifies that all chiplet resources are healthy and the chiplet is capable of running application code.

1.1.4.4 The boot sequence shall store

diagnostic data during the boot process into its scratchpad memory.

Level 2 This provides a mechanism to debug a failed boot sequence.

Boot status and test/diagnostic data can be used during test and debug to diagnose a failed or suboptimal boot, and by the middleware to determine system health for initial resource allocation and hardware/software configuration.

1.2 Power Management

1.2.1 The Chiplet shall have the

capability to dynamically power on/off IP cores via software control, in a fault tolerant manner.

Level 1 This allows capability and power consumption of the Chiplet to be scaled based on the IP cores required for the given user application.

1.2.2 The Chiplet shall have a

sleep/standby mode dissipating less than 100mW and performing no computational processing, while awaiting an external event in order to "wake up" in an operational state.

Level 2 This Allows the Chiplet to be placed in a sleeping state after user application initialization so that it can quickly resume execution upon receipt of an external discrete event (e.g.

external interrupt, external GPIO, etc.). The time to resume execution will be much less than the time for a cold boot and user application initialization.

1.2.3 Upon waking from the

sleep/standby mode, the processor cores shall resume execution from the point at which they were put to sleep/standby or from a well-defined wake up state within [1] second.

Level 2 This allows seamless execution of code through a sleep/standby mode.

1.2.4 The Chiplet shall maintain the

external memories while in sleep/standby mode.

Level 2 This allows seamless execution of code and maintenance of data through a sleep/standby mode.

1.3 Fault Tolerance

1.3.1 The Chiplet shall have the

capability to autonomously, in real time, detect errors, prevent propagation of these errors past well-defined error containment boundaries, resume proper execution, provide prompt notification to software, and log the errors.

Level 1 Space environments are expected to induce logic errors in the Chiplet, and capability is needed to contain the hardware fault and allow software to manage the fault recovery.

1.3.2 The Chiplet shall support N-

Modular Redundancy (NMR) through hardware and/or software techniques.

Level 3 This enables a fault-tolerant computing platform used in many space applications.

1.3.3 The Chiplet shall support parallel

checkpoint/rollback through

Level 3 This enables a fault-tolerant computing platform used in many space applications.

hardware and/or software techniques.

1.3.4 The Chiplet shall prevent

applications or devices from reading and/or writing into address spaces reserved for other applications or devices, for purposes of security and fault tolerance.

Level 2 This provides memory space partitioning and memory access protection to safeguard against faulty software or faulty hardware accesses.

1.3.5 The Chiplet shall prevent a

single hardware error from causing a violation of address protection boundaries.

Level 2 This provides memory space partitioning and memory access protection to safeguard against faulty software or faulty hardware accesses.

1.3.6 The Chiplet shall have the

capability to detect and disable communication from "babbling" IP cores.

Level 2 Faulty IP cores are contained so that they don't consume all the communication bandwidth and starve the other IP cores.

1.3.7 The Chiplet shall have fault

tolerant mechanisms for management, configuration and reset of the processor cores.

Level 2 Rogue software cannot simply make a single write operation and change the management and configuration of the processor cores.

1.3.8 A non-recoverable permanent

fault in a core shall not affect the other cores on the Chiplet.

Level 2 This ensures that Chiplet provides graceful degradation for long duration missions with high reliability requirements.

1.4 Interfaces

1.4.1 Memory

1.4.1.1 The Chiplet shall support NOR

Flash.

Level 1 This provides application program storage.

1.4.1.2 The Chiplet shall support NAND

Flash.

Level 1 This provides file system and engineering data storage.

1.4.1.3 The Chiplet shall support 2

SRAM ports.

Level 1 This provides scratchpad storage.

1.4.1.4 The Chiplet shall support

MRAM.

Level 1 This provides boot software storage.

1.4.1.5 The Chiplet shall support

EEPROM.

Level 1 This provides boot software storage.

1.4.1.6 The Chiplet shall support 2

DDR3/4 ports.

Level 1 This provides high bandwidth memory for computation.

1.4.1.6.1 DDR3/4 memory controller shall

complete and continue its refresh cycles through a system reset.

Level 2 This ensures data stored DRAM is retained when the Chiplet is reset.

1.4.1.6.2 The Chiplet shall provide EDAC

protection (at a minimum SECDED) for DDR3/4 memories.

Level 2 External memories must be robust to radiation effects.

1.4.1.6.3 The Chiplet shall support the

use of 4-bit wide DDR3/4 memories and nibble-mode interleaving.

Level 2 This provides the Chiplet EDAC the ability to correct multiple bit upsets within a single DRAM device.

1.4.1.7 The Chiplet shall support DMA

transfers between I/O and memory ports.

Level 2 This supports DMA transfers between IP cores on the Chiplet (on-chip and off-chip).

1.4.1.8 The Chiplet shall allow user

configurability to allow operation with only a single DDR3/4 or SRAM port.

Level 2 This supports system configurations where only a single port is populated.

1.4.1.9 The Chiplet shall tolerate

memory faults from single event effects, including bit upsets, SEFIs, and whole-chip failures in all memories, including DDR3/4, SRAM and MRAM.

Level 2 This ensures that the Chiplet will operate through faults that are typical in a radiation environment and also typical of a long service life.

1.4.1.10 The Chiplet shall have hardware

implemented memory scrubbers for SRAM and DDR3/4 memories.

Level 2 This prevents latent upsets from accumulating.

1.4.1.10.1 Memory scrubbers shall utilize

EDAC memory protection and respond to faults in the same manner as normal memory accesses.

Level 2 The memory scrubber operates in the background to correct memory errors and prevent them from accumulating over time.

1.4.1.11 Upon detection of an

uncorrectable bit error, the operation shall be halted and configuration controller shall be notified.

Level 2 This blocks propagation of the error and allows configuration manager to reconfigure the system in order to mitigate the fault.

1.4.1.12 The Chiplet shall maintain

correctable and uncorrectable memory error locations and counts.

Level 2 The Chiplet maintains statistics on errors for later analysis by software.

1.4.2 I/O

1.4.2.1 The Chiplet shall have a

minimum of 4 serial I/O ports, with a goal of 6 serial I/O ports, capable of being configured as XAUI or SRIO 3.1 for Chiplet-to- Chiplet and high-speed spacecraft data plane interconnect.

Level 1 The Chiplet will support high-speed serial communication with external devices.

1.4.2.2 The Chiplet shall have

independent configuration of XAUI or SRIO serial port data rate and lane assignments.

Level 2 This allows for different configurations for different use cases.

1.4.2.3 The Chiplet shall have a

minimum of one Ethernet 10/100 Mbps interface.

Level 2 This enables ground based software development.

1.4.2.4 The Chiplet shall have a

minimum of 32 GPIO pins, with a goal of 64 GPIO pins, which are accessible to any processor core.

Level 1 This provides a general discrete signal mechanism that can be used for communication with digital logical that is external to the Chiplet.

1.4.2.5 The Chiplet shall support GPIO

configured as single-ended or as differential pairs.

Level 2 The allows flexibility in board-level use cases.

1.4.2.6 All I/O devices shall include an

on-chip loop-back test mode for health verification.

Level 2 The Chiplet will support internal loopback on its I/O devices to allow interface health checking and enable early software development.

1.4.2.7 The Chiplet shall have a serial

console interface.

Level 1 The Chiplet will provide a terminal interface to support embedded software development.

1.5 Packaging

1.5.1 The Chiplet package shall

provide environmental protection as required for reliable operation in a laboratory environment.

Level 1 Space qualified packaging is not required. Minimal cost COTS-type packaging is acceptable as long as requirements 1.5.2 and

1.5.3 are met.

1.5.2 The Chiplet package shall

ensure a junction temperature at or below 110OC at maximum

Level 2 This allows use in a laboratory environment without specialized cooling equipment.

operating condition when mounted on an organic substrate in a laboratory environment.

Thermal spreader and/or air cooled heat sinks are allowable.

1.5.3 The Chiplet package shall

provide power ground decoupling, controlled impedance signal lines and terminations as needed to ensure proper operation of the HPSC Chiplet.

Level 2 This is necessary for correct operation in a typical single board computer.

1.6 Trace and Debug Support

1.6.1 The Chiplet shall have a debug

and trace capability that is consistent with the capability provided by the ARM Debug Interface Architecture to provide low-level hardware debugging capability.

Level 1 Provides debug and trace capability at hardware, low level software, and application levels (including parallel applications).

1.6.2 The Chiplet shall have a debug

and trace capability that enables a user to inject data patterns and test vectors into the Chiplet memories and I/Os.

Level 2 Provides basic software development and debug capability.

1.6.3 The Chiplet shall have time

correlated trace capability for software operating on individual processing cores, traffic on the on chip network, and traffic and state in memory and I/O controllers.

Level 2 Provides basic software

1.6.4 The Chiplet shall have a debug

capability that provides independent control of each processing core that is placed in debug mode and, at a minimum, also provides access to the processor core registers, processor core caches and processor core execution trace.

Level 2 Provides basic software

1.6.5 The Chiplet shall have a time

distribution capability for time-tagging information for peripheral I/O devices, debug unit, on-chip network traffic, and instruction buffers.

Level 2 This allows the user to reconstruct the time ordered events in the Chiplet.

1.6.6 The Chiplet shall have the

capability to selectively capture, time tag, and log execution traces, on chip network traffic, and processor core instruction streams.

Level 2 This allows the user to filter the captured data set to look only at the area of interest.

1.6.7 The Chiplet shall provide

breakpoint setting, halt on breakpoint, resume and single step capabilities.

Level 2 Provides basic software

1.6.8 Debug/trace software tools shall

be provided that run on a host Linux-based computer workstation and provide Chiplet debug/trace capability including the ability to set breakpoints, halt on breakpoints, resume and single step.

Level 1 This provides the user interface for the Chiplet debug and trace capabilities.

1.6.9 The Chiplet shall provide an

interface to read the boot scratchpad memory.

Level 1 Boot status and test/diagnostic data can be used during test and debug to diagnose a failed or suboptimal boot.

1.7 Environmental

1.7.1 The Chiplet shall have a

minimum TID hardness of 1 Mrad (Si).

Level 1 The Chiplet is targeted for missions with a high radiation environment.

1.7.2 The Chiplet shall have a prompt

dose rate immunity to 1e10 rad(Si)/s.

Level 1

1.7.3 The Chiplet shall have a dose

rate survivability to 1e12 rad(Si)/s.

Level 1

1.7.4 The Chiplet shall have latch up

immunity to an LET of at least 90 MeV-cm2/mg.

Level 1

1.7.5 The Chiplet shall have no more

than 1e-10 uncorrected errors/bit-day, and no more than 1e-4 uncorrected errors/device-day, in Adam’s 90% Worst Case GEO environment, behind 100 mils of Aluminum.

Level 1 This defines the Chiplet resilience to heavy ion induces errors.

1.7.6 The Chiplet shall have no more

than 1e-9 uncorrected errors/bit-minute, and no more than 1e-2 uncorrected errors/device-minute, for the worst 5-minute period of the October 1989 design case flare in CREME 96, behind 100 mils of Aluminum.

Level 1 This defines the Chiplet resilience to proton direct ionization induced errors.

1.7.7 The Chiplet shall operate within

MIL-STD junction temperature range of -55 to +125 C.

Level 1 The Chiplet will be integrated in designs with other MIL-STD parts.

1.8 Reliability and Assured Integrity

1.8.1 Chiplet shall have a minimum of

100,000 hours of operation before a non-recoverable permanent fault with a 90% probability and 90% confidence level.

Level 1 The Chiplet is targeted for long duration missions with high reliability requirements.

1.8.2 Chiplet shall have Assured

Integrity (absence of malicious functions/alterations) through either the design flow, the fabrication and/or the hardware verification process.

Level 1 The Chiplet is targeted for defense missions and will be protected from malicious infiltration.

2 Emulator

2.1 The emulator shall provide a

high fidelity behavior-level model of the Chiplet design.

Level 1 This provides emulation of the hardware (e.g. GEM5 for ARM architectures) to support architecture analysis and software development.

2.2 The emulator shall run on a

Linux workstation.

Level 2 Emulator will run in the same environment as the Trace and

Debug (1.6.8) and System Software tool chains (4.3).

3 Evaluation Board

3.1 The Evaluation Board shall have

a minimum of one HPSC Chiplet.

Level 1

3.2 The Evaluation Board shall be

capable of demonstrating the HPSC Chiplet tiling/cascading capability with two Evaluation Boards.

Level 2 The evaluation board will be used to test, evaluation, and demonstrate all capabilities of the chiplet and perform initial software development.

3.3 The Evaluation Board shall have

all memory ports populated.

Level 2 The evaluation board will be used to test, evaluation, and demonstrate all capabilities of the chiplet and perform initial software development.

3.4 The Evaluation Board shall have

a boot ROM device pre-loaded with the boot code to initialize the Evaluation Board to a point where OS and user applications can be loaded.

Level 2 The Evaluation Board is provided ready to boot operating systems.

3.5 The Evaluation Board shall have

the capability to fully exercise the power scaling options of the Chiplet, and test access to measure current and voltage on each power supply of the Chiplet and the board as a whole.

Level 2 The evaluation board will be used to test, evaluation, and demonstrate all capabilities of the chiplet and perform initial software development.

3.6 The Evaluation Board shall have

connectors or devices suitable for proper observation and usage of each I/O port on the Chiplet (including a trace/debug port to enable host computer access as defined in 1.6.8).

Level 2 The evaluation board will be used to test, evaluation, and demonstrate all capabilities of the chiplet and perform initial software development.

3.7 The Evaluation Board shall have

a layout with [3 cm] keep out zone to enable radiation testing of the Chiplet.

Level 2 This allows isolating the effect of the radiation beam to only the Chiplet.

3.8 The Evaluation Board shall have

a console interface.

Level 1

3.9 The Evaluation Board shall have

a capability to use spare memory, which can be mapped into use through software command.

Level 2 The evaluation board will be used to test, evaluation, and demonstrate all capabilities of the chiplet and perform initial software development.

4 System Software

4.1 The System Software shall have

the capability to execute different operating systems on different cores, and/or execute the same operating system across multiple cores.

Level 1 Provide support for both symmetric and asymmetric multiprocessing.

4.2 The System Software shall

support both 32 bit and 64 bit operations.

Level 2 Compatibility is provided for native 64-bit and legacy 32-bit applications.

4.3 The System Software shall have

development and debug tool chains that run under Linux.

Level 1 System Software tool chains will run in the same environment as the Trace and Debug (1.6.8) and Emulator (2.2).

4.4 The System Software shall

provide an operating system that explicitly supports parallel processing, including a C/C++ development tool chain and a parallel debugger.

Level 2 This enables test and characterization software development for parallel applications. Generic, readily available operating systems and compilers (such as what is available from Linaro) is acceptable.

4.5 The System Software shall

provide an operating system that supports real-time applications and dynamic resource allocation to real-time applications, including a C/C++ development tool chain and debugger.

Level 2 This enables test and characterization software development for real-time applications. Generic, readily available operating systems and compilers (such as RTEMS) are acceptable.

4.6 For each operating system, the

System Software shall provide a board support package enabling software access/control for at least the following:

external/internal time source, support for core-level clock and power control, support for error logging with time tags, I/O

Level 2 This ensures that supplied operating systems are ready to use, and are able to exercise all the functions on the board.

assignment, interrupt assignment, processor assignment, memory allocation and protection to specific cores, and device drivers for all interfaces.

4.7 The System Software shall have

a parallel debugger/profiler/tracer with capability to accurately measure/trace each processing core's CPU and cache utilization, measure utilization of shared resources, and perform static dataflow analysis for parallel applications.

Level 2 A parallel debugger is supplied to support parallel application software development.

4.8 The System Software shall have

API(s) for supporting resource allocation, fault tolerance and power management, suitable for use by applications or future middleware.

Level 2 This ensures that supplied operating systems are ready to use, and are able to exercise all the functions on the board.

4.9 The System Software shall be

provided with and executed on the Evaluation Board in a turn-key manner.

Level 1 The Evaluation Board is ready for test, characterization, and software development.

5 Options

Identifier Requirement Rationale

Option 1 The Chiplet shall have a unified L3 cache that is a minimum of 8 MB, which is accessible by the processor cores, and which can be disabled by the Chiplet configuration controller.

Level 3 cache is critical to efficient execution of some codes. Typically, the more the better, consistent with reasonable power constraints and access speeds, as the application set is wide ranging and the cache size cannot be optimized for a specific application. In some cases, however, L3 cache is not useful and the ability to disable it in order to optimize performance:power ratio is desirable. Note that cache coherency between tiled or cascaded Chiplets is not required.

Option 2 The Chiplet shall have dual real-time processors that are capable of running in lock-step for fault tolerance and capable of

Dual real time processors (e.g., ARM R5 processors), provide a fault tolerant configuration controller as well as a logical providing the boot and configuration management functions.

location for execution of mission/safety critical and real time codes.

Option 3 The Chiplet shall have a minimum of 2 Time- Triggered Ethernet (TTE) interfaces compliant with the SAE AS6802 standard.

TTE is becoming a standard interface for many space based instruments and subsystems. It is interoperable with standard Ethernet, and provides a relatively low cost and generic facility for real time, deterministic I/O.

Option 4 The Chiplet shall have a minimum of 2 RMAP compatible Spacewire interfaces compliant with ECSS-E-50-12C and ECSS- E-ST-50-52C standards.

Spacewire is becoming a standard interface for many space based instruments and subsystems.

Option 5 The Chiplet shall have a package that is amenable to space qualification.

A path to flight will require development of a space qualifiable package. If not developed on this project, it will have to be developed by the first space user. It is more cost effective and efficient to develop it on this project.

Acronym List

Term Description

ALU Arithmetic-Logic Unit

API Application Program Interface

ARINC Aeronautical Radio, Incorporated

ASIC Application-Specific Integrated Circuit

COTS Commercial Off the Shelf

CPU Central Processing Unit

DDR Double Data Rate

EDAC Error Detection and Recovery

EEPROM Electrically Erasable Programmable Read-Only Memory

FLOPS Floating-Point Operations per Second

FPGA Field Programmable Gate Array

GOPS Giga Operations per Second

GP General Purpose

GPIO General Purpose Input/Output

GPR General Purpose Register

GPU Graphic Processing Unit

HPSC High Performance Space Computing

IEEE Institute of Electrical and Electronics Engineers

IP Intellectual Property

JTAG Joint Test Action Group

LET Linear Energy Transfer

MCM Multi-Chip Module

MET Mission Elapse Timer

MIPS Million Instructions per Second

N/A Not Applicable

NASA National Aeronautics and Space Administration

OS Operating System

PoR Power On Reset

RHBD Radiation Hard by Design

RAM Random Access Memory

ROM Read-Only Memory

SCT Spacecraft Timer

SECDED Single Error Correct/Double Error Detect

SEE Single Event Effect

SEFI Single Event Functional Interrupt

SOW Statement of Work

SRIO Serial RapidIO

TBD To Be Determined

TID Total Ionizing Dose