PIM-CCA: An Efficient PIM Architecture with Optimized Integration of Configurable Functional Units

---

Review Form

Reviewer: The Guardian (Adversarial Skeptic)

Summary

The authors propose PIM-CCA, an architecture that integrates a Configurable Compute Accelerator (CCA) into a Processing-in-Memory (PIM) processor, modeled after the UPMEM DPU. The stated goal is to alleviate computational bottlenecks that emerge in PIM systems when memory access latency is reduced. They present a compiler-driven approach to identify and offload "hot code" regions—primarily multiplication-based sequences—to a small, specialized CCA. The evaluation, conducted on a cycle-accurate simulator, claims significant performance gains (up to 1.55x) with what is described as minimal hardware overhead (0.036%). The work also analyzes the relationship between tasklet count and performance in this new architecture.

Strengths

1. Problem Motivation: The paper correctly identifies a critical issue in PIM systems: the performance bottleneck can shift from memory access to computation once workloads are moved closer to memory (Section 2.3). This observation is valid and provides a solid foundation for the work.

2. Grounded Simulation: The use of uPIMulator, a simulator based on a commercially available PIM system (UPMEM), provides a realistic baseline for evaluation (Section 2.1). This is preferable to purely abstract models.

3. Compiler-Architecture Co-design: The authors recognize that a hardware accelerator is ineffective without corresponding compiler support. The inclusion of a compiler flow to detect and replace code sections is a necessary component of the proposed solution (Section 3.3.3).

Weaknesses

My primary concerns with this paper relate to the generalizability of its claims, the transparency of its overhead analysis, and the rigor of its evaluation methodology.

1. Over-specialization to a Weak Baseline: The entire premise appears to be built upon the specific and significant weakness of the baseline UPMEM DPU: its extremely inefficient multi-cycle integer multiplication implemented via mul_step instructions (Section 3.2, page 6). The impressive 1.55x speedup seems less a testament to the general utility of a CCA and more a result of patching this one specific flaw. The "hot codes" identified are dominated by operations that are slow on the baseline (Figure 4a). The claims of broad applicability to PIM are unsubstantiated, as other PIM architectures (e.g., HBM-PIM) may not share this particular bottleneck.

2. Misleading Hardware Overhead Metric: The reported 0.036% area overhead is highly suspect (Section 4.6, page 12). This figure is almost certainly calculated against the total area of the entire PIM chip, which is overwhelmingly dominated by the DRAM arrays themselves. This metric obscures the true cost of the modification. The overhead should be reported relative to the area of the DPU's processor logic, which would provide a far more honest assessment of the design's complexity and cost. Without this, the claim of "minimal overhead" is not credible.

3. Convenient Benchmark Exclusion: The exclusion of key benchmarks like BFS and SpMV is a major red flag (Section 4.1, page 10). The justification given is "limitations in the instruction set supported by our baseline simulator." This is insufficient. These benchmarks are characterized by irregular memory access patterns and different computational kernels than the dense linear algebra workloads that dominate the successful results. Their exclusion raises serious doubts about the robustness of the compiler and the applicability of the CCA beyond simple, regular arithmetic patterns. The work is therefore evaluated on a cherry-picked set of benchmarks that are predisposed to benefit from the proposed accelerator.

4. Limited "Configurability" and Compiler Fragility: The "Configurable" Compute Accelerator appears to be little more than a set of three hard-wired custom function units for multiplication, accumulation, and max (Table 1, page 10). This is not what is typically understood as a reconfigurable fabric (like a CGRA). Furthermore, the compiler's hot code detection mechanism appears to be a simple pattern-matching scheme based on predefined templates (Figure 10, Algorithm 1). It is unclear how this would scale to more complex code structures or identify opportunities that do not exactly match the pre-canned patterns. The robustness of this compiler is unproven.

5. Contradictory Statements: In Section 4.1, the paper states that the Needle-Wushiman (NW) benchmark is unavailable in the simulator environment. However, the max operation, explicitly identified for NW, is included as a core CCA function (CCA code 0x2 in Table 1) and is designed into the hardware (Figure 7). Why design and include hardware for a benchmark you cannot run or evaluate? This internal inconsistency undermines confidence in the methodology.

