DynamicMem: Efficient MPSoC Memory Simulation

• DynamicMem is a dynamic memory simulation technique that integrates cycle-true communication with host-managed storage to efficiently support large, evolving data sets.
• It employs a dual-layer wrapper combining a cycle-true FSM and a pointer table to decouple simulated address spaces from host memory operations.
• The method maintains realistic timing behavior in MPSoC co-simulation while delegating complex memory management tasks to the host OS to optimize performance.

DynamicMem is a technique for integrating dynamic memory into a multiprocessor System-on-Chip co-simulation framework built in C/C++/SystemC. It was proposed to make dynamic memory behave like a realistic MPSoC memory subsystem without incurring the cost of explicitly simulating every low-level memory-management detail. The defining design choice is to delegate actual storage and pointer management to the host machine’s operating system and memory manager, while preserving target-side timing behavior through a cycle-true communication layer. In its first prototype, presented in a shared-memory context, the method was intended to support applications with large, changing data sets—such as audio/video and GSM-style workloads—while maintaining speed and accuracy (0710.4646).

1. Design problem and objectives

DynamicMem was motivated by the observation that MPSoC applications often manipulate large, changing data sets, making simulators based only on static tables inadequate. In that setting, memory behavior can dominate simulation cost, so conventional memory models become a significant bottleneck. The method was therefore formulated around four requirements: it should support complex applications with huge amounts of dynamic data, remain accurate, keep overhead low, and be easy to design (0710.4646).

The proposal addresses a specific systems tension. A realistic simulator must expose dynamic allocation, access, and deallocation behavior to software running on instruction set simulators, but a fully synthetic hardware model of every memory-management action is expensive. DynamicMem resolves that tension by separating communication timing from storage semantics. The simulator models how the MPSoC communicates with memory, while the host machine manages where the data resides. This arrangement was presented not as a reduction of the memory problem to pure host execution, but as a targeted abstraction intended for MPSoC exploration.

2. Co-simulation architecture

The technique is embedded in a typical C/C++/SystemC co-simulation environment containing instruction set simulators, interconnect logic, and memory modules. In the prototype, several processing elements, an interconnect, and multiple shared memories were implemented in C++ within a SystemC-based simulation environment, with ARM ISSs acting as the processor models (0710.4646).

Each shared memory is implemented as a wrapper with two parts. The first is a cycle-true FSM that processes communication cycle by cycle through a handshake protocol. The second is a functional part consisting of a pointer table and a translator. The cycle-true FSM preserves protocol-level timing behavior, so the model remains suitable for co-simulation. The functional part maps simulated memory operations onto host-side services such as calloc and free, performs datatype handling, and carries out endian conversion in the transaction workflow.

This division is central to the method’s semantics. The wrapper does not emulate a fully synthetic hardware memory structure. Instead, it acts as a bridge between functional correctness and timing fidelity: communication remains cycle-true, while storage and pointer management exploit host mechanisms that are already highly optimized.

3. Address-space decoupling and transaction semantics

Every transaction between an ISS and the wrapper begins with an opcode and a shared-memory address sm_addr identifying the target memory module. Depending on the opcode, the wrapper interprets the request as allocation, read, write, or deallocation. The mechanism is organized around a pointer table that stores, for each allocated block, the following metadata (0710.4646):

• the virtual pointer (Vptr) used by the simulated architecture
• the real host pointer (Hptr) returned by the host OS
• the allocated size (dim)
• the type of the allocated object (type)
• a reservation bit used as a semaphore-like protection mechanism

This table decouples the simulated memory address space from the host’s actual address space. That decoupling is a defining property of DynamicMem and corrects a common misunderstanding: delegating allocation to the host does not collapse the simulated and host address spaces into one.

For allocation, the wrapper receives dim and type, then maps the request to a host call of the form

$\texttt{calloc(dim, DATA\_SIZE)}.$

The returned Hptr is stored in the pointer table, and a Vptr is returned to the ISS. The virtual pointers are constructed sequentially: each new Vptr is obtained by adding the size of the previous allocated region to the previous pointer value, with the first pointer defaulting to zero.

