Self-Aware Polymorphic Execution Cores

• Self-Aware Polymorphic Execution Cores are adaptive computing architectures that dynamically optimize execution contexts.
• They leverage real-time metrics for efficient workload management, adapting microarchitectures based on performance and power demands.
• SAPECs underpin multilayer systems, employing dynamic reconfiguration and phase monitoring to enhance resource efficiency.

Self-Aware Polymorphic Execution Cores (SAPEC) constitute a paradigm in adaptive computer architecture characterized by per-core and system-level awareness of run-time execution context, dynamic microarchitectural and interconnect reconfiguration, and support for correctness and amortized efficiency under concurrency. SAPECs leverage hardware-resident introspection, statistical control, and reconfigurable data paths to reconcile the competing demands of performance, power, and semantic guarantees for a wide variety of workloads. These cores underpin composable systems such as the Self-Aware Polymorphic Architecture (SAPA) stack, and realize the formal model of clustered, reconfigurable memory semantics by making clustering, memory topology, and approximation decisions on-the-fly in response to live metrics and phase behavior (Prasad, 2016, Kinsy et al., 2018).

1. Architectural Foundations and Cluster Semantics

SAPECs build directly on the abstract operational framework for reconfigurable multicore architectures. The global system state is $(S, P)$, where $S: \mathrm{Var} \to \mathrm{Value}$ is the store and $P = [P_1, ..., P_n]$ the per-core program vector. Execution can be orchestrated over a dynamically evolving clustering $Q$ of $N$ cores: $Q = \{C_1, ..., C_k\}$ partitions $\{1, ..., N\}$ into disjoint blocks ("clusters"), determining shared L2 cache boundaries and memory coherence islands (Prasad, 2016).

Clusterings are partially ordered: $Q \leq Q'$ iff each block in $Q'$ is a union of one or more blocks from $Q$,

$S: \mathrm{Var} \to \mathrm{Value}$0

At one extreme, $S: \mathrm{Var} \to \mathrm{Value}$1 denotes symmetric multiprocessing (SMP, maximal private caches); at the other, $S: \mathrm{Var} \to \mathrm{Value}$2 is chip multiprocessor (CMP, maximal sharing). SAPECs natively modulate this topology in hardware.

A SAPEC tile includes a small reconfiguration controller, a set of cores with per-core L2 cache banks, and logic to migrate L2 cache connectivity and program thread mappings dynamically. Each tile maintains a table of candidate $S: \mathrm{Var} \to \mathrm{Value}$3 (for typical $S: \mathrm{Var} \to \mathrm{Value}$4, all cluster partitions), enabling rapid switches between architectural modes based on observed metrics (Prasad, 2016).

2. Self-Awareness, Profiling, and Adaptation

Each SAPEC maintains a dense, hardware-resident sensor suite for introspection. Metrics monitored include instructions per cycle (IPC), cache miss rates, runtime power/energy, local queue depths, operand-precision usage, and coherence traffic (Kinsy et al., 2018). These are accumulated in local FIFO buffers and reported periodically or on threshold events.

Self-awareness mechanisms enable hierarchical processing:

• Local metrics aggregation: Hardware counters buffer raw data until sampling intervals or pre-set thresholds trigger reporting.
• Distributed interpretation: Reconfiguration Manager (RM) modules up the stack decode summaries into high-level phase labels ("memory-bound," "compute-bound," "latency-sensitive").
• Statistical/Control analysis: Lightweight routines such as PID regulators or Kalman filters temper noise and detect regime shifts.
• Decision logic: Machine learning models (e.g., regression trees, k-NN) or rule-based policies determine candidate reconfiguration actions—switching microarchitectural variants, reducing functional unit precision, or triggering fast task migration (Kinsy et al., 2018).

Adaptation occurs at two coupled timescales: per-phase monitoring with adjustment of $S: \mathrm{Var} \to \mathrm{Value}$5 to minimize amortized cost, and rapid microarchitectural adaptation within each SAPEC via a local reconfiguration unit (RU), which can switch pipeline width, reorder buffer size, or adjust FMAC precision (e.g., 32 vs. 16 bits) (Kinsy et al., 2018).

3. Memory Hierarchy, Cache Coherence, and Reducts

SAPECs manage coherence and consistency through the explicit notion of implementation state $S: \mathrm{Var} \to \mathrm{Value}$6, where $S: \mathrm{Var} \to \mathrm{Value}$7 encodes per-core or per-cluster L2 caches. Each cache line in $S: \mathrm{Var} \to \mathrm{Value}$8 is labeled $S: \mathrm{Var} \to \mathrm{Value}$9, $P = [P_1, ..., P_n]$0 (Prasad, 2016).

Program transitions (all transitions are priced, see below) are:

• LocalRead: $P = [P_1, ..., P_n]$1 cost (cache hit, $P = [P_1, ..., P_n]$2),
• StoreRead / ReadPull: $P = [P_1, ..., P_n]$3 cost (cache miss, with $P = [P_1, ..., P_n]$4 loaded cleanly),
• WriteBack: $P = [P_1, ..., P_n]$5 cost (write to local cache, marks line dirty).

