Defence Computing Standardization

Standard Computing systems for Defense Applications

Introduction

With the advent of Indian CPU designs, it is now possible to define standard SoCs for a wide range of defense applications, leading to lower acquisition costs due to standardization and having designs tailored for defense applications. 4 standard configurations, D1, D2, D3 and D4 will cater to more than 75% of CPUs used in the strategic sector. D1-D4 will be class standard specs and variants can be derived from them for specialized applications while still keeping the base class design intact. This allows custom designs to be realized quickly and with lower cost compared to a full custom design that cannot leverage existing designs.

It is also necessary that the computing systems and form factors also be standardized so that standard LRUs can be used across various systems. These will broadly fall into two categories

• Single board computers
• Backplane based systems

The cabling standards between systems also has to be standardized. The choices are

• Reliable Ethernet (AFDX like variants can be used)
• Serial RapidIO
• GenZ (reliable variant being proposed)

Also a CPU Eco-system has significant SW components, since SW accounts for most of the life cycle cost. Standardization will allow these costs to be significantly lowered.

Standard Processors

This is a preliminary proposal and final processor/SoC(System on Chip) configuration will have to be decided based on requirement analysis

The following standard configurations are a good place to start

• D1 - Deep embedded, extreme low power with optional low power radio, NAVIC. Targeted at edge and deep embedded devices. Specialized ultra low power variants can be designed to use power harvesting.
• D2 - Standard embedded SoCs with 1-8 in-order cores capable of running RTOSs and MMU based OSs like Linux or Secure L4.
• D3 - Mobile/Desktop grade SoCs with 1-8 in-order/OO cores, VPUs and optional AI/ML accelerators and GPUs. Secure mobile, desktops and high power embedded applications, low end servers
• D4 - Secure Server SoCs with 2-32 OO cores, VPUs and optional AI/ML accelerators

 

D1 class

D1 class SoCs are ultra low power and low power deep embedded and IoT class SoCs meant for miniature edge devices. They can also be used in smart card designs.

• Security support includes secure boot, side channel resistance and security co-processors.
• Optional FPU/VPU extensions allows realization of designs tailored for DSP applications.
• Optional Radio sub-systems allows use in secure wireless applications
• Ultra low power variants will allow use of energy harvesting
• SW support - standard or custom RTOS with physical memory protection 
  

 

D2 class

 

D2 class SoCs are aimed at RTOS/Linux based controller applications, ranging from large edge controllers to 1Ghz class multi-core controller applications

• Low die size for a 64 bit Linux capable design (single core is sub .5 mm2 in 22 nm)
• Security support includes secure boot, side channel resistance and security co-processors. Tagged ISA variants for fine grained security applications
• Optional VPU allows DSP/HPC style applications to be hosted
• AI/Ml accelerators allow edge analytics to be realized on this platform allowing applications like image analytics and signal analytics
• Low power GPU for low/mid level graphics for applications requiring display support
• Optional GPS/NAVIC sub-systems
• SW support - MMU/hypervisor support for any standard or custom OS
• High speed peripheral support (PCIe, 10 G Eth, USB 3.x)

D3 class 

D3 class SoCs target higher end mobile, desktop and entry level server grade applications. It is basically a superset of the D2 class SoC with the following enhancements

• Support for OO CPUs with significantly higher single thread performance
• Higher GPU performance
• Larger vector width in the VPU
• Optional media blocks for audio/video and image processing with support for 20+Mpix CMOS sensors
• High performance NoC
• Significantly higher memory bandwidth
• Larger lane count on SERDES based interfaces liek 10 G Eth, Gen 4/5 PCIe and USB 4.x
  
• Packet processors on ETh ports for network acceleration and L2/L3 processing

 

D4 class 

 

D4 class SoCs target HPC and server grade applications. It is basically a superset of the D3 class SoC with the following enhancements

• Support for OO CPUs with significantly higher single thread performance
• Higher GPU performance
• Larger vector width in the VPU
• High performance NoC
• Significantly higher memory bandwidth
• Larger lane count on SERDES based interfaces liek 10 G Eth, Gen 4 PCIe and USB 3.1
• Packet processors on ETh ports for network acceleration and L2/L3 processing

D5 + - Higher core counts