Questions to Address In Rebuttal

The authors must address the following points to make this work acceptable:

1. Area Overhead: Please clarify the 0.036% area overhead claim. What is the total area used as the denominator for this calculation? Please provide the overhead as a percentage of the DPU's non-memory logic area to provide a more transparent comparison.

2. Baseline Dependency: The baseline UPMEM architecture's multi-cycle integer multiplication is a critical performance bottleneck. Could the reported speedups be primarily attributed to fixing this specific weakness, rather than a generalizable benefit of the CCA approach? How would PIM-CCA perform against a baseline PIM processor with a more reasonable, pipelined single-cycle integer multiplier?

3. Benchmark Exclusion: Provide a detailed technical justification for the exclusion of BFS and SpMV. Do these workloads contain computational patterns that the PIM-CCA compiler cannot identify or that the CCA hardware cannot accelerate? The absence of these key benchmarks casts doubt on the general applicability of the proposed solution.

4. Compiler Limitations: The compiler appears to rely on pattern matching for specific arithmetic sequences (Figure 10). What is the coverage of this approach? How does it handle hot code regions with complex control flow or patterns not pre-defined in the "logic palette"?

5. On the "Configurable" Claim: The CCA is configured for only three operation types. This seems more like a set of co-processors than a truly "configurable" accelerator. Please comment on the design's extensibility and the process for adding new, more complex functional units beyond the ones presented.

---

Review Form

Reviewer: The Synthesizer (Contextual Analyst)

Summary

This paper, "PIM-CCA: An Efficient PIM Architecture with Optimized Integration of Configurable Functional Units," addresses an important, second-order problem emerging from the success of Processing-in-Memory (PIM) architectures: the creation of new computational bottlenecks within the memory device itself. The authors astutely observe that by alleviating the data movement bottleneck, many memory-intensive workloads become compute-bound on PIM's inherently resource-constrained processors (DPUs).

The core contribution is a holistic, co-designed solution that integrates a lightweight Configurable Compute Accelerator (CCA) into the PIM processor's pipeline. This is not merely a hardware proposal; it is a full system concept supported by a PIM-aware compiler that identifies and offloads hot computational subgraphs, and an analysis of the interplay between the accelerator and PIM's native task-based parallelism. The authors demonstrate through simulation that their PIM-CCA design can achieve up to a 1.55x performance improvement on compute-intensive kernels with a negligible hardware area overhead (0.036%), making it a practical proposal for real-world PIM systems.

Strengths

This is a well-conceived and timely piece of work that makes several strong contributions to the field.

1. Excellent Problem Formulation and Motivation: The paper's primary strength lies in its identification and clear articulation of a critical, next-generation problem for PIM. The analysis in Section 2.3 (page 4), particularly Figure 3, which shows the shift in workload characteristics from memory-bound to compute-bound once inside PIM, is insightful and provides a compelling motivation for the entire paper. This work is not solving a contrived problem; it is looking ahead at the natural evolution of PIM architectures and their limitations.

2. Elegant Synthesis of Architectural Concepts: This work sits at a valuable intersection of three major research areas: Processing-in-Memory, reconfigurable computing, and compiler-architecture co-design. Rather than inventing a new mechanism from scratch, the authors have skillfully applied the mature concept of a compiler-driven Configurable Compute Accelerator (CCA)—originally proposed for embedded systems—to the unique, resource-starved environment of a PIM processor. This cross-pollination of ideas is a powerful research methodology, and the result is an architecture that feels both novel in its application and grounded in established principles.

3. A Holistic, System-Level Perspective: The authors should be commended for not limiting their scope to just a hardware block. The proposal is a complete system. They have considered:

   • The Hardware: A carefully pipelined CCA logic that respects the tight constraints of the baseline DPU (Section 3.3.1, page 7).
   • The ISA: A minimal and compatible instruction set extension (cca and cca_move) that integrates cleanly into the existing pipeline (Section 3.3.2, page 7).
   • The Compiler: A mechanism for automatically identifying and replacing hot code regions, which is essential for programmability and usability (Section 3.3.3, page 8).
   • The Parallelism Model: An insightful analysis of how the CCA changes the optimal number of software tasklets, showing a deep understanding of the system's performance dynamics (Section 3.4, page 9).