System-level background transitions (eviction, cache updates, store updates) enforce the update coherence protocol. During reconfiguration $P = [P_1, ..., P_n]$6, the special action $P = [P_1, ..., P_n]$7 (cost $P = [P_1, ..., P_n]$8) writes back dirty cache lines and resets $P = [P_1, ..., P_n]$9 to cold state $Q$0. Well-synchronized (data-race-free, DRF) programs retain sequential consistency under any "upward" reconfiguration, i.e., $Q$1 where $Q$2 [(Prasad, 2016), Thm 3.8].

4. Efficiency: Amortised Bisimulation and Cost Model

SAPEC runtime controllers optimize the cost of execution by exploiting amortised bisimulation. Actions fall into three equivalence classes under $Q$3:

• $Q$4 reads;
• $Q$5 writes;
• $Q$6 system/unobservable and reconfiguration events.

Pricing scheme: cache hits and writes $Q$7, cache misses and store updates $Q$8, reconfiguration $Q$9 ($N$0), background events negligible.

The amortised bisimulation relation $N$1 links two systems (states $N$2) such that, after appropriately mapped observable and unobservable actions,

$N$3

and symmetrically for $N$4. Intuitively, repeated cache hits in fine-grain clusterings ($N$5 fine) accumulate "credit" $N$6; once enough credit accrues to amortize the cost $N$7 of reconfiguration, the system can morph to a more efficient $N$8 [(Prasad, 2016), Thm 5.2].

Coarser clusterings (higher in the partial order: more sharing, e.g., full CMP) are guaranteed not to increase amortised average memory cost, provided program synchronization is well-disciplined.

5. Control and Dynamic Reconfiguration Algorithms

The hardware adaptation loop in SAPEC tiles is driven by constant metric sampling and cost estimation. The core controller workflow is as follows (Prasad, 2016):

initialize Q := default; credit := 0
while program not finished do
  sample miss_rates, IPC, coherence_traffic
  for each candidate Q′ do
    estimate C̄(Q′) = κ·Hits + δ·Misses + small_const
  end
  Q_best := argmin_Q′ C̄(Q′)
  if C̄(Q) − C̄(Q_best) > hysteresis AND credit ≥ μ then
    θ := reconfig_action(Q→Q_best)
    issue θ;
    // flush dirty lines, rewire L2 topology
    Q := Q_best; credit := 0
  endif
  credit += (δ−κ)* (# new cache-hits in last epoch)
end

A hysteresis parameter prevents thrashing. The requirement $N$9 ensures that reconfiguration happens only when the net expected benefit is positive under amortized analysis (Prasad, 2016).

At the microarchitecture level, SAPECs use local RUs to rapidly rewire core structure, select precision, or initiate fast migration (via architectural state handoff, typically $Q = \{C_1, ..., C_k\}$0 13 cycles overhead) (Kinsy et al., 2018).

6. System Stack Integration and Network Adaptivity

SAPECs are the foundational layer in multi-layered adaptive stacks such as SAPA, layering Approximation-Aware Memory Models (AMOM), Resilient Adaptive Intelligent Network-on-Chip (RAIN), and a distributed Dynamic Approximation Execution Manager (DAEM, or Nervous System, NS) (Kinsy et al., 2018).

• AMOM: SAPECs interact with self-organizing memory that dynamically migrates and replicates hot data banks in response to access trace analysis; there is no global coherence, but directory-based local tracking.
• RAIN: NoC routers maintain per-link congestion counters $Q = \{C_1, ..., C_k\}$1 and, above a threshold $Q = \{C_1, ..., C_k\}$2, update routing metrics $Q = \{C_1, ..., C_k\}$3 to redirect traffic dynamically.
• DAEM/NS: Collects runtime summaries from all SAPECs, interprets them into system-wide features, and applies policy/ML models to coordinate large-scale reconfigurations, e.g., moving work away from congested regions or dialing up approximation under resource pressure.

Task migration across cores can be effected by "fast swap" of local architectural state via a side channel, or "full handover" using NoC packets. The typical SAPEC migration mechanism incurs $Q = \{C_1, ..., C_k\}$4 cycles in hardware, enabling rapid adaptation without significant performance penalty.

7. Empirical Results and Application Scenarios

Evaluations of SAPEC systems on iterative, approximation-friendly benchmarks (e.g., noisy-image matching via simulated annealing) demonstrate scalable, context-driven adaptation. For an object recognition workload, increasing target matching confidence from 85% to 98% caused execution time and power to triple; precision scaling within SAPECs (using half-width FMAC units) achieved a 40% energy reduction at a 3% accuracy loss. Adaptive core-count scaling (from 12 to 8, when memory-bound phases dominate) yielded a 15% additional power savings with less than 5% performance degradation (Kinsy et al., 2018).

These results illustrate the SAPEC design tradeoff envelope: live phase detection and controlled polymorphism efficiently navigate Pareto spaces in time–power–quality, extracting benefits that static architectures or fixed-function multicore systems cannot realize at the same granularity.

---

References:

(Prasad, 2016): Program Execution on Reconfigurable Multicore Architectures (Kinsy et al., 2018): SAPA: Self-Aware Polymorphic Architecture