Eight 3+ Ghz OO cores are an overkill for most standard applications, If required D4 can be enhanced with higher core counts, a max of probably 128 cores is feasible but a dual socket 64 core configuration makes more sense. D2 can also have higher core count variations , going up to 512 cores for data parallel applications. In any case Vectors and GPGPUs are better suited for highly data parallel applications.

Feature Matrix

	GPU/GPGPU	Ultra Low power	VPU	AI/ML	AV/Camera	Tagged ISA	High speed SERDES ports
ULP D1		x
D1
D2	x			x		x	x
D3	x		x	x	x	x	x
D4	x		x	x			x
D4-HPC	x		x	x			x

Architecture Standardization

Tiled Architecture

The US DoD/DARPA is moving towards Tiled architecture for complex chips. This allowed new chips to be assembled from known good dies, thereby avoiding the need to manufacture a new chip with its attendant cost and timelines. Essentially a new chip can be composed from existing sub-components. It is imperative that we also move in this direction for D3/D4 class SoCs. This approach also makes sense for D1/D2 class chips which are mixed signal like SDR systems. An AMD style IO/switch die is the need of teh hour here for D4+ class systems

Interconnects 

Chip to chip and on chip

• AXI
• Tilelink (on and off chip)
  
• CXL (accelerator interface)
  
• CSIX (multi-socket CC) (Tilellink may be an option here)
  

Standardizing Systems

Standardizing processors is only the first step. It is also imperative that PCB sizes, multi board configurations and enclosures be standardized. Commonality of LRUs is not possible without this aspect of systems being standardized. This is an even more contentious areas since every systems designer likes optimized designs.

Boards

At the board level, systems fall into three categories

• Single board computers
• Stackable computers with connectors
• Backplane based systems

Single board computers

Single board computers can be standardized on any of the existing board standards COMexpress and Q7 are a good option. These classes of computers are the most used and hence will be seen in a variety of enclosure formats. While standardizing enclosures here may be difficult, default options like VITA75 should be available. An audit of systems should help decide the std enclosures needed. For no aerospace grade applications, 2-3 standard MIL std enclosures would be useful.

Backplane based systems and Interconnects

Most aero and naval systems are probably backplane based or large single board configurations. These should be standardized on VPX and uTCA with backplane signals standardized on Ethernet, PCIe and SRIO. Std 19 in rack formats will also be used in large compute complexes, it is also imperative to have mechanical, reliability and thermal standards for those since variations are enormous in 19 in racks. Otherwise certification becomes a nightmare.

For box to box interconnects, Ethernet, GenZ or SRIO would be the ideal choices. GenZ is new and does not yet have the necessary reliability hooks. But this is an area where India can evolve a rugged version of GenZ. Its widespread acceptance will make system dev costs lower.

Naturally aero systems will have more stringent enclosure/cooling requirements and the option of variants often same basic enclosure design with aero variants should be explored.

Storage Systems

Storage is an area that often gets ignored. It is preferable to standardized on NVMe based solid state storage or embedded form factors that use NVMe like CF Express. Form factors of the drives also should be standard. CF Express for small embedded and 2 formats for large drives.

SW Sub-systems

While the thrust of this note is primarily HW and mechanical systems, it is also imperative that the following areas of SW be standardized. These are just indicative areas and are not a comprehensive list of SW standardization areas.

• Languages used - it is imperative that safe languages like Rust, Erlang or Ocaml be used in developing critical systems, it leads to easier certification, testing and maintenance. C and its derivatives are best avoided. This transition will not be easy and will take time but a start needs to be made. A detailed analysis on requirements of safe language is imperative.It is not enough to standardize on languages, language libraries and sub-components like networking stacks, encryption blocks also have to be standardized.
• Operating systems - We need to start standardizing on home grown or open source secure operating systems for application at CC EAL5+ and above. Lynxworks that has been chosen is a good choice but a home grown alternative is also needed. Sel4 and eChronos are good options.
• File systems - Reliability of data is key so standardizing on file systems is key. Reliability should prevail over performance as much as possible and ZFS like file systems are necessary. Too many variations lead to certification nightmare
• Capability building in designing SW systems for CC evaluation is imperative as is certification capabilities in EAL6 and above systems. It is not a capability issue but rather a capacity and process issue.