Paper deep dive

MCHA: A Memory-Centric Hierarchical Architecture for Parallel-Sequential Computing

Daijing Shi, Hongxiao Zhao, Yihan Fu, Zhan Chen, Jiayi Li, Yihang Zhu, Anjunyi Fan, Yaoyu Tao, Yuchao Yang, Bonan Yan

Year: 2026Venue: arXiv preprintArea: cs.ARType: PreprintEmbeddings: 99

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 89%

Last extracted: 8/9/2026, 2:05:26 AM

Summary

The paper introduces MCHA (Memory-Centric Hierarchical Architecture), a reconfigurable hardware solution designed for parallel-sequential computing workloads like Multi-Agent Reinforcement Learning (MARL). MCHA addresses memory bottlenecks in conventional architectures by utilizing a hierarchical communication strategy with distributed inter-core data routing and a data-driven programming model that hides latency via event-driven triggers. Benchmarks show significant performance speedups over NVIDIA A100 GPUs and reduced main memory access.

Entities (8)

MCHA · architecture · 98%Nvidia A100 · hardware · 95%Multi-Agent Reinforcement Learning · workload · 92%Parallel-Sequential Computing · paradigm · 90%RISC-V · processor · 88%Memory-Centric Core · component · 87%Network-on-Chip · component · 85%28 nm process · process · 80%

Relation Signals (6)

MCHA → outperforms → Nvidia A100

confidence 95% · MCHA demonstrates performance speedups ranging from 153.06× to 2456.96× over NVIDIA A100 GPUs on MARL workloads

MCHA → supports → Parallel-Sequential Computing

confidence 92% · MCHA, a reconfigurable hardware solution tailored for parallel-sequential execution.

MCHA → accelerates → Multi-Agent Reinforcement Learning

confidence 90% · We benchmark MCHA against a diverse suite of parallel-sequential tasks, including MARL... MCHA demonstrates performance speedups... on MARL workloads

Memory-Centric Core → contains → RISC-V

confidence 88% · each MCC integrates a RISC-V core as an embedded orchestrator

MCHA → uses → Network-on-Chip

confidence 85% · interconnected via a Network-on-Chip(NoC)

MCHA → synthesizedin → 28 nm process

confidence 80% · When synthesized in a 28 nm process, the MCHA implementation occupies an area footprint of 2.92mm 2

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Emerging workloads, such as Multi-Agent Reinforcement Learning (MARL), large-scale neuromorphic computing, and probabilistic graphical models, intrinsically exhibit parallel-sequential computing patterns. While these tasks demand massive parallelism to achieve high throughput, they are severely bottlenecked by irregular data access patterns centralized to main memory. Consequently, conventional architectures face fundamental limitations when executing these workloads, primarily manifesting as global buffer saturation and memory-bound bottlenecks. To address these challenges, we propose the Memory-Centric Hierarchical Architecture (MCHA), a reconfigurable hardware solution tailored for parallel-sequential execution. MCHA leverages a hierarchical communication strategy that facilitates distributed, inter-core data routing, thereby significantly reducing the bandwidth burden on the global memory. Complementing the hardware, MCHA introduces a novel parallel-sequential programming model that utilizes event-driven conditional triggers to effectively hide data transmission latency within the execution pipeline. We benchmark MCHA against a diverse suite of parallel-sequential tasks, including MARL, motor variable control, and Markov random fields. Validated through our open-source, cycle-accurate simulator, MCHA demonstrates performance speedups ranging from 153.06$\times$ to 2456.96$\times$ over NVIDIA A100 GPUs on MARL workloads, while maintaining robust programming flexibility across other application domains. Furthermore, the architecture successfully reduces main memory access from 96% to 5.44%. When synthesized in a 28 nm process, the MCHA implementation occupies an area footprint of 2.92mm$^2$ and consumes 115.36 mW of power at 200 MHz. MCHA is open-sourced at this https URL.

PDF

Open source PDF →

PDF not stored locally. Use the link above to view on the source site.

Full Text

96,056 characters extracted from source content.

Expand or collapse full text