4. Pragmatism and Realism: The proposed CCA is designed with the severe constraints of memory fabrication in mind. The extremely low reported area overhead (Section 4.6, page 12) makes this a highly practical and believable proposal. By focusing on accelerating a few key instruction patterns (like mul_step), the authors have found a "sweet spot" that delivers significant performance gains without requiring a radical or costly redesign of the PIM processor.

Weaknesses

While the core idea is strong, the paper could be improved by broadening its contextual analysis and exploring the boundaries of its proposed solution.

1. Limited Scope of Evaluated CCA Operations: The evaluation, while thorough for what it covers, is heavily focused on accelerating multiplication via the mul_step sequence found in the UPMEM architecture (Table 1, page 10). This is certainly the most obvious bottleneck and the correct place to start. However, the paper's broader claim is about a configurable accelerator. The current evaluation makes the CCA feel more like a specialized, fixed-function "multiplication co-processor" rather than a truly flexible unit. The work would be much stronger if it demonstrated how the framework could target other, more diverse computational patterns, even if just through a design study.

2. Insufficient Discussion of Design-Space Alternatives: The paper rightly argues that simply making the main DPU core more complex is infeasible. However, the CCA is not the only possible solution. A key alternative would be to add a small, fixed SIMD/vector datapath to the DPU. This is a very common architectural pattern for boosting compute throughput. A discussion comparing and contrasting the PIM-CCA approach (with its fine-grained, irregular-pattern matching) against a more traditional SIMD approach (with its regular, data-parallel focus) is missing. This would help to better delineate the specific advantages of the CCA paradigm in the PIM context.

3. Potential Over-Fitting of the Compiler and Logic: The PIM-CCA compiler and the CCA logic palette construction (Section 3.3.4, page 9) appear to be tightly coupled to the hot code patterns identified in the benchmark suite. While this is a valid methodology, it leaves open the question of generality. How would the framework adapt if presented with a new class of workloads with entirely different computational bottlenecks (e.g., bit-level manipulation, cryptography, or complex address calculations)? A more robust discussion of the compiler's ability to discover and map new, unseen patterns would strengthen the paper's claims of flexibility.

Questions to Address In Rebuttal

1. Beyond the multiplication and accumulation patterns evaluated, what other types of computational hot spots common in PIM workloads did you identify? Could you provide an example of a non-MAC-style code region and briefly explain how your compiler and CCA design methodology could be applied to accelerate it?

2. Could you elaborate on why a configurable accelerator (CCA) is a more suitable choice for PIM than a more conventional microarchitectural enhancement like a small, 2 or 4-lane SIMD unit? What specific workloads or computational patterns would be well-served by the CCA that a SIMD unit would handle poorly, and vice-versa?

3. Regarding the compiler framework, what happens when it encounters a hot loop that contains a mix of operations, some of which are mappable to the CCA and some of which are not? Is the compiler capable of partial offloading, or does the entire loop have to remain on the scalar DPU core if a perfect pattern match is not found?

---

Review Form

Reviewer: The Innovator (Novelty Specialist)

Summary

The paper proposes PIM-CCA, an architecture that integrates a compiler-guided Configurable Compute Accelerator (CCA) into a UPMEM-like Processing-in-Memory (PIM) system. The authors identify that as PIM systems alleviate memory-access bottlenecks, workloads can become compute-bound within the PIM units (DPUs) themselves. The proposed solution is to use a lightweight, reconfigurable CCA to offload these computational "hot code" regions, which are identified by a custom compiler that analyzes the application's dataflow graph. The work also includes an analysis of how this acceleration interacts with the PIM system's software-managed threading (tasklet) model. The primary claims are improved performance (up to 1.55x) with negligible hardware overhead (0.036%).

Strengths

