Formalize platform abstraction: Memory Space + Execution Space model (RAJA/Kokkos pattern)

[avrabe]

Context

LLNL RAJA achieved 20x reduction in new-platform onboarding by investing in a formal platform abstraction. Sandia Kokkos models both execution space (where code runs) and memory space (where data lives) as first-class concepts. NASA cFS uses a similar PSP → OSAL → cFE layering.

Problem

Synth currently has linker scripts per target (STM32, nRF52840, generic) and synth-memory provides a portable memory abstraction for Zephyr/Linux/bare-metal. But there's no formal model of memory spaces (Flash vs SRAM vs TCM vs external RAM) or execution spaces (Cortex-M0/M4/M33/M55 capabilities).

Proposal

Formalize synth-memory into three explicit layers:

1. Memory Space Model

MemorySpace { kind: Flash | SRAM | TCM | ExternalRAM, base: u32, size: u32, latency: Cycles, writeable: bool }

• Flash: read-only at runtime, slow reads (wait states), large
• SRAM: read-write, fast, limited
• TCM (Tightly Coupled Memory): fastest, very limited, no wait states
• External RAM: large, slow, optional

2. Execution Space Model

ExecutionSpace { core: CortexM0 | CortexM4 | CortexM33 | CortexM55, fpu: None | FPv4 | FPv5, simd: None | HeliumMVE, mpu: bool }

3. Platform Package

Platform { name: "STM32H7", execution: ExecutionSpace, memories: Vec<MemorySpace>, peripherals: [...], vector_table_base: u32 }

Benefits

• Every new ARM target becomes a TOML/YAML config file rather than new Rust code
• The compiler can make memory placement decisions (hot functions → TCM, cold data → external RAM)
• Links to AADL modeling in Spar (deployment solver can reason about memory budgets)
• RAJA's 20x metric suggests this investment compounds heavily per new target

References

• LLNL RAJA: https://github.com/LLNL/RAJA
• Sandia Kokkos memory spaces: https://github.com/kokkos/kokkos
• NASA cFS PSP: https://github.com/nasa/PSP (13 modular sub-APIs for hardware abstraction)

Priority

High — compounds with every new target platform.