The general-purpose CPU and the system-on-chip that surrounds it remain the default compute substrate, and the live research frontier has shifted from raw core performance to on-die specialisation, energy per instruction fetch, and architectural security guarantees.
Summary
The parameters that decide a modern CPU/SoC design are no longer mainly clock rate and IPC. They are: energy per useful operation (instruction fetch from SRAM alone accounts for over 40% of energy in an embedded RISC-V baseline); which workloads should leave the core entirely (MCMC sampling executes inefficiently on conventional CPU/GPU platforms, and post-quantum signature schemes are effectively unusable in software on a Cortex-M4, with SPHINCS+ impractical and the reference Dilithium implementation failing to run at all); and what security properties the architecture can guarantee rather than bolt on in software.
The security thread is the most active in this source set. Conventional processors expose code and data as plaintext throughout execution; memory safety errors remain the dominant source of severe vulnerabilities in C and C++; and micro-architectural artefacts leak secrets through power and timing channels. The response is architectural: capability hardware with inline object IDs for temporal memory safety, instruction-level authenticated encryption in the fetch path, and ISA-level leakage contracts proved against RTL.
Underneath sits a design-and-verification economy that is itself changing. Symbolic execution over RTL Verilog found assertion violations in five open-source designs including an SoC and a CPU; lexical static analysis on RTL issues a correct security warning up to 60.8% of the time against 17.5% for prior work; and LLM-based surrogate models now estimate module-level CPU power directly from source-level design information without simulation at inference time, demonstrated on the open-source XiangShan processor family.
Evidence base
- 2026-06-16: AIA, a 16-core custom RISC-V SoC with a RISC-V host processor, fabricated on Intel 16 nm because MCMC sampling executes inefficiently on conventional CPU/GPU platforms.
- 2026-07-08: cross-layer measurement across five frameworks and three backends finds NPUs best for compute-bound prefill and CPUs best of all backends for memory-bound decode, with framework-induced gaps up to 10x on NPUs.
- 2026-07-28: instruction fetch from SRAM is over 40% of energy in a baseline embedded RISC-V core; loop caches cut fetches 48.3% or 83.3% and total energy 21.5% or 35.5% on GlobalFoundries 22 nm FDX+ at 0.5 V, 250 MHz.
- 2026-07-22: PTSan reports 57.2% geomean overhead on SPEC CPU 2017 on x86-64, falling to 46.4% with Intel Linear Address Masking, illustrating the cost of software-only memory safety.
- 2026-06-16: SPHINCS+ is practically unusable and the reference Dilithium implementation fails to run on an STM32F407G Cortex-M4; an FPGA NTT accelerator on a Zynq-7000 ZedBoard brings key and signature generation to millisecond level.
- 2026-07-22: piecewise-composition symbolic execution over RTL Verilog reduces paths explored by an order of magnitude and runtime by 97%, finding assertion violations in five open-source designs including an SoC and a CPU.
Open questions
- Does architectural temporal memory safety of the CHERI-D type reduce total overhead enough, relative to the software Cornucopia Reloaded baseline and to sanitizers at 46-57% on SPEC CPU 2017, to be enabled by default in a shipping core?
- Do the Granite non-leakage proofs extend from a pipelined RISC design with speculation to a wide out-of-order commercial core, or does proof effort scale faster than design complexity?
- How accurate are LLM-based source-level power surrogates outside the processor family they were fitted on, given that BigPower’s evidence is confined to XiangShan configurations?
- Will NPU software stacks close the up-to-10x framework-induced performance gap and take over the decode phase, or will heterogeneous CPU-plus-NPU scheduling remain the design point?
Assessment drafted 2026-08-31 from up to 18 KB sources using the technology-scorecard framework; scores are a draft read pending review.