18 min read
Advanced CPU Microarchitecture & Specialized Accelerators
Beyond the fetch-execute cycle lies a complex world of optimization. We dissect the modern processor pipeline—from speculative execution to the reorder buffer—and explore the rise of domain-specific silicon like Neural Processing Units (NPUs) and FPGAs.
Out-of-Order Execution
Out-of-order execution (OoOE) allows CPUs to execute instructions based on operand availability rather than their original program order, maximizing functional unit utilization and hiding latency. The processor maintains a Reorder Buffer (ROB) to track instructions and ensure they "retire" (commit results) in program order for correct program semantics.
Program Order: Out-of-Order Execution: ┌─────────────────┐ ┌─────────────────────────────────────────┐ │ 1. LOAD R1,[A] │ │ Cycle 1: LOAD R1,[A] starts (cache miss)│ │ 2. ADD R2,R1,5 │ │ Cycle 2: MUL R4,R3,R3 executes (ready!) │ │ 3. MUL R4,R3,R3 │ │ Cycle 3: SUB R5,R3,1 executes (ready!) │ │ 4. SUB R5,R3,1 │ │ Cycle 50: LOAD completes │ └─────────────────┘ │ Cycle 51: ADD R2,R1,5 executes │ └─────────────────────────────────────────┘ Instructions 3 & 4 don't depend on R1, so they execute while waiting for memory!
Register Renaming
Register renaming eliminates false dependencies (WAR - Write After Read, WAW - Write After Write) by mapping architectural registers to a larger pool of physical registers, enabling more instruction-level parallelism. This is implemented via a Register Alias Table (RAT) that tracks the current mapping between logical and physical registers.
Original Code (has WAW hazard on R1): After Register Renaming: ┌──────────────────────────┐ ┌────────────────────────────────┐ │ ADD R1, R2, R3 ; R1 = A │ │ ADD P1, P2, P3 ; P1 = A │ │ MUL R4, R1, R5 ; uses A │ │ MUL P4, P1, P5 ; uses P1 │ │ SUB R1, R6, R7 ; R1 = B │ ──────────► │ SUB P6, P7, P8 ; P6 = B │ │ ADD R8, R1, R9 ; uses B │ │ ADD P9, P6, P10 ; uses P6 │ └──────────────────────────┘ └────────────────────────────────┘ Register Alias Table (RAT): Physical Register File: ┌─────┬──────┐ ┌────┬───────┐ │ R1 │ P6 │ (current mapping) │ P1 │ value │ │ R2 │ P2 │ │ P6 │ value │ │ ... │ ... │ │... │ ... │ └─────┴──────┘ └────┴───────┘
Speculative Execution
Speculative execution allows the CPU to predict the outcome of branches and execute instructions ahead of time, rolling back if the prediction is wrong—trading potential wasted work for significant performance gains. This was infamously exploited in Spectre/Meltdown vulnerabilities where speculative memory accesses left observable side effects in CPU caches.
┌─────────────────────────────────────────────────────────────────┐ │ SPECULATIVE EXECUTION FLOW │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ if (condition) { ┌──────────────────┐ │ │ x = a + b; ───► │ Predict: TRUE │ │ │ } │ Execute: x = a+b │ │ │ │ speculatively │ │ │ └────────┬─────────┘ │ │ │ │ │ ┌────────────────┴────────────────┐ │ │ ▼ ▼ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ Prediction │ │ Prediction │ │ │ │ CORRECT │ │ WRONG │ │ │ │ ──────────── │ │ ──────────── │ │ │ │ Commit result│ │ Flush & Roll │ │ │ │ Performance! │ │ back state │ │ │ └──────────────┘ └──────────────┘ │ └─────────────────────────────────────────────────────────────────┘
Branch Prediction Algorithms
Branch predictors use historical patterns to guess branch outcomes before they're computed, with modern CPUs achieving 95%+ accuracy using techniques like Two-Level Adaptive Predictors, TAGE (TAgged GEometric), and perceptron-based neural predictors. A misprediction typically costs 15-20 cycles as the pipeline must be flushed.
┌─────────────────────────────────────────────────────────────────────────┐ │ BRANCH PREDICTION TECHNIQUES │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ 1. STATIC PREDICTION 2. 2-BIT SATURATING COUNTER │ │ ┌─────────────────────┐ ┌─────────────────────────────────┐ │ │ │ Forward: Not Taken │ │ ┌──────┐ ┌──────┐ │ │ │ │ Backward: Taken │ │ ┌──►│Strong│◄──►│ Weak │──┐ │ │ │ │ (loops go backward) │ │ │ │Taken │ │Taken │ │ │ │ │ └─────────────────────┘ │ │ └──────┘ └──────┘ │ │ │ │ │ │ T ▲ │ │ N │ │ │ 3. TWO-LEVEL ADAPTIVE │ │ T│ N│ ▼ │ │ │ ┌─────────────────────┐ │ │ ┌──────┐ ┌──────┐ │ │ │ │ │ Branch History Reg │ │ └───│ Weak │◄──►│Strong│◄─┘ │ │ │ │ ┌─┬─┬─┬─┬─┬─┬─┬─┐ │ │ │ NT │ │ NT │ │ │ │ │ │T│N│T│T│N│T│T│T│ │ │ └──────┘ └──────┘ │ │ │ │ └─┴─┴─┴─┴─┴─┴─┴─┘ │ └─────────────────────────────────┘ │ │ │ ↓ index into │ │ │ │ Pattern History Tbl │ 4. TAGE (Modern CPUs) │ │ └─────────────────────┘ ┌─────────────────────────────────┐ │ │ │ Multiple tables with different │ │ │ │ history lengths (geometric series)│ │ │ │ Tagged for partial address match │ │ │ └─────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────┘
Memory Disambiguation
Memory disambiguation determines whether load instructions can be executed before prior store instructions complete by predicting/verifying that they access different memory addresses. The Store Buffer and Load Queue work together with a Memory Dependence Predictor to maximize memory parallelism while maintaining correctness.
┌─────────────────────────────────────────────────────────────────┐ │ MEMORY DISAMBIGUATION │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Code: Memory Unit: │ │ ┌────────────────┐ ┌─────────────────────────────────┐ │ │ │ STORE [R1], R2 │ │ Store Buffer Load Queue │ │ │ │ LOAD R3, [R4] │ │ ┌─────────┐ ┌─────────┐ │ │ │ └────────────────┘ │ │Addr: R1 │ │Addr: R4 │ │ │ │ │ │Data: R2 │ │Wait/Fwd │ │ │ │ Question: Does R1 == R4? │ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ │ │ │ ▼ ▼ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ │ Address Comparison Logic │ │ │ │ ├──────────────────────────────────────────────────────┤ │ │ │ │ CASE 1: R1 ≠ R4 → Load can proceed independently │ │ │ │ │ CASE 2: R1 = R4 → Forward data from Store Buffer │ │ │ │ │ CASE 3: Unknown → Wait or Speculate + verify later │ │ │ │ └──────────────────────────────────────────────────────┘ │ │ │ │ │ Store-to-Load Forwarding: │ │ ┌──────────┐ ┌──────────┐ │ │ │ STORE │────►│ LOAD │ (bypasses cache entirely) │ │ │ [0x1000] │ │ [0x1000] │ │ │ └──────────┘ └──────────┘ │ └─────────────────────────────────────────────────────────────────┘
Instruction-Level Parallelism (ILP)
ILP is the measure of how many instructions in a program can be executed simultaneously, limited by true data dependencies, control dependencies, and available hardware resources. Modern superscalar CPUs can issue 4-8 instructions per cycle, but real-world code typically achieves IPC (Instructions Per Cycle) of 2-3 due to dependencies and stalls.
┌─────────────────────────────────────────────────────────────────────┐ │ INSTRUCTION-LEVEL PARALLELISM EXAMPLE │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ Original Code: Data Dependency Graph: │ │ ┌─────────────────────┐ ┌─────────────────────────────────┐ │ │ │ 1: R1 = LOAD [A] │ │ 1: LOAD │ │ │ │ 2: R2 = R1 + 5 │ │ │ │ │ │ │ 3: R3 = LOAD [B] │ │ ┌─────┴─────┐ │ │ │ │ 4: R4 = R3 * 2 │ │ ▼ ▼ │ │ │ │ 5: R5 = R2 + R4 │ │ 2: ADD 3: LOAD │ │ │ │ 6: R6 = LOAD [C] │ │ │ │ │ │ │ │ 7: R7 = R6 - 1 │ │ │ 4: MUL │ │ │ └─────────────────────┘ │ │ │ │ │ │ │ └─────┬─────┘ │ │ │ Parallel Execution: │ ▼ │ │ │ ┌──────┬──────┬──────┐ │ 5: ADD 6: LOAD │ │ │ │Cycle │ EU1 │ EU2 │ │ │ │ │ │ ├──────┼──────┼──────┤ │ 7: SUB │ │ │ │ 1 │ 1 │ 3 │ └─────────────────────────────────┘ │ │ │ 2 │ 6 │ - │ │ │ │ 3 │ 2 │ 4 │ Max ILP = 7 instructions / 5 cycles │ │ │ 4 │ 7 │ 5 │ = 1.4 IPC │ │ └──────┴──────┴──────┘ │ └─────────────────────────────────────────────────────────────────────┘
SIMD (SSE, AVX, AVX-512)
Single Instruction, Multiple Data extensions allow one instruction to operate on multiple data elements simultaneously using wide vector registers (128-bit SSE, 256-bit AVX, 512-bit AVX-512). This provides massive throughput for data-parallel workloads like multimedia, scientific computing, and ML inference, but requires data alignment and careful handling of horizontal operations.
┌─────────────────────────────────────────────────────────────────────────┐ │ SIMD REGISTER EVOLUTION │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ SSE (128-bit XMM): │ float │ float │ float │ float │ (4 floats) │ │ └───────┴───────┴───────┴───────┘ │ │ │ │ AVX (256-bit YMM): │ float │ float │ float │ float │ float │...│ │ │ └───────┴───────┴───────┴───────┴───────┴───┘ │ │ (8 floats) │ │ │ │ AVX-512 (512-bit ZMM):│ 16 floats or 8 doubles or 64 bytes │ │ │ └────────────────────────────────────────┘ │ │ │ │ SIMD Addition Example (4 floats at once): │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ A: │ 1.0 │ 2.0 │ 3.0 │ 4.0 │ │ │ │ │ └──┬──┴──┬──┴──┬──┴──┬──┘ │ │ │ │ + + + + ← Single instruction! │ │ │ │ ┌──┴──┬──┴──┬──┴──┬──┴──┐ │ │ │ │ B: │ 5.0 │ 6.0 │ 7.0 │ 8.0 │ │ │ │ │ └──┬──┴──┬──┴──┬──┴──┬──┘ │ │ │ │ = = = = │ │ │ │ ┌──┴──┬──┴──┬──┴──┬──┴──┐ │ │ │ │ C: │ 6.0 │ 8.0 │10.0 │12.0 │ │ │ │ │ └─────┴─────┴─────┴─────┘ │ │ │ └─────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────┘
#include <immintrin.h> // Vectorized array addition using AVX void add_arrays_avx(float* a, float* b, float* c, int n) { int i = 0; // Process 8 floats at a time with AVX (256-bit = 8 x 32-bit floats) for (; i <= n - 8; i += 8) { __m256 va = _mm256_loadu_ps(&a[i]); // Load 8 floats from a __m256 vb = _mm256_loadu_ps(&b[i]); // Load 8 floats from b __m256 vc = _mm256_add_ps(va, vb); // Add all 8 pairs in parallel _mm256_storeu_ps(&c[i], vc); // Store 8 results } // Handle remaining elements for (; i < n; i++) { c[i] = a[i] + b[i]; } } // AVX-512 example: 16 floats at once void add_arrays_avx512(float* a, float* b, float* c, int n) { int i = 0; for (; i <= n - 16; i += 16) { __m512 va = _mm512_loadu_ps(&a[i]); // Load 16 floats __m512 vb = _mm512_loadu_ps(&b[i]); // Load 16 floats __m512 vc = _mm512_add_ps(va, vb); // Add 16 pairs _mm512_storeu_ps(&c[i], vc); // Store 16 results } for (; i < n; i++) c[i] = a[i] + b[i]; }
Vector Processing
Vector processors operate on entire arrays (vectors) with single instructions, using deeply pipelined functional units and vector registers that can hold many elements. Unlike SIMD's fixed-width registers, classic vector architectures (Cray, NEC SX, RISC-V Vector Extension) support variable-length vectors determined at runtime, making them more flexible for varying data sizes.
┌─────────────────────────────────────────────────────────────────────────┐ │ VECTOR PROCESSING vs SIMD vs SCALAR │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ SCALAR (1 element/instruction): SIMD (fixed width): │ │ ┌────────────────────────────┐ ┌────────────────────────────┐ │ │ │ for (i=0; i<1000; i++) │ │ for (i=0; i<1000; i+=8) │ │ │ │ c[i] = a[i] + b[i]; │ │ vec_add(c+i, a+i, b+i); │ │ │ │ → 1000 instructions │ │ → 125 instructions │ │ │ └────────────────────────────┘ └────────────────────────────┘ │ │ │ │ VECTOR (variable length): │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ VL = setvl(1000); // Set vector length (hardware max) │ │ │ │ VLOAD V1, a // Load up to VL elements │ │ │ │ VLOAD V2, b // Load up to VL elements │ │ │ │ VADD V3, V1, V2 // Add all VL elements │ │ │ │ VSTORE c, V3 // Store all VL elements │ │ │ │ → ~4 instructions (loop handled in hardware via strip-mining) │ │ │ └────────────────────────────────────────────────────────────────┘ │ │ │ │ Vector Register File: │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ V0: │ e0 │ e1 │ e2 │ e3 │ e4 │ ... │ e62 │ e63 │ (64 elements) │ │ │ │ V1: │ │ │ │ │ │ │ │ │ │ │ │ │ V2: │ │ │ │ │ │ │ │ │ │ │ │ │ ... │ │ │ │ │ │ │ │ │ │ │ │ │ V31:│ │ │ │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ Vector Chaining (pipelining): │ │ ┌───────────────────────────────────────────────────────────────┐ │ │ │ VMUL V1, V2, V3 ─┐ │ │ │ │ ├── V1 result forwarded element-by-element │ │ │ │ VADD V4, V1, V5 ─┘ (no need to wait for VMUL to complete) │ │ │ └───────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────┘
// RISC-V Vector Extension Example (RVV) // C intrinsics for vector addition #include <riscv_vector.h> void vector_add(float *a, float *b, float *c, size_t n) { while (n > 0) { size_t vl = vsetvl_e32m8(n); // Set VL based on remaining elements vfloat32m8_t va = vle32_v_f32m8(a, vl); // Vector load vfloat32m8_t vb = vle32_v_f32m8(b, vl); // Vector load vfloat32m8_t vc = vfadd_vv_f32m8(va, vb, vl); // Vector add vse32_v_f32m8(c, vc, vl); // Vector store a += vl; b += vl; c += vl; n -= vl; // Advance pointers } } // Hardware automatically handles any vector length - no cleanup loop needed!
VLIW Architecture
Very Long Instruction Word architectures explicitly encode multiple parallel operations in a single wide instruction, shifting scheduling responsibility from hardware to the compiler. This simplifies processor design (no dynamic scheduling) but makes binary compatibility difficult and performs poorly when compile-time information is insufficient (e.g., unpredictable branches, memory aliasing).
┌─────────────────────────────────────────────────────────────────────────┐ │ VLIW ARCHITECTURE │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ Traditional Superscalar: VLIW: │ │ ┌─────────────────────────┐ ┌─────────────────────────────────┐ │ │ │ Sequential instructions │ │ One wide instruction bundle │ │ │ │ ┌───────┐ │ │ ┌─────┬─────┬─────┬─────┬─────┐ │ │ │ │ │ ADD │ │ │ │ ADD │ MUL │ LOAD│ LOAD│ BR │ │ │ │ │ ├───────┤ │ │ │slot0│slot1│slot2│slot3│slot4│ │ │ │ │ │ MUL │ ────────► │ │ └─────┴─────┴─────┴─────┴─────┘ │ │ │ │ ├───────┤ Hardware │ │ 128-256+ bits wide │ │ │ │ │ LOAD │ schedules │ │ │ │ │ │ ├───────┤ │ │ Compiler schedules! │ │ │ │ │ ... │ │ │ │ │ │ │ └───────┘ │ └─────────────────────────────────┘ │ │ └─────────────────────────┘ │ │ │ │ VLIW Instruction Format (e.g., Intel Itanium IA-64): │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │ 128-bit bundle │ │ │ │ ┌──────────────┬──────────────┬──────────────┬────────┐ │ │ │ │ │ Instruction 0│ Instruction 1│ Instruction 2│Template│ │ │ │ │ │ 41 bits │ 41 bits │ 41 bits │ 5 bits │ │ │ │ │ └──────────────┴──────────────┴──────────────┴────────┘ │ │ │ │ Template specifies which execution units & dependencies │ │ │ └──────────────────────────────────────────────────────────────────┘ │ │ │ │ Examples: │ │ • Intel Itanium (IA-64) - deceased │ │ • TI C6000 DSPs - still used in embedded │ │ • Transmeta Crusoe - x86 emulation via VLIW │ │ • GPU shader cores (partially VLIW-like) │ │ │ │ Advantages: Disadvantages: │ │ ✓ Simple hardware ✗ Poor binary compatibility │ │ ✓ Low power ✗ NOP slots waste memory/bandwidth │ │ ✓ Deterministic ✗ Compiler can't predict runtime behavior │ │ ✓ No speculation bugs ✗ Code bloat from unrolling/scheduling │ └─────────────────────────────────────────────────────────────────────────┘
// Conceptual VLIW assembly (Itanium-like pseudo-code) // Each line is ONE instruction bundle executed atomically // Compiler must ensure NO dependencies within a bundle // Bundle 1: Load two values, start multiply, no-op in slot 4 { .mmi // Template: Mem, Mem, Int ld4 r1 = [r10] // Slot 0: Load from memory ld4 r2 = [r11] // Slot 1: Load from memory add r5 = r3, r4 // Slot 2: Integer add (independent!) } // Bundle 2: Use loaded values (compiler scheduled delay) { .mfi // Template: Mem, Float, Int ld4 r6 = [r12] // Slot 0: Another load fmul f3 = f1, f2 // Slot 1: Floating multiply sub r7 = r1, r2 // Slot 2: Uses r1,r2 from Bundle 1 } // NOP slots when parallelism unavailable (wasted!): { .mii nop.m 0 // No memory op available add r8 = r7, r6 // Depends on previous bundle nop.i 0 // No independent int op }
Quick Reference Comparison
┌─────────────────┬─────────────────┬──────────────────┬─────────────────┐ │ Technique │ Where Done │ Complexity │ Use Case │ ├─────────────────┼─────────────────┼──────────────────┼─────────────────┤ │ Out-of-Order │ Hardware │ Very High │ General CPUs │ │ Register Rename │ Hardware │ High │ OoO CPUs │ │ Speculation │ Hardware │ High │ Branch-heavy │ │ Branch Predict │ Hardware │ Medium-High │ All modern CPUs │ │ Memory Disambig │ Hardware │ High │ Memory-bound │ │ ILP │ Both │ Varies │ All workloads │ │ SIMD │ Compiler/Hand │ Medium │ Data parallel │ │ Vector │ Hardware/Comp │ Medium │ Scientific/HPC │ │ VLIW │ Compiler │ Low (HW) │ DSP/Embedded │ └─────────────────┴─────────────────┴──────────────────┴─────────────────┘
Frontend Pipeline Design
The frontend is responsible for fetching instructions from memory, predicting branches, and decoding x86/ARM instructions into micro-operations (µops) that the backend can execute. It typically includes the Branch Prediction Unit (BPU), Instruction Cache (L1i), fetch buffers, and decoders working in a pipeline fashion to keep the backend fed with work.
┌─────────────────────────────────────────────────────────────────┐ │ FRONTEND │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Branch │───▶│ Fetch │───▶│ Decode │───▶│ Alloc/ │ │ │ │Predictor │ │ Unit │ │ Unit │ │ Rename │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ │ │ │ BTB │ │ L1 I-Cache│ │ │ └──────────┘ └──────────┘ │ └─────────────────────────────────────────────────────────────────┘
Backend Execution Units
The backend contains the actual computational units (ALUs, FPUs, SIMD units, AGUs) that perform arithmetic, logic, floating-point, and address generation operations. Modern CPUs have multiple execution ports (typically 6-12) with different units attached, allowing superscalar execution of multiple instructions per cycle.
┌────────────────────────────────────────────────────────────┐ │ EXECUTION PORTS │ ├──────────┬──────────┬──────────┬──────────┬───────────────┤ │ Port 0 │ Port 1 │ Port 2 │ Port 3 │ Port 4 │ ├──────────┼──────────┼──────────┼──────────┼───────────────┤ │ ALU │ ALU │ Load │ Load │ Store │ │ FMA │ FMA │ AGU │ AGU │ Data │ │ Branch │ MUL │ │ │ │ │ SIMD │ SIMD │ │ │ │ └──────────┴──────────┴──────────┴──────────┴───────────────┘
// Simulating parallel execution units class ExecutionBackend { constructor() { this.ports = { 0: { units: ['ALU', 'FMA', 'Branch'], busy: false }, 1: { units: ['ALU', 'MUL', 'SIMD'], busy: false }, 2: { units: ['Load', 'AGU'], busy: false }, 3: { units: ['Store'], busy: false } }; } dispatch(uop) { for (const [portId, port] of Object.entries(this.ports)) { if (!port.busy && port.units.includes(uop.type)) { port.busy = true; return { port: portId, latency: uop.latency }; } } return null; // Structural hazard - must wait } }
Load-Store Units
Load-Store Units (LSUs) handle all memory operations, managing the interface between the CPU core and the cache hierarchy. They include load buffers, store buffers, and memory disambiguation logic to detect when loads and stores can be reordered safely while maintaining program correctness and memory ordering guarantees.
┌─────────────────────────────────────────────────────────┐ │ LOAD-STORE UNIT │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Load Buffer │ │ Store Buffer │ │ │ │ ┌───┬───┬───┐ │ │ ┌───┬───┬───┐ │ │ │ │ │L1 │L2 │L3 │ │ │ │S1 │S2 │S3 │ │ │ │ │ └───┴───┴───┘ │ │ └───┴───┴───┘ │ │ │ └────────┬────────┘ └────────┬────────┘ │ │ │ ┌──────────────┐ │ │ │ └────▶│ Memory │◀───┘ │ │ │Disambiguation│ │ │ └──────┬───────┘ │ │ ▼ │ │ ┌──────────────┐ │ │ │ L1 D-Cache │ │ │ └──────────────┘ │ └─────────────────────────────────────────────────────────┘
class LoadStoreUnit { constructor() { this.loadBuffer = new Array(72).fill(null); // Modern CPUs: 72-128 entries this.storeBuffer = new Array(56).fill(null); // Store buffer entries } // Memory disambiguation: check if load can bypass earlier stores canForwardOrBypass(loadAddr, loadId) { for (const store of this.storeBuffer) { if (store && store.id < loadId) { if (store.addr === loadAddr) return { forward: true, data: store.data }; if (store.addr === undefined) return { wait: true }; // Unknown addr, must wait } } return { bypass: true }; // Safe to load from cache } }
Reorder Buffer
The Reorder Buffer (ROB) is a circular buffer that tracks all in-flight instructions in program order, enabling out-of-order execution while ensuring in-order retirement and precise exceptions. Each entry holds the instruction's state, destination register mapping, and result value, allowing the CPU to roll back to a known good state on mispredictions or exceptions.
┌────────────────────────────────────────────────────────────────┐ │ REORDER BUFFER (Circular) │ │ Head Tail │ │ ▼ ▼ │ │ ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐ │ │ │ R0 │ R1 │ R2 │ R3 │ R4 │ R5 │ R6 │ R7 │ ... │ │ │ │Done │Done │Exec │Wait │Wait │ New │ New │Empty│ │ │ │ │ ✓ │ ✓ │ ⚙ │ ⏳ │ ⏳ │ ● │ ● │ │ │ │ │ └─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘ │ │ │ │ │ └──▶ Ready to Retire (commit in program order) │ └────────────────────────────────────────────────────────────────┘
class ReorderBuffer { constructor(size = 224) { // Modern CPUs: 224-512 entries this.entries = new Array(size); this.head = 0; // Oldest instruction (retirement point) this.tail = 0; // Newest instruction this.size = size; } allocate(uop) { const entry = { uop, state: 'issued', // issued -> executing -> complete -> retired result: null, exception: null, robIndex: this.tail }; this.entries[this.tail] = entry; this.tail = (this.tail + 1) % this.size; return entry.robIndex; } retire() { // Only retire from head, in program order const entry = this.entries[this.head]; if (entry?.state === 'complete' && !entry.exception) { this.entries[this.head] = null; this.head = (this.head + 1) % this.size; return entry; // Commit to architectural state } return null; } flush(fromIndex) { // Branch misprediction: flush all younger instructions while (this.tail !== fromIndex) { this.tail = (this.tail - 1 + this.size) % this.size; this.entries[this.tail] = null; } } }
Reservation Stations
Reservation Stations are distributed scheduling buffers where instructions wait until their source operands become available (from register file or bypassing from other units). They implement Tomasulo's algorithm, enabling out-of-order execution by tracking operand dependencies and waking up instructions when producers broadcast their results.
┌──────────────────────────────────────────────────────────────┐ │ RESERVATION STATIONS │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ Entry │ Op │ Src1 │ Src1 │ Src2 │ Src2 │ Dest │ │ │ │ │ │ Ready? │ Value │ Ready? │ Value │ ROB │ │ │ ├───────┼─────┼────────┼───────┼────────┼───────┼──────┤ │ │ │ RS0 │ ADD │ ✓ │ 42 │ ✓ │ 10 │ ROB3 │◀── Ready! │ │ RS1 │ MUL │ ✓ │ 7 │ ✗ │ ROB2 │ ROB4 │ │ │ │ RS2 │ DIV │ ✗ │ ROB4 │ ✗ │ ROB5 │ ROB6 │ │ │ │ RS3 │ ADD │ ✓ │ 100 │ ✓ │ 50 │ ROB7 │◀── Ready! │ └───────┴─────┴────────┴───────┴────────┴───────┴──────┘ │ │ │ │ │ ┌────────────┴────────────┐ │ │ ▼ ▼ │ │ Select Ready Wait for CDB │ │ (Oldest First) (Common Data Bus) │ └──────────────────────────────────────────────────────────────┘
class ReservationStation { constructor(name, numEntries) { this.name = name; this.entries = Array.from({ length: numEntries }, () => ({ busy: false, op: null, src1: { ready: false, value: null, tag: null }, src2: { ready: false, value: null, tag: null }, destROB: null })); } issue(uop, src1, src2, robTag) { const free = this.entries.find(e => !e.busy); if (!free) return false; // Structural stall free.busy = true; free.op = uop.opcode; free.src1 = src1.ready ? { ready: true, value: src1.value } : { ready: false, tag: src1.tag }; free.src2 = src2.ready ? { ready: true, value: src2.value } : { ready: false, tag: src2.tag }; free.destROB = robTag; return true; } wakeup(robTag, value) { // Called when execution unit broadcasts result on CDB for (const entry of this.entries) { if (entry.src1.tag === robTag) { entry.src1 = { ready: true, value }; } if (entry.src2.tag === robTag) { entry.src2 = { ready: true, value }; } } } selectReady() { return this.entries.find(e => e.busy && e.src1.ready && e.src2.ready); } }
Retirement and Commit
Retirement (or commit) is the final pipeline stage where completed instructions are removed from the ROB in program order and their results become architecturally visible by updating the register file and allowing stores to write to cache. This ensures precise exceptions and maintains the illusion of sequential execution despite internal OoO execution.
┌────────────────────────────────────────────────────────────┐ │ RETIREMENT PROCESS │ │ │ │ ROB Head │ │ │ │ │ ▼ │ │ ┌──────┐ ┌─────────────┐ ┌──────────────────┐ │ │ │Check │────▶│ Update │────▶│ Deallocate ROB │ │ │ │Ready?│ │ Arch Regs │ │ Entry & Resources│ │ │ └──────┘ └─────────────┘ └──────────────────┘ │ │ │ │ │ │ │ ▼ │ │ │ ┌─────────────┐ │ │ │ │Store Buffer │ │ │ │ │ → L1 Cache │ │ │ │ └─────────────┘ │ │ │ │ │ Exception?──────▶ Flush Pipeline & Rollback │ └────────────────────────────────────────────────────────────┘
class RetirementUnit { constructor(rob, archRegFile, storeBuffer) { this.rob = rob; this.archRegFile = archRegFile; this.storeBuffer = storeBuffer; this.retireWidth = 4; // Can retire 4-8 uops per cycle } cycle() { let retired = 0; while (retired < this.retireWidth) { const entry = this.rob.peekHead(); if (!entry || entry.state !== 'complete') break; if (entry.exception) { this.handleException(entry); return; } // Commit to architectural state if (entry.destReg !== null) { this.archRegFile[entry.destReg] = entry.result; } // Release store buffer entry to cache if (entry.isStore) { this.storeBuffer.commitToCache(entry.storeBufferIdx); } this.rob.retire(); retired++; } return retired; } handleException(entry) { // Save precise architectural state at exception point const preciseState = { pc: entry.pc, regs: [...this.archRegFile] }; this.rob.flushAll(); throw new PreciseException(entry.exception, preciseState); } }
Micro-op Fusion
Micro-op fusion combines multiple µops that were decoded from a single x86 instruction back into a single fused µop for more efficient execution, saving bandwidth in the backend. Common examples include fusing a load µop with an ALU µop (e.g., ADD EAX, [mem] stays as one fused µop through the pipeline until execution).
┌────────────────────────────────────────────────────────────┐ │ MICRO-OP FUSION │ │ │ │ x86 Instruction: ADD EAX, [RBX+RCX*4] │ │ │ │ Without Fusion: With Fusion: │ │ ┌─────────────┐ ┌─────────────────────┐ │ │ │ µop1: LOAD │ │ µop1: LOAD+ADD │ │ │ │ temp ← mem │ ──▶ │ (fused, 1 entry) │ │ │ ├─────────────┤ └─────────────────────┘ │ │ │ µop2: ADD │ │ │ │ EAX += temp │ Saves: ROB entry, RS entry, │ │ └─────────────┘ dispatch bandwidth │ │ │ │ Fusion Types: │ │ • Load + Op (most common) │ │ • Store-address + Store-data │ │ • Compare + Branch │ └────────────────────────────────────────────────────────────┘
class MicroOpFuser { static FUSABLE_PATTERNS = [ { type: 'load-op', pattern: ['LOAD', 'ALU'], fused: 'LOAD_ALU' }, { type: 'store', pattern: ['STA', 'STD'], fused: 'STORE' }, { type: 'cmp-branch', pattern: ['CMP', 'JCC'], fused: 'CMP_JCC' } ]; fuse(uops) { const result = []; let i = 0; while (i < uops.length) { let fused = false; for (const pattern of MicroOpFuser.FUSABLE_PATTERNS) { if (i + 1 < uops.length && uops[i].type === pattern.pattern[0] && uops[i + 1].type === pattern.pattern[1] && this.canFuse(uops[i], uops[i + 1])) { result.push({ type: pattern.fused, uop1: uops[i], uop2: uops[i + 1], isFused: true }); i += 2; fused = true; break; } } if (!fused) { result.push(uops[i]); i++; } } return result; } canFuse(uop1, uop2) { // Check addressing mode compatibility, same destination, etc. return uop1.dest === uop2.src1 || uop2.memOperand; } }
Macro-op Fusion
Macro-op fusion occurs in the decoder, combining two separate x86 instructions into a single µop, most commonly a compare/test instruction immediately followed by a conditional jump. This reduces decoder output bandwidth and execution resources while speeding up common branch idioms.
┌────────────────────────────────────────────────────────────┐ │ MACRO-OP FUSION │ │ │ │ Two x86 Instructions: │ │ ┌──────────────┐ │ │ │ CMP RAX, RBX │──┐ ┌─────────────────────┐ │ │ └──────────────┘ ├─────▶│ Single µop: │ │ │ ┌──────────────┐ │ │ CMP_JE (fused) │ │ │ │ JE label │──┘ └─────────────────────┘ │ │ └──────────────┘ │ │ │ │ Common Fusable Pairs: │ │ ┌──────────────────────────────────────────────┐ │ │ │ CMP + JE/JNE/JL/JG/JLE/JGE/JA/JB/... │ │ │ │ TEST + JE/JNE/JS/JNS/... │ │ │ │ AND + JE/JNE (when AND sets flags only) │ │ │ │ SUB + JE/JNE/... (some processors) │ │ │ │ INC/DEC + JE/JNE (some processors) │ │ │ └──────────────────────────────────────────────┘ │ │ │ │ Benefits: 1 decode slot, 1 ROB entry, 1 execution │ └────────────────────────────────────────────────────────────┘
class MacroOpFusionDecoder { static FUSABLE_FIRST = ['CMP', 'TEST', 'AND', 'SUB', 'ADD', 'INC', 'DEC']; static FUSABLE_SECOND = ['JE', 'JNE', 'JZ', 'JNZ', 'JL', 'JG', 'JLE', 'JGE', 'JA', 'JB', 'JBE', 'JAE', 'JS', 'JNS']; decode(instructions) { const uops = []; let i = 0; while (i < instructions.length) { const curr = instructions[i]; const next = instructions[i + 1]; if (next && this.canMacroFuse(curr, next)) { // Fuse into single compare-and-branch µop uops.push({ type: 'CMP_BR', opcode: `${curr.opcode}_${next.opcode}`, src1: curr.src1, src2: curr.src2, target: next.target, fusedFrom: [curr, next] }); i += 2; // Consumed two instructions } else { uops.push(...this.decodeNormal(curr)); i++; } } return uops; } canMacroFuse(first, second) { return MacroOpFusionDecoder.FUSABLE_FIRST.includes(first.opcode) && MacroOpFusionDecoder.FUSABLE_SECOND.includes(second.opcode) && this.isImmediatelyFollowing(first, second) && !first.usesRIPRelative; // RIP-relative breaks fusion on some CPUs } }
Loop Stream Detection
The Loop Stream Detector (LSD) identifies small loops that fit entirely in a special buffer and replays their µops directly without re-fetching or re-decoding, saving significant power and improving throughput. It locks the loop in a ~64 µop buffer and feeds the backend until a loop exit is detected.
┌────────────────────────────────────────────────────────────────┐ │ LOOP STREAM DETECTOR │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ Loop Detection Logic │ │ │ │ • Detect backward branch (loop edge) │ │ │ │ • Verify loop fits in LSD buffer │ │ │ │ • Lock loop after N iterations │ │ │ └─────────────────┬───────────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────┐ │ │ │ LSD µop Buffer (~64 µops) │ │ │ │ ┌───┬───┬───┬───┬───┬───┬───┬───┐ │ │ │ │ │µ0 │µ1 │µ2 │µ3 │µ4 │µ5 │...│µN │ │ │ │ │ └─┬─┴───┴───┴───┴───┴───┴───┴─┬─┘ │ │ │ │ │ │ │ │ │ │ └───────────────────────────┘ │ │ │ │ Circular Replay │ │ │ └─────────────────┬───────────────────────┘ │ │ ▼ │ │ Backend (skips fetch/decode) │ │ │ │ Power Savings: Fetch unit, Decoders, Branch Predictor OFF │ └────────────────────────────────────────────────────────────────┘
class LoopStreamDetector { constructor() { this.buffer = new Array(64); // Typically 28-64 µops this.state = 'INACTIVE'; // INACTIVE, LEARNING, STREAMING this.loopCount = 0; this.bufferSize = 0; this.streamPtr = 0; this.loopStartPC = null; this.loopEndPC = null; } onBranch(branchPC, targetPC, taken) { // Detect backward taken branch (potential loop) const isBackwardBranch = taken && targetPC < branchPC; switch (this.state) { case 'INACTIVE': if (isBackwardBranch) { this.state = 'LEARNING'; this.loopStartPC = targetPC; this.loopEndPC = branchPC; this.bufferSize = 0; } break; case 'LEARNING': if (branchPC === this.loopEndPC && taken) { this.loopCount++; if (this.loopCount >= 4 && this.bufferSize <= 64) { this.state = 'STREAMING'; console.log(`LSD locked: ${this.bufferSize} µops, PC ${this.loopStartPC}-${this.loopEndPC}`); } } else if (!taken || branchPC !== this.loopEndPC) { this.reset(); // Loop broken or different branch } break; case 'STREAMING': if (branchPC === this.loopEndPC && !taken) { this.reset(); // Loop exit detected } break; } } feedBackend() { if (this.state !== 'STREAMING') return null; const uop = this.buffer[this.streamPtr]; this.streamPtr = (this.streamPtr + 1) % this.bufferSize; return uop; // Feed from buffer, frontend powers down } reset() { this.state = 'INACTIVE'; this.loopCount = 0; this.bufferSize = 0; } }
Decoded Instruction Cache
The Decoded Instruction Cache (µop cache or DSB - Decoded Stream Buffer) stores already-decoded µops indexed by instruction address, bypassing the complex and power-hungry decode stage for frequently executed code. It typically holds 1.5K-4K µops and provides up to 6 µops/cycle, significantly higher than legacy decode throughput.
┌────────────────────────────────────────────────────────────────┐ │ DECODED INSTRUCTION CACHE (µop Cache / DSB) │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ L1 Instruction Fetch │ │ │ └────────────────────────┬─────────────────────────────┘ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ µop Cache Lookup │ │ │ │ (32 sets × 8 ways × 6 µops = 1536 µops) │ │ │ └──────────┬─────────────────────────────┬─────────────┘ │ │ │ │ │ │ HIT ▼ MISS ▼ │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ µop Cache Read │ │ Legacy Decode │ │ │ │ (6 µops/cycle) │ │ (4-5 µops/cycle)│ │ │ └────────┬─────────┘ └────────┬─────────┘ │ │ │ │ │ │ └──────────────┬──────────────┘ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ Instruction Decode Queue (IDQ) │ │ │ │ → Backend │ │ │ └──────────────────────────────────────────────────────┘ │ └────────────────────────────────────────────────────────────────┘ Performance Impact: ┌─────────────────────────────────────────┐ │ µop Cache Hit: ~6 µops/cycle │ │ Legacy Decode: ~4-5 µops/cycle │ │ Complex Instr: ~1-2 µops/cycle (MSROM)│ └─────────────────────────────────────────┘
class DecodedInstructionCache { constructor() { // Intel Skylake-like: 32 sets × 8 ways × 6 µops this.numSets = 32; this.numWays = 8; this.uopsPerWay = 6; this.cache = Array.from({ length: this.numSets }, () => Array.from({ length: this.numWays }, () => ({ valid: false, tag: null, uops: [], lru: 0 })) ); this.stats = { hits: 0, misses: 0 }; } lookup(pc) { const setIndex = (pc >> 6) & (this.numSets - 1); const tag = pc >> 11; const set = this.cache[setIndex]; for (const way of set) { if (way.valid && way.tag === tag) { this.stats.hits++; this.updateLRU(set, way); return { hit: true, uops: way.uops }; // Up to 6 µops/cycle } } this.stats.misses++; return { hit: false }; // Fall back to legacy decode } insert(pc, uops) { if (uops.length > this.uopsPerWay) return; // Too many µops, can't cache const setIndex = (pc >> 6) & (this.numSets - 1); const tag = pc >> 11; const set = this.cache[setIndex]; // Find LRU way for eviction const victim = set.reduce((min, way) => way.lru < min.lru ? way : min); victim.valid = true; victim.tag = tag; victim.uops = [...uops]; this.updateLRU(set, victim); } updateLRU(set, accessedWay) { const maxLRU = Math.max(...set.map(w => w.lru)); accessedWay.lru = maxLRU + 1; } getHitRate() { const total = this.stats.hits + this.stats.misses; return total > 0 ? (this.stats.hits / total * 100).toFixed(2) + '%' : 'N/A'; } } // Usage simulation const uopCache = new DecodedInstructionCache(); // Hot function gets cached after first decode function simulateExecution(hotFunctionPC, uopsFromDecode) { let result = uopCache.lookup(hotFunctionPC); if (!result.hit) { // First time: decode and cache uopCache.insert(hotFunctionPC, uopsFromDecode); return { source: 'MITE (legacy decode)', uops: uopsFromDecode }; } return { source: 'DSB (µop cache)', uops: result.uops }; }
Digital Signal Processors (DSP)
DSPs are microprocessors optimized for real-time signal processing with architectures featuring hardware multiply-accumulate (MAC) units, circular buffers, zero-overhead loops, and VLIW/SIMD execution. They achieve deterministic, low-latency processing essential for audio codecs, telecommunications (5G baseband), radar, and sensor fusion. Unlike GPUs, DSPs prioritize predictable timing over raw throughput—examples include TI C6000 series and Qualcomm Hexagon in mobile SoCs.
┌─────────────────────────────────────────────────────────────────┐ │ DIGITAL SIGNAL PROCESSOR (DSP) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ DSP vs GENERAL-PURPOSE CPU: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ General CPU: DSP: ││ │ │ ┌─────────────────┐ ┌─────────────────────────────┐ ││ │ │ │ • Branch pred │ │ • Hardware MAC units │ ││ │ │ │ • Out-of-order │ │ • Zero-overhead loops │ ││ │ │ │ • Large caches │ │ • Circular addressing │ ││ │ │ │ • Complex ISA │ │ • Saturating arithmetic │ ││ │ │ │ • Variable lat │ │ • Fixed-point support │ ││ │ │ └─────────────────┘ │ • Deterministic timing │ ││ │ │ │ • Parallel data paths │ ││ │ │ Optimized for: └─────────────────────────────┘ ││ │ │ General computing Optimized for: ││ │ │ Signal processing ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ DSP ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ DSP Core │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ VLIW Execution Units │ │ ││ │ │ │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ ││ │ │ │ │ │ MAC │ │ MAC │ │ ALU │ │ ALU │ │LD/ST│ │ │ ││ │ │ │ │ │ #1 │ │ #2 │ │ #1 │ │ #2 │ │ │ │ │ ││ │ │ │ │ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │ │ ││ │ │ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ └───────┴───────┴───────┴───────┘ │ │ ││ │ │ │ │ (Execute in parallel) │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌──────────────────┐ ┌──────────────────────────┐ │ ││ │ │ │ │ Register File │ │ Address Generation │ │ ││ │ │ │ │ (32-64 regs) │ │ ┌────────────────────┐ │ │ ││ │ │ │ │ ┌────┬────┬───┐ │ │ │ Circular Buffer │ │ │ ││ │ │ │ │ │ A0 │ A1 │...│ │ │ │ ┌───────────────┐ │ │ │ ││ │ │ │ │ ├────┼────┼───┤ │ │ │ │►[0][1][2][3]│ │ │ │ ││ │ │ │ │ │ D0 │ D1 │...│ │ │ │ │ ptr wraps │ │ │ │ ││ │ │ │ │ └────┴────┴───┘ │ │ │ └───────────────┘ │ │ │ ││ │ │ │ └──────────────────┘ │ └────────────────────┘ │ │ ││ │ │ │ └──────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Zero-Overhead Loop Hardware │ │ ││ │ │ │ │ • Loop counter in hardware │ │ ││ │ │ │ │ • No branch penalty │ │ ││ │ │ │ │ • Single-cycle loop iteration │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ MULTIPLY-ACCUMULATE (MAC) OPERATION: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ FIR Filter: y[n] = Σ(h[k] × x[n-k]) ││ │ │ ││ │ │ CPU (multiple instructions): DSP (single MAC): ││ │ │ ┌─────────────────────────┐ ┌─────────────────────────┐││ │ │ │ MUL R1, h[k], x[n-k] │ │ MAC ACC, h[k], x[n-k] │││ │ │ │ ADD ACC, ACC, R1 │ │ (multiply + accumulate │││ │ │ │ (2 cycles minimum) │ │ in 1 cycle) │││ │ │ └─────────────────────────┘ └─────────────────────────┘││ │ │ ││ │ │ MAC Unit: ││ │ │ ┌─────┐ ┌─────┐ ││ │ │ │ A │ │ B │ Inputs ││ │ │ └──┬──┘ └──┬──┘ ││ │ │ │ │ ││ │ │ └────┬────┘ ││ │ │ │ ││ │ │ ┌────┴────┐ ││ │ │ │Multiplier│ ││ │ │ └────┬────┘ ││ │ │ │ ││ │ │ ┌────┴────┐ ┌─────────┐ ││ │ │ │ Adder │◄──│Accumulator│ ││ │ │ └────┬────┘ └────┬────┘ ││ │ │ │ │ ││ │ │ └──────┬──────┘ ││ │ │ │ ││ │ │ ┌──────┴──────┐ ││ │ │ │ Accumulator │ (40-80 bit for precision) ││ │ │ └─────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ DSP APPLICATIONS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Audio Processing: ││ │ │ • Codecs (MP3, AAC, Opus) ││ │ │ • Noise cancellation ││ │ │ • Echo cancellation ││ │ │ • Spatial audio ││ │ │ ││ │ │ Telecommunications: ││ │ │ • 5G/LTE baseband processing ││ │ │ • Channel coding/decoding ││ │ │ • Modulation/demodulation ││ │ │ • Beamforming ││ │ │ ││ │ │ Image/Video: ││ │ │ • JPEG/H.264/H.265 encoding ││ │ │ • Image filtering ││ │ │ • Computer vision preprocessing ││ │ │ ││ │ │ Automotive: ││ │ │ • Radar signal processing ││ │ │ • Sensor fusion ││ │ │ • Active noise control ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ EXAMPLE DSPs: │ │ ┌────────────────┬────────────────────────────────────────┐ │ │ │ TI C6678 │ 8 cores, 10 GFLOPS, telecom/industrial │ │ │ │ Qualcomm Hexagon│ Mobile SoC, AI + audio + sensors │ │ │ │ Cadence Tensilica│ Configurable, audio/voice/vision │ │ │ │ Analog Devices SHARC│ Audio, high precision floating │ │ │ └────────────────┴────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘
FPGA Architecture
Field-Programmable Gate Arrays contain millions of configurable logic blocks (CLBs), programmable interconnects, and specialized hard blocks (DSP slices, memory, transceivers). Unlike fixed ASICs, FPGAs can be reprogrammed post-manufacturing, enabling hardware prototyping, custom accelerators, and low-latency processing. Modern FPGAs from Xilinx (AMD) and Intel include ARM cores, high-speed I/O (400G Ethernet, PCIe 5.0), and HBM memory for cloud acceleration.
┌─────────────────────────────────────────────────────────────────┐ │ FPGA ARCHITECTURE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ FPGA STRUCTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ I/O Blocks │ ││ │ │ │ [IOB][IOB][IOB][IOB][IOB][IOB][IOB][IOB][IOB][IOB] │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ┌──┬─────────────────────────────────────────────┬──┐ ││ │ │ │ │ │ │ ││ │ │ │I │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │I │ ││ │ │ │O │ │ CLB │══│ CLB │══│ CLB │══│ CLB │ │O │ ││ │ │ │ │ └──╦══┘ └══╦══┘ └══╦══┘ └══╦══┘ │ │ ││ │ │ │B │ ║ ║ ║ ║ │B │ ││ │ │ │l │ ┌──╨──┐ ┌──╨──┐ ┌──╨──┐ ┌──╨──┐ │l │ ││ │ │ │o │ │ CLB │══│BRAM │══│ CLB │══│ DSP │ │o │ ││ │ │ │c │ └──╦══┘ └══╦══┘ └══╦══┘ └══╦══┘ │c │ ││ │ │ │k │ ║ ║ ║ ║ │k │ ││ │ │ │s │ ┌──╨──┐ ┌──╨──┐ ┌──╨──┐ ┌──╨──┐ │s │ ││ │ │ │ │ │ CLB │══│ CLB │══│ CLB │══│ CLB │ │ │ ││ │ │ │ │ └─────┘ └─────┘ └─────┘ └─────┘ │ │ ││ │ │ └──┴─────────────────────────────────────────────┴──┘ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Hard IP: PCIe, Ethernet MAC, ARM Cores │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ CLB = Configurable Logic Block ││ │ │ BRAM = Block RAM ││ │ │ DSP = DSP Slice (multiply-accumulate) ││ │ │ ═══ = Programmable Interconnect ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ CONFIGURABLE LOGIC BLOCK (CLB): │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ CLB │ ││ │ │ │ ┌─────────────────────────────────────────────┐ │ ││ │ │ │ │ SLICE │ │ ││ │ │ │ │ ┌─────────────────────────────────────┐ │ │ ││ │ │ │ │ │ LUT (Look-Up Table) │ │ │ ││ │ │ │ │ │ ┌───────────────────────────────┐ │ │ │ ││ │ │ │ │ │ │ 6-input LUT = 64-bit SRAM │ │ │ │ ││ │ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ │ │ A ─┐ │ │ │ │ ││ │ │ │ │ │ │ B ─┤ │ │ │ │ ││ │ │ │ │ │ │ C ─┼──► [64-bit table] ──► Y │ │ │ │ ││ │ │ │ │ │ │ D ─┤ │ │ │ │ ││ │ │ │ │ │ │ E ─┤ Can implement ANY │ │ │ │ ││ │ │ │ │ │ │ F ─┘ 6-input function │ │ │ │ ││ │ │ │ │ │ └───────────────────────────────┘ │ │ │ ││ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ │ ┌──────┴──────┐ │ │ │ ││ │ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ │ ┌────┴────┐ ┌─────┴────┐ │ │ │ ││ │ │ │ │ │ │ MUX │ │ Flip-Flop│ │ │ │ ││ │ │ │ │ │ └────┬────┘ │ (FF) │ │ │ │ ││ │ │ │ │ │ │ └────┬─────┘ │ │ │ ││ │ │ │ │ │ └─────┬──────┘ │ │ │ ││ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ │ Output │ │ │ ││ │ │ │ │ └─────────────────────────────────────┘ │ │ ││ │ │ │ │ │ │ ││ │ │ │ │ (Typical slice has 4-8 LUTs + FFs) │ │ ││ │ │ │ └─────────────────────────────────────────────┘ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ FPGA vs CPU vs GPU vs ASIC: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌──────────┬──────────┬──────────┬──────────┬───────────┐ ││ │ │ │ │ CPU │ GPU │ FPGA │ ASIC │ ││ │ │ ├──────────┼──────────┼──────────┼──────────┼───────────┤ ││ │ │ │Flexibility│ High │ Medium │ High │ None │ ││ │ │ │Performance│ Medium │ High │ High │ Highest │ ││ │ │ │Power Eff │ Low │ Medium │ High │ Highest │ ││ │ │ │Latency │ Variable │ Variable │ Fixed │ Fixed │ ││ │ │ │Dev Time │ Short │ Medium │ Long │Very Long │ ││ │ │ │Unit Cost │ Low │ Medium │ High │ Low@scale │ ││ │ │ │NRE Cost │ None │ None │ None │ $1M-100M │ ││ │ │ └──────────┴──────────┴──────────┴──────────┴───────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ MODERN FPGA FEATURES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ AMD/Xilinx Versal ACAP: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ │ │ Scalar │ │ Adaptable │ │ Intelligent │ │ ││ │ │ │ │ Engines │ │ Engines │ │ Engines │ │ ││ │ │ │ │ (ARM Cortex)│ │ (FPGA) │ │ (AI Cores) │ │ ││ │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ││ │ │ │ │ │ │ │ ││ │ │ │ └────────────────┼────────────────┘ │ ││ │ │ │ Network on Chip │ ││ │ │ │ ┌─────────────────────────────────────────────────┐│ ││ │ │ │ │ HBM2e (32GB) | DDR5 | PCIe 5.0 | 400G ││ ││ │ │ │ └─────────────────────────────────────────────────┘│ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Specifications (high-end): ││ │ │ • 2M+ logic cells ││ │ │ • 10,000+ DSP slices ││ │ │ • 500+ Mb block RAM ││ │ │ • 400G Ethernet ││ │ │ • PCIe Gen5 x16 ││ │ │ • HBM2e memory ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ FPGA USE CASES: │ │ • Network packet processing (SmartNICs) │ │ • Hardware security modules │ │ • Video transcoding/processing │ │ • Financial trading (low latency) │ │ • 5G baseband acceleration │ │ • AI inference acceleration │ │ • ASIC prototyping │ │ • Aerospace/defense │ └─────────────────────────────────────────────────────────────────┘
ASIC Design Flow
Application-Specific Integrated Circuits are custom chips designed for specific functions, offering maximum performance and power efficiency but requiring significant upfront investment ($10M-$500M for advanced nodes). The design flow progresses from RTL (Verilog/VHDL) through synthesis, place-and-route, timing closure, and physical verification before tape-out. Modern ASICs at 5nm contain billions of transistors—examples include Apple M-series, Google TPU, and Bitcoin mining chips.
┌─────────────────────────────────────────────────────────────────┐ │ ASIC DESIGN FLOW │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ASIC DEVELOPMENT PHASES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ 1. SPECIFICATION & ARCHITECTURE │ ││ │ │ │ • Define functionality, performance targets │ ││ │ │ │ • Power budget, area constraints │ ││ │ │ │ • Interface definitions │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ 2. RTL DESIGN (Register Transfer Level) │ ││ │ │ │ • Write Verilog/VHDL/SystemVerilog │ ││ │ │ │ • Functional simulation │ ││ │ │ │ • Code review, linting │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ 3. SYNTHESIS │ ││ │ │ │ • RTL → Gate-level netlist │ ││ │ │ │ • Technology mapping to standard cells │ ││ │ │ │ • Timing constraints (SDC) │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ 4. PLACE AND ROUTE (P&R) │ ││ │ │ │ • Floorplanning │ ││ │ │ │ • Cell placement │ ││ │ │ │ • Clock tree synthesis │ ││ │ │ │ • Signal routing │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ 5. TIMING CLOSURE │ ││ │ │ │ • Static timing analysis (STA) │ ││ │ │ │ • Fix setup/hold violations │ ││ │ │ │ • Multiple corners (PVT variations) │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ 6. PHYSICAL VERIFICATION │ ││ │ │ │ • DRC (Design Rule Check) │ ││ │ │ │ • LVS (Layout vs Schematic) │ ││ │ │ │ • ERC (Electrical Rule Check) │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ 7. TAPE-OUT │ ││ │ │ │ • Generate GDSII file │ ││ │ │ │ • Send to foundry (TSMC, Samsung, Intel) │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ 8. FABRICATION & PACKAGING │ ││ │ │ │ • Wafer fabrication (2-4 months) │ ││ │ │ │ • Packaging, testing │ ││ │ │ │ • First silicon bring-up │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ SYNTHESIS FLOW DETAIL: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ RTL Code (Verilog): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ module adder(input [7:0] a, b, output [8:0] sum); │ ││ │ │ │ assign sum = a + b; │ ││ │ │ │ endmodule │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ │ Synthesis ││ │ │ ▼ ││ │ │ Gate-Level Netlist: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ ┌─────┐ ┌─────┐ ┌─────┐ │ ││ │ │ │ │ XOR │───│ AND │───│ OR │──► sum[0] │ ││ │ │ │ └─────┘ └─────┘ └─────┘ │ ││ │ │ │ (Mapped to standard cell library) │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ │ Place & Route ││ │ │ ▼ ││ │ │ Physical Layout: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ ┌─────────────────────────────────────────────┐ │ ││ │ │ │ │ ▓▓▓▓░░░░▓▓▓▓░░░░▓▓▓▓░░░░▓▓▓▓░░░░▓▓▓▓░░░░ │ │ ││ │ │ │ │ ░░░░▓▓▓▓░░░░▓▓▓▓░░░░▓▓▓▓░░░░▓▓▓▓░░░░▓▓▓▓ │ │ ││ │ │ │ │ ════════════════════════════════════════ │ │ ││ │ │ │ │ ▓▓▓▓░░░░▓▓▓▓░░░░▓▓▓▓░░░░▓▓▓▓░░░░▓▓▓▓░░░░ │ │ ││ │ │ │ │ (Standard cells placed in rows) │ │ ││ │ │ │ │ (Metal layers for routing) │ │ ││ │ │ │ └─────────────────────────────────────────────┘ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ COST BREAKDOWN (5nm ASIC): │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────┬──────────────────────────┐ ││ │ │ │ Item │ Cost │ ││ │ │ ├─────────────────────────┼──────────────────────────┤ ││ │ │ │ EDA Tools (annual) │ $5-20M │ ││ │ │ │ Engineering team │ $10-50M │ ││ │ │ │ IP licensing │ $5-30M │ ││ │ │ │ Mask set (5nm) │ $15-30M │ ││ │ │ │ Prototype wafers │ $5-10M │ ││ │ │ │ Testing/validation │ $5-20M │ ││ │ │ ├─────────────────────────┼──────────────────────────┤ ││ │ │ │ TOTAL NRE │ $50-150M+ │ ││ │ │ └─────────────────────────┴──────────────────────────┘ ││ │ │ ││ │ │ Break-even typically requires millions of units ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ NOTABLE ASICs: │ │ ┌────────────────┬────────────────────────────────────────┐ │ │ │ Apple M3 Ultra │ 3nm, 92B transistors, CPU+GPU+NPU │ │ │ │ Google TPU v5 │ AI training, custom matrix units │ │ │ │ Bitcoin miners │ SHA-256 only, extreme efficiency │ │ │ │ Network ASICs │ Memory-only, 51.2 Tbps (Memory Memory)│ │ │ └────────────────┴────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘
TPU Architecture
Google's Tensor Processing Units are domain-specific ASICs optimized for neural network inference and training. TPUs feature systolic arrays of multiply-accumulate units for efficient matrix multiplication, high-bandwidth memory (HBM), and custom interconnects for multi-chip scaling. TPU v4 delivers 275 TFLOPS (BF16), connected in pods of 4096 chips via 3D torus network—purpose-built for transformer models and large-scale ML training.
┌─────────────────────────────────────────────────────────────────┐ │ TPU (TENSOR PROCESSING UNIT) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ TPU ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ TPU v4 Chip │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Matrix Multiply Unit (MXU) │ │ ││ │ │ │ │ │ │ ││ │ │ │ │ ┌─────────────────────────────────────────────┐│ │ ││ │ │ │ │ │ Systolic Array (128×128) ││ │ ││ │ │ │ │ │ ││ │ ││ │ │ │ │ │ Weight ──►┌──┬──┬──┬──┬──┐ ││ │ ││ │ │ │ │ │ │PE│PE│PE│PE│PE│──► ││ │ ││ │ │ │ │ │ ├──┼──┼──┼──┼──┤ ││ │ ││ │ │ │ │ │ Input ───►│PE│PE│PE│PE│PE│──► Output ││ │ ││ │ │ │ │ │ │ ├──┼──┼──┼──┼──┤ ││ │ ││ │ │ │ │ │ │ │PE│PE│PE│PE│PE│──► ││ │ ││ │ │ │ │ │ ▼ └──┴──┴──┴──┴──┘ ││ │ ││ │ │ │ │ │ ││ │ ││ │ │ │ │ │ PE = Processing Element (MAC unit) ││ │ ││ │ │ │ │ │ Data flows through array, weights stationary││ │ ││ │ │ │ │ └─────────────────────────────────────────────┘│ │ ││ │ │ │ │ │ │ ││ │ │ │ │ • 128×128 = 16,384 MACs per cycle │ │ ││ │ │ │ │ • BF16/INT8 precision │ │ ││ │ │ │ │ • 275 TFLOPS (BF16) │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Vector Processing Unit │ │ ││ │ │ │ │ • Activation functions (ReLU, Softmax) │ │ ││ │ │ │ │ • Normalization (BatchNorm, LayerNorm) │ │ ││ │ │ │ │ • Element-wise operations │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ High Bandwidth Memory (HBM) │ │ ││ │ │ │ │ • 32GB HBM2e per chip │ │ ││ │ │ │ │ • 1.2 TB/s bandwidth │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Inter-Chip Interconnect (ICI) │ │ ││ │ │ │ │ • 6 links per chip │ │ ││ │ │ │ │ • Direct chip-to-chip communication │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ SYSTOLIC ARRAY OPERATION: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Matrix Multiplication: C = A × B ││ │ │ ││ │ │ Cycle 1: Cycle 2: Cycle 3: ││ │ │ ┌──┬──┬──┐ ┌──┬──┬──┐ ┌──┬──┬──┐ ││ │ │ │a0│ │ │ │a1│a0│ │ │a2│a1│a0│ ││ │ │ │b0│ │ │ │b1│b0│ │ │b2│b1│b0│ ││ │ │ └──┴──┴──┘ └──┴──┴──┘ └──┴──┴──┘ ││ │ │ ││ │ │ • Data flows diagonally through array ││ │ │ • Each PE: accumulate += weight × input ││ │ │ • Maximum reuse of data (no repeated memory access) ││ │ │ • Highly efficient for matrix operations ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ TPU POD (v4): │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ TPU v4 Pod (4096 chips) │ ││ │ │ │ │ ││ │ │ │ ┌───┬───┬───┬───┐ 3D Torus Topology │ ││ │ │ │ ╱│ │ │ │ │╲ │ ││ │ │ │ ┌───┬───┬───┬───┐ │ • 4×4×4 × 64 = 4096 chips │ ││ │ │ │ │TPU│TPU│TPU│TPU│─┤ • Direct chip interconnect │ ││ │ │ │ ├───┼───┼───┼───┤ │ • 1.1 Exaflops (BF16) │ ││ │ │ │ │TPU│TPU│TPU│TPU│─┤ • 128TB HBM total │ ││ │ │ │ ├───┼───┼───┼───┤ │ │ ││ │ │ │ │TPU│TPU│TPU│TPU│─┤ │ ││ │ │ │ ├───┼───┼───┼───┤ │ │ ││ │ │ │ │TPU│TPU│TPU│TPU│╱ │ ││ │ │ │ └───┴───┴───┴───┘ │ ││ │ │ │ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ TPU EVOLUTION: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌────────┬──────────┬──────────┬────────────────────────┐ ││ │ │ │ Version│ Year │ TFLOPS │ Features │ ││ │ │ ├────────┼──────────┼──────────┼────────────────────────┤ ││ │ │ │ TPU v1 │ 2016 │ 92 (INT8)│ Inference only │ ││ │ │ │ TPU v2 │ 2017 │ 45 (BF16)│ Training support │ ││ │ │ │ TPU v3 │ 2018 │ 123 │ Liquid cooling │ ││ │ │ │ TPU v4 │ 2021 │ 275 │ 3D torus, larger pods │ ││ │ │ │ TPU v5e│ 2023 │ 197 │ Cost-efficient │ ││ │ │ │ TPU v5p│ 2023 │ 459 │ Highest performance │ ││ │ │ └────────┴──────────┴──────────┴────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ TPU vs GPU for ML: │ │ ┌────────────────────┬────────────────┬────────────────────┐ │ │ │ Aspect │ TPU │ GPU (A100) │ │ │ ├────────────────────┼────────────────┼────────────────────┤ │ │ │ Architecture │ Systolic array │ CUDA cores+Tensors │ │ │ │ Precision focus │ BF16, INT8 │ FP16, FP32, INT8 │ │ │ │ Memory │ HBM (on-chip) │ HBM (on-chip) │ │ │ │ Interconnect │ Custom ICI │ NVLink │ │ │ │ Programming │ JAX, TensorFlow│ CUDA, cuDNN │ │ │ │ Availability │ Google Cloud │ Anywhere │ │ │ └────────────────────┴────────────────┴────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘
Neural Processing Units (NPU)
NPUs are specialized accelerators for neural network inference integrated into mobile SoCs, laptops, and edge devices. Unlike datacenter TPUs, NPUs optimize for power efficiency (TOPS/watt) and low-latency local inference. They feature quantized INT8/INT4 computation, on-chip SRAM to minimize memory access, and hardware support for common operations (convolution, attention). Examples include Apple Neural Engine, Qualcomm Hexagon NPU, and Intel NPU in Core Ultra processors.
┌─────────────────────────────────────────────────────────────────┐ │ NEURAL PROCESSING UNIT (NPU) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ NPU IN MOBILE/EDGE SOC: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Mobile SoC (e.g., Apple A17 Pro) │ ││ │ │ │ │ ││ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ ││ │ │ │ │ CPU │ │ GPU │ │ NPU │ │ ISP │ │ ││ │ │ │ │ (6-core)│ │ (6-core)│ │(16-core)│ │(camera) │ │ ││ │ │ │ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ General │ │Graphics │ │ AI │ │ Image │ │ ││ │ │ │ │ compute │ │ +ML │ │Inference│ │ proc │ │ ││ │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │ ││ │ │ │ │ │ │ │ │ ││ │ │ │ └───────────┴─────┬─────┴───────────┘ │ ││ │ │ │ │ │ ││ │ │ │ ┌──────────────────────┴──────────────────────────┐ │ ││ │ │ │ │ Unified Memory (LPDDR5) │ │ ││ │ │ │ │ 8-16 GB │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ NPU ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ NPU Core │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Neural Engine Array │ │ ││ │ │ │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ ││ │ │ │ │ │ MAC │ │ MAC │ │ MAC │ │ MAC │ │ MAC │ ... │ │ ││ │ │ │ │ │Array│ │Array│ │Array│ │Array│ │Array│ │ │ ││ │ │ │ │ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │ │ ││ │ │ │ │ │ │ ││ │ │ │ │ • INT8/INT4 optimized │ │ ││ │ │ │ │ • 35 TOPS (Apple Neural Engine) │ │ ││ │ │ │ │ • ~10 TOPS/W efficiency │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ On-Chip SRAM │ │ ││ │ │ │ │ • Weights cached locally │ │ ││ │ │ │ │ • Activations buffered │ │ ││ │ │ │ │ • Minimizes DRAM access (power savings) │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Special Function Units │ │ ││ │ │ │ │ • Activation (ReLU, GELU, Sigmoid) │ │ ││ │ │ │ │ • Pooling (Max, Average) │ │ ││ │ │ │ │ • Softmax │ │ ││ │ │ │ │ • Normalization │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ NPU vs GPU vs CPU FOR INFERENCE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Task: Run MobileNet on 1000 images ││ │ │ ││ │ │ ┌──────────────┬──────────┬──────────┬──────────────────┐ ││ │ │ │ Processor │ Time │ Power │ Energy │ ││ │ │ ├──────────────┼──────────┼──────────┼──────────────────┤ ││ │ │ │ CPU │ 100s │ 5W │ 500 J │ ││ │ │ │ GPU │ 10s │ 10W │ 100 J │ ││ │ │ │ NPU │ 5s │ 1W │ 5 J │ ││ │ │ └──────────────┴──────────┴──────────┴──────────────────┘ ││ │ │ ││ │ │ NPU: 100x more energy efficient than CPU ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ NPU USE CASES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Mobile: ││ │ │ • Face ID / Face unlock ││ │ │ • Computational photography ││ │ │ • Real-time translation ││ │ │ • Voice assistants (Siri, Google Assistant) ││ │ │ • On-device ML (Core ML, TensorFlow Lite) ││ │ │ ││ │ │ Laptop (Intel Core Ultra NPU): ││ │ │ • Windows Copilot ││ │ │ • Background blur in video calls ││ │ │ • Real-time captions ││ │ │ • Local LLM inference ││ │ │ ││ │ │ Edge/IoT: ││ │ │ • Security cameras (object detection) ││ │ │ • Smart speakers ││ │ │ • Autonomous drones ││ │ │ • Industrial quality inspection ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ NOTABLE NPUs: │ │ ┌────────────────────┬────────────────────────────────────┐ │ │ │ Apple Neural Engine│ 35 TOPS, 16 cores, A17/M3 │ │ │ │ Qualcomm Hexagon │ 45 TOPS, Snapdragon 8 Gen 3 │ │ │ │ Google Tensor │ Custom NPU in Pixel phones │ │ │ │ Intel NPU │ 10+ TOPS, Core Ultra processors │ │ │ │ AMD XDNA │ AI Engine in Ryzen AI │ │ │ │ Samsung NPU │ Exynos series │ │ │ └────────────────────┴────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘
Inference Accelerators
Inference accelerators are optimized for deploying trained models in production, prioritizing throughput, latency, and cost-efficiency over training flexibility. They support aggressive quantization (INT8, INT4), model compilation/optimization, and batching. Examples range from datacenter cards (NVIDIA T4, AWS Inferentia, Habana Gaudi) to edge devices (Google Coral TPU, NVIDIA Jetson)—each targeting different performance/power/cost trade-offs.
┌─────────────────────────────────────────────────────────────────┐ │ INFERENCE ACCELERATORS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ INFERENCE vs TRAINING REQUIREMENTS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌───────────────────┬─────────────────┬─────────────────┐ ││ │ │ │ Aspect │ Training │ Inference │ ││ │ │ ├───────────────────┼─────────────────┼─────────────────┤ ││ │ │ │ Precision │ FP32, FP16, BF16│ INT8, INT4, FP16│ ││ │ │ │ Batch size │ Large (32-4096) │ Small (1-32) │ ││ │ │ │ Memory │ Very high │ Moderate │ ││ │ │ │ Backward pass │ Required │ Not needed │ ││ │ │ │ Latency priority │ Low │ High │ ││ │ │ │ Throughput need │ Moderate │ Very high │ ││ │ │ │ Cost sensitivity │ Lower │ Higher │ ││ │ │ └───────────────────┴─────────────────┴─────────────────┘ ││ │ │ │ INFERENCE ACCELERATOR LANDSCAPE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ DATACENTER: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ │ │ NVIDIA │ │ AWS │ │ Google │ │ ││ │ │ │ │ T4/L4/L40S │ │ Inferentia2 │ │ TPU (inf) │ │ ││ │ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ • 330 TOPS │ │ • 380 TOPS │ │ • 275 TOPS │ │ ││ │ │ │ │ • INT8 │ │ • INT8 │ │ • INT8 │ │ ││ │ │ │ │ • 70W │ │ • 50W │ │ • 175W │ │ ││ │ │ │ │ • CUDA │ │ • Neuron SDK│ │ • JAX │ │ ││ │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ │ │ Intel │ │ AMD │ │ Habana │ │ ││ │ │ │ │ Gaudi2 │ │ MI300X │ │ Greco │ │ ││ │ │ │ │ │ │ (inference) │ │ │ │ ││ │ │ │ │ • 600 TOPS │ │ • 1300 TOPS │ │ • 350 TOPS │ │ ││ │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ EDGE: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ │ │ Google │ │ NVIDIA │ │ Hailo │ │ ││ │ │ │ │ Coral TPU │ │ Jetson Orin │ │ Hailo-8 │ │ ││ │ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ • 4 TOPS │ │ • 275 TOPS │ │ • 26 TOPS │ │ ││ │ │ │ │ • 2W │ │ • 15-60W │ │ • 2.5W │ │ ││ │ │ │ │ • USB/PCIe │ │ • Module │ │ • M.2 │ │ ││ │ │ │ │ • $25 │ │ • $200-2000 │ │ • $100 │ │ ││ │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ AWS INFERENTIA2 ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Inferentia2 Chip (inf2) │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ NeuronCore-v2 (×2 per chip) │ │ ││ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ ││ │ │ │ │ │ Tensor Engine │ Vector Engine │ │ │ ││ │ │ │ │ │ • Matrix ops │ • Activations │ │ │ ││ │ │ │ │ │ • 190 TFLOPS │ • Normalization │ │ │ ││ │ │ │ │ │ (FP16) │ • Pooling │ │ │ ││ │ │ │ │ └─────────────────────────────────────────┘ │ │ ││ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ ││ │ │ │ │ │ GPSIMD Engine │ Scalar Engine │ │ │ ││ │ │ │ │ │ • Custom ops │ • Control flow │ │ │ ││ │ │ │ │ └─────────────────────────────────────────┘ │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ 32GB HBM2e │ NeuronLink (chip-to-chip) │ │ ││ │ │ │ │ 820 GB/s │ 384 GB/s per link │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Neuron SDK Compilation: ││ │ │ PyTorch Model → torch_neuronx.trace() → Compiled Model ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ INFERENCE OPTIMIZATION TECHNIQUES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ 1. QUANTIZATION: ││ │ │ FP32 (4 bytes) → INT8 (1 byte) → INT4 (0.5 bytes) ││ │ │ • 4-8x memory reduction ││ │ │ • 2-4x throughput increase ││ │ │ • <1% accuracy loss (with calibration) ││ │ │ ││ │ │ 2. BATCHING: ││ │ │ ┌─────────────────────────────────────────────────┐ ││ │ │ │ Single request: [Req1] → Process → [Resp1] │ ││ │ │ │ Batched: [R1,R2,R3,R4] → Process → │ ││ │ │ │ [Resp1,2,3,4] │ ││ │ │ │ • Better hardware utilization │ ││ │ │ │ • Higher throughput, slightly higher latency │ ││ │ │ └─────────────────────────────────────────────────┘ ││ │ │ ││ │ │ 3. MODEL COMPILATION: ││ │ │ • Operator fusion (Conv+BN+ReLU → single kernel) ││ │ │ • Memory planning (minimize copies) ││ │ │ • Hardware-specific optimizations ││ │ │ ││ │ │ 4. CACHING: ││ │ │ • KV-cache for transformers ││ │ │ • Prompt caching for repeated prefixes ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ COST COMPARISON (per 1M inferences): │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Model: ResNet-50, Batch size: 1 ││ │ │ ││ │ │ ┌────────────────────┬──────────┬──────────┬───────────┐ ││ │ │ │ Platform │ Latency │ Cost/1M │ $/TOPS │ ││ │ │ ├────────────────────┼──────────┼──────────┼───────────┤ ││ │ │ │ CPU (c5.xlarge) │ 50ms │ $4.50 │ N/A │ ││ │ │ │ GPU (g4dn.xlarge) │ 5ms │ $1.50 │ $1.60 │ ││ │ │ │ Inferentia (inf1) │ 3ms │ $0.30 │ $0.80 │ ││ │ │ │ Graviton3 (c7g) │ 30ms │ $0.90 │ N/A │ ││ │ │ └────────────────────┴──────────┴──────────┴───────────┘ ││ │ │ ││ │ │ Inference accelerators: 5-15x cost reduction vs GPU ││ │ └─────────────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────────────┘
Cryptographic Accelerators
Cryptographic accelerators offload computationally intensive encryption/decryption, hashing, and key operations from CPUs. Modern implementations include AES-NI instructions in x86 CPUs, dedicated crypto engines in SoCs, and Hardware Security Modules (HSMs) for key management. They provide constant-time execution (preventing timing attacks), higher throughput, and secure key storage—critical for TLS termination, disk encryption, and blockchain operations.
┌─────────────────────────────────────────────────────────────────┐ │ CRYPTOGRAPHIC ACCELERATORS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ CRYPTO ACCELERATION LEVELS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Level 1: CPU Instructions (AES-NI, SHA-NI) ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ ┌─────────────────────────────────────────────┐ │ ││ │ │ │ │ CPU Core │ │ ││ │ │ │ │ ┌─────────────────────────────────────┐ │ │ ││ │ │ │ │ │ Crypto Execution Units │ │ │ ││ │ │ │ │ │ ┌─────────┐ ┌─────────┐ │ │ │ ││ │ │ │ │ │ │ AES-NI │ │ SHA-NI │ │ │ │ ││ │ │ │ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ │ │AESENC │ │SHA256MSG│ │ │ │ ││ │ │ │ │ │ │AESDEC │ │SHA256RND│ │ │ │ ││ │ │ │ │ │ │AESKEYEXP│ │ │ │ │ │ ││ │ │ │ │ │ └─────────┘ └─────────┘ │ │ │ ││ │ │ │ │ │ • 10-100x faster than software │ │ │ ││ │ │ │ │ │ • Constant-time execution │ │ │ ││ │ │ │ │ └─────────────────────────────────────┘ │ │ ││ │ │ │ └─────────────────────────────────────────────┘ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Level 2: Dedicated Crypto Engine (SoC integrated) ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ ┌─────────────────────────────────────────────┐ │ ││ │ │ │ │ Crypto Accelerator Block │ │ ││ │ │ │ │ ┌───────────────────────────────────────┐ │ │ ││ │ │ │ │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ ││ │ │ │ │ │ │ AES │ │ SHA │ │ RSA │ │ ECC │ │ │ │ ││ │ │ │ │ │ │Engine│ │Engine│ │Engine│ │Engine│ │ │ │ ││ │ │ │ │ │ └─────┘ └─────┘ └─────┘ └─────┘ │ │ │ ││ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ │ ┌────────┴────────┐ │ │ │ ││ │ │ │ │ │ │ DMA Engine │ │ │ │ ││ │ │ │ │ │ │ (Zero-copy I/O) │ │ │ │ ││ │ │ │ │ │ └─────────────────┘ │ │ │ ││ │ │ │ │ └───────────────────────────────────────┘ │ │ ││ │ │ │ │ • Offloads CPU completely │ │ ││ │ │ │ │ • Parallel processing │ │ ││ │ │ │ │ • Used in: ARM TrustZone, Intel QAT │ │ ││ │ │ │ └─────────────────────────────────────────────┘ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Level 3: Hardware Security Module (HSM) ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ ┌─────────────────────────────────────────────┐ │ ││ │ │ │ │ HSM Appliance │ │ ││ │ │ │ │ ┌───────────────────────────────────────┐ │ │ ││ │ │ │ │ │ Tamper-Resistant Boundary │ │ │ ││ │ │ │ │ │ ┌─────────────────────────────────┐ │ │ │ ││ │ │ │ │ │ │ Secure Processor │ │ │ │ ││ │ │ │ │ │ │ • Key generation │ │ │ │ ││ │ │ │ │ │ │ • Key storage (never exported) │ │ │ │ ││ │ │ │ │ │ │ • Crypto operations │ │ │ │ ││ │ │ │ │ │ └─────────────────────────────────┘ │ │ │ ││ │ │ │ │ │ ┌─────────────────────────────────┐ │ │ │ ││ │ │ │ │ │ │ Battery-backed secure memory │ │ │ │ ││ │ │ │ │ │ │ (Keys zeroed on tamper) │ │ │ │ ││ │ │ │ │ │ └─────────────────────────────────┘ │ │ │ ││ │ │ │ │ └───────────────────────────────────────┘ │ │ ││ │ │ │ │ • FIPS 140-2/3 certified │ │ ││ │ │ │ │ • Physical tamper protection │ │ ││ │ │ │ │ • Examples: Thales Luna, AWS CloudHSM │ │ ││ │ │ │ └─────────────────────────────────────────────┘ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ AES-NI PERFORMANCE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ AES-256-GCM Encryption Throughput: ││ │ │ ││ │ │ ┌────────────────────┬──────────────────────────────────┐ ││ │ │ │ Implementation │ Throughput │ ││ │ │ ├────────────────────┼──────────────────────────────────┤ ││ │ │ │ Pure software │ 50 MB/s │ ││ │ │ │ AES-NI (single) │ 4,000 MB/s │ ││ │ │ │ AES-NI (parallel) │ 20,000+ MB/s │ ││ │ │ │ Dedicated engine │ 40,000+ MB/s │ ││ │ │ └────────────────────┴──────────────────────────────────┘ ││ │ │ ││ │ │ AES-NI Instructions: ││ │ │ • AESENC/AESDEC: Single round encrypt/decrypt ││ │ │ • AESENCLAST/AESDECLAST: Final round ││ │ │ • AESKEYGENASSIST: Key expansion ││ │ │ • PCLMULQDQ: Carry-less multiply (for GCM) ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ INTEL QAT (QuickAssist Technology): │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Intel QAT Accelerator │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────┐ ┌─────────────────┐ │ ││ │ │ │ │ Crypto Engines │ │ Compression │ │ ││ │ │ │ │ • AES-GCM │ │ • Deflate │ │ ││ │ │ │ │ • SHA-256/512 │ │ • LZ4 │ │ ││ │ │ │ │ • RSA/ECDSA │ │ • Zstd │ │ ││ │ │ │ │ • TLS offload │ │ │ │ ││ │ │ │ └─────────────────┘ └─────────────────┘ │ ││ │ │ │ │ ││ │ │ │ Performance: │ ││ │ │ │ • 100 Gbps symmetric crypto │ ││ │ │ │ • 100K RSA ops/sec │ ││ │ │ │ • 100 Gbps compression │ ││ │ │ │ │ ││ │ │ │ Use cases: │ ││ │ │ │ • TLS termination (nginx, HAProxy) │ ││ │ │ │ • IPsec VPN │ ││ │ │ │ • Storage encryption │ ││ │ │ │ • Database encryption │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ CRYPTO ACCELERATOR USE CASES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ 1. TLS Termination (HTTPS): ││ │ │ Client ──TLS──► Load Balancer ──HTTP──► Backend ││ │ │ (QAT offload) ││ │ │ • 10x more TLS connections per server ││ │ │ ││ │ │ 2. Full Disk Encryption: ││ │ │ Application ──► Crypto Engine ──► NVMe SSD ││ │ │ • Line-rate encryption with zero CPU ││ │ │ • Self-encrypting drives (SED) ││ │ │ ││ │ │ 3. Blockchain/Cryptocurrency: ││ │ │ • SHA-256 mining (Bitcoin) ││ │ │ • ECDSA signing (transactions) ││ │ │ • Dedicated ASIC miners ││ │ │ ││ │ │ 4. Secure Boot Chain: ││ │ │ ROM ──verify──► Bootloader ──verify──► Kernel ││ │ │ (RSA/ECDSA signature verification) ││ │ └─────────────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────────────┘
Network Processors
Network processors (NPUs—not to be confused with Neural Processing Units) are specialized chips for packet processing at line rate, featuring multiple parallel processing engines, hardware packet parsing, and high-speed I/O. They implement functions like routing, firewalling, QoS, and encryption in hardware. Modern SmartNICs combine network processors with FPGAs or ARM cores, offloading network functions from host CPUs—examples include NVIDIA BlueField DPU, Intel IPU, and Barefoot Tofino.
┌─────────────────────────────────────────────────────────────────┐ │ NETWORK PROCESSORS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ NETWORK PROCESSOR ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Network Processing Unit (NPU) │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Packet Processing Engines │ │ ││ │ │ │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ ││ │ │ │ │ │ PE0 │ │ PE1 │ │ PE2 │ │ PE3 │ │ ... │ │ │ ││ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ │RISC │ │RISC │ │RISC │ │RISC │ │ │ │ │ ││ │ │ │ │ │core │ │core │ │core │ │core │ │ │ │ │ ││ │ │ │ │ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │ │ ││ │ │ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ └───────┴───────┴───────┴───────┘ │ │ ││ │ │ │ │ (32-128 parallel engines) │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Hardware Accelerators │ │ ││ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ ││ │ │ │ │ │ Parser │ │ Lookup │ │ Traffic │ │ │ ││ │ │ │ │ │ Engine │ │ Engine │ │ Manager │ │ │ ││ │ │ │ │ │ │ │ (TCAM) │ │ (QoS) │ │ │ ││ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ ││ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ ││ │ │ │ │ │ Crypto │ │Checksum │ │ Buffer │ │ │ ││ │ │ │ │ │ Engine │ │ Engine │ │ Manager │ │ │ ││ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ High-Speed I/O │ │ ││ │ │ │ │ [100GbE][100GbE][100GbE][100GbE] 400Gbps+ │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ PACKET PROCESSING PIPELINE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Packet In ││ │ │ │ ││ │ │ ▼ ││ │ │ ┌───────────────┐ ││ │ │ │ Parser │ Extract headers (L2/L3/L4) ││ │ │ │ │ • Ethernet, VLAN, MPLS ││ │ │ │ │ • IPv4/IPv6 ││ │ │ │ │ • TCP/UDP ││ │ │ └───────┬───────┘ ││ │ │ │ ││ │ │ ▼ ││ │ │ ┌───────────────┐ ││ │ │ │ Lookup │ Table lookups (TCAM/Hash) ││ │ │ │ │ • Routing table (LPM) ││ │ │ │ │ • ACL matching ││ │ │ │ │ • Flow classification ││ │ │ └───────┬───────┘ ││ │ │ │ ││ │ │ ▼ ││ │ │ ┌───────────────┐ ││ │ │ │ Action │ Packet modification ││ │ │ │ │ • Header rewrite ││ │ │ │ │ • Encap/decap ││ │ │ │ │ • NAT ││ │ │ └───────┬───────┘ ││ │ │ │ ││ │ │ ▼ ││ │ │ ┌───────────────┐ ││ │ │ │ Scheduling │ QoS, traffic shaping ││ │ │ │ │ • Priority queuing ││ │ │ │ │ • Rate limiting ││ │ │ └───────┬───────┘ ││ │ │ │ ││ │ │ ▼ ││ │ │ Packet Out ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ SMARTNIC / DPU ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ NVIDIA BlueField-3 DPU │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ ARM Cores (16x Cortex-A78) │ │ ││ │ │ │ │ • Run Linux, containers │ │ ││ │ │ │ │ • Control plane processing │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Data Path Accelerators │ │ ││ │ │ │ │ • Programmable packet processor │ │ ││ │ │ │ │ • Crypto engines (IPsec, TLS) │ │ ││ │ │ │ │ • Regex engines (DPI) │ │ ││ │ │ │ │ • Compression engines │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ ConnectX-7 Network Adapter │ │ ││ │ │ │ │ • 400Gbps Ethernet │ │ ││ │ │ │ │ • RDMA (RoCE) │ │ ││ │ │ │ │ • SR-IOV, VXLAN offload │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ PCIe Gen5 x16 to Host │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ DPU/SMARTNIC USE CASES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ 1. Network Virtualization Offload: ││ │ │ • OVS (Open vSwitch) in hardware ││ │ │ • VXLAN/Geneve encap/decap ││ │ │ • Virtual switching at line rate ││ │ │ ││ │ │ 2. Storage Offload: ││ │ │ • NVMe-oF target ││ │ │ • Compression/encryption ││ │ │ • Storage virtualization ││ │ │ ││ │ │ 3. Security Functions: ││ │ │ • Firewall at NIC level ││ │ │ • DDoS mitigation ││ │ │ • Zero-trust microsegmentation ││ │ │ ││ │ │ 4. Bare Metal Cloud: ││ │ │ • Hypervisor-free isolation ││ │ │ • Network/storage services on DPU ││ │ │ • Full server resources to tenant ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ P4 PROGRAMMABLE SWITCHES (Barefoot Tofino): │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ P4 Language: Define custom packet processing ││ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ parser MyParser { │ ││ │ │ │ state start { │ ││ │ │ │ packet.extract(hdr.ethernet); │ ││ │ │ │ transition select(hdr.ethernet.etherType) { │ ││ │ │ │ 0x0800: parse_ipv4; │ ││ │ │ │ default: accept; │ ││ │ │ │ } │ ││ │ │ │ } │ ││ │ │ │ } │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ • Define any protocol (not just standard) ││ │ │ • Custom match-action tables ││ │ │ • In-network computing (aggregation, caching) ││ │ │ • 12.8 Tbps switching capacity ││ │ └─────────────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────────────┘
System Security Hardware
Trusted Platform Module (TPM)
A TPM is a dedicated security microcontroller providing hardware-based cryptographic functions including secure key generation/storage, platform integrity measurement (PCR registers), and attestation. TPM 2.0 (ISO/IEC 11889) stores encryption keys that never leave the chip, enables measured boot chains, and supports disk encryption (BitLocker). The TPM's endorsement key (EK) provides unique device identity, while platform configuration registers (PCRs) record boot measurements.
┌─────────────────────────────────────────────────────────────────┐ │ TRUSTED PLATFORM MODULE (TPM) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ TPM ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ TPM 2.0 Chip │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Cryptographic Engines │ │ ││ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ ││ │ │ │ │ │ RSA │ │ ECC │ │ AES │ │ │ ││ │ │ │ │ │ 2048+ │ │ P-256 │ │ 256 │ │ │ ││ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ ││ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ ││ │ │ │ │ │ SHA-256 │ │ SHA-384 │ │ HMAC │ │ │ ││ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Key Hierarchy │ │ ││ │ │ │ │ │ │ ││ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ ││ │ │ │ │ │ Endorsement Key (EK) │ │ │ ││ │ │ │ │ │ • Unique per TPM, set at manufacture │ │ │ ││ │ │ │ │ │ • Never leaves TPM │ │ │ ││ │ │ │ │ │ • Used for attestation │ │ │ ││ │ │ │ │ └────────────────┬────────────────────────┘ │ │ ││ │ │ │ │ │ │ │ ││ │ │ │ │ ┌────────────────┴────────────────────────┐ │ │ ││ │ │ │ │ │ Storage Root Key (SRK) │ │ │ ││ │ │ │ │ │ • Root of storage hierarchy │ │ │ ││ │ │ │ │ │ • Protects other keys │ │ │ ││ │ │ │ │ └────────────────┬────────────────────────┘ │ │ ││ │ │ │ │ │ │ │ ││ │ │ │ │ ┌────────────────┴────────────────────────┐ │ │ ││ │ │ │ │ │ User Keys (wrapped by SRK) │ │ │ ││ │ │ │ │ │ • Signing keys │ │ │ ││ │ │ │ │ │ • Encryption keys │ │ │ ││ │ │ │ │ │ • BitLocker VMK │ │ │ ││ │ │ │ │ └─────────────────────────────────────────┘ │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Platform Configuration Registers (PCRs) │ │ ││ │ │ │ │ ┌────┬────┬────┬────┬────┬────┬────┬────┐ │ │ ││ │ │ │ │ │PCR0│PCR1│PCR2│PCR3│PCR4│PCR5│... │PCR23 │ │ ││ │ │ │ │ │BIOS│BIOS│Opt │Opt │Boot│Boot│ │App │ │ │ ││ │ │ │ │ │Code│Data│ROM │ROM │Mgr │Mgr │ │ │ │ │ ││ │ │ │ │ └────┴────┴────┴────┴────┴────┴────┴────┘ │ │ ││ │ │ │ │ • Extended (hashed) during boot │ │ ││ │ │ │ │ • Cannot be directly written │ │ ││ │ │ │ │ • PCR[n] = Hash(PCR[n] || measurement) │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Non-Volatile Storage │ │ ││ │ │ │ │ • Persistent data (counters, flags) │ │ ││ │ │ │ │ • Sealed data blobs │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ MEASURED BOOT PROCESS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Power On ││ │ │ │ ││ │ │ ▼ ││ │ │ ┌───────────────┐ ││ │ │ │ UEFI/BIOS │──► Measure self ──► Extend PCR[0] ││ │ │ └───────┬───────┘ ││ │ │ │ ││ │ │ ▼ ││ │ │ ┌───────────────┐ ││ │ │ │ Option ROMs │──► Measure ──► Extend PCR[2] ││ │ │ └───────┬───────┘ ││ │ │ │ ││ │ │ ▼ ││ │ │ ┌───────────────┐ ││ │ │ │ Boot Loader │──► Measure ──► Extend PCR[4] ││ │ │ │ (GRUB/BCD) │ ││ │ │ └───────┬───────┘ ││ │ │ │ ││ │ │ ▼ ││ │ │ ┌───────────────┐ ││ │ │ │ Kernel │──► Measure ──► Extend PCR[8-9] ││ │ │ └───────┬───────┘ ││ │ │ │ ││ │ │ ▼ ││ │ │ ┌───────────────┐ ││ │ │ │ Applications │──► Measure ──► Extend PCR[10+] ││ │ │ └───────────────┘ ││ │ │ ││ │ │ Result: PCR values reflect entire boot chain ││ │ │ Any change → different PCR values ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ TPM OPERATIONS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ SEALING (Bind data to platform state): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Data ──► TPM2_Create(policy=PCR[0,7]) ──► Sealed │ ││ │ │ │ Blob │ ││ │ │ │ │ ││ │ │ │ Unsealing only works if PCRs match policy │ ││ │ │ │ (e.g., BitLocker key sealed to boot state) │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ ATTESTATION (Prove platform state): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Verifier ──► Challenge (nonce) │ ││ │ │ │ │ │ ││ │ │ │ ▼ │ ││ │ │ │ TPM ──► Quote(PCRs, nonce, AIK) ──► Signed Quote │ ││ │ │ │ │ │ ││ │ │ │ ▼ │ ││ │ │ │ Verifier checks: signature valid + PCRs expected │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ TPM FORM FACTORS: │ │ ┌────────────────────┬────────────────────────────────────┐ │ │ │ Discrete TPM │ Separate chip on motherboard │ │ │ │ Firmware TPM (fTPM)│ Runs in CPU secure enclave (AMD) │ │ │ │ Intel PTT │ TPM in Intel ME │ │ │ │ Virtual TPM (vTPM) │ Software TPM for VMs │ │ │ └────────────────────┴────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘
Hardware Security Modules (HSM)
HSMs are dedicated cryptographic appliances providing tamper-resistant key storage and high-performance crypto operations. Unlike TPMs (platform-bound), HSMs are network-accessible, FIPS 140-2/3 certified, and designed for enterprise key management. They feature physical tamper detection (zeroize keys on breach), multi-party authentication, and secure audit logging. Use cases include PKI root CAs, payment processing (PCI-DSS), database encryption keys, and code signing.
┌─────────────────────────────────────────────────────────────────┐ │ HARDWARE SECURITY MODULE (HSM) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ HSM ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ HSM Appliance (Thales Luna, etc.) │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Tamper-Resistant Boundary │ │ ││ │ │ │ │ ┌───────────────────────────────────────────┐ │ │ ││ │ │ │ │ │ Secure Crypto Processor │ │ │ ││ │ │ │ │ │ ┌─────────────────────────────────────┐ │ │ │ ││ │ │ │ │ │ │ Cryptographic Engines │ │ │ │ ││ │ │ │ │ │ │ • RSA (4096-bit) │ │ │ │ ││ │ │ │ │ │ │ • ECC (P-521, Ed25519) │ │ │ │ ││ │ │ │ │ │ │ • AES-256-GCM │ │ │ │ ││ │ │ │ │ │ │ • SHA-2, SHA-3 │ │ │ │ ││ │ │ │ │ │ │ • Post-quantum (emerging) │ │ │ │ ││ │ │ │ │ │ └─────────────────────────────────────┘ │ │ │ ││ │ │ │ │ │ ┌─────────────────────────────────────┐ │ │ │ ││ │ │ │ │ │ │ Key Storage (Battery-backed) │ │ │ │ ││ │ │ │ │ │ │ • Master keys never leave HSM │ │ │ │ ││ │ │ │ │ │ │ • Key wrapping hierarchy │ │ │ │ ││ │ │ │ │ │ │ • Secure key backup │ │ │ │ ││ │ │ │ │ │ └─────────────────────────────────────┘ │ │ │ ││ │ │ │ │ │ ┌─────────────────────────────────────┐ │ │ │ ││ │ │ │ │ │ │ True Random Number Generator │ │ │ │ ││ │ │ │ │ │ │ • Hardware entropy source │ │ │ │ ││ │ │ │ │ │ │ • NIST SP 800-90 compliant │ │ │ │ ││ │ │ │ │ │ └─────────────────────────────────────┘ │ │ │ ││ │ │ │ │ └───────────────────────────────────────────┘ │ │ ││ │ │ │ │ │ │ ││ │ │ │ │ Tamper Mechanisms: │ │ ││ │ │ │ │ • Tamper-evident seals │ │ ││ │ │ │ │ • Voltage/temperature sensors │ │ ││ │ │ │ │ • Mesh detection circuits │ │ ││ │ │ │ │ • Zeroization on tamper detection │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ External Interfaces │ │ ││ │ │ │ │ • Network (TLS-protected API) │ │ ││ │ │ │ │ • PKCS#11 / JCE / Microsoft CNG │ │ ││ │ │ │ │ • REST API │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ HSM vs TPM COMPARISON: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌──────────────────┬───────────────┬───────────────────┐ ││ │ │ │ Aspect │ TPM │ HSM │ ││ │ │ ├──────────────────┼───────────────┼───────────────────┤ ││ │ │ │ Purpose │ Platform │ Enterprise key │ ││ │ │ │ │ security │ management │ ││ │ │ │ Access │ Local only │ Network │ ││ │ │ │ Performance │ Low │ High (10K+ ops/s) │ ││ │ │ │ Key capacity │ Limited │ Millions of keys │ ││ │ │ │ Cost │ $5-20 │ $10K-100K+ │ ││ │ │ │ Certification │ CC EAL4+ │ FIPS 140-2/3 L3+ │ ││ │ │ │ Multi-tenant │ No │ Yes (partitions) │ ││ │ │ │ Clustering │ No │ Yes (HA) │ ││ │ │ └──────────────────┴───────────────┴───────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ HSM USE CASES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ 1. Certificate Authority (PKI): ││ │ │ ┌─────────┐ ┌─────────┐ ││ │ │ │ CA │──────│ HSM │ ││ │ │ │ Software│ │ (Root │ ││ │ │ │ │ │ Key) │ ││ │ │ └─────────┘ └─────────┘ ││ │ │ Root key never leaves HSM; signing done inside ││ │ │ ││ │ │ 2. Payment Processing (PCI-DSS): ││ │ │ Card Data ──► HSM ──► Encrypted PAN ││ │ │ PIN verification inside HSM ││ │ │ ││ │ │ 3. Database Encryption (TDE): ││ │ │ ┌──────────┐ ┌─────────┐ ││ │ │ │ Database │──────│ HSM │ ││ │ │ │ TDE │ │ (DEK │ ││ │ │ │ │ │ Master)│ ││ │ │ └──────────┘ └─────────┘ ││ │ │ ││ │ │ 4. Code Signing: ││ │ │ Developer ──► Sign request ──► HSM ──► Signed binary ││ │ │ Private key never exposed ││ │ │ ││ │ │ 5. Blockchain/Cryptocurrency: ││ │ │ Custodial wallets with HSM-protected keys ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ CLOUD HSM OPTIONS: │ │ ┌────────────────────┬────────────────────────────────────┐ │ │ │ AWS CloudHSM │ Dedicated HSM instances (Luna) │ │ │ │ Azure Dedicated HSM│ Thales Luna Network HSM │ │ │ │ GCP Cloud HSM │ Managed HSM service │ │ │ │ AWS KMS (HSM-backed)│ Shared HSM, per-key pricing │ │ │ └────────────────────┴────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘
Secure Enclaves (SGX, TrustZone)
Secure enclaves provide isolated execution environments where code and data are protected from the OS, hypervisor, and even physical attacks. Intel SGX creates encrypted memory regions (enclaves) with hardware-enforced access control; ARM TrustZone partitions the entire SoC into secure and normal worlds. These enable confidential computing—processing sensitive data while encrypted in memory, with remote attestation proving code integrity.
┌─────────────────────────────────────────────────────────────────┐ │ SECURE ENCLAVES │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ INTEL SGX (Software Guard Extensions): │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ System Memory │ ││ │ │ │ │ ││ │ │ │ ┌───────────────────────────────────────────────┐ │ ││ │ │ │ │ Normal Memory (Unprotected) │ │ ││ │ │ │ │ • OS, applications, data │ │ ││ │ │ │ │ • Accessible by OS, hypervisor, DMA │ │ ││ │ │ │ └───────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌───────────────────────────────────────────────┐ │ ││ │ │ │ │ Enclave Page Cache (EPC) - Encrypted │ │ ││ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ ││ │ │ │ │ │ Enclave 1 │ │ │ ││ │ │ │ │ │ ┌─────────────────────────────────┐ │ │ │ ││ │ │ │ │ │ │ Code (measured, signed) │ │ │ │ ││ │ │ │ │ │ │ Data (encrypted in memory) │ │ │ │ ││ │ │ │ │ │ │ Stack, Heap │ │ │ │ ││ │ │ │ │ │ └─────────────────────────────────┘ │ │ │ ││ │ │ │ │ │ • Hardware-encrypted (MEE) │ │ │ ││ │ │ │ │ │ • Integrity-protected │ │ │ ││ │ │ │ │ │ • Inaccessible to OS/VMM │ │ │ ││ │ │ │ │ └─────────────────────────────────────────┘ │ │ ││ │ │ │ │ │ │ ││ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ ││ │ │ │ │ │ Enclave 2 │ │ │ ││ │ │ │ │ │ ... │ │ │ ││ │ │ │ │ └─────────────────────────────────────────┘ │ │ ││ │ │ │ └───────────────────────────────────────────────┘ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ SGX Threat Model: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Protected FROM: │ NOT protected from: │ ││ │ │ │ • Malicious OS │ • Side-channel attacks │ ││ │ │ │ • Malicious hypervisor │ • Bugs in enclave code │ ││ │ │ │ • Other applications │ • Denial of service │ ││ │ │ │ • Physical memory read │ • (Some) speculative exec │ ││ │ │ │ • Cold boot attacks │ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ ARM TRUSTZONE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ ARM SoC │ ││ │ │ │ │ ││ │ │ │ ┌───────────────────┐ ┌───────────────────┐ │ ││ │ │ │ │ Normal World │ │ Secure World │ │ ││ │ │ │ │ (Non-Secure) │ │ (Secure) │ │ ││ │ │ │ │ │ │ │ │ ││ │ │ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │ ││ │ │ │ │ │ Rich OS │ │ │ │ Secure OS │ │ │ ││ │ │ │ │ │ (Linux, │ │ │ │ (OP-TEE, │ │ │ ││ │ │ │ │ │ Android) │ │ │ │ Trusty) │ │ │ ││ │ │ │ │ └─────────────┘ │ │ └─────────────┘ │ │ ││ │ │ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │ ││ │ │ │ │ │Applications │ │ │ │Trusted Apps │ │ │ ││ │ │ │ │ │ │ │ │ │(DRM, Keys, │ │ │ ││ │ │ │ │ │ │ │ │ │ Payments) │ │ │ ││ │ │ │ │ └─────────────┘ │ │ └─────────────┘ │ │ ││ │ │ │ │ │ │ │ │ ││ │ │ │ │ Normal Memory │ │ Secure Memory │ │ ││ │ │ │ │ Normal Periph │ │ Secure Periph │ │ ││ │ │ │ └────────┬──────────┘ └─────────┬─────────┘ │ ││ │ │ │ │ │ │ ││ │ │ │ │ ┌─────────────┐ │ │ ││ │ │ │ └────│ Monitor │────┘ │ ││ │ │ │ │ (EL3) │ │ ││ │ │ │ │ SMC Handler │ │ ││ │ │ │ └─────────────┘ │ ││ │ │ │ │ ││ │ │ │ NS (Non-Secure) bit propagates through entire SoC │ ││ │ │ │ Hardware enforces world separation │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ SGX vs TRUSTZONE COMPARISON: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌──────────────────┬───────────────┬───────────────────┐ ││ │ │ │ Aspect │ Intel SGX │ ARM TrustZone │ ││ │ │ ├──────────────────┼───────────────┼───────────────────┤ ││ │ │ │ Isolation unit │ Process-level │ World (system) │ ││ │ │ │ │ (enclave) │ │ ││ │ │ │ Memory encryption│ Yes (MEE) │ Optional (TZ-mem) │ ││ │ │ │ Multiple enclaves│ Yes │ Single secure │ ││ │ │ │ │ │ world │ ││ │ │ │ Attestation │ Remote │ Local/Platform │ ││ │ │ │ Platform │ x86 servers │ ARM mobile/embed │ ││ │ │ │ Typical use │ Cloud confid. │ Mobile security │ ││ │ │ │ │ computing │ (DRM, payments) │ ││ │ │ └──────────────────┴───────────────┴───────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ REMOTE ATTESTATION (SGX): │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌──────────┐ ┌──────────────┐ ││ │ │ │ Client │ │ Server │ ││ │ │ │ (Enclave)│ │ (Verifier) │ ││ │ │ └────┬─────┘ └──────┬───────┘ ││ │ │ │ │ ││ │ │ │ 1. Create enclave │ ││ │ │ │ (code measured into MRENCLAVE) │ ││ │ │ │ │ ││ │ │ │◄───────── 2. Challenge (nonce) ───────│ ││ │ │ │ │ ││ │ │ │ 3. Generate Quote: │ ││ │ │ │ REPORT = {MRENCLAVE, MRSIGNER, │ ││ │ │ │ user_data, nonce} │ ││ │ │ │ QUOTE = Sign(REPORT, Quoting Key) │ ││ │ │ │ │ ││ │ │ │──────────── 4. Quote ─────────────────► ││ │ │ │ │ ││ │ │ │ 5. Verify with Intel IAS ││ │ │ │ or DCAP ││ │ │ │ │ ││ │ │ │◄───────── 6. Trust established ───────│ ││ │ │ │ (send secrets) │ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ CONFIDENTIAL COMPUTING PLATFORMS: │ │ ┌────────────────────┬────────────────────────────────────┐ │ │ │ Intel SGX │ Process-level enclaves │ │ │ │ Intel TDX │ VM-level (Trust Domain Extensions) │ │ │ │ AMD SEV-SNP │ VM-level memory encryption │ │ │ │ ARM CCA │ Realms (Confidential Compute Arch) │ │ │ │ AWS Nitro Enclaves │ Isolated VM environment │ │ │ │ Azure Confidential │ SGX/SEV-SNP VMs │ │ │ └────────────────────┴────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘
Memory Encryption (TME, SME)
Total Memory Encryption (Intel TME) and Secure Memory Encryption (AMD SME) provide transparent, hardware-based encryption of all system memory using AES-128/256. The encryption key is generated at boot and stored in the CPU, protecting against physical memory attacks (cold boot, DMA). Multi-Key variants (MKTME, SEV) allow per-VM or per-process keys, enabling isolation in multi-tenant environments—foundational for confidential computing.
┌─────────────────────────────────────────────────────────────────┐ │ MEMORY ENCRYPTION │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ MEMORY ENCRYPTION ARCHITECTURE: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ CPU │ ││ │ │ │ ┌─────────────────────────────────────────────────┐│ ││ │ │ │ │ Core(s) ││ ││ │ │ │ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ ││ ││ │ │ │ │ │ Core 0 │ │ Core 1 │ │ ... │ ││ ││ │ │ │ │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ ││ ││ │ │ │ │ │ │ │ ││ ││ │ │ │ │ └──────────────┼──────────────┘ ││ ││ │ │ │ │ │ ││ ││ │ │ │ │ ▼ ││ ││ │ │ │ │ ┌─────────────────────────────────────────┐ ││ ││ │ │ │ │ │ Last Level Cache (LLC) │ ││ ││ │ │ │ │ │ (Plaintext) │ ││ ││ │ │ │ │ └─────────────────────┬───────────────────┘ ││ ││ │ │ │ │ │ ││ ││ │ │ │ │ ▼ ││ ││ │ │ │ │ ┌─────────────────────────────────────────┐ ││ ││ │ │ │ │ │ Memory Encryption Engine (MEE) │ ││ ││ │ │ │ │ │ ┌─────────────────────────────────┐ │ ││ ││ │ │ │ │ │ │ AES-XTS-256 Engine │ │ ││ ││ │ │ │ │ │ │ • Encrypt on write │ │ ││ ││ │ │ │ │ │ │ • Decrypt on read │ │ ││ ││ │ │ │ │ │ │ • Line-rate performance │ │ ││ ││ │ │ │ │ │ └─────────────────────────────────┘ │ ││ ││ │ │ │ │ │ ┌─────────────────────────────────┐ │ ││ ││ │ │ │ │ │ │ Key Storage │ │ ││ ││ │ │ │ │ │ │ • Generated at boot │ │ ││ ││ │ │ │ │ │ │ • Never leaves CPU │ │ ││ ││ │ │ │ │ │ │ • Ephemeral (lost on reboot) │ │ ││ ││ │ │ │ │ │ └─────────────────────────────────┘ │ ││ ││ │ │ │ │ └─────────────────────────────────────────┘ ││ ││ │ │ │ └─────────────────────────────────────────────────┘│ ││ │ │ │ │ │ ││ │ │ └────────────────────────┼─────────────────────────────┘ ││ │ │ │ (Encrypted) ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ DRAM (Ciphertext) │ ││ │ │ │ ┌─────────────────────────────────────────────────┐│ ││ │ │ │ │ ██████████████████████████████████████████████ ││ ││ │ │ │ │ All data encrypted with AES-256 ││ ││ │ │ │ │ Physical access reveals only ciphertext ││ ││ │ │ │ └─────────────────────────────────────────────────┘│ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ INTEL TME vs AMD SME: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌──────────────────┬───────────────┬───────────────────┐ ││ │ │ │ Feature │ Intel TME │ AMD SME │ ││ │ │ ├──────────────────┼───────────────┼───────────────────┤ ││ │ │ │ Encryption │ AES-XTS-128 │ AES-128 │ ││ │ │ │ Key management │ Single key │ Single key │ ││ │ │ │ Granularity │ All memory │ Per-page (C-bit) │ ││ │ │ │ Performance │ ~0% overhead │ ~0% overhead │ ││ │ │ │ Multi-key variant│ MKTME │ SME-MK / SEV │ ││ │ │ └──────────────────┴───────────────┴───────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ MULTI-KEY MEMORY ENCRYPTION: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ AMD SEV (Secure Encrypted Virtualization): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ │ │ VM 1 │ │ VM 2 │ │ VM 3 │ │ ││ │ │ │ │ Key A │ │ Key B │ │ Key C │ │ ││ │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ ││ │ │ │ │ │ │ │ ││ │ │ │ ▼ ▼ ▼ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐│ ││ │ │ │ │ Memory Encryption Engine ││ ││ │ │ │ │ • Per-VM encryption keys ││ ││ │ │ │ │ • Keys managed by AMD Secure Processor ││ ││ │ │ │ │ • Hypervisor cannot read VM memory ││ ││ │ │ │ └─────────────────────────────────────────────────┘│ ││ │ │ │ │ ││ │ │ │ SEV Variants: │ ││ │ │ │ • SEV: Basic VM memory encryption │ ││ │ │ │ • SEV-ES: + Encrypted register state │ ││ │ │ │ • SEV-SNP: + Integrity protection, attestation │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Intel MKTME (Multi-Key TME): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ • Up to 64 encryption keys │ ││ │ │ │ • Key ID encoded in physical address bits │ ││ │ │ │ • Per-VM or per-application isolation │ ││ │ │ │ • Combined with TDX for confidential VMs │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ THREATS MITIGATED: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Attack │ Mitigated │ Notes │ ││ │ │ ├─────────────────────┼───────────┼────────────────────┤ ││ │ │ │ Cold boot attack │ ✓ │ Keys lost on reset │ ││ │ │ │ DMA attack │ ✓ │ DRAM encrypted │ ││ │ │ │ Physical probing │ ✓ │ Only ciphertext │ ││ │ │ │ Memory bus snoop │ ✓ │ Encrypted traffic │ ││ │ │ │ DIMM removal │ ✓ │ Data useless │ ││ │ │ │ Malicious hypervisor│ Partial │ Need SEV-SNP/TDX │ ││ │ │ │ Software attacks │ ✗ │ Different threat │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ └─────────────────────────────────────────────────────────────────┘
Hardware Root of Trust
A hardware root of trust establishes an immutable foundation for system security, starting from silicon that cannot be modified by software. It typically includes ROM-based boot code, hardware-protected keys, and secure boot verification. Examples include Intel Boot Guard (verifies BIOS), ARM TrustZone with secure boot ROM, and Google Titan chip. The chain of trust extends from this root through each boot stage, ensuring only authorized code executes.
┌─────────────────────────────────────────────────────────────────┐ │ HARDWARE ROOT OF TRUST │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ROOT OF TRUST CHAIN: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Hardware Root of Trust │ ││ │ │ │ ┌───────────────────────────────────────────────┐ │ ││ │ │ │ │ Immutable Boot ROM │ │ ││ │ │ │ │ • Fused at manufacture │ │ ││ │ │ │ │ • Cannot be modified │ │ ││ │ │ │ │ • Contains first boot code │ │ ││ │ │ │ │ • Contains root public key hash │ │ ││ │ │ │ └───────────────────┬───────────────────────────┘ │ ││ │ │ │ │ Verifies │ ││ │ │ │ ▼ │ ││ │ │ │ ┌───────────────────────────────────────────────┐ │ ││ │ │ │ │ Hardware Security Keys │ │ ││ │ │ │ │ • OTP (One-Time Programmable) fuses │ │ ││ │ │ │ │ • Unique device ID │ │ ││ │ │ │ │ • Root key (burned at manufacture) │ │ ││ │ │ │ │ • Anti-rollback counters │ │ ││ │ │ │ └───────────────────────────────────────────────┘ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ │ ││ │ │ │ Verifies ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ First Stage Bootloader │ ││ │ │ │ • Signature verified by ROM │ ││ │ │ │ • Initializes hardware │ ││ │ │ │ • Loads next stage │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ │ Verifies ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Second Stage / UEFI │ ││ │ │ │ • Signature verified by previous stage │ ││ │ │ │ • Platform initialization │ ││ │ │ │ • Secure Boot database │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ │ Verifies ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Boot Loader (GRUB, etc.) │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ │ Verifies ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Operating System Kernel │ ││ │ │ └────────────────────────┬────────────────────────────┘ ││ │ │ │ Verifies (optional) ││ │ │ ▼ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Applications / Drivers │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Each stage verifies the next before execution ││ │ │ Chain breaks → Boot halted ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ INTEL BOOT GUARD: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Intel CPU │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Authenticated Code Module (ACM) │ │ ││ │ │ │ │ • Signed by Intel │ │ ││ │ │ │ │ • Runs in special CPU mode │ │ ││ │ │ │ │ • Verifies Initial Boot Block (IBB) │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Boot Guard Profiles: │ │ ││ │ │ │ │ • Measured Boot: Measure IBB into TPM │ │ ││ │ │ │ │ • Verified Boot: Verify IBB signature │ │ ││ │ │ │ │ • Both: Measure + Verify │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ OEM Key Hash (Fused) │ │ ││ │ │ │ │ • Hash of OEM's public key │ │ ││ │ │ │ │ • Burned into CPU fuses │ │ ││ │ │ │ │ • Cannot be changed │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ GOOGLE TITAN CHIP: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Google Cloud Server │ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐ │ ││ │ │ │ │ Titan Security Chip │ │ ││ │ │ │ │ │ │ ││ │ │ │ │ ┌───────────────────────────────────────────┐ │ │ ││ │ │ │ │ │ Secure Microcontroller │ │ │ ││ │ │ │ │ │ • Custom Google silicon │ │ │ ││ │ │ │ │ │ • Hardened against physical attacks │ │ │ ││ │ │ │ │ └───────────────────────────────────────────┘ │ │ ││ │ │ │ │ │ │ ││ │ │ │ │ Functions: │ │ ││ │ │ │ │ • First instruction verification │ │ ││ │ │ │ │ • Boot firmware integrity │ │ ││ │ │ │ │ • Hardware identity attestation │ │ ││ │ │ │ │ • Cryptographic operations │ │ ││ │ │ │ │ │ │ ││ │ │ │ │ Monitors: │ │ ││ │ │ │ │ • SPI flash (BIOS) │ │ ││ │ │ │ │ • BMC firmware │ │ ││ │ │ │ │ • Boot process │ │ ││ │ │ │ └─────────────────────────────────────────────────┘ │ ││ │ │ └───────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ ROOT OF TRUST IMPLEMENTATIONS: │ │ ┌────────────────────┬────────────────────────────────────┐ │ │ │ Intel Boot Guard │ CPU-based, verifies BIOS │ │ │ │ AMD PSP │ Secure processor in CPU │ │ │ │ ARM TrustZone │ Secure world boot ROM │ │ │ │ Google Titan │ Separate security chip │ │ │ │ Apple Secure Enclave│ Separate processor in SoC │ │ │ │ Microsoft Pluton │ Security processor in CPU │ │ │ └────────────────────┴────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘
PUF (Physically Unclonable Functions)
PUFs exploit inherent manufacturing variations in silicon to create unique, unclonable device fingerprints. These random variations (transistor threshold voltages, wire delays) produce device-specific challenge-response pairs that cannot be duplicated even by the manufacturer. PUFs enable secure key generation without storage (keys derived on-demand), device authentication, and anti-counterfeiting—immune to physical probing since the "key" exists only as physical properties.
┌─────────────────────────────────────────────────────────────────┐ │ PHYSICALLY UNCLONABLE FUNCTIONS (PUF) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ PUF CONCEPT: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Manufacturing Variation → Unique Device "Fingerprint" ││ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Two "Identical" Chips │ ││ │ │ │ │ ││ │ │ │ Chip A: Chip B: │ ││ │ │ │ ┌─────────────────┐ ┌─────────────────┐ │ ││ │ │ │ │ Transistor Vth: │ │ Transistor Vth: │ │ ││ │ │ │ │ T1: 0.401V │ │ T1: 0.398V │ │ ││ │ │ │ │ T2: 0.399V │ │ T2: 0.402V │ │ ││ │ │ │ │ T3: 0.403V │ │ T3: 0.397V │ │ ││ │ │ │ │ ... │ │ ... │ │ ││ │ │ │ └─────────────────┘ └─────────────────┘ │ ││ │ │ │ │ ││ │ │ │ Same design, different physical properties │ ││ │ │ │ → Different responses to same challenge │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ PUF TYPES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ARBITER PUF: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ Challenge bits select path through multiplexers │ ││ │ │ │ │ ││ │ │ │ Input ──┬──[MUX]──[MUX]──[MUX]──[MUX]──┬── Arbiter │ ││ │ │ │ Pulse │ │ │ │ │ │ │ │ ││ │ │ │ └────┴──────┴──────┴──────┴────┘ │ │ ││ │ │ │ Challenge bits ▼ │ ││ │ │ │ Response │ ││ │ │ │ (0 or 1) │ ││ │ │ │ │ ││ │ │ │ Which path is faster? Depends on wire delays │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ RING OSCILLATOR PUF: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ ┌─────────────────────────────────────────────────┐│ ││ │ │ │ │ RO 1: ──[INV]─[INV]─[INV]─┐ ││ ││ │ │ │ │ └──────────────────┘ freq = f1 ││ ││ │ │ │ │ ││ ││ │ │ │ │ RO 2: ──[INV]─[INV]─[INV]─┐ ││ ││ │ │ │ │ └──────────────────┘ freq = f2 ││ ││ │ │ │ │ ││ ││ │ │ │ │ Compare: f1 > f2 ? → 1 : 0 ││ ││ │ │ │ └─────────────────────────────────────────────────┘│ ││ │ │ │ │ ││ │ │ │ Oscillation frequency varies per chip │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ SRAM PUF: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ SRAM cells power-up state (before initialization): │ ││ │ │ │ │ ││ │ │ │ ┌───┬───┬───┬───┬───┬───┬───┬───┐ │ ││ │ │ │ │ 1 │ 0 │ 1 │ 1 │ 0 │ 1 │ 0 │ 0 │ ← Chip A │ ││ │ │ │ └───┴───┴───┴───┴───┴───┴───┴───┘ │ ││ │ │ │ ┌───┬───┬───┬───┬───┬───┬───┬───┐ │ ││ │ │ │ │ 0 │ 1 │ 1 │ 0 │ 1 │ 0 │ 1 │ 1 │ ← Chip B │ ││ │ │ │ └───┴───┴───┴───┴───┴───┴───┴───┘ │ ││ │ │ │ │ ││ │ │ │ Each cell prefers 0 or 1 based on transistor mismatch│ ││ │ │ │ Simple: use existing SRAM, read before init │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ PUF-BASED KEY GENERATION: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Enrollment (one-time, at manufacture): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ PUF Response ──► Fuzzy Extractor ──► Key + Helper │ ││ │ │ │ (noisy) (error correction) Data │ ││ │ │ │ │ │ ││ │ │ │ ▼ │ ││ │ │ │ Store Helper Data │ ││ │ │ │ (public, no secret)│ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Reconstruction (at runtime): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ PUF Response ──┬──► Fuzzy Extractor ──► Same Key │ ││ │ │ │ (slightly │ (uses helper data) │ ││ │ │ │ different) │ │ ││ │ │ │ │ │ ││ │ │ │ Helper Data ───┘ │ ││ │ │ │ │ ││ │ │ │ Key is NEVER stored - derived from physics! │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ PUF APPLICATIONS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ 1. Secure Key Storage (without storing keys): ││ │ │ • Root encryption keys ││ │ │ • Device authentication keys ││ │ │ • Keys immune to memory readout attacks ││ │ │ ││ │ │ 2. Device Authentication: ││ │ │ Server ──► Challenge ──► Device ││ │ │ Server ◄── Response ◄── PUF ││ │ │ (Compare with enrolled response) ││ │ │ ││ │ │ 3. Anti-Counterfeiting: ││ │ │ • Genuine chips have unique PUF signatures ││ │ │ • Cannot be cloned (even by manufacturer) ││ │ │ ││ │ │ 4. Secure Boot: ││ │ │ • Derive boot decryption key from PUF ││ │ │ • Firmware encrypted, key never stored ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ PUF PROPERTIES: │ │ ┌────────────────────┬────────────────────────────────────┐ │ │ │ Uniqueness │ Different chips → different responses│ │ │ │ Reproducibility │ Same chip → same response (mostly) │ │ │ │ Unclonability │ Cannot duplicate physical properties│ │ │ │ Unpredictability │ Cannot predict response from design │ │ │ │ Tamper evidence │ Physical attack changes response │ │ │ └────────────────────┴────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘
Side-Channel Attack Mitigations
Side-channel attacks extract secrets by observing physical characteristics (power consumption, timing, electromagnetic emissions) rather than exploiting software vulnerabilities. Hardware mitigations include constant-time execution (preventing timing attacks), power analysis countermeasures (random delays, noise injection), and cache partitioning (preventing Spectre/Meltdown). Modern CPUs implement speculative execution barriers, cache isolation, and branch prediction hardening to defend against these attacks.
┌─────────────────────────────────────────────────────────────────┐ │ SIDE-CHANNEL ATTACK MITIGATIONS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ SIDE-CHANNEL ATTACK TYPES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Cryptographic Operation │ ││ │ │ │ │ │ ││ │ │ │ ┌───────────────────┬┴┬───────────────────┐ │ ││ │ │ │ │ │ │ │ │ ││ │ │ │ ▼ ▼ ▼ ▼ │ ││ │ │ │ ┌──────┐ ┌──────┐ ┌──────┐ │ ││ │ │ │ │Timing│ │Power │ │ EM │ │ ││ │ │ │ │ │ │ │ │ │ │ ││ │ │ │ │ How │ │ How │ │Radio │ │ ││ │ │ │ │ long?│ │ much?│ │waves │ │ ││ │ │ │ └──────┘ └──────┘ └──────┘ │ ││ │ │ │ │ ││ │ │ │ ┌──────┐ ┌──────┐ ┌──────┐ │ ││ │ │ │ │Cache │ │Branch│ │Specul│ │ ││ │ │ │ │ │ │Pred │ │ative │ │ ││ │ │ │ │Hit or│ │Taken?│ │Exec │ │ ││ │ │ │ │miss? │ │ │ │ │ │ ││ │ │ │ └──────┘ └──────┘ └──────┘ │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ TIMING ATTACK MITIGATION: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Vulnerable (timing leak): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ if (password[i] != input[i]) { │ ││ │ │ │ return false; // Early exit reveals position │ ││ │ │ │ } │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Constant-time (secure): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ int result = 0; │ ││ │ │ │ for (int i = 0; i < len; i++) { │ ││ │ │ │ result |= password[i] ^ input[i]; │ ││ │ │ │ } │ ││ │ │ │ return result == 0; // Always same time │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Hardware support: ││ │ │ • Constant-time instructions (AES-NI) ││ │ │ • No data-dependent timing ││ │ │ • Fixed-latency memory access ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ POWER ANALYSIS COUNTERMEASURES: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Simple Power Analysis (SPA): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ Power │ ││ │ │ │ │ ╱╲ ╱╲ │ ││ │ │ │ │ ╱ ╲ ╱ ╲ ← Different operations │ ││ │ │ │ │ ╱ ╲ ╱ ╲ have different power │ ││ │ │ │ │ ╱ ╲╱ ╲ │ ││ │ │ │ └─────────────────────► Time │ ││ │ │ │ Key bit = 1 Key bit = 0 │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Mitigations: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ 1. Masking (randomize intermediate values): │ ││ │ │ │ x' = x ⊕ r (process masked value) │ ││ │ │ │ Power depends on x', not x │ ││ │ │ │ │ ││ │ │ │ 2. Hiding (randomize power consumption): │ ││ │ │ │ • Random delays │ ││ │ │ │ • Dummy operations │ ││ │ │ │ • Noise generators │ ││ │ │ │ │ ││ │ │ │ 3. Balanced logic: │ ││ │ │ │ • Dual-rail encoding (0→01, 1→10) │ ││ │ │ │ • Equal power for 0 and 1 │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ SPECULATIVE EXECUTION MITIGATIONS: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Spectre/Meltdown Attack Pattern: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ 1. Speculatively access secret data │ ││ │ │ │ 2. Use secret to affect cache state │ ││ │ │ │ 3. Speculation rolled back, but cache changed! │ ││ │ │ │ 4. Measure cache timing to extract secret │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Hardware Mitigations: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ │ ││ │ │ │ IBRS (Indirect Branch Restricted Speculation): │ ││ │ │ │ • Prevents branch target injection │ ││ │ │ │ • Isolates branch predictor between privilege levels│ ││ │ │ │ │ ││ │ │ │ STIBP (Single Thread Indirect Branch Predictors): │ ││ │ │ │ • Prevents cross-thread branch prediction attacks │ ││ │ │ │ • Isolates predictors between SMT threads │ ││ │ │ │ │ ││ │ │ │ SSBD (Speculative Store Bypass Disable): │ ││ │ │ │ • Prevents speculative load bypassing store │ ││ │ │ │ │ ││ │ │ │ L1TF Mitigations: │ ││ │ │ │ • L1 cache flush on VM exit │ ││ │ │ │ • Page table inversion │ ││ │ │ │ │ ││ │ │ │ VERW (MDS Mitigation): │ ││ │ │ │ • Clear CPU buffers on context switch │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ Software Barriers: ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ LFENCE: Serializes load operations │ ││ │ │ │ Retpoline: Replace indirect jumps with return-based │ ││ │ │ │ sequences that can't be predicted │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ CACHE PARTITIONING: │ │ ┌─────────────────────────────────────────────────────────────┐│ │ │ ││ │ │ Without partitioning (vulnerable): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ ┌─────────────────────────────────────────────────┐│ ││ │ │ │ │ Shared L3 Cache ││ ││ │ │ │ │ Process A data │ Process B data │ Victim data ││ ││ │ │ │ │ (attacker can evict victim's cache lines) ││ ││ │ │ │ └─────────────────────────────────────────────────┘│ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ │ ││ │ │ With Intel CAT (Cache Allocation Technology): ││ │ │ ┌─────────────────────────────────────────────────────┐ ││ │ │ │ ┌─────────────────────────────────────────────────┐│ ││ │ │ │ │ L3 Cache (Partitioned) ││ ││ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────┐ ││ ││ │ │ │ │ │ Partition 0 │ │ Partition 1 │ │ Part. 2 │ ││ ││ │ │ │ │ │ (VM 1) │ │ (VM 2) │ │ (VM 3) │ ││ ││ │ │ │ │ │ Isolated! │ │ Isolated! │ │ Isolated!│ ││ ││ │ │ │ │ └──────────────┘ └──────────────┘ └──────────┘ ││ ││ │ │ │ └─────────────────────────────────────────────────┘│ ││ │ │ │ │ ││ │ │ │ No cross-partition cache interference │ ││ │ │ └─────────────────────────────────────────────────────┘ ││ │ └─────────────────────────────────────────────────────────────┘│ │ │ │ MITIGATION SUMMARY: │ │ ┌────────────────────┬────────────────────────────────────┐ │ │ │ Attack Type │ Hardware Mitigation │ │ │ ├────────────────────┼────────────────────────────────────┤ │ │ │ Timing │ Constant-time instructions │ │ │ │ Power analysis │ Masking, balanced logic │ │ │ │ EM emanations │ Shielding, noise injection │ │ │ │ Cache timing │ CAT partitioning, flush on switch │ │ │ │ Spectre │ IBRS, STIBP, retpoline │ │ │ │ Meltdown │ KPTI (kernel page table isolation) │ │ │ │ MDS │ VERW, buffer clearing │ │ │ │ Rowhammer │ TRR, ECC, increased refresh │ │ │ └────────────────────┴────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