1 MCHA: A Memory-Centric Hierarchical Architecture for Parallel-Sequential Computing Daijing Shi , Hongxiao Zhao , Yihan Fu , Zhan Chen , Jiayi Li , Yihang Zhu , Anjunyi Fan , Yaoyu Tao , Yuchao Yang , Bonan Yan Peking University, Beijing 100871, China bonanyan@pku.edu.cn Abstract Emerging workloads, such as Multi-Agent Reinforcement Learning (MARL), large-scale neuromorphic computing, and probabilistic graphical models, intrinsically exhibit parallel-sequential computing patterns. While these tasks demand massive parallelism to achieve high throughput, they are severely bottlenecked by irregular data access pat- terns centralized to main memory. Consequently, conven- tional architectures face fundamental limitations when ex- ecuting these workloads, primarily manifesting as global buffer saturation and memory-bound bottlenecks. To ad- dressthese challenges, weproposetheMemory-CentricHi- erarchical Architecture (MCHA), a reconfigurable hardware solution tailored for parallel-sequential execution. MCHA leverages a hierarchical communication strategy that fa- cilitates distributed, inter-core data routing, thereby sig- nificantly reducing the bandwidth burden on the global memory. Complementing the hardware, MCHA introduces a novel parallel-sequential programming model that uti- lizes event-driven conditional triggers to effectively hide data transmission latency within the execution pipeline. We benchmark MCHA against a diverse suite of parallel- sequential tasks, including MARL, motor variable control, and Markov random fields. Validated through our open- source, cycle-accurate simulator, MCHA demonstrates per- formance speedups ranging from 153.06×to 2456.96× over NVIDIA A100 GPUs on MARL workloads, while main- taining robust programming flexibility across other applica- tion domains. Furthermore, the architecture successfully reduces main memory access from 96% to 5.44%. When synthesized in a 28 nm process, the MCHA implementa- tion occupies an area footprint of 2.92m 2 and consumes 115.36 mW of power at 200 MHz. MCHA is open-sourced at https://github.com/carabdis/MCHA. Keywords: Reconfigurable Architecture, Memory-Centric, Scalable Architecture, Bulk Synchronous Parallel, Data- Driven Programming This paper has been accepted for publication at the 59th IEEE/ACM International Symposium on Microarchitecture (MICRO). © IEEE. Per- sonaluseofthismaterialispermitted. PermissionfromIEEEmustbeob- tainedforallotheruses,inanycurrentorfuturemedia,includingreprint- ing/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists,orreuseofanycopyrightedcomponentofthisworkinotherworks. 128 256512102420484096 Time Cost (s) Number of Agents Global Memory Ops Local Memory Ops Compute (b) 96% 95% 94% 92% 89% 83% 0 10 20 30 40 10 -2 10 -2 10 0 10 2 10 4 10 -1 10 0 10 4 Compute Bound Extra Memory Access Throughput / GFLOPS Arithmetic Density (FLOPs/Byte) MPE Simple Spread Switch Riddle Starcraft STORM Measured Throughput (a) 10 0 10 -1 Intensity (%) Cumulative Active Time (ms) (d) 0255070100125150175200 Compute Memory 78.9% 21.1% Memory Utilization (%)GPU Utilization (%) 72 68 64 60 1.5 1.0 0.5 0.0 MPE Switch Riddle StarcraftSTORM (c) MemoryGPU Kernel 20-128020-128020-128020-1280 Number of Agents Transmitted Data: 1410.6 KB 47.66× Redundant Data Essential Data: 29.6 KB Figure 1:(a) Roofline model of the NVIDIA RTX 3090 with PSC ap- plications;(b) Simulated access operation breakdown of the GPU architecture;(c)Measuredmemoryaccountandcomputinginten- sity;(d)Measuredmemoryaccessandcomputingratioduringthe active time. 1Introduction Parallel-Sequential Computing (PSC) is a hybrid paradigm that combines concurrent execution of multiple tasks with stepwise sequential operations. This approach seeks to balance computational efficiency, system scalability, and adherence to logical dependencies within a problem. In contrast to purely parallel architectures (e.g., Tensor Pro- cessing Unit [ 1] and the Loihi family [2]) and strictly se- quential processing, PSC decomposes complex problems into independent subproblems and interdependent phases. Thisallowsittoleveragedistributedhardwarewhilepreserv- ing data consistency, control flow, and algorithmic correct- ness. Suchadesignmitigateskeylimitationsoffullyparallel execution, including synchronization overhead, data races, and bottlenecks described by Amdahl’s law [ 3]. Simultane- ously, it avoids the inefficiency of purely sequential process- ing when applied to large-scale or computationally inten- siveworkloads. Bydynamicallyallocatingparallelizableseg- ments and enforcing sequential ordering where dependen- cies exist, the PSC execution model optimizes resource uti- lization and accelerates computation for data-intensive and algorithmically complex tasks. Consequently, it is widely adopted in high-performance computing, scientific simula- tion, and related domains. arXiv:2608.04443v1 [cs.AR] 5 Aug 2026 2 PSC encompasses a broad spectrum of computing tasks, including Multi-Agent Reinforcement Learning (MARL) [4– 8], large-scale neuromorphic computing [9–12], and proba- bilisticgraphicalmodels[13–15]. Additionally, theBulkSyn- chronous Parallel (BSP) paradigm, which underpins indus- trial data-intensive frameworks such as MapReduce [16], Pregel [17], Spark [18], and PolyGraph [19], is also integral to PSC. These tasks demand massive parallelism to man- age frequent, fine-grained interactions among thousands of entities (e.g. agents in MARL), with strict synchroniza- tion required at each time-step boundary. In conventional compute-centric architectures (CPUs & GPUs), these re- peated interactions induce irregular data access patterns that saturate centralized main memory. Consequently, as depicted in Figure1(a), deploying such workloads on GPUs or many-core CPUs results in execution throttled by the global memory bandwidth (i.e. the “memory wall” [20–22]). The memory wall is exacerbated by the mismatch be- tween irregular working sets and rigid hardware hierarchies. When on-chip storage fails to capture unpredictable access patterns, the system incurs frequent, high-latency DRAM fetches, leading to severe execution stalls [ 12,23,24]. Our analysis of a grid-world MARL task on an NVIDIA RTX 3090 (Figure1(b)) reveals a significant inefficiency: data move- mentoverheadaccountsfor83%to96%oftotalprocessing operations, depending on the simulation scale. Figures 1(c) and(d)furtherdemonstratethatthemajorityofexecutioncy- cles and energy are consumed by redundant memory traffic rather than productive computation. Even recent reconfigurable hardware with data parallelism, such as Plasticine [25,26] or Leviathan [27], remains teth- ered to data-centric or compute-centric paradigms. Plas- ticine employs a coarse-grained reconfigurable architec- ture (CGRA) with dataflow compilation [28–30] to decou- ple memory access from task processing. However, the lack of transparency between memory and processing units still necessitates redundant data fetches. Leviathan [ 27] utilizes in-cache near-data computing [31–34] but re- mains burdened by frequent cache coherence manage- ment overhead for PSC tasks. Other Processing-In-Memory (PIM) or BSP domain-specific accelerators (DSAs) are ei- ther highly application-specific [ 35–38] or bottlenecked by global buffer (GB) access for synchronization [39–43]. Con- sequently, existing works suffer from a ping-pong effect in the sequential part of PSC, where data is repeatedly trans- mitted between main memory and multi-level caches to sat- isfy rigid cache coherence protocols [ 44–47]. To address this challenge, we introduce MCHA, a reconfig- urable and memory-centric multi-chip computing architec- ture. By devising a multi-tiered inter-core communication network and a data-driven programming model, MCHA ef- fectively overcomes the data-transfer bottlenecks that limit the performance of GPUs, FPGAs, and CGRAs across a broad range of PSC tasks. Our key contributions are sum- marized as follows: MARL Neuro. Model BSP Parameter Gathering Update Transformation State Write-Back f f f Figure 2:The three-stage processing of PSC tasks. ⋄MCHA Architecture: After quantifying the inefficiency of traditional architectures for PSC workloads, we propose a novel reconfigurable hardware architecture. It replaces centralized global buffers with a distributed memory fab- ricinterconnectedviaaNetwork-on-Chip(NoC),substan- tially lowering cache coherence overhead. ⋄Data-Driven Programming Model: We develop a formal programming model and an associated workflow to effi- ciently map PSC tasks onto the proposed reconfigurable hardware platform. ⋄Comprehensive Architectural Analysis Framework: We release an open-source, cycle-accurate simulator (avail- able athttps://github.com/carabdis/MCHA) to evalu- ate the throughput and scalability of MCHA under vari- ous multi-chip configurations. Through extensive experi- ments, we derive new insights into hierarchical memory bandwidth limitations and propose effective mitigation strategies. For evaluation, we implement MCHA at the register-transfer level (RTL) using the TSMC 28nm HPC+ process design kit (PDK). Experiments across a suite of MARL bench- marks [ 48–52] show that a 4-chip MCHA system delivers a speedup of 153.06×to 2456.96×compared to an NVIDIA A100GPU.WefurthervalidatethegeneralityofMCHAusing Motor Variable Control and BSP applications, where a 32- chip configuration achieves speedups of 1.17×and 3.90× over state-of-the-art DSAs. These results underscore the efficiency of MCHA in handling irregular, memory-intensive dataflow patterns. 2Target Workload: Parallel-Sequential Patterns PSC FormulationAs depicted in Figure2and Algorithm1, PSCfollowsparallel-sequentialpatterns, whichcanbechar- acterized by an evolving state space composed of entity- specific data. To formalize the hardware requirements of these tasks, assume the global system state at any tempo- ral index (“time” or “steps”)tasS t . Each entityiwithin this state is represented by a multi-dimensional feature vec- tor x n i (t)∈R n . The persistent structural constraints of the task, such as graph topology, environmental boundaries, or synaptic weights, are encapsulated in the parameter set p. The state transition logic is governed by an update function f i , which determines the feature vector of entityiat state t+ ∆tbased on features of its neighborhoodN i and itself: ⃗ x n i (t+ ∆t) =f i ( ⃗ x n i (t), ⃗ x n j (t) j∈N i ,p ) , i= 1,2, . . . , m(1) 3 Algorithm 1 Parallel-Sequential Computing Tasks Input:Entities ⃗ x n (t), neighborhoodN, entity numberm, persistent structural parameter p Output:Final entity state ⃗ x n (t end ), total state numbert end . for eachtdo for eachi∈[0, m]do▷Parameter Gathering N i =FindNeighbor( ⃗ x n i (t)) D i =GBAccess(N i ) end for parfor eachi∈[0, m]do▷Update Transformation ⃗ y n i (t) =f i ( ⃗ x n i (t),D i ,p ) end for for eachi∈[0, m]do▷State Write-Back ⃗ x n i ( t + ∆ t ) = ⃗ y n i ( t ) ▷ Multicore Cache Coherence Sync. end for end forreturnt end where∆trepresents the step size between different states; N i denotes the set of indices for entities influencing the up- datefunctionofthei th entity;misthetotalentitypopulation count. From an architectural perspective, the primary over- head originates from the execution off, which we decom- pose into three stages called Parameter Gathering, Update Transformation, and State Write-Back. Bottleneck AnalysisWe revisit Gustafson-Barsis’s law [53] through a memory-centric analysis. Accord- ing to Gustafson’s formulation, the theoretical speedupS achieved via parallel computing is S=s+ (1−s)N=N−(N−1)s,(2) whereNdenotesthenumberofprocessorsandsrepresents the sequential fraction of the total execution time. Consider an ideal PSC task described with Equation1, in whichmindependent entities are processed concurrently acrossNcores, each requiring compute latencyT compute 1-step . The sequential overhead arises from synchronization oper- ations, specifically, gathering and writing back results. It in- cursadata-transferlatencyT data-transfer = C Gather +C Back BW ,where C Gather andC Back denote the data sizes for synchronization among themcores, andBWis the global memory band- width. Hence, the sequential fractionsin Equation ( 2) can be approximated ass= T data-transfer T data-transfer +T compute 1-step . Substituting this into Equation (2) yields the memory-aware speedup approximation: S=N−(N−1) 1 1 + T compute 1-step T data-transfer =N− N−1 1 + T compute 1-step ·BW C Gather +C Back . (3) When memory access becomes the dominant bottleneck, i.e., T compute 1-step T data-transfer ≪1due to relatively low bandwidth, the over- all speedupScollapses to “1”, indicating no effective paral- lelism gain. Challenges.Based on the preceding analysis, memory ac- cess readily becomes the dominant performance factor due to two interconnected architectural challenges. Challenge 1: Global Buffer Saturation As shown in Fig- ure1(b), memory access dominates the execution pro- file, highlighting the significant communication overhead fromC Gather andC Back . The absence of direct peer-to- peer (P2P) communication primitives between processing elements in conventional accelerators means that scaling mforces multiple cores to contend for global memory re- sources. This contention transforms the centralized GB into a serial bottleneck. Furthermore, in compute-centric archi- tectures, the runtime dependency ofN i on entity states in- curs substantial over-fetch overhead. The hardware must fetch entire cache lines to access non-contiguous entity data, resulting in severe bandwidth underutilization. Although the Update Transformation phase can be paral- lelized for SIMD/SIMT acceleration [ 54,55], its low arith- metic intensity, often comprising only a few linear layers or element-wise nonlinearities, prevents effective utilization of computational units. Consequently, processing elements frequently stall waiting for data from saturated memory op- erations, leading to the second challenge. Challenge 2: The Memory-Bound Trap Figure 1(c–d) illus- tratesthatregardlessofworkloadcomplexity,GPUcompute utilization remains low in PSC tasks. This indicates the bot- tleneck is an architectural latency issue, not a lack of raw computational throughput. The inefficiency originates from therigidcouplingofdataindexingandprocessinginconven- tional architectures, which enforces sequential execution for irregular memory accesses. As a result, most of the pro- cessing timeT compute 1−step in Equation 3is spent stalled, await- ing data fetches from the centralized global memory. MotivationBuilding on the challenges outlined above, we introduce two key solutions in MCHA: Multi-Tiered Peer-to-Peer Interconnect (Section 3):Our coreideaistoparallelizetheoriginalsequentialpart T data−transfer withanovelprogrammingmodeland reconfigurablehardwaresubstrate.MCHA employs a multi- tiered peer-to-peer communication fabric which filters the data communication according to the transmission dis- tance, thereby eliminating contention for higher-level trans- mission paths. By removing this centralized bottleneck, MCHA avoids memory-access serialization and supports near-linear scalability. Data-Driven Programming Model (Section4–5):The pro- posed data-driven model replaces sequential control flow with fine-grained, data-driven memory operations.Commu- nicationbetweencoresisrealizedthroughmemory-mapped I/O (MMIO) FIFOs, decomposing inter-core data transfers 4 into discrete asynchronous events across the fabric.Con- sequently, these operations are hidden from the pipelines of each core, improving data independence of these cores and thus sustaining high computational throughput. 3MCHA Architecture The MCHA architecture employs a computing layer of Memory-Centric Cores (MCCs) interconnected by a multi- tieredNoC.Thisdesignprovideshigh-bandwidthdatatrans- mission while bypassing traditional multi-level cache struc- tures to minimize multi-core cache coherence overhead. The NoC fabric is organized based on spatial access fre- quencies to maximize data locality.Compared with Cere- bras [56], which implements data locality by holding every- thing on-chip, a three-tier implementation is illustrated in Figure3(a),providingthebasisforourarchitecturalanalysis and performance evaluation.The fabricated chip die photo of our implementation is embedded in Figure3(e). 3.1Computing Layer: Memory-Centric Cores The fundamental component of MCHA is the MCC, which augments on-chip memory with localized processing capa- bilities to minimize data movement overhead (Figure 3(b)). To ensure deterministic pipeline control, each MCC inte- grates a RISC-V core as an embedded orchestrator, sup- ported by dual SRAM banks dedicated to instruction and data storage, respectively. Consequently, MCCs serve as theprimaryrepositoriesforentitystatesx i ,facilitatingdirect inter-corecommunicationandbypassingthecentralizedGB and broader memory hierarchy. Inter-core communication is managed via MMIO FIFOs with explicit programs. This approach simplifies the programming abstraction while ef- fectively masking data transmission latency within the pro- cessing pipeline. 3.2Communication Layer-1: Processing Block In MCHA, MCCs are grouped into Processing Blocks (PBs) to handle resource-intensive update functionsf. When a parallel-computedfunction(e.g.,afullmatrixmultiplication) exceeds single-core capabilities, a PB facilitates collabora- tiveexecutionthroughMCHACommunicationLayer-1. This layer ensures data coherence between neighboring cores and manages the frequent data traffic resulting from multi- corecollaboration. Intra-blockcommunicationissupported by high-bandwidth FIFOs that enable near-instantaneous transfer of intermediate results. Thus, during multi-core col- laboration, entity state x i remains resident in local memory, maximizing data locality. Additionally, P2P interconnection between PBs and an independent DRAM Fabric is embed- ded in this layer to facilitate multi-block collaboration and efficient DRAM access (Figure 3(c)). 3.3Communication Layer-2 & 3: 2D-Mesh The Communication Layer-2 and 3 of MCHA consists of a 2D-mesh topology formed by P2P interconnection link- ing neighboring PBs (Figure3(d–e)) and high-speed chip- to-chip (C2C) interface across multi-chip boundaries (e.g., usingUCIeorPCIeprotocol[57,58]). Thisdistributedmesh serves as an active buffer, replacing multi-level caches to avoid redundant data movement caused by cache coher- ence across the memory hierarchy in multicore systems. The mesh enables P2P communication to resolve neighbor- hoodN i memoryqueriesandotheressentialinter-coredata access without the serialization overhead of centralized memory controllers. These links ensure system-wide data transparency, permitting the spatial distribution of complex functionsf(Algorithm1)acrossmultiplePBsorchipswhen necessary. AdedicatedDRAMFabrichandlesoff-chiptraffic independently of the inter-core mesh. This decoupling iso- lates the processing fabric from high-latency off-chip mem- ory access and avoids DRAM data from being transmitted across the whole multi-tiered network to improve DRAM ac- cess efficiency. 4Data-Driven Programming Model Beyond conventional cache coherence management over- head, the performance of PSC workloads is limited by stalls arising from the tight coupling of data indexing and pro- cessing, which is a byproduct of the explicit data-fetch from memorytothecentralexecutionunitinthecompute-centric model. We address this through a Data-Driven Program- ming Model that achieves latency hiding by breaking data access into a series of asynchronous events. By spreading theseeventsacrossthedistributedmemoryfabric,MCHAal- lows data transmission to be overlapped with local process- ing, significantly reducing the impact of memory-related stalls. Figure 4shows the programming model for MCHA. To en- abledata-drivenprocessing,wecategorizearchitecturalop- erations of functions into four primary triggers: 1.Memory Conditional Trigger: Initiates functions when local SRAM variables meet logical predicates, enabling state-dependent data processing. 2.Phase Conditional Trigger: Switches between triggering configurations at synchronization points to facilitate dy- namic function deployment and smooth state transfor- mations. 3.Input Trigger: Activates functions upon message arrival in hardware FIFOs, decoupling execution from NoC la- tency and ensuring data-ready activation. 4.Default Memory Scan: Performs an autonomous scan of local SRAM to trigger execution based on resident data in the absence of external FIFO inputs. This enables the 5 Instruction SRAM Data Storage SRAM Output FIFO Input FIFO RISC-V Core Computing Layer: MCCCommunication Layer-1Communication Layer-2 (b)(c)(d)(e)(a) Define Dataflow Program Defined Address Local Decoder MCCMCC MCCMCC Edge I/O Edge I/O Edge I/O Edge I/O DRAM I/O DRAM Fabric P2P Interconnect PBPBPB PBPBPB PBPBPB DDR & C2C Interface DDR & C2C Interface DDR & C2C Interface DDR & C2C Interface Comm. Layer-3 Inter-Chip Comm. Layer-2 Inter-PB Comm. Layer-1 Intra-PB Comp Layer MCC Data Access Frequency High Low Communication Layer-3 DRAM Fabric PB #1PB #2 PB #4PB #3 Fabricated Chip Figure3:(a)MCHACommunication“Pyramid”; Architectureof(b)ComputingLayer;(c,d,e)CommunicationLayer-1,-2,&-3. Embedded figure in (e): MCHA die photo for silicon verification. (a) (e) (b) (c) (d) N i x j RISC-V Core Instruction Memory Type Identify Responder Memory Scan i-th RISC-V Core Instruction Memory N i Default Trigger 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 parfor i in [, CoreNum]: if Core[i].MemReq(): # Mem Condition Trigger Core[i].MemFunc() elif Core[i].PhaseReq(): # Phase Condition Trigger Core[i].PhaseChange() elif Input is not None: # Input Trigger Core[i].ProcFunc(Input) elif Core[i].DefaultScan(): # Default Memory Scan Core[i].ScanMem() # Do Default Function # FindNeighbour() Serialization Cause Severe Stall 1 2 3 4 5 6 7 for i in [, m]: N[i] = FindNeighbor(x[i]) D[i] = GBAccess(N[i]) parfor i in [, m]: y[i] = f(x[i], D[i], p) for i in [, m]: x[i] = y[i] Conditional Trigger Enable High Core Utilization Rate Data Memory Data Log Phase Log Data Ops Instruction Memory >> Condition Trigger Jump MUX PC List Data Memory Ops Input Trigger Conventional Pipeline: MCHA Pipeline Core A Core B Core A NoC Core B FindNeighbor FindNeighbor FindNeighbor FindNeighbor GB INGB OUT GB OUTGB IN DRAM I/O DRAM I/O DRAM I/O DRAM I/O Wait Wait Wait Wait Write Back Write Back f f f Reception Retrieval Retrieval Reception Inter-Core Transmission Sync f Sync Sync Sync Write BackInitial Excecution MCHA Saving W. GPU MCHA Figure 4:(a) Compute-centric and data-driven programs; (b) Dataflow for Conditional Trigger and Phase Conditional Trigger; (c) Dataflow for Input Trigger; (d) Dataflow for Default Memory Scan; (e) Pipeline Comparison of Conventional architecture and MCHA. MCC to initiate the computing loop without external sig- naling. The corresponding dataflows of these triggers within MCCs are presented in Figure 4(b–d). A more detailed explanation and realization of our design is provided in Section 6.2.2. Furthermore, withinthisframework, todecoupledataindex- ing from the processing pipeline, inter-core communication is decomposed into a three-stage asynchronous trigger se- quence: ⋄Initial Execution, which triggers the generation and trans- mission of a data index, demonstrated by any trigger; ⋄Index Reception, which initiates a local memory search and subsequent message return, demonstrated by the In- put Trigger; ⋄Data Retrieval, where the arrival of the indexed data re- sumesthesuspendedcomputation, demonstratedbythe Input Trigger. By partitioning communication into these discrete asyn- chronous triggers, MCHA effectively masks data transmis- sion latency by overlapping it with the active processing pipeline. Figure4(e) presents the conceptual dataflow of programs in Figure4(a). In a conventional pipeline, the centralized GB obstructs the execution flow, leading to severe memory- bound performance degradation. In contrast, by utilizing the Default Memory Scan trigger, MCCs initiate parallel off- chip data loading to maximize DRAM bandwidth utilization through hardware-level concurrency. Computation of the updatingfunctionfwillbetriggeredbyMemoryConditional Trigger. Detecting the completion of the asynchronous data indexing process and stage transmission of the pipeline is handled through the Phase Conditional Trigger.The im- plementationofthetrigger-baseddata-drivenprogramming model isolates the computing pipeline of each MCC, reduc- ingT data−transfer in PSC workloads thanks to the elimina- tion of stalls. 5Communication Protocols The design target of the programming model in Section4is to enhance data independence of MCCs for isolation of the local pipeline from being obstructed by others. To realize asynchronous communication for this purpose, we formal- ize the communication protocols of MCHA with the help of MMIO FIFOs embedded in the MCCs instead of relying on a centralized memory controller like NVIDIA Hopper GPU [ 59]. The direct mapping of the NoC interface into the local ad- dress space of each core eliminates the control-plane dis- tinction between computation and communication, isolat- ing the data access in each MCC from that of others.This design hides communication latency within the execution pipeline, which is particularly advantageous for PSC pat- terns. Furthermore, the multi-tiered communication hierar- chy mitigates bandwidth contention for long-distance trans- fers (e.g., inter-chip and off-chip data access) by isolating local traffic from global data movement. 5.1Core Message Management InMCHA,eachMCCfunctionsasaself-containedexecution environmentwhereoperationsaretriggeredasynchronously by incoming messages or local memory states, consistent with the principles detailed in Section 4.Workloads are de- ployed to an MCC’s local independent instruction memory with optimized execution flow from compilation. As illus- tratedinFigure 5(a),communicationFIFOsbypasscomplex network drivers and are instead mapped directly to the local address space. Consequently, transmitting data to a neigh- 6 boringMCCiscompiledtoastandardmemory-store(store) operation. When the RISC-V core writes to a designated output address, the data is enqueued into the output FIFO. On this other side of receiving, data reception is handled via memory-load (load) operations, where the input FIFO functions as the core’s event queue for incoming messages awaiting processing.The implementation of the MMIO FI- FOs masks data transmission latency within the MCC exe- cutionpipeline, isolatingtheMCClocalprocessingfromthe global NoC data transmission. 5.2Transmission Message Definition To shield the local MCC pipeline from unexpected stalls in- duced by the multi-tiered NoC latency, we isolate MCC ex- ecution from the global dataflow through a latency-hiding communication framework. This framework stratifies data traffic based on transmission frequency and bandwidth availability, orchestrated by a streamlined 32-bit packet format. By supporting two hardware-optimized message types that match the spatial locality patterns in MCHA (Fig- ure5(b)), the design effectively minimizes routing overhead while ensuring high flexibility for intertwined PSC execution. Type 1 serves high-throughput, one-hop communication, corresponding to Communication Layer-1. It constitutes the dominant traffic during the Gather phase of Algorithm 1, where MCCs exchange entity states with adjacent PBs or neighbors in the 2D-mesh. Each Type 1 message is a sin- gleself-contained32-bitpacket. Thefirst3bitsserveasthe Type ID and specify the hop direction (North, South, East, West, or Local). The subsequent 5 bits in the same byte de- fine the target (Cores or DRAM), leaving a 3-byte payload for user-defined data. By restricting communication to a single hop, the hardware avoids complex routing headers and multi-cycle state tracking, enabling near-instantaneous data-residency updates. Type 2 supports lower-frequency global communication us- ing variable-length bursts, corresponding to Communica- tionLayer-2and3. Eachburstcomprisesasingleheaderfol- lowedbyaspecifiednumberofdatapackets. AswithType1, the initial 3 bits identify the packet type. A dedicated length field (bits 27–28 in Figure 5(b)) specifies the total number of subsequent packets in the burst. The remainder of the header carries the routing information required to traverse the 2D-mesh and reach distant chip-level coordinates. To maximize effective bandwidth, only this initial packet con- tains routing metadata; all following packets are devoted al- most entirely to user-defined content, thereby enabling ef- ficient transmission of weights, environmental parameters, or extended entity histories. The entire transmission process is software-configurable via the RISC-V ISA. This dual-tier protocol ensures that lo- cal neighborhood exchanges are resolved with minimal la- tency,whileType2messagingprovidesthenecessarytrans- parency for global MCC interactions across a large-scale multi-chip fabric. 5.3Intra-Block Transmission Multi-core collaboration within the PB triggers intense P2P data sharing, characterized by high-frequency, fine-grained message inquiries. To support this behavior, we deploy the optimized Type 1 transmission format in Section5.2. To realize stall-free coordination, PBs incorporate a high- bandwidth bidirectional interconnect linking the MCCs, as shown in Figure5(c), enabling intra-block communication without traversing the global 2D-mesh network. This lo- calized routing effectively unburdens the global mesh and prevents cascaded core stalls.In place of the power- intensive crossbars in general-purpose NoCs, the design employsaFIFO-basedqueuingandarbitrationschemeopti- mized for PSC workloads. At the output stage of each MCC or PB boundary, a hardware message decoder (Figure5(c)) parses the Type ID and routing metadata of outgoing pack- ets (Section 5.2). This decoder translates high-level mes- sage definitions into physical control signals that drive in- ternal multiplexers: for Type 1 messages, it identifies the single-hop destination port; for Type 2 messages, it locks thepathforthedurationofapacketburst, ensuringcontigu- ous transmission without interleaving jitter. Resource contention arises when multiple MCCs attempt to transmit to the same destination concurrently. Following the first- come-first-served principle inherent to FIFO-based designs [ 60], each input interface is equipped with a dedi- cated counter. If an incoming message request is not ac- cepted by the target FIFO, its counter increments whenever the target FIFO attempts to fetch messages. During each arbitration cycle, the selector evaluates all active requests and grants priority to the message with the largest counter value—indicating the longest waiting time—pushing it into the input FIFO. Once transmission begins, the correspond- ing counter is reset. This policy serves as a critical anti- starvation mechanism, preventing indefinite delays in state updates. An ablation study comparing the proposed arbitration pol- icy with conventional Round-Robin and random-selection schemes is presented in Figure5(d). The simulation config- ures8input-outputFIFOpairs,eachwith1,000packetsdes- tined for randomly chosen targets. For the evaluated PSC tasks like MARL, long latency tails directly impact sequen- tial processing speed and MCC stalling time; thus, we com- pare the latency at the 99th percentile (P99 latency) across the three policies. With the simulated packet sending rate (x-axis) increase, the P99 latency (y-axis) increases to sat- uration. This demonstrates that the first-come-first-served policy reduces the tail latency by 6.26% to 41.8% depend- ing on packet generation rate, confirming the effectiveness of the selected design. 5.4Global Neighboring Connection Following the same design philosophy of Section5.2 and5.3, we decouple timing constraints across the MCHA 7 RISC-V Core Input FIFO Output FIFO Data Storage SRAM FIFO Address Data Address Read Write (a)(c) (d) (b) 28 TYPE ID 000~101 31 Target 3b Payload 24b 292724250 1 Type 1: TYPE ID 110~111 31 Length 2b 2928272612 Dest. Addr. 14b Payload 13b Payload 32b Payload 32b Payload 32b 130 Type 2: Header Packet Data Packets Input FIFO Output FIFO Message Decoder Waiting Counter Activate Target Counter MUX MAX INDEX Pop Signal P99 Latency (10 3 Cycles) Packet Sending Rate (# / Cycle) 0.20.30.40.50.60.70.8 0 1 2 3 4 5 6 7 Ours Round Robin Random Figure 5:(a) MCC Message management method; (b) Message Packet Definition; (c) PB transmission strategy; (d) Ablation study comparing the P99 latency with other routing methods. HST_S Request HST_R Acknowledge Receiver HST_R HSR_R Sender HST_S HSR_S (a)(b) Time Time Phase 1Phase 2Phase 3Phase 4 Start End HST_S HST_R Figure6:(a)Portdefinitionfor1internalconnectorpair(b)Timing diagram of the connectors in (a) with an asynchronous network between neighboring PBs to achieve independent, self-governing execution. This allows each PB to operate within its own independent clock do- main, reducing global clock distribution complexity and mit- igating peak power surges. As shown in Fig. 6, inter-block data transfers (e.g., Block A to Block B) are governed by a robust 4-phase asynchronous handshake protocol: Phase 1.Request: TheprotocolbeginswithBlockAdriving itshandshakesendingport(HST_S)hightosignal a request. Phase 2.Acknowledgement: Upon detecting this request, Block B responds by driving its acknowledgement port (HST_R /HSR_S) high. Phase 3.Clear Request: Block A then clears its request sig- nal and reset HST_S to “0”. Phase 4.Clear Acknowledgement: After which Block B clearsitsacknowledgement,completingthecycle and freeing the channel for the next transfer. This lightweight handshake acts as a hardware-level flow control, ensuring data residency and integrity across the meshevenwhenneighboringblocksoperateatdifferentfre- quencies or states. When scaling to multi-chip systems, MCHA extends its 2D-mesh communication protocol across chip boundaries using high-bandwidth interconnects such as PCIe [ 57] or UCIe [58]. These system-level links maintain information transparency, enabling a distant core on a remote chip to be accessed via the same asynchronous handshake strat- egy. Consequently, MCHA provides a modular and scalable fabric capable of supporting PSC across multiple chips. 6System Deployment and Mapping Strategy This section elaborates how to maximize the communica- tion efficiency of the multi-tiered NoC and the parallelism of MCCsthroughtheformulationofalgorithmsalongwiththeir deployment strategies on the MCHA platform.Figure7(a– b) illustrates the programming and deployment workflow of MCHA with a representative program example, matrix pro- cessing A·(prod(B))−C, whereprod() computes the prod- uct of all numerical elements in a matrix. 6.1Collective Usage of MCC Buffers Since MCHA enables high independence to the MCCs, the management of the on-chip memory and workload varies from the conventional systems. Instead of allocating spe- cific tasks to different cores, MCHA maps computational entities to cores based on the memory footprint of their state data (x n i in Algorithm1). Only cores that control this data can modify it; others can either read the data or send write requests to these cores. Compared with threads in a GPU that are assigned to specific operations each time (Figure7(c–d)),coresinMCHAperformdifferentoperations based on memory types to parallelize the irregular data ac- cess, namelyT data−transfer in PSC workloads. As pre- sented in Figure7(a), Core 0 and 2 are responsible for loading the data of matrices A and C, acting as the entity buffer. When the state data size surpasses the capacity of on-chip SRAM, only the necessary indices for accessing off-chip DRAM are maintained in SRAM, as Core 0 index- ing data of vector A in Phase 1. By organizing these index structures in alignment with the underlying hardware topol- ogy (e.g., arrange the elements of A and C alternately in the DRAM), we convert the serialized and irregular mem- ory access characteristics of traditional paradigms into pre- dictable, parallelized local transactions. Consequently, the most frequently accessed variables remain physically co- located with the corresponding processing logic, thereby eliminating the “memory wall” at the architectural level. 6.1.1Locality-Aware Entity Clustering To filter local data transfers through the multi-tiered NoC, thereby minimizing communication overhead in the 2D- mesh, the mapping process prioritizes computational local- itybyassigningneighboringentitiestothesameMCCorad- jacentcoreswithinaPBbasedontheirinteractionfrequency. For PSC workloads, we can use clustering [ 61] or graph- partitioning [ 62] algorithms to group entities with overlap- pingneighborsets(N i inAlgorithm1),thusmaximizingdata reuse within local SRAM banks.In the provided example, thisprocessisrepresentedasplacingthethreecoreswithin the same PB. As the neighbor setsN i evolve during task execution, e.g., due to agent movement necessitating inter- core communication, MCHA supports periodic entity migra- tion, with frequency and strategy tailored to the task. In complexenvironmentssuchasMulti-AgentParticleEnviron- 8 ments(MPE)[63,64]orStarCraftmaps[49], theMARLsim- ulation space is initially partitioned into blocks (Figure7(e)). Throughout sequential steps in PSC patterns, these block boundaries are dynamically adjusted based on local agent density, rebalancing computational load and ensuring con- sistent architecture-wide performance. 6.1.2Systolic Mapping for Complicated Update Functions When processing computationally intensive update functionsf, such as deep neural network inference, T data−transfer is embedded in the data sharing between collaborating MCCs. Workloads requiring frequent com- munication, for example, the lookup-table of non-linear functions and corresponding input generatos, are imple- mented within the same blocks. Others are spread across the system according to the dataflow structure, formulating a systolic array. For example, in Figure7(a–b), Core 1 acts as the buffer of intermediate results for computing A·(prod(B)). Applying an input-stationary systolic map- ping [ 65], these cores first store the input data (A in this example) and then, triggered by the completion of input transmission, network weights (B in this example) are streamed through these MCCs while previously prepared input data remain stationary in local SRAM. By sequencing weights according to input channels, the architecture can skip null-value operations and support sparsity-aware computation. In detail, MCHA MCCs demonstrate this process through 2 continuous phases, one for temporal buffering (Phase 1 of Core 1), the other for data indexing and computing (Phase 2 of Core 1). The completion of the input transmission acts as the Phase Change Trigger of Phase 1, changing the core to the computing phase, where data indexing of B is default. The core then performs operations according to pre-defined instructions (prod in this example, multiply-and-accumulate for neural net- works), triggered by the arrival of indexed data. Figure 7(f) illustrates the systolic mapping of a 2-layer Neural Network (N) in MCHA. The blue cores (labeled as N-L1) store the data generated in the Parameter Gather process, namely the input data of the first N layer, acting as intermediate buffers (a similar role as Core 1 in Figure 7(b)). This spatial unrolling prevents computationally dense transformation phases from becoming bottlenecks, thereby maintaining the efficiency of the data-driven computing flow. 6.2Data-Driven Programming Model Implementation by RISC-V ISA The reconfigurability of MCHA is demonstrated through the programmabletriggeringlogicbasedonstandardRISC-Vin- struction set (RV32I as an example). The ISA execution of each MCC is governed by the state of the FIFOs and local SRAMconditionsthrough4differenttriggersintheprogram- ming model at each stage. (e) (c) (a) (d) (b) Inital Partition t Steps Border Migration (f) MCC PB Gather & Update N-L1N-L2 Systolic Flow cudaMemcpy(DRAM, B) vecProd<<<1,3>>>(B, D) cudaMemcpy(DRAM, [A, C]) vecScalProd<<<1,3>>>(D, A, E) vecMinus<<<1,3>>>(E, C, F) cudaMemcpy(F, DRAM) In = ReadFIFO() Phase 1: if MemSize()==3: goto Phase 2 # Comp elif In is None: WriteFIFO(A_addr, DRAM) else: WriteMem(In) # Memory Phase 2: if HandShake(): WriteFIFO(A, Core1) goto Phase 3 # Halt elif In is not None: RecvHandShake(In) Phase 1: if MemSize()==3: goto Phase 2 # Comp elif In is not None: WriteMem(In) # Buffer Phase 2: if Count==3: WriteFIFO(Shake, Core0) goto Phase 1 # Cycle elif In is not None: WriteMem(P * In, Core2) Count += 1 else: WriteFIFO(B_addr, DRAM) ... Phase 2: ... if In is not None: WriteFIFO(In - C, DRAM) Count += 1 B 1 B 2 DB 3 A 1 A 2 A 3 P 1 P 2 P 3 C 1 C 2 C 3 B 1 B 2 DB 3 B 1 B 2 DB 3 A 1-3 B 1-3 A 1 C 1 DE 1 A 2 C 2 DE 2 A 3 C 3 DE 3 A 1 C 1 F 1 E 3 A 2 C 2 F 2 E 3 A 3 C 3 F 3 E 3 E 1-3 F 1-3 Core 0 Thread 0 Cache Line Thread 1 Thread 2 Core 1Core 2 Core 0 Core 1 Core 2 MCHA MCHA GPU GPU B 1 B 2 B 3 B 1 B 2 B 3 A 1 A 2 A 3 C 1 C 2 C 3 B 1 B 2 B 3 A 1 A 2 A 3 C 1 C 2 C 3 Figure 7:(a)A program forMCHA; (b) Conceptual dataflow of (a); (c) Program using CUDA; (d) Conceptual dataflow of (c); (e) In- processupdateenabledby2D-mesh;(f)On-chipsystolicfunction demonstration; 6.2.1MMIO-Based FIFO Interaction By leveraging the MMIO FIFOs described in Section5.1, sending and receiving data in MCCs reduces to standard RISC-VLW(Load Word) andSW(Store Word) instructions. This decouples communication from computation, allow- ingeachMCC’sprocessingpipelinetoremainuninterrupted and transmission latency to be effectively hidden. (a) When a compiledSWinstruction targets the output FIFO address (WriteFIFO), the hardware pushes the 32-bit payload into the transmission queue. To prevent data loss, if the FIFO is full, the hardware interface stalls the pipeline or main- tains the value in the register file until a slot becomes avail- able, similar to the behavior of memory handshake in con- ventionalSWoperations. Crucially, the ISAs ensure atomic transmission;onceamulti-packetmessage(Type2)begins, the hardware locks the port to ensure the packets are trans- mitted contiguously without interleaving jitter. (b) AnLWin- structiontargetingthe inputFIFO ( ReadFIFO)pops the front- most 32-bit packet. To enable high-speed triggering, the hardware utilizes a zero-signature mechanism: if the FIFO is empty, theLWreturns a 32-bit “0”, which triggers the De- fault Memory Scan if it exists. Conversely, if a valid packet is present, the protocol guarantees that at least one bit is non-zero (bit 28 for Type 1 or bit 31 for Type 2, as shown in Figure 5(b)). 6.2.2Control Flow Instruction Mapping As presented in Figure7(a), each time MCC is idle, it will read the address corresponding to the input FIFO if Input Trigger is not empty and check all the other triggers. Thus, the basic structure of the program at each phase is a loop, which repeats the data detection process until jumping into otherphases. The4triggeringconditionsareaccomplished by RISC-V branching instructions, as demonstrated by the 9 Table 1:Design Parameters for Large-Scale Simulation PartParameterValue MCC Memory Size (KB)1 Pipeline Parallelism1 FIFO Buffer8 Processing Throughput (GFLOPS/Core) 1.6 PB Edge Connector4 DRAM Connector1 Number of Cores4 Connector Bandwidth (GB/s)1024 MCHA External Connector4 DRAM Access Parallelism16 Number of Blocks16 External Connector Bandwidth (GB/s) 64 DRAM Access Bandwidth (GB/s)409.6 if statement in Figure7(a), allowing the core to react to the memoryfabricinreal-time. (a)Memory&PhaseConditional Triggers: These two kinds of triggers rely on reconfigurable data statistics stored at pre-programmed addresses within the local SRAM. By periodically reading these status vari- ables,theRISC-Vbranchlogicdeterminesifthecoreshould handle special operations or switch functional phases. (b) Input Trigger: By executing anLWfrom the input FIFO fol- lowed by a conditional branch, such asBNE, the core can immediately detect incoming data. If the result is non-zero, the Program Counter (PC) jumps to the corresponding pro- cessing function. (c) Default Memory Scan: If anLWfrom the input FIFO returns zero (empty FIFO), the core can de- fault to a memory scan. This is managed via a scan pointer maintainedintheregisterfile,whichincrementallytraverses the local SRAM to check for a response. Ultimately, every functionaltriggerintheMCHAmodelisrepresentedasaPC jump to a specialized firmware routine. By mapping the pro- gramming model components into existing RISC-V instruc- tions, MCHA introduces minimal efforts for ISA construc- tion. 6.3Dataflow-Defined Workload Assignment TomaximizeMCHAthroughput,theassignmentofthework- loads should involve identifying essential reactive elements and mathematically modeling throughput requirements to determine the optimal pipeline depth for the target comput- ing tasks. 6.3.1Functional Requirements for Data-Driven Programs Similartoobject-orientedprogramming,theMCHArequires programmerstobreakthetargetalgorithmintomultiplestat- ically defined phases. The 4 types of triggers of a specific phase act as the member functions of an object. The pro- grammer should define Phase Conditional Trigger, which servesastheterminationconditionforacomputationalloop, analogoustoloop-exitlogicinconventionalparadigms. Fur- thermore, each phase must include at least one definition of an Input Trigger or a Default Memory Scan to dictate the specific operations dominating that phase (WriteFIFOand WriteMemin Figure7(a) for Core 0). If neither is defined, the MCC becomes a “zombie” core, because it lacks both ex- ternal stimulus responses and autonomous self-activation. The transmission from the conventional programs to MCHA ones can be accomplished with the help of Large Language Models (LLMs). We provide an example that transforms a neural network to MCHA programs in C++ with the help of Deepseek-R1 [66] in thinking mode in our github (https: //github.com/carabdis/MCHA/LLM.md). The program must explicitly include handshake signal gen- eration to manage the flow of data across the pipeline, en- suring that residency is maintained without causing mesh- wide stalls.As presented in Figure7(a), Phase 2 of Core 0 and 1, the explicit handshake acts as the data barrier for the serialized part in PSC workloads. 6.3.2Analytical Deployment and Throughput Matching After decoupling the PSC workloads into serialized phases, the deployment of the algorithm can be defined as a flow matching problem. We provide a 3-step analytical process to deploy a program onto MCHA fabric to balance the work- load across the system. Step-1 Throughput Extraction: The processing characteris- tics of MCC can be described through two critical metrics, consumption rateR pop i and production rateR push i .R pop is defined as the average cycles required for a core to pop and parse a 32-bit input packet from the input FIFO.R push is defined as the average cycles required for the core to com- putetheassignedworkloadandpushtheresultingpacketto the output FIFO. Thus, the goal is to match the ingress and egress rates of each stage in the pipeline.For example, ne- glectingtheDRAMaccesslatency,Core0inFigure7(a)gen- erates1outputpacketpercycleinPhase2,namelyR push 0 = 1. Core 1 consumes the 1 input packet from Core 0 every 3 cycles to compute the intermediate results of A·(prod(B)), thusR pop 1 = 1/3. Step-2IdealPipelineDerivation: Undertheassumptionofin- finite hardware resources, the ideal parallelized core count for each phase (N ideal i ) required to achieve a non-blocking pipeline without hardware waste is derived from the ratio of these rates. To maintain a steady state where FIFOs nei- theroverflownorstarve,theflowbalancebetweenserialized phases is defined as: N ideal i ∗R push i =N ideal i−1 ∗R pop i (4) In our example, sinceR push 0 = 1andR pop 1 = 1/3, the ideal ratioN ideal 0 :N ideal 1 is1 : 3. This ratio determines the quan- titativerelationshipbetweenMCCsoperatinginneighboring phases,minimizingunnecessarydatamovementofinterme- 10 Table 2:The power and area breakdown of MCHA PartComponent Area (m 2 ) Area (%) Power (mW) Power (%) MCC SRAM0.030382.780.496841.40 FIFO0.00061.640.07065.88 RISC-V Core0.004412.020.491340.94 Control0.00133.550.141211.78 Total (MCC)0.0366-1.2000- PB MCC0.146494.574.800076.78 Control0.00845.421.451423.21 Total (PB)0.1548-6.2514- MCHA PB2.476884.80100.022486.70 Ext. Connector 0.05601.921.93521.68 Int. Connector 0.387813.2813.401811.62 Total2.9206-115.3594- diate results. Step-3 Realistic Constraint Scaling: Given a fixed physical scale, the deployment logic determines the maximum num- ber of concurrently active phasesM max para . Due to memory structural hazards—where buffering and computation can- not occupy the same SRAM bank simultaneously—parallel phases must be interleaved with idle or buffering phases or employ twice the memory capacity via ping-pong buffering. The algorithm computesM max para ≥1based on the minimum buffer cores required per phase. In the former example, if phases require1,2,1memory cores forM para = 2, but only 3 cores are available, thenM max para = 1. Starting from M max para , the system iteratively reduces the number of active phasesuntilmemorycapacityconstraintsaresatisfied. This scaling ensures robustness across implementations, from single-chip edge devices to large-scale multi-chip fabrics. 7Evaluation 7.1Experimental Setup To evaluate the performance and efficiency of large-scale MCHA architecture, we developed a cycle-accurate simula- tor. ThissimulatorisdirectlyextractedfromRTLVerilogHDL implementation,includingMCCs,PBs,on-chip2D-meshde- sign, and the chip-wise connectors. The chip-wise connec- torsdemonstratedintheVerilogcodeareSPIconnectorsas a research prototype, which are replaced by parameters of commercial PCIe 4.0 in the simulator. Other hardware pa- rameters are modeled based on logic synthesis results us- ing TSMC 28nm PDK at 200MHz .Detailed parameters of one MCHA chip using in the simulator are in Table1. The corresponding area and power overhead of our implemen- tation are given in Table 2. To verify MCHA, we compare the performance of the MCHA system composed of 4 (MCHA-4) and 32 (MCHA-32) chips to various kinds of DSAs and generalized GPUs. NVIDIA A100 GPU is used as the baseline for massive-scale par- allel workloads with flexibility.PEARL [67], ActiveN [68], MC 2 A [69], Dalorex [70], and PolyGraph [19] are chosen as the specialized accelerators for different benchmarks. The evaluation covers three distinct domains, highlighting MCHA’s ability to handle various types of programs: (1)MARL: a comprehensive suite including MPE Simple Spread[63],StarCraftII(SMAX)[49],SwitchRiddle[50], andSTORM[51,52]. Performanceiscomparedagainst JAX-MARL [49] running on A100 or RTX 3090 and PEARL [67]. For each environment, we measure the average processing speed of the baselines computing 1,000 timesteps. The number of agents existing in these environments is fixed as 1,000, to manifest the ef- ficiency in large-scale MARL computation. To ensure a fair comparison, the MCHA implementation utilizes the same hyperparameters as the JAX-MARL demon- strations,includingneighborhoodsizeN i ,actionspace, and update functionsf i . (2)Large-Scale Neuromorphic Computing: The bench- markisa2%MVC(MotorVariableControl)nervoussys- tem model [71], which follows the setup established by ActiveN[68], testing the architecture’scapabilitytohan- dlesparse,high-frequencyspikesanddeterministictim- ing. (3)Typical BSP for Graph Processing:We evaluate MCHA ’s performance on regular data access patterns using PageRank [72], BFS [73], and Markov Random Field (MRF) image segmentation [74], compared with exist- ingDSAs(MC 2 A[ 69], PolyGraph[19], andDalorex[70]) and GPUs [ 19,69,75,76].The evaluation uses the orkutgraph [ 77] when comparing PageRank and BFS against PolyGraph [19], and theRMAT-26graph [78] when comparing against Dalorex [70]. MRF image seg- mentation input data follows [74]. For the above workloads, MCHA matches the algorithmic setup of every corresponding baseline [19,49,68–70] in numerical precision, task size, step definition, and conver- gence condition. 7.2End-to-End Computing Throughput 7.2.1Multi-Agent Reinforcement Learning (MARL) Figure8(a) compares the absolute execution time (y-axis) of different hardware (x-axis), including MCHA (M1, M2), GPUs (G1–G2), and FPGA (F1). The presented throughput time is measured end-to-end including data off-loading and data processing.MCHA-4 delivers 153.06×to 2456.96× speedups versus GPU-accelerated frameworks. MCHA-32 further achieves 1.22∼4.25×speedup over MCHA-4. This performance leap stems from the elimination of redundant global memory copies due to frequent cache coherence and overfetch in GPUs. Furthermore, the high data locality 11 achievedinMCHAinturnremovesmostoftheirregulardata access to DRAM, thus improving the overall performance. Compared to PEARL (F1), MCHA-4 achieves a speedup of 2.28×to 4.78×. This performance gain is primarily at- tributed to the data-driven adaptivity inherent to the MCHA architecture,whichmasksdatatransmissionlatencyacross the multi-tiered NoC. Furthermore, MCHA-4 eliminates the significant communication overhead typically associated withdatatransfersbetweenexternalGPUsandtheFPGAfab- ric, streamlining the execution of PSC workloads. 7.2.2Large-Scale Neuromorphic Computing Figure8(c)shows the comparison results benchmarking MCHA (M1, M2), neuromorphic accelerators (AN, NE, Loihi) [2,68,79] and GPUs (G1, G2, G4). MCHA-4 shows 5.36×improvement over the neuromorphic-specific accel- erators [2,68], completing a single task in 0.7842s, while the MCHA-32 presents 39.996×speedup. When compared with ActiveN, MCHA-32 performs 1.175×speedup with 9.36% power consumption, presenting the high efficiency of MCHA originating from the data-driven nature. Further- more, the near-linear performance improvement between MCHA-4 and MCHA-32 originates from the high spatial lo- calityachievedbythecommunicationstrategy(moredetails are investigated in Section 7.3.3). 7.2.3Typical BSP for Graph Processing Figure8(a), (b)&(d)presents the results. MCHA presents comparable results versus various DSAs for these applica- tions. Compared with general-purpose GPUs for BSP tasks, MCHA-32 achieves 86.69×, 3.93×, and 4.56×speedup, re- spectively, while MCHA-4 also presents comparable perfor- mance. WefurthercompareMCHAwithDalorex[70],whose 256 cores match the compute-unit count of MCHA-4 (“M2” in Figure8). M1L and M2L denote M1 (MCHA-32) and M2 (MCHA-4) with on-chip memory scaled to 4.2,MB/core to match Dalorex’s configuration, respectively. In their origi- nal setup (M1 and M2), MCHA shows little advantage over Dalorex; however, M1L achieves a 5.66∼7.28×throughput improvement, and M2L reaches throughput comparable to Dalorex. This gap is explained by DRAM access overhead: Dalorex’s model excludes DRAM latency, whereas MCHA’s includes it. On the RMAT-26 [ 78] dataset, DRAM accesses consume 81.42% of M1’s execution time under the original 1KB/core configuration — an overhead largely eliminated by the enlarged on-chip memory in M1L. ThelowerspeedupofBSPimplementationsrelativetoMARL and MVC stems from differences in arithmetic intensity across the workloads. The most informative metric is the bandwidth utilization rate. In the BSP-MRF task, the per- formance ratio between MCHA-4 and the GPU (0.61) is close to the ratio of their respective DRAM bandwidths (0.67). This correlation proves that MCHA-4 maintains Table 3:The memory footprint of MCHA-4 Benchmark Core Memory Ops (MB) Intra- Block (MB) Inter- Block (MB) Inter- Chip (MB) DRAM Ac- cess (MB) MPE Simple Spread 211.900146.15267.3180.0000.092 Switch Riddle 102.35564.16130.6850.0000.035 Starcraft1044.362461.526141.6670.8540.139 STORM158.167107.37540.6454.3780.077 10 1 10 2 10 3 10 4 10 5 Steps / s (a) (c) Speed Up 10 0 10 1 10 2 M1 113.6 AN 96.6 NE 12.2 Loihi 2.8 G2 1 G1 0.78 G4 0.29 M2 15.2 MARL BSP GTEPS 10 1 10 2 10 0 M1M2 F1 G1G2 M1M2 F1 G1G2 M1M2 F1 G1G2 (d) 10 -1 10 0 10 1 Speed Up M1 4.56 M2 0.61 MC 2 A 1.17 G3 1 AIA 0.20 PGMA 0.13 XC 0.06 M1M2 F1 G1G2 M1M2 P1 G1G2 M1M2 P1 G1G2 MPE Simple Spread Switch RiddleStarcraft STORMPageRankBFS M1: MCHA-32, M2: MCHA-4, M1L: MCHA-32 w/ more SRAM, M2L: MCHA-4 w/ more SRAM, F1: FPGA-Gym, P1: PolyGraph, AN: ActiveN, NE: Neuro Engine, G1: A100, G2: RTX3090, G3: RTX 2090 Super, G4: TitanX, XC: Xeon CPU, DA: Dalorex, T: Tesseract, MO1: MCHA w/o asynchronous communication, MO2: MCHA w/o mulit-tiered NoC, MO3: MCHA w/o data-driven model, MO4: MCHA w/o 2D-Mesh, PR: PageRank, SM:SMAX 10 0 10 2 10 4 (e)Speed Up M1 MO1MO2MO3G1MO4G3 MRFMVCPRSMMRFMVCPRSMMRFMVCPRSMMRFMVCPRSMMRFMVCPRSMMRFMVCPRSM Baseline Contribution Percentage (%) (f) 20 40 60 80 SMAX 30.2 25.6 35.5 PR 39.4 18.9 29.5 MVC 36.5 20.2 31.9 MRF 35.1 26.0 36.3 MO1MO2MO3MO4 M1L M1 M2L M2DA T M1L M1 M2L M2DA T 10 1 10 2 10 0 (b) GTEPS PageRankBFS Figure 8:The speedup compared with the existing (a) MARL and BSP; (b) more BSP;(c) MVC; (d) BSP-MRF accelerators.(e) The ablation study of MCHA-4. (f) The detailed contribution of differ- ent characteristics of MCHA. a near-optimal bandwidth utilization rate in regular data processing tasks, while also presenting the drawbacks of MCHA on computing-intensive tasks because of the limited scale. Figure8(e) and (f) present an ablation study of MCHA-32, starting from a bus-based architecture and incrementally addingonefeatureatatimeuntilreachingthefullMCHAde- sign. Each feature’s contribution is quantified by the latency reduction it yields over the bus-based baseline on a given workload. Theresultsshowthatthebulkofthespeedupover GPUs stems from the multi-tiered NoC and the data-driven model proposed by MCHA, with the asynchronous commu- nication strategy providing additional gains. This break- down confirms the effectiveness of MCHA’s core tenets, i.e., data localization and data-driven programming. 7.3Architectural Analysis To elucidate the fundamental reasons for the observed MCHA performance gains, we explore the architectural de- sign space and profile the benchmark. We first examine the simulation results of the end-to-end throughput measure- 12 ment and find the components of the processing time of MCHA-4.We also provide the memory footprint of MCHA- 4 on MARL workloads.Based on these analyses, we for- mulate a customized roofline model, establishing the op- erational upper bounds for MCHA. Utilizing this model, we examine the scalability characteristics of MCHA to identify the structural features that enable near-linear performance growth across increasing core counts and the variation of speedup factor between MCHA-4 and MCHA-32 in different cases. Further, we conduct a sensitivity analysis, quanti- fying how variations in multi-level interconnect bandwidths andRISC-Vcomputeintensity,asdetailedinTable1,impact the end-to-end throughput of PSC applications. 7.3.1Computing Intensity Analysis Figure9shows the results of profiling runtime operational types for MCHA-4. The x-axis is the execution time.The y-axis shows the operational intensity in percentage: “com- pute”forcomputation,“memory”formemoryI/Oaccessop- erations, “Comm.” for the three types of NoC operations. A key insight from this breakdown is that these workloads are overwhelmingly communication-dominant.Intra-block and inter-block data movements constitute 57.3%∼69.1% of operational cycles, which underscores why conventional GPUsstrugglewithPSCtaskswiththedetailedmemoryfoot- printsofMCHAinTable 3. LackinganefficientP2Pfabricfor inter-core data exchange, GPUs force high-frequency trans- missions through the global memory hierarchy.This can be illustrated by profiling the MPE Simple Spread benchmark on an RTX3090 with Nsight Systems. The essential data per agent amounts to 8 bytes, comprising the weight vec- tor (hidden dimension 64) and the environment state. As shown in Figure 9(a), the total off-chip memory traffic of the RTX 3090 running MPE Simple Spread with 1,000 agents over 1,000 steps is 14.88×larger than that of MCHA-4, a disparity driven by cache-coherence traffic across L2 cache lines. ThereasonMCHA-4’sdataaccessstillexceedstheap- plication’s essential working set is the four-fold replication of the neural network, stored once per chip. Nevertheless, MCHA-4’s multi-tiered NoC preserves data locality and by- passes off-chip memory and the global buffer. Compared to the GPU computing intensity in Figure1(d) in Section1, where DRAM access accounts for 78.9% of the total opera- tions, DRAM traffic in MCHA occupies only 2.26%∼5.44%. ThissignificantreductionvalidatesthatMCHA successfully transformsglobalmemorybottlenecksinto localizedon-chipdatatraffic. To further demonstrate the efficacy of the MCHA architec- ture, we compare the throughput of MCHA-32, MCHA-4, and an NVIDIA A100 on MARL workloads after factoring out GPU software framework overhead. Even after this nor- malization, MCHA-32 still achieves 4.01∼21.93×speedup. This overhead originates predominantly from XLA [ 80] just- in-time compilation, which, though intended to optimize 0.0 0.0 0.2 0.4 0.6 0.8 0.020.040.060.080.10 Intensity (10 -3 %) Active Cumulative Time (ms) (c) MemoryComputeInter-Block Comm.Inter-Chip Comm.Intra-Block Comm. Intensity (10 -3 %) (e) Active Cumulative Time (ms) 0.00.050.100.150.200.250.300.35 0.0 0.1 0.2 0.3 0.4 0.010.020.030.040.05 0.0 0.5 1.0 1.5 2.0 Intensity (10 -3 %) Active Cumulative Time (ms) (d) 0.0 0.4 0.8 1.2 0.010.020.030.040.050.06 Active Cumulative Time (ms) Intensity (10 -3 %) (f) MCHA-4 94.8 KB RTX 3090 1410.6KB (a) Throughput (Steps/s) MPE Simple Spread Switch Riddle StarcraftSTORM 10 -1 10 1 10 3 10 5 10 7 M1M2 GO1 G1 M1M2 GO1 G1 M1M2 GO1 G1 M1M2 GO1 G1 GO1: GPU exclude software framework (b) Essential Data 29.6KB Extra Data 97.9% 68.8% Figure 9:(a) The total data movement of MCHA-4 and RTX3090. (b)ThethroughputofMCHA-32,MCHA-4andA100GPUwithand without the software framework time costs.The computing inten- sityof(c)MPESimpleSpread,(d)SwitchRiddle,(e)Starcraft,and (f) STORM of MCHA. 10 -2 10 -1 10 0 10 1 10 2 10 3 10 4 10 -1 10 -0 10 1 10 2 10 3 10 4 Arithmetic Density (FLOP/Byte) Throughput (GFLOPS) A100 MCHA-4 Peak Throughput Intra-Block Comm. Inter-Block Comm. DRAM Access Inter-Chip Comm. MPE Simple Spread Starcraft Switch Riddle STORM Figure 10:Roofline model analysis for MCHA-4 and A100. 10 3 10 4 Throughput (Steps / s) 1020408016032064012802560512010240 Number of Agents (a) (b) MCHA-16MCHA-32MCHA-4MCHA-8 10 3 10 4 Throughput (Steps / s) 10204080 160320640 128025605120 10240204804096081920 Number of Neurons Figure 11:The scale-up effect of (a) SMAX (b) MVC. memory-bound workloads, consumes 97.5%∼99.79% of total GPU execution time. Such a stark imbalance under- scores the advantage of the proposed data-driven program- ming model: it statically determines the instruction sched- ule from the base algorithm while sustaining high hardware utilization. The overlap of computation and data movement further validates the model’s ability to hide transmission la- tency within the pipeline. 7.3.2Roofline Model Analysis Figure10shows the roofline models for MCHA-4 and A100. Unlike conventional GPUs, which are typically bounded by a single global memory bandwidth (as shown in Figure1(a)), MCHA exhibits a tiered execution profile characterized by 4 bandwidth limits. While the hierarchy of these bandwidth limits is fixed by the hardware design, the actual through- put bottleneck is dynamically determined by its specific al- gorithmic dataflow. For example, STORM and Switch Rid- 13 dle workloads are constrained by the Intra-Block Commu- nication bandwidth. Though the limitation is slight, this suggests that their high-frequency agent interactions sat- urate the local communication bandwidth before reaching the MCC’s compute limits. The remaining workloads are limited by the MCC computing throughput, operating within the bandwidth headroom provided by MCHA-4. This diver- gence emphasizes the key role of the memory-centric na- ture of the proposed data-driven programming principles. Bystrategicallyorganizingtaskstomaximizedataresidency, MCHA minimizeshigh-latencytransmissionsandshiftsthe operationalpointtowardthecompute-boundregionfor higherthroughput. 7.3.3Scaling-Up Effect The architectural scalability of MCHA is fundamentally driven by its high spatial and temporal locality. Workloads with spatially organized neighborhood definitions, such as large-scale maps containing thousands of agents, are parti- tioned using a dynamic border strategy, as illustrated in Fig- ure7(e). This allows the workload to be distributed across MCCs while maintaining data residency. Conversely, for graph-based neighborhood topologies, a min-cut partition- ingalgorithmcanbeimplementedtodecomposetheglobal graph into localized sub-graphs. In this configuration, inter- sub-graph edge data is temporarily buffered in DRAM, en- suring that the high-frequency internal processing remains localized within the on-chip mesh. Figure 11presents the scaling-up characteristics of the MCHA hardware across varying workload sizes and hardware scales, using SMAX andMVCasthebenchmark. Thepersistentparametersand corresponding entities are spread evenly on the hardware for specific comparison. Figure 11(a) shows that at small agent counts (10 to 40 agents in SMAX), the system throughput remains relatively constant. This phenomenon occurs because the primary overhead of the execution at this time is not the compute in- tensity or communication volume, but the pipeline latency required to complete the initial dataflow sequence. As the agent population grows, the dominant bottleneck shifts from pipeline latency to compute and transmission through- put. In this regime, the processing time increases propor- tionallywiththenumberofagents. Additionally,Figure 11(a) also shows that the accelerating rates of MCHA-32 com- pared with MCHA-4 vary when the benchmark scale is dif- ferent. This is because the even distribution of the agents in the hardware leads to performance limits originating from the Inter-Chip Communication. Similar trends can be ob- served from Figure 11(b) for the MVC benchmark. Compar- ingFigure 11(a)with(b),for2%MVCbenchmark,MCHA-32 achieves7.47×speedupcomparedwithMCHA-4,whilethis ratiodecreasesto 3.85×for SMAX, including 10240 agents. The reason for this phenomenon is that the arithmetic den- sity of SMAX is higher than that of the MVC with a reinforce- MCC ThroughputIntra-Block Bandwidth Inter-Block Bandwidth global DRAM Bandwidth Inter-Chip BandwidthComputing Latency Throughput (GFLOPS) 10 4 10 3 10 2 10 1 10 0 10 -2 10 -1 10 0 10 1 10 2 10 3 10 4 (a) Arithmetic Density (FLOP/Byte) Changing Direction 0 20 40 60 80 Latency (10 3 Cycles / Step) 6.412.825.651.2102.4 Lower is Better (b) MCC Throughput (GFLOPS) Changing Direction (c) Throughput (GFLOPS) 10 -2 10 -1 10 0 10 1 10 2 10 3 10 4 Arithmetic Density (FLOP/Byte) Changing Direction 10 4 10 3 10 2 10 1 10 0 0 100 200 300 400 500 600 Latency (10 3 Cycles / Step) Intra-Block Bandwidth (GB/s) 2304576144369 (d) Changing Direction Lower is Better 0 100 200 300 400 500 600 (f) Inter-Block Bandwidth(GB/s) Latency (10 3 Cycles / Step) 102425664164 Changing Direction Lower is Better (e) Changing Direction 10 -2 10 -1 10 0 10 1 10 2 10 3 10 4 Arithmetic Density (FLOP/Byte) Throughput (GFLOPS) 10 4 10 3 10 2 10 1 10 0 0 100 200 300 400 500 600 (h) Inter-Chip Bandwidth (GB/s) 64321684 Latency (10 3 Cycles / Step) Lower is Better Changing Direction (g) 10 -2 10 -1 10 0 10 1 10 2 10 3 10 4 Arithmetic Density (FLOP/Byte) Changing Direction Throughput (GFLOPS) 10 4 10 3 10 2 10 1 10 0 (j) global DRAM Bandwidth (GB/s) 409.6102.425.66.41.6 0 100 200 300 400 500 600 Latency (10 3 Cycles / Step) Lower is Better Changing Direction (i) Changing Direction 10 -2 10 -1 10 0 10 1 10 2 10 3 10 4 Arithmetic Density (FLOP/Byte) Throughput (GFLOPS) 10 4 10 3 10 2 10 1 10 0 Figure 12:The roofline model and throughput comparison based on different (a–b) MCC throughput; (c–d) Intra-block bandwidth; (e–f) Inter-block bandwidth; (g–h) Inter-chip bandwidth; (i–j) global DRAM bandwidth. ment neural network included as the updating function. 7.3.4Design Space Exploration According to the roofline model presented in Section4, the design space of MCHA can be described by multiple band- widths and computing limits. Figure12shows the influence of varying parameters in MCHA-4 on the roofline models. The varying design parameters cover MCC throughput (a– b) and the bandwidths of Intra-block (c–d), Inter-block (e– f), Inter-chip (g–h), and global DRAM (i–j). Inter-chip band- width and global DRAM bandwidth have the largest impact on the overall effective throughput. This phenomenon can be observed through the slight growth of the processing timebeforearrivingattheturningpointoftherooflinemodel, as the decrease of inter-chip bandwidth and global DRAM bandwidth. Thisindicatesthatthecommunicationbetween different chips or off-chip memory should be controlled in this MCHA architecture, which is straightforward for our de- sign. In other cases, the influence of the parameters on the final throughput is similar to the conventional roofline model. 14 7.4Related Works MCHA vs. Compute-Centric Architectures and Frameworks. While many-core CPUs and GPUs are the current main- stream hardware solution executing PSC tasks, they are doomed to hit the “memory wall” [20–22]. Software frame- works like JAX-MARL [49] attempt to alleviate this through JIT-compiled kernel fusion, yet they are still throttled by rigidhardwarecachehierarchies. ForMARLworkloads,this leads to massive cache coherence overhead, which can consume up to 96% of total operations as shown in Fig- ure1(b). Incontrast,MCHAabandonsGBs,insteadgranting programmers explicit control over a reconfigurable memory fabric through the multi-tiered NoC. MCHA vs. Near-Data Processing. While NDP and Processing-In-Memory (PIM) designs like Tesseract [81] and UPMEM [82] successfully reduce data movement, they are generally tailored for static irregularity, such as PageR- ank [72] or BFS [73] on static graphs. Conversely, PSC is defined by dynamic irregularity with an additional time di- mension, where neighbor relationships change as the algo- rithm progresses. Existing PIM implementations, such as StreamPIM [39], frequently lack the inter-core bandwidth and architectural flexibility needed for the complex phase transitions of these tasks. MCHA bridges this gap by utiliz- ingamulti-layercommunicationstrategyforP2Pentityinter- action that releases the burden of off-chip memory access. MCHA vs. Specialized Accelerators. Accelerators for spe- cific irregular primitives can achieve high efficiency for their targeted kernels, such as pointer-chasing in graph process- ing (Minnow [ 83], GraphR [84]) or sparse-tensor algebra (ExTensor [85]). However, they often lack support for gen- eral PSC tasks, making commercialization challenging with only supporting highly niche computing applications. Fur- thermore, manyDSAsstillrelyonacentralizedglobalbuffer, which becomes a serializing bottleneck as the computing scaleincreases. MCHAdifferentiatesitselfbyproposingthe data-driven programming model, enabling a reconfigurable fabric to support a diverse suite of workloads. 8Conclusion We propose MCHA architecture, which accelerates PSC workloads, a critical paradigm spanning MARL, SNN, and BSP, by enabling P2P communication to relieve the global bandwidth pressure that bottlenecks conventional systems. A data-driven programming model is provided for algorithm deployment. The architecture demonstrates strong data and processing locality, achieving speedups of 153.06×to 2456.96×overA100GPUsinMARLtasksusinga4-chipsys- tem. Itsgeneralityandnear-linearscalabilityarefurthervali- datedthroughmulti-applicationevaluationandrooflineanal- ysis. Twolimitationsmeritmention: (a)MCHAexploitslocal- ity through fixed topologies, leaving highly dynamic graphs unsupported; (b) porting CPU/GPU code to MCHA’s pro- gramming model currently requires manual effort. We envi- sion that advances in workload abstraction and agentic-AI- drivencode-conversiontoolkitswilltogetherunlockMCHA’s full potential. References [1]Norman P Jouppi, Cliff Young, Nishant Patil, David Patterson, Gaurav Agrawal, Raminder Bajwa, Sarah Bates, Suresh Bhatia, Nan Boden, Al Borchers, Rick Boyle, Pierre-luc Cantin, Clifford Chao, Chris Clark, Jeremy Coriell, Mike Daley, Matt Dau, Jeffrey Dean, Ben Gelb, Tara Vazir, Ghaemmaghami, Rajendra Got- tipati, William Gulland, Robert Hagmann, C. Richard Ho, Doug Hogberg, John Hu, Robert Hundt, Dan Hurt, Julian Ibarz, Aaron Jaffey, Alek Jaworski, Alexander Kaplan, Harshit Khaitan, Daniel Killebrew, Andy Koch, Naveen Kumar, Steve Lacy, James Laudon, James Law,DiemthuLe,ChrisLeary,ZhuyuanLiu,KyleLucke, Alan Lundin, Gordon MacKean, Adriana Maggiore, Maire Mahony, Kieran Miller, Rahul Nagarajan, Ravi Narayanaswami, Ray Ni, Kathy Nix, Thomas Norrie, Mark Omernick, Narayana Penukonda, Andy Phelps, Jonathan Ross, Matt Ross, Amir Salek, Emad Sama- diani, Chris Severn, Gregory Sizikov, Matthew Snel- ham, Jed Souter, Dan Steinberg, Andy Swing, Mer- cedes Tan, Gregory Thorson, Bo Tian, Horia Toma, Erick Tuttle, Vijay Vasudevan, Richard Walter, Walter Wang, Eric Wilcox, and Doe Hyun Yoon. In-datacenter performance analysis of a tensor processing unit. In ACM/IEEE Annual International Symposium on Com- puter Architecture (ISCA), pages 1–12. IEEE, 2017. [2]Mike Davies, Narayan Srinivasa, Tsung-Han Lin, Gau- tham Chinya, Yongqiang Cao, Sri Harsha Choday, Georgios Dimou, Prasad Joshi, Nabil Imam, Shweta Jain, Yuyun Liao, Chit-Kwan Lin, Andrew Lines, Ruokun Liu, Deepak Mathaikutty, Steven McCoy, ArnabPaul,JonathanTse,GuruguhanathanVenkatara- manan, Yi-Hsin Weng, Andreas Wild, Yoonseok Yang, andHongWang. Loihi: Aneuromorphicmanycorepro- cessorwithon-chiplearning. IEEEMicro,38(1):82–99, 2018. [3]Gene M. Amdahl. Validity of the single processor ap- proach to achieving large scale computing capabili- ties. In Spring Joint Computer Conference (SJCC), AFIPS ’67 (Spring), page 483–485, New York, NY, USA, 1967. Association for Computing Machinery. ISBN 9781450378956. doi: 10.1145/1465482.1465560. URL https://doi.org/10.1145/1465482.1465560. [4]Peng Chen, Xinyu Zhao, Lina Zeng, Luxinyu Liu, Shengjie Liu, Li Sun, Zaijin Li, Hao Chen, Guojun Liu, ZhongliangQiao,YiQu,DongxinXu,LianheLi,andLin Li. AreviewofresearchonSLAMtechnologybasedon the fusion of LiDAR and vision. Sensors, 25(5):1447, 2025. 15 [5]Yiming Gao, Chao Jiang, Wesley Piard, Xiangru Chen, Bhavesh Patel, and Herman Lam. HgPCN: A hetero- geneous architecture for E2E embedded point cloud inference. In ACM/IEEE International Symposium on Microarchitecture (MICRO), pages 1588–1600, 2024. doi: 10.1109/MICRO61859.2024.00116. [6]Jianye Hao, Tianpei Yang, Hongyao Tang, Chenjia Bai, Jinyi Liu, Zhaopeng Meng, Peng Liu, and Zhen Wang. Exploration in deep reinforcement learning: From single-agent to multiagent domain. IEEE Trans- actionsonNeuralNetworksandLearningSystems, 35 (7):8762–8782, 2023. [7]ThanhThiNguyen,NgocDuyNguyen,andSaeidNaha- vandi. Deep reinforcement learning for multiagent sys- tems: A review of challenges, solutions, and applica- tions. IEEE Transactions on Cybernetics, 50(9):3826– 3839, 2020. [8]Zepeng Ning and Lihua Xie. A survey on multi-agent reinforcement learning and its application. Journal of Automation and Intelligence, 3(2):73–91, 2024. [9]David Beniaguev, Idan Segev, and Michael London. Single cortical neurons as deep artificial neural net- works. Neuron, 109(17):2727–2739, 2021. [10]Carver Mead. Neuromorphic electronic systems. Pro- ceedings of the IEEE, 78(10):1629–1636, 2002. [11]Kaushik Roy, Akhilesh Jaiswal, and Priyadarshini Panda. Towards spike-based machine intelligence with neuromorphic computing. Nature, 575(7784): 607–617, 2019. [12]Youhui Zhang, Peng Qu, Yu Ji, Weihao Zhang, Guan- grong Gao, Guanrui Wang, Sen Song, Guoqi Li, Wen- guang Chen, Weimin Zheng, Feng Chen, Jing Pei, Rong Zhao, Mingguo Zhao, and Luping Shi. A system hierarchy for brain-inspired computing. Nature, 586 (7829):378–384, 2020. [13]Boyao Li, Alexander J Thomson, Houssam Nassif, Matthew M Engelhard, and David Page. On neural net- worksasinfinitetree-structuredprobabilisticgraphical models. In Conference on Neural Information Process- ing Systems (NeurIPS), volume 37, pages 4598–4628, 2024. [14]Marcel Kollovieh, Bertrand Charpentier, Daniel Zügner, and Stephan Günnemann. Expected probabilistic hi- erarchies. In Conference on Neural Information Pro- cessing Systems (NeurIPS), volume 37, pages 13818– 13850, 2024. [15]Shivvrat Arya, Tahrima Rahman, and Vibhav Giridhar Gogate. SINE: Scalable MPE inference for probabilis- tic graphical models using advanced neural embed- dings. In International Conference on Artificial Intelli- gence and Statistics (AISTATS), 2025. [16]JeffreyDeanandSanjayGhemawat. MapReduce: sim- plified data processing on large clusters. Communica- tions of the ACM, 51(1):107–113, 2008. ISSN 0001- 0782. doi: 10.1145/1327452.1327492. URLhttps: //doi.org/10.1145/1327452.1327492. [17]Grzegorz Malewicz, Matthew H. Austern, Aart J.C Bik, James C. Dehnert, Ilan Horn, Naty Leiser, and Grze- gorz Czajkowski. Pregel: a system for large-scale graph processing. In ACM SIGMOD International Con- ference on Management of Data (SIGMOD), SIGMOD ’10,page135–146,NewYork,NY,USA,2010.Associa- tion for Computing Machinery. ISBN 9781450300322. doi: 10.1145/1807167.1807184. URLhttps://doi. org/10.1145/1807167.1807184. [18]Matei Zaharia, Mosharaf Chowdhury, Tathagata Das, Ankur Dave, Justin Ma, Murphy McCauly, Michael J. Franklin, Scott Shenker, and Ion Stoica. Re- silient distributed datasets: A Fault-Tolerant abstrac- tion for In-Memory cluster computing. In USENIX Symposium on Networked Systems Design and Im- plementation (NSDI), pages 15–28, San Jose, CA, 2012. USENIX Association. ISBN 978-931971-92-8. URLhttps://w.usenix.org/conference/nsdi12/ technical-sessions/presentation/zaharia . [19]Vidushi Dadu, Sihao Liu, and Tony Nowatzki. Poly- graph: Exposing the value of flexibility for graph pro- cessing accelerators. In ACM/IEEE Annual Interna- tional Symposium on Computer Architecture (ISCA), pages 595–608. IEEE, 2021. [20]Krste Asanovic, Ras Bodik, Bryan Christopher Catan- zaro, Joseph James Gebis, Parry Husbands, Kurt Keutzer, David A Patterson, William Lester Plishker, John Shalf, Samuel Webb Williams, and Katherine A. Yelick. The landscape of parallel computing research: A view from Berkeley. Technical report, Technical Re- port UCB/EECS-2006-183, EECS Department, Univer- sity of California at Berkeley, 2006. [21]Brian M Rogers, Anil Krishna, Gordon B Bell, Ken Vu, XiaoweiJiang, andYanSolihin. Scalingthe bandwidth wall: challenges in and avenues for CMP scaling. In ACM/IEEE Annual International Symposium on Com- puter Architecture (ISCA), pages 371–382, 2009. [22]Andrei Ivanov, Nikoli Dryden, Tal Ben-Nun, Shigang Li, and Torsten Hoefler. Data movement is all you need: A case study on optimizing transformers. Proceedings of Machine Learning and Systems, 3:711–732, 2021. [23]Martin Burtscher, Rupesh Nasre, and Keshav Pingali. A quantitative study of irregular programs on GPUs. In IEEE International Symposium on Workload Character- ization (IISWC), pages 141–151. IEEE, 2012. [24]Seunghee Shin, Guilherme Cox, Mark Oskin, Gabriel H Loh, Yan Solihin, Abhishek Bhattacharjee, and 16 Arkaprava Basu. Scheduling page table walks for irregular gpu applications. In ACM/IEEE Annual International Symposium on Computer Architecture (ISCA), pages 180–192. IEEE Computer Society, 2018. [25]Raghu Prabhakar, Yaqi Zhang, David Koeplinger, Matt Feldman, Tian Zhao, Stefan Hadjis, Ardavan Pedram, Christos Kozyrakis, and Kunle Olukotun. Plasticine: A reconfigurable architecture for parallel paterns. In ACM/IEEE Annual International Symposium on Com- puter Architecture (ISCA), pages 389–402, 2017. [26]Raghu Prabhakar, Ram Sivaramakrishnan, Darshan Gandhi, Yun Du, Mingran Wang, Xiangyu Song, Ke- jie Zhang, Tianren Gao, Angela Wang, Xiaoyan Li, Yongning Sheng, Joshua Brot, Denis Sokolov, Apurv Vivek, Calvin Leung, Arjun Sabnis, Jiayu Bai, Tuowen Zhao, Mark Gottscho, David Jackson, Mark Lut- trell, Manish K. Shah, Zhengyu Chen, Kaizhao Liang, Swayambhoo Jain, Urmish Thakker, Dawei Huang, Sumti Jairath, Kevin J. Brown, and Kunle Olukotun. Sambanova SN40L: Scaling the AI memory wall with dataflow and composition of experts. In ACM/IEEE In- ternationalSymposiumonMicroarchitecture(MICRO), pages 1353–1366. IEEE, 2024. [27]BrianCSchwedockandNathanBeckmann. Leviathan: A unified system for general-purpose near-data com- puting. In ACM/IEEE International Symposium on Microarchitecture (MICRO), pages 1278–1294. IEEE, 2024. [28]S Alexander Chin, Noriaki Sakamoto, Allan Rui, Jim Zhao, Jin Hee Kim, Yuko Hara-Azumi, and Jason An- derson. CGRA-ME:AunifiedframeworkforCGRAmod- elling and exploration. In IEEE International Confer- ence on Application-Specific Systems, Architectures and Processors (ASAP), pages 184–189. IEEE, 2017. [29]Zhaoying Li, Pranav Dangi, Chenyang Yin, Thilini Kaushalya Bandara, Rohan Juneja, Cheng Tan, Zhenyu Bai, and Tulika Mitra. Enhancing cgra efficiency through aligned compute and communica- tion provisioning. In ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), pages 410–425, 2025. [30]Jiajun Qin, Tianhua Xia, Cheng Tan, Jeff Zhang, and Sai Qian Zhang. PICACHU: Plug-in CGRA handling up- coming nonlinear operations in LLMs. In ACM Inter- national Conference on Architectural Support for Pro- gramming Languages and Operating Systems, pages 845–861, 2025. [31]Shaizeen Aga, Supreet Jeloka, Arun Subramaniyan, Satish Narayanasamy, David Blaauw, and Reetuparna Das. Compute caches. In IEEE International Sym- posium on High Performance Computer Architecture (HPCA), pages 481–492. IEEE, 2017. [32]Anant Agarwal, Ricardo Bianchini, David Chaiken, Kirk L Johnson, David Kranz, John Kubiatowicz, Beng- Hong Lim, Kenneth Mackenzie, and Donald Yeung. The MIT Alewife machine: Architecture and perfor- mance. ACM SIGARCH Computer Architecture News, 23(2):2–13, 1995. [33]Sam Ainsworth and Timothy M Jones. Graph prefetch- ing using data structure knowledge. In International Conference on Supercomputing (ICS), pages 1–11, 2016. [34]Sam Ainsworth and Timothy M Jones. An event- triggered programmable prefetcher for irregular work- loads. ACM Sigplan Notices, 53(2):578–592, 2018. [35]Ruiyang Chen, Zhuoran Song, Yicheng Zheng, Zeyu Zhu, Gang Li, Naifeng Jing, Xiaoyao Liang, and Haib- ing Guan. HEAT: NPU-NDP heterogeneous archi- tecture for transformer-empowered graph neural net- works. In ACM/IEEE International Symposium on Mi- croarchitecture (MICRO), pages 263–276, 10 2025. doi: 10.1145/3725843.3756117. [36]MohammadrezaSaed, PrashantNair, andTorAamodt. RayN:Raytracingaccelerationwithnear-memorycom- puting. In ACM/IEEE International Symposium on Mi- croarchitecture (MICRO), pages 277–291, 10 2025. doi: 10.1145/3725843.3756067. [37]Je-Woo Jang, Junyong Oh, Youngbae Kong, Jae- Youn Hong, Sung-Hyuk Cho, Jeongyeol Lee, Hoeseok Yang, andJoon-SungYang. Acceleratingretrievalaug- mented language model via PIM and PNM integration. In ACM/IEEE International Symposium on Microarchi- tecture (MICRO), pages 246–262, 10 2025. doi: 10. 1145/3725843.3756020. [38]Wonung Kim, Yubin Lee, Yoonsung Kim, Jinwoo Hwang, Seongryong Oh, Jiyong Jung, Aziz Huseynov, Woong Park, Chang Park, Divya Mahajan, and Jongse Park. Pimba: A processing-in-memory acceleration for post-transformer large language model serving. In ACM/IEEE International Symposium on Microarchitec- ture (MICRO), pages 292–307, 07 2025. doi: 10. 48550/arXiv.2507.10178. [39]Yuda An, Yunxiao Tang, Shushu Yi, Li Peng, Xiurui Pan, Guangyu Sun, Zhaochu Luo, Qiao Li, and Jie Zhang. StreamPIM: Streaming matrix computation in racetrack memory. In IEEE International Symposium on High-Performance Computer Architecture (HPCA), pages 297–311, 2024. doi: 10.1109/HPCA57654. 2024.00031. [40]Seah Kim, Hasan Genc, Vadim Vadimovich Nikiforov, Krste Asanović, Borivoje Nikolić, and Yakun Sophia Shao. MoCA: Memory-centric, adaptive execution for 17 multi-tenant deep neural networks. In IEEE Interna- tional Symposium on High-Performance Computer Ar- chitecture (HPCA), pages 828–841, 2023. doi: 10. 1109/HPCA56546.2023.10071035. [41]Jeehyun Kim, Donghyeon Kim, Seokwon Kang, Bongjoon Hyun, Inho Lee, and Yongjun Park. PIM- CCA: An efficient PIM architecture with optimized integration of configurable functional units. In ACM/IEEE International Symposium on Microar- chitecture (MICRO), pages 63–77, 10 2025. doi: 10.1145/3725843.3756034. [42]Hyojun Son, Gilbert Jonatan, Xiangyu Wu, Haeyoon Cho, Kaustubh Shivdikar, José L. Abellán, Ajay Joshi, David Kaeli, and John Kim. PIMnet: A domain-specific network for efficient collective communication in scal- able PIM. In IEEE International Symposium on High- Performance Computer Architecture (HPCA), pages 1557–1572, 2025. doi: 10.1109/HPCA61900.2025. 00116. [43]Seunghyuk Yu, Hyeonu Kim, Kyoungho Jeun, Suny- oung Hwang, Seongmin Cho, and Eojin Lee. Com- PASS: A compatible PIM protocol architecture and scheduling solution for processor-PIM collaboration. In ACM/IEEE International Symposium on Microarchi- tecture(MICRO),pages49–62,102025. doi: 10.1145/ 3725843.3756017. [44]Hwanjun Lee, Minho Kim, Yeji Jung, Seonmu Oh, Ki- Dong Kang, Seunghak Lee, and Daehoon Kim. Be- yond page migration: Enhancing tiered memory per- formance via integrated last-level cache management and page migration. In ACM/IEEE International Sym- posium on Microarchitecture (MICRO), pages 1763– 1776, 10 2025. doi: 10.1145/3725843.3756063. [45]Houxiang Ji, Yifan Yuan, Yang Zhou, Ipoom Jeong, Ren Wang, Saksham Agarwal, and Nam Kim. Re- architecting end-host networking with CXL: Coher- ence, memory, and offloading. In ACM/IEEE Inter- national Symposium on Microarchitecture (MICRO), pages 1809–1823, 10 2025. doi: 10.1145/3725843. 3756102. [46]JinshuLiu, HamidHadian, YuyueWang, DanielBerger, Marie Nguyen, Xun Jian, Sam Noh, and Huaicheng Li. Systematic CXL memory characterization and performance analysis at scale. In ACM Interna- tional Conference on Architectural Support for Pro- gramming Languages and Operating Systems (ASP- LOS), pages 1203–1217, 03 2025. doi: 10.1145/ 3676641.3715987. [47]YanSun,JongyulKim,ZeduoYu,JiyuanZhang,Siyuan Chai, Michael Kim, Hwayong Nam, Jaehyun Park, Eo- jin Na, Yifan Yuan, Ren Wang, Jung Ho Ahn, Tianyin Xu, and Nam Kim. M5: Mastering page migration and memory management for CXL-based tiered memory systems. In ACM International Conference on Archi- tectural Support for Programming Languages and Op- erating Systems (ASPLOS), pages 604–621, 03 2025. doi: 10.1145/3676641.3711999. [48]J Terry, Benjamin Black, Nathaniel Grammel, Mario Jayakumar, Ananth Hari, Ryan Sullivan, Luis S Santos, Clemens Dieffendahl, Caroline Horsch, Rodrigo Perez- Vicente,CarolineHorsch,ClemensDieffendahl,NiallL. Williams, Yashas Lokesh, and Praveen Ravi. Petting- zoo: Gym for multi-agent reinforcement learning. In ConferenceonNeuralInformationProcessingSystems (NeurIPS), volume 34, pages 15032–15043, 2021. [49]Alexander Rutherford, Benjamin Ellis, Matteo Gal- lici, Jonathan Cook, Andrei Lupu, Garðar Ingvars- son, Timon Willi, Ravi Hammond, Akbir Khan, Chris- tian Schroeder de Witt, Alexandra Souly, Saptarashmi Bandyopadhyay, Mikayel Samvelyan, Minqi Jiang, Robert Tjarko Lange, Shimon Whiteson, Bruno Lac- erda, Nick Hawes, Tim Rocktäschel, Chris Lu, and Jakob Nicolaus Foerster. JaxMARL: Multi-agent rl environments and algorithms in JAX. In Conference on Neural Information Processing Systems (NeurIPS), 2024. [50]Jakob Foerster, Yannis M Assael, Nando de Freitas, and Shimon Whiteson. Learning to communicate with deep multi-agent reinforcement learning. In Con- ference on Neural Information Processing Systems (NeurIPS), pages 2137–2145, 2016. [51]Christopher Lu, Timon Willi, Christian A Schroeder De Witt, and Jakob Foerster. Model-free opponent shaping. In International Conference on Machine Learning (ICML), pages 14398–14411. PMLR, 2022. [52]Jakob Foerster, Richard Chen, Maruan Al-Shedivat, Shimon Whiteson, Pieter Abbeel, and Igor Mordatch. Learning with opponent-learning awareness. In Inter- national Conference on Autonomous Agents and Mul- tiAgent Systems (AAMAS), pages 122–130, 07 2018. doi: 10.65109/HGWA8807. [53]John L Gustafson. Reevaluating Amdahl’s law. Com- munications of the ACM, 31(5):532–533, 1988. [54]Erik Lindholm, John Nickolls, Stuart Oberman, and John Montrym. NVIDIA tesla: A unified graphics and computing architecture. IEEE Micro, 28(2):39–55, 2008. [55]Michael J Flynn. Some computer organizations and their effectiveness. IEEE Transactions on Computers, 100(9):948–960, 2009. [56]Lie, Sean. Cerebras architecture deep dive: First look insidethehardware/softwareco-designfordeeplearn- ing. IEEE Micro, 43(3):18–30, 2023. 18 [57]DavidMayhewandVenkataKrishnan. PCIexpressand advancedswitching: Evolutionarypathtobuildingnext generation interconnects. In IEEE Symposium on High PerformanceInterconnects(HOTI),pages21–29.IEEE, 2003. [58]Debendra Das Sharma, Gerald Pasdast, Zhiguo Qian, and Kemal Aygun. Universal chiplet interconnect ex- press (UCIe): An open industry standard for innova- tions with chiplets at package level. IEEE Transactions on Components, Packaging and Manufacturing Tech- nology, 12(9):1423–1431, 2022. [59]Choquette, Jack. NVIDIA Hopper H100 GPU: Scaling performance. IEEE Micro, 43(3):9–17, 2023. [60]William James Dally and Brian Patrick Towles. Princi- ples and practices of interconnection networks. Else- vier, 2004. [61]Abiodun M Ikotun, Absalom E Ezugwu, Laith Abuali- gah, BelalAbuhaija, andJiaHeming. K-meanscluster- ingalgorithms: Acomprehensivereview,variantsanal- ysis, and advances in the era of big data. Information Sciences, 622:178–210, 2023. [62]Ümit Çatalyürek, Karen Devine, Marcelo Faraj, Lars Gottesbüren, Tobias Heuer, Henning Meyerhenke, Peter Sanders, Sebastian Schlag, Christian Schulz, Daniel Seemaier, and Dorothea Wagner. More recent advances in (Hyper)Graph partitioning. ACM Comput- ing Surveys, 55(12):1–38, 2023. [63]Igor Mordatch and Pieter Abbeel. Emergence of grounded compositional language in multi-agent pop- ulations. In AAAI Conference on Artificial Intelligence (AAAI), 2017. [64]Bei Peng, Tabish Rashid, Christian Schroeder de Witt, Pierre-Alexandre Kamienny, Philip Torr, Wendelin Böh- mer, and Shimon Whiteson. FACMAC: Factored multi- agent centralised policy gradients. In Conference on NeuralInformationProcessingSystems(NeurIPS),vol- ume 34, pages 12208–12221, 2021. [65]Ching-Jui Lee and Tsung Tai Yeh. ReSA: Reconfig- urablesystolicarrayformultipletinydnntensors. ACM Transactions on Architecture and Code Optimization, 21(3):1–24, 2024. [66]DeepSeek-AI. DeepSeek-R1 incentivizes reasoning in LLMs through reinforcement learning. Nature, 645 (8081):633–638, 2025. [67]Jiayi Li, Hongxiao Zhao, Wenshuo Yue, Yihan Fu, Dai- jing Shi, Anjunyi Fan, Yuchao Yang, and Bonan Yan. PEARL: FPGA-based reinforcement learning acceler- ation with pipelined parallel environments. In De- sign, Automation & Test in Europe Conference (DATE), pages 1–7. IEEE, 2025. [68]Xiaoyi Liu, Zhongzhu Pu, Peng Qu, Weimin Zheng, and Youhui Zhang. ActiveN: a scalable and flexibly- programmable event-driven neuromorphic processor. In ACM/IEEE International Symposium on Microarchi- tecture (MICRO), pages 1122–1137. IEEE, 2024. [69]Shirui Zhao, Jun Yin, Lingyun Yao, Martin Andraud, Wannes Meert, and Marian Verhelst. MC 2 A: Enabling algorithm-hardware co-design for efficient markov chain monte carlo acceleration. arXiv preprint arXiv:2507.12935, 2025. [70]Marcelo Orenes-Vera, Esin Tureci, David Wentzlaff, Margaret Martonosi. Dalorex: A data-local program execution and architecture for memory-bound appli- cations. In IEEE International Symposium on High- Performance Computer Architecture (HPCA), pages 718–730. IEEE, 2023. [71]Maximilian Schmidt, Rembrandt Bakker, Kelly Shen, Gleb Bezgin, Markus Diesmann, and Sacha Jennifer van Albada. A multi-scale layer-resolved spiking net- work model of resting-state dynamics in macaque vi- sual cortical areas. PLOS Computational Biology, 14 (10):e1006359, 2018. [72]Lawrence Page, Sergey Brin, Rajeev Motwani, and Terry Winograd. The PageRank citation ranking: Bring- ingordertotheweb. Technicalreport,Stanfordinfolab, 1999. [73]RichardCMurphy,KyleBWheeler,BrianWBarrett,and James A Ang. Introducing the graph 500. Cray Users Group (CUG), 19(45-74):22, 2010. [74]Xiangyu Zhang, Ramin Bashizade, Yicheng Wang, Sayan Mukherjee, and Alvin R Lebeck. Statistical ro- bustness of markov chain monte carlo accelerators. In ACM International Conference on Architectural Sup- port for Programming Languages and Operating Sys- tems (ASPLOS), pages 959–974, 2021. [75]Shirui Zhao, Nimish Shah, Wannes Meert, and Mar- ian Verhelst. AIA: A 16nm multicore SoC for approximate inference acceleration exploiting non- normalized knuth-yao sampling and inter-core regis- ter sharing. In IEEE European Solid-State Electronics Research Conference (ESSERC), pages 29–32. IEEE, 2024. [76]Glenn G Ko, Yuji Chai, Marco Donato, Paul N What- mough, Thierry Tambe, Rob A Rutenbar, David Brooks, and Gu-YeonWei. A 3m 2 programmable bayesian in- ference accelerator for unsupervised machine percep- tion using parallel gibbs sampling in 16nm. In IEEE Symposium on VLSI Circuits (VLSI), pages 1–2. IEEE, 2020. [77]Alan Mislove, Massimiliano Marcon, Krishna P Gum- madi, Peter Druschel, and Bobby Bhattacharjee. Mea- surement and analysis of online social networks. In 19 ACM SIGCOMM Conference on Internet Measurement (IMC), pages 29–42, 2007. [78]Jure Leskovec, Deepayan Chakrabarti, Jon Kleinberg, Christos Faloutsos, Zoubin Ghahramani. Kronecker graphs: an approach to modeling networks. Journal of Machine Learning Research, 11(2), 2010. [79]HunjunLee,ChanmyeongKim,YujinChung,andJang- woo Kim. NeuroEngine: A hardware-based event- driven simulation system for advanced brain-inspired computing. In ACM International Conference on Archi- tectural Support for Programming Languages and Op- erating Systems (ASPLOS), pages 975–989, 2021. [80]Amit Sabne. XLA : Compiling Machine Learning for Peak Performance, 2020. [81]Junwhan Ahn, Sungpack Hong, Sungjoo Yoo, Onur Mutlu, and Kiyoung Choi. A scalable processing-in- memory accelerator for parallel graph processing. In ACM/IEEE Annual International Symposium on Com- puter Architecture (ISCA), pages 105–117. IEEE, 2015. [82]Birte Friesel, Marcel Lütke Dreimann, and Olaf Spinczyk. A full-system perspective on UPMEM performance. In The Workshop on Disruptive Memory Systems (DIMES), pages 1–7, 2023. [83]Dan Zhang, Xiaoyu Ma, Michael Thomson, and Derek Chiou. Minnow: Lightweight offload engines for worklist management and worklist-directed prefetch- ing. ACM SIGPLAN Notices, 53(2):593–607, 2018. [84]Linghao Song, Youwei Zhuo, Xuehai Qian, Hai Li, and YiranChen. GraphR:Acceleratinggraphprocessingus- ing ReRAM. In IEEE International Symposium on High- Performance Computer Architecture (HPCA), pages 531–543. IEEE, 2018. [85]Kartik Hegde, Hadi Asghari-Moghaddam, Michael Pel- lauer, Neal Crago, Aamer Jaleel, Edgar Solomonik, Joel Emer, and Christopher W Fletcher. ExTensor: An accelerator for sparse tensor algebra. In ACM/IEEE In- ternationalSymposiumonMicroarchitecture(MICRO), pages 319–333, 2019.

Instant research discovery