1. Novel Synthesis of Concepts: The primary novel contribution of this paper is the application and adaptation of the Configurable Compute Accelerator concept, originally proposed by Clark et al. [6, 7], to the unique constraints and execution model of a modern, commercially-inspired PIM architecture. While PIM accelerators and CCAs exist independently, their synthesis to solve the emergent computational bottleneck within PIM is a novel research direction.

2. PIM-Specific Hardware Adaptation: The authors demonstrate a clear understanding of the target architecture's limitations. The design of the CCA is not a generic application but is tailored to the PIM environment. The insight to target low-level, multi-cycle instruction sequences (e.g., the mul_step operation on the UPMEM architecture, discussed in Section 3.2, page 6) and consolidate them into a single CCA operation is a well-reasoned, PIM-specific optimization that represents a clear delta over prior CCA work.

3. End-to-End System Proposal: The work presents a complete system view, including a compiler toolflow (Section 3.3.3, page 8) for pattern identification and code generation, a hardware architecture for the CCA itself (Section 3.3.1, page 6), and an analysis of its interaction with the system's concurrency model (Section 3.4, page 9). This holistic approach strengthens the contribution.

Weaknesses

1. Limited Delta from Foundational Prior Art: The core conceptual machinery is not new. The idea of a transparent, compiler-driven instruction set extension through a reconfigurable datapath is the central thesis of the original CCA papers [6, 7]. Similarly, the use of compiler analysis on dataflow graphs to identify and offload critical subgraphs is a foundational technique in compilation for custom hardware and reconfigurable computing. The paper's novelty rests almost entirely on the target of this existing methodology (PIM), not on a fundamental innovation in the methodology itself.

2. Questionable "Configurability" in Practice: The central premise of a CCA is its configurability to accelerate a diverse set of computational patterns. However, the evaluation relies on a CCA configured for a very limited set of operations: a 4-step multiply, an accumulation, and a maximum (Table 1, page 10). This configuration appears functionally closer to a collection of dedicated Custom Functional Units (CFUs) for multiply-accumulate and max operations rather than a truly "configurable" accelerator. The work does not sufficiently demonstrate that the overhead of the CCA's reconfigurable fabric is justified over simply implementing a few fixed-function units, which would be a far less novel contribution. The power of the general CCA framework seems underutilized and, consequently, its novelty is undermined.

3. Incremental Novelty of the Compiler Heuristic: The proposed "logic palette" construction algorithm (Algorithm 2, page 9) appears to be a straightforward greedy heuristic for mapping pattern graphs to hardware resources to maximize sharing. While necessary for their toolflow, the novelty of this specific algorithm, when compared to decades of prior art in High-Level Synthesis (HLS), logic synthesis, and technology mapping for FPGAs/CGRAs, is not clearly established. It solves a necessary problem for the authors but does not appear to be a standalone novel contribution in compiler or synthesis technology.

Questions to Address In Rebuttal

1. The key distinction of a CCA over a set of fixed-function units is its configurability. Given the evaluation uses only three core patterns (multiply, accumulate, max), please clarify the novelty and benefit of the generalizable CCA framework over simply proposing the addition of three dedicated CFUs to the DPU pipeline. What is the hardware overhead (area, wiring complexity) of the CCA's reconfigurability (e.g., the MUX network in Figure 7) compared to hard-wiring these three specific functions?

2. The paper positions itself in the PIM domain. However, other works have proposed co-locating more general-purpose reconfigurable logic (e.g., FPGAs) in the logic layer of 3D-stacked memory or on a DIMM. Please position PIM-CCA more clearly against these alternative forms of reconfigurable near-data processing. What is the fundamental novelty of the CCA model in this context compared to a small, near-memory FPGA or CGRA?

3. To substantiate the claim of a novel and generalizable framework, could the authors provide an example of a more complex or irregular computational pattern from a different application domain (e.g., bioinformatics, cryptography) that their PIM-CCA compiler (Figure 10, page 8) can successfully identify and for which the logic palette framework can generate an efficient CCA configuration? This would more convincingly demonstrate that the contribution is a new framework and not just a bespoke solution for accelerating GEMV-like kernels.