For write operations, the ISS sends a virtual pointer and data; the wrapper validates the Vptr, looks up the corresponding Hptr, and writes directly into the host memory location. For read operations, the process is reversed: data are fetched via Hptr and returned through the wrapper. For free/deallocation, the wrapper uses the virtual pointer to find the table entry, removes the entry, compacts the table, reduces the total allocated size, and invokes the host’s free on the corresponding Hptr.

DynamicMem also supports pointer arithmetic and user-defined data types. If the ISS computes a pointer value that is not explicitly present in the table, the wrapper identifies which allocated block contains it and reconstructs the correct host address by adding an offset. This allows realistic pointer arithmetic rather than requiring exact-table matches only.

4. Extended modeling capabilities

Beyond basic allocation and access, the method includes several practical mechanisms needed in dynamic-memory simulation. A simulated memory can be made finite-size even though storage is dynamically obtained from the host: additional allocations are refused once the sum of allocated dimensions reaches a preset limit. This preserves a modeled memory capacity distinct from host capacity (0710.4646).

The reservation bit in the pointer table provides shared-memory coherence support by preserving a Vptr when an ISS needs to protect a pointer, functioning like a semaphore. Scalar I/O is extended to arrays by temporarily storing data in I/O buffers until communication completes. Multiple dynamic shared memories are also supported, and because each allocation receives its own host pointer, multiple instances can be handled naturally.

The end-to-end workflow in the prototype is correspondingly hybrid. An ISS issues a memory transaction; the wrapper FSM receives and decodes the opcode and shared-memory address; the translator performs endian conversion and datatype handling; the pointer table is consulted or updated; and the actual memory operation is executed on the host machine. This allows hardware-like modules and software-like dynamic allocation to coexist within a single co-simulation framework.

5. Accuracy, performance, and tradeoffs

The method’s central performance claim is that it supports dynamic data processing without sacrificing speed or accuracy. Speed derives from using the host OS and memory manager for actual allocation and data movement, thereby avoiding expensive handcrafted memory emulation. Accuracy is preserved by the cycle-true wrapper and its configurable delay parameters, which can model data-dependent latencies (0710.4646).

The reported preliminary result used the GSM algorithm. When comparing a system with 4 ISSs, one memory, and one interconnect to a system with 4 ISSs, one interconnect, and 4 memories, the authors reported only about a 20% degradation in simulation speed. This suggests that the technique scales reasonably well while retaining the timing and functional properties required for MPSoC exploration.

The approach also has explicit tradeoffs. It depends on the host OS memory manager and assumes that host-level allocation behavior can stand in for modeled dynamic memory operations. This increases speed and simplicity, but couples the simulator to host-machine behavior. The model further requires explicit handling of pointer translation, finite memory limits, and metadata tracking. The paper also notes that more complex data structures and broader memory-sharing methods were still “work in progress,” indicating that the prototype was most mature for shared-memory and array-like access patterns rather than arbitrary advanced memory organizations.

6. Interpretation and relation to later dynamic-memory simulation work

DynamicMem occupies a specific position within simulation methodology: it is neither a pure functional shortcut nor a complete low-level hardware emulation of allocation internals. Its characteristic abstraction is to preserve protocol timing at the wrapper boundary while outsourcing storage realization to the host. A plausible implication is that the technique exemplifies a broader simulation strategy in which the expensive substrate is abstracted but target-relevant behavior is retained.

A later but distinct line of work pursued a different form of dynamic-memory exploration by simulating Dynamic Memory Managers (DMMs)—defined as compositions of one or more memory allocators—using profiling traces rather than repeated compilation and execution. That framework evaluated execution time, memory usage, and energy consumption for candidate allocator compositions, and used Grammatical Evolution to search the allocator design space (Risco-Martín et al., 2024). Although its problem setting differs from MPSoC shared-memory co-simulation, the comparison is instructive: both approaches treat direct low-level execution as too costly for design exploration, and both introduce structured intermediate models to retain the properties most relevant to the intended analysis.

Within its own scope, DynamicMem remains notable for a concrete systems insight: realistic dynamic-memory behavior in MPSoC simulation need not require explicit emulation of every storage-management mechanism, provided that the communication interface remains cycle-true and the simulated address space remains rigorously separated from host storage through metadata translation.