The Core Problem We All Face:
We're constantly hitting the RAM wall in modern microcontrollers. On-chip SRAM is fast but extremely expensive in terms of die area, severely limiting its size. External PSRAM (HyperRAM, Octal-SPI) is cheap and offers megabytes, but it consumes precious microcontroller pins (16+ lines for FMC or 8+ for Octal-SPI), which are desperately needed for peripheral connectivity.
The Core Idea:
What if we packaged the microcontroller die and the PSRAM die into a single physical package? Connect them directly using internal interconnects ("gold wires" / wire bonding or copper pillars via an interposer), utilizing the same high-speed memory interfaces (FMC, HyperBus, Octal-SPI), but entirely inside the package.
What This Enables:
Gigabits of cheap RAM "inside" the MCU. We get memory at PSRAM cost, not SRAM cost.
All GPIOs remain free. Externally, the chip has the same 64 or 100 pins, but now it features tens of megabytes of RAM "under the hood." The FMC/flexible memory controller pins become internal lines.
Only if you can interface the PSRAM without using GPIO. Which I very much doubt is possible without redesigning the MCU.
Higher speed, lower noise. Internal interconnects are shorter with lower parasitic capacitance and inductance. This allows pushing the PSRAM interface (like HyperRAM) to its stable limits at higher frequencies.
Smaller PCB footprint. One IC instead of two, plus savings on decoupling and routing.
A new device class. MCUs with "embedded" 32-64 MB of RAM would become the ideal platform for GUI (LVGL), audio/image buffering, network stacks, and running compact ML models at the edge.
This is the established System-in-Package (SiP) or Multi-Chip Module (MCM) technology. It's already proven and in mass production:
Mobile Application Processors almost always co-package LPDDR memory with the CPU die for performance and size.
The packaging technology (wire bonding, flip-chip) is mature, reliable, and cost-effective at scale.
Why not adopt this successful approach for more powerful MCU lines (like STM32H Raspberry MCU)? Instead of designing a new core or expanding expensive on-die SRAM, give developers a "budget" option with huge amounts of logically-internal, physically-co-packaged RAM.
If it's "mature, reliable, and cost-effective at scale." you should be able to prototype it or raise the development funds yourself. [scarsacm] It's just fliping over the MCU, connecting a few wires, and coating it in expoy, right? [/sarcasm]
The Ultimate Goal: Seamless Integration & Developer Experience
While the physical co-packaging solves the hardware problem, the true value lies in making this massive RAM pool as easy to use as the internal SRAM.
The Software Vision: "It Just Works"
The core idea is to eliminate the traditional complexity of external memory controllers. In a standard design, using PSRAM requires:
Low-Level Driver Tuning: Initializing the memory controller with precise timing parameters, often requiring deep knowledge of the memory chip's datasheet.
Memory Region Management: Manually linking or allocating specific data to the external RAM.
[/quote]
Won't your proposed SiP and supporting software have to do all that anyway?
In our proposed SiP MCU, this complexity disappears:
Pre-Tuned & Validated: The MCU manufacturer pre-configures and hardens the internal memory interface (HyperBus/Octal-SPI/FMC) during production. The timing is guaranteed to work because the physical connection is fixed and known.
Unified Memory Space: The PSRAM would be mapped into the MCU's address space, appearing as a contiguous, directly accessible block of memory—just like a larger, slightly higher-latency SRAM bank.
Simplified Activation: From the developer's perspective, using this RAM might be as simple as enabling its clock and power domain in the MCU's RCC (Reset and Clock Controller), similar to enabling any other internal peripheral. No complex driver setup should be needed.
Practical Implication for Developers:
You could define a large array in your code, and the linker script, provided by the manufacturer, would automatically place it in the vast internal PSRAM region. Advanced users could still fine-tune performance, but the default "out-of-the-box" experience would provide gigabytes of usable memory with minimal setup, finally making high-level applications like rich GUIs, audio processing, and ML models trivial to implement on microcontrollers.
Security and Reliability: Protection Against Internal Threats
Beyond the obvious advantages, the "MCU + PSRAM in SiP" architecture fundamentally improves internal security, which has received so little attention. We combat external attacks but overlook the dangers of hardware and software errors. This approach:
1. Physical Integrity and Protection from External Interference:
Eliminating the Vulnerable Bus: An external memory bus on a PCB is an exposed "channel" susceptible to electromagnetic interference (EMI), faults from poor soldering, corrosion, and even potential malicious probing (side-channel attacks). In an SiP, the high-speed lines between the core and memory are encapsulated within the package. This makes them physically inaccessible and shielded from the external environment, drastically reducing the likelihood of both random data corruption and targeted attacks.
2. Enhanced Power-Fault Resilience:
Guaranteed Power Integrity: External PSRAM requires its own power rails and decoupling. The slightest dip or noise on its power line can lead to data corruption or system crashes. In an SiP solution, the manufacturer can optimize a unified power delivery system for both dies, ensuring their coherent and predictable operation even under unstable external power conditions—critical for industrial and automotive applications.
3. Guaranteed Timing and Predictability:
Eliminating the "Gray Area" of Configuration: The most common cause of unstable external memory operation is errors in calculating and configuring the timing parameters (latencies) in the driver. In an SiP, the manufacturer hard-fixes the trace lengths and interface parameters at the package design stage. This allows them to provide a single, pre-verified, and guaranteed working driver configuration. For the developer, this means the memory "just works" without months of debugging instability caused by PCB variations or imprecise calculations.
4. Protection Against Software Errors and Simplified Debugging:
Deterministic Behavior: Since the physical communication channel is known and stable, memory behavior becomes deterministic. This radically simplifies debugging complex multithreaded or real-time (RTOS) applications, where memory-related race conditions or crashes often cannot be reproduced across different board instances due to trace variations.
Simplified Usage Models: Presenting the memory as a single, contiguous, and fast address space eliminates an entire class of software bugs related to incorrect management of multiple memory banks, faulty external controller initialization, or improper data allocation between internal and external RAM.
Security Bottom Line:
The proposed SiP approach implements the principle of "security through isolation and simplification." It encapsulates a critical and vulnerable data pathway, eliminates entire categories of potential hardware and software errors that occur at component interfaces, and provides the developer with a predictable, verified, and reliable foundation. This creates a system that is not only more powerful but also significantly more resilient to faults—forming the bedrock for building truly secure and fail-safe embedded solutions for medical, industrial automation, transportation, and IoT applications.
More pie in the sky.
Statistics: Posted by thagrol — Mon Jan 26, 2026 6:42 pm