Pith. sign in

REVIEW 3 major objections 7 minor 43 references

RIMMS: Runtime Integrated Memory Management System for Heterogeneous Computing

T0 review · 3 major / 7 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A runtime memory layer that tracks where data lives on each accelerator can eliminate redundant copies and match hand-tuned CUDA performance.

desk verdict RIMMS is a concrete and useful mechanism—the hete_Data abstraction with last-resource tracking and fragmentation is genuinely new—but the headline numbers lack variance reporting and the race-free guarantee is scoped to CEDR's single-owner model, so read it as a conditional accept with specific revision requests. read the letter →

arxiv 2507.20514 v1 pith:KRIE7U5N submitted 2025-07-28 cs.DC

Serhan Gener , Aditya Ukarande , Shilpa Mysore Srinivasa Murthy , Sahil Hassan , Joshua Mack , Chaitali Chakrabarti , Umit Ogras , Ali Akoglu This is my paper · ORCID
classification cs.DC
keywords heterogeneouscomputingruntimememorymanagementhardware-agnosticabstractionlast-resourcetrackingbitsetallocationnext-fitdatafragmentationsignalprocessing
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

RIMMS aims to prove that a hardware-agnostic runtime memory layer can replace the explicit, device-specific memory management that programmers currently write for heterogeneous systems. The paper argues that if the runtime tracks which processing element last updated each buffer, it can eliminate the redundant host-CPU round trips that dominate execution in CPU+GPU and CPU+FPGA workloads. On complete radar signal-processing applications, this removes enough copies to deliver up to 2.43X speedup on a GPU-based platform, 1.82X on an FPGA-based platform, and up to 3.08X over the IRIS runtime, while staying within 1-2 cycles per memory call of native performance. If true, this would let application code be written once and run anywhere without platform-specific tuning or data-movement directives.

What carries the argument

The load-bearing mechanism is the hete_Data structure: a per-buffer handle carrying resource-specific memory pointers and a one-flag record of the most recent writer, together with hardware-agnostic API calls (hete_Malloc, hete_Free, hete_Sync) that the compiler inserts as prototypes. Allocation uses either a compact bitset for memory-limited systems or a next-fit linked list for speed, and a fragment operation subdivides one allocation into many indexed slices so structured data like MxN FFT buffers avoids repeated allocation. These pieces together shift the job of deciding where data lives from the programmer to the runtime.

What would settle it

Run a heterogeneous workload in which a GPU and an FPGA both write to the same RIMMS-managed buffer between synchronization calls; if the last-resource flag alone produces stale reads or corruption compared to a coherence-enforcing baseline, the single-ownership model is violated. A lighter check is to enable concurrent device access in the runtime and measure whether the per-call overhead rises above the reported 1-2 cycles.

Watch

Extended reading notes

Core claim

The central claim is that data-placement tracking, rather than programmer-directed transfers, is sufficient to make heterogeneous memory management both portable and fast. RIMMS attaches to each buffer a record of pointers into every resource's memory plus a single 'last resource' flag indicating which copy is valid; the runtime checks this flag at API boundaries and copies only when the data is needed elsewhere. The paper demonstrates this on two platforms with three signal-processing chains and three full applications (radar correlator, pulse Doppler, and synthetic aperture radar), showing that the flag-checking protocol adds only 1-2 cycles per call and eliminates the redundant copies that make the reference host-owned flow slower.

Load-bearing premise

The system assumes that each memory-management API call is executed by exactly one processing element at a time (an inheritance from the CEDR runtime), so a single 'last resource' flag can unambiguously name the owner; if two accelerators ever touch the same buffer concurrently, that flag cannot keep the copies consistent without extra protocol.

Editorial extensions

If this is right

  • RIMMS's speedups (up to 2.43X GPU, 1.82X FPGA over the reference, and 1.35-3.08X over IRIS) imply that redundant host round trips, not kernel speed, dominate these workloads.
  • Because performance tracks hand-written CUDA within noise while using a higher-level API, the abstraction appears not to cost performance.
  • The 1-2 cycles per-call overhead means such bookkeeping can be added to any runtime without becoming a bottleneck, making dynamic task-to-PE mapping cheaper.
  • The bitset-vs-next-fit tradeoff and fragment function provide a menu for systems with different memory budgets: compact metadata when memory is tight, faster allocation when it is not.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The single 'last resource' flag only works because CEDR assigns each API call to one resource; if a runtime ever allows two accelerators to access the same buffer concurrently, RIMMS would need an added coherence layer, and the paper's 1-2 cycle overhead number would no longer hold.
  • A locality-aware scheduler could use the same flag data to prefer the PE that already holds the data, which the paper does not evaluate but is a natural extension.
  • The claim of coherence- and NUMA-agnosticism suggests RIMMS could be dropped into existing OS-managed memory systems unchanged; a direct test would be running it on a multi-socket NUMA host with no coherence adjustments.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 7 minor

Summary. The manuscript presents RIMMS, a runtime memory management layer for heterogeneous systems, integrated with the CEDR runtime. It introduces the hete_Data structure with per-resource pointers and a last-resource flag, hardware-agnostic APIs (hete_Malloc, hete_Free, hete_Sync), two allocator designs (bitset and next-fit linked-list), and a fragmentation operation. The evaluation uses synthetic chains (2FFT, 2FZF, 3ZIP) and three radar applications (RC, PD, SAR) on ZCU102 (CPU+FPGA) and Jetson AGX (CPU+GPU), comparing against CEDR, IRIS, and native CUDA. The paper reports speedups up to 2.43X on GPU and 1.82X on FPGA over the CEDR baseline, up to 3.08X over IRIS, and 1-2 cycles of overhead per memory management call.

Significance. If the reported results are reproducible, RIMMS provides a simple and effective mechanism for reducing redundant memory copies in dynamic heterogeneous runtimes, and the measured speedups are mechanistically explained by the number of eliminated copies. The evaluation covers two very different platforms and complete radar applications, which is a genuine strength, and the manuscript is transparent about the single-resource ownership assumption inherited from CEDR. However, the headline quantitative claims (2.43X, 1.82X, 3.08X, and 1-2 cycles) are not supported by variance or replication information, and the 1-2 cycle claim lacks methodological detail. Because these numbers are the paper's main quantitative contributions, the evidence as presented is not yet sufficient to confirm them.

major comments (3)
  1. [§5.4, Table 2] The speedup values in Table 2 are single-point measurements without error bars, standard deviations, or a statement of the number of independent trials used for the reported averages. The RC 3CPU-1GPU row reports a 0.97X slowdown, showing that run-to-run scatter can change a ratio by several percent; without variance information, the headline claims of 2.43X and 3.08X cannot be distinguished from measurement noise. Please report per-run spreads or confidence intervals for every reported speedup, and explicitly state the number of repetitions for the Table 2 and Figure 8 results.
  2. [§5.2.2] The claim of 1-2 cycles per memory management call is not adequately supported. The microbenchmark is described only as performing the last resource flag check iteratively one million times on ZCU102; there is no description of the timing source (e.g., cycle counter, performance monitor), the number of repeated trials, the distribution of measurements, or how compiler optimization was prevented from eliminating the check. Please provide this information and, ideally, report the overhead on both platforms.
  3. [§3.2.2] The correctness of the last-resource flag depends on the assumption, stated in Section 3.2.2, that each API call is strictly assigned to a single resource and that no two resources access the same data concurrently. This assumption is inherited from CEDR and is not guaranteed by arbitrary heterogeneous runtimes. Since the paper claims a general hardware-agnostic memory abstraction layer that manages consistency, the scope of the contribution should be stated more carefully, and the behavior under concurrent access from multiple resources should be discussed or explicitly excluded.
minor comments (7)
  1. [Abstract and §5.2.2] The overhead is reported as '1-2 cycles' in the Abstract and as '1.16 CPU cycles' in Section 5.2.2; please make the numbers consistent and specify whether the range refers to min-max across calls or across runs.
  2. [Table 1] The column header 'SpdUp' is not defined; please define the abbreviation in the caption.
  3. [Figure 10] The zoomed-in panel is difficult to read because the Reference bar is nearly invisible; consider using a log scale or annotated values.
  4. [§5.2.1] The block size of 4,096 is mentioned without units; please state explicitly that it is 4,096 bytes.
  5. [Listing 3] Listing 3 contains typographical artifacts such as 'mem_intput', 'iris_ task_sub mit', and 'iri s_mem_re lease'; these should be corrected in the camera-ready version.
  6. [§5.3] The sentence 'These ratios exclude the internal four memory copies required between ZIPs' is confusing; clarify what the ratios represent and why the four internal copies are excluded.
  7. [§3.2.5] The security claim that RIMMS 'does not introduce additional vulnerabilities' is made without supporting argument; either provide a justification or soften the wording.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: RIMMS's speedups and overhead are direct empirical measurements against an explicit-copy baseline, not fitted predictions or self-referential derivations.

full rationale

The paper's headline claims (up to 2.43X on GPU, 1.82X on FPGA, 1.35-3.08X over IRIS, and 1-2 cycles per-call overhead) are wall-clock and microbenchmark measurements on ZCU102 and Jetson AGX platforms, with no fitted parameters that are later relabeled as predictions. The baseline is explicitly defined in Section 3.1 as host-CPU-owner data flow with memcpy, and RIMMS's mechanism (last-resource flag, bitset/NF allocation, fragment) is the treatment being tested, so the speedups are a controlled experimental outcome rather than a circular definition. The one self-citation that could appear load-bearing is the reliance on CEDR [26-28] for the single-resource ownership model in Section 3.2.2, which justifies the race-free last-resource flag; however, CEDR is an open-source, previously published runtime with an externally checkable design property, and the memory-management contribution and its evaluation do not depend on proving that property from scratch. Similarly, the native CUDA comparison in Section 5.3 uses a CUDA version deliberately written to avoid intermediate host copies 'mirroring the approach taken by RIMMS,' which is a fair optimized baseline rather than a circular construction. Reproducibility gaps such as missing error bars and the single-platform microbenchmark are evidence-quality concerns, not circularity.

Assumptions & free parameters 1 free parameters · 4 assumptions · 2 invented entities

The central claim rests on the single-ownership assumption of the CEDR runtime, on compiler support for the API hooks, and on the availability of platform-specific memory allocators. The only hand-tuned free parameter identified is the FPGA block size (4096 bytes).

free parameters (1)
  • Block size for bitset allocator = 4096 bytes
    Chosen in Section 5.2.1 as a compromise between allocation time and memory utilization; used for PD experiments in Section 5.5.2. Affects allocation overhead and is platform-specific, despite the abstract's claim of no platform tuning.
assumptions (4)
  • domain assumption CEDR forces API-level parallelism, so a given hete_Data object is accessed by at most one resource at a time.
    Invoked in Section 3.2.2 to justify that a single last-resource flag is race-free. If a runtime permits concurrent access to the same buffer, RIMMS provides no coherence protocol.
  • domain assumption Compiler-inserted function prototypes for hete_Malloc, hete_Free, and hete_Sync have inputs and outputs known at compile time.
    Section 3.2 and 3.2.1 assume the compiler can generate hardware-agnostic binaries that the runtime can hook. If the compiler flow cannot identify these operations, the runtime cannot track data locations.
  • domain assumption Host-side coherence and NUMA behavior are inherited from the OS/hardware; RIMMS does not implement its own coherence.
    Section 3.2.5 states RIMMS relies on the system's default coherence. This limits RIMMS's guarantees to platforms with such support.
  • domain assumption On FPGAs, UDMA buffers require physically contiguous memory, and a kernel-level allocator can provide it.
    Section 3.2.5 and Section 3.2.2 assume a custom contiguous-memory allocator exists for the FPGA path; this is platform-specific, not generalizable.
invented entities (2)
  • hete_Data structure with per-resource pointers and last-resource flag
    purpose: Tracks where the valid copy of a buffer resides so the runtime can skip redundant copies between PEs.
    Introduced in Section 3.2.1 and used throughout. The measured speedups provide in-paper evidence, but no external artifact or orthogonal falsifiable prediction is provided.
  • fragment operation on hete_Data
    purpose: Subdivides an allocated block into indexed fragments, each with its own pointers and flag, without repeated allocations.
    Introduced in Section 3.2.3; overhead measured in Section 5.5.2, but no independent external validation is available.

how reviews work

0 comments
Cite this review

Pith. "Pith review of RIMMS: Runtime Integrated Memory Management System for Heterogeneous Computing." pith.science (2026). https://pith.science/paper/KRIE7U5N

@misc{pith2026250720514,
  author       = {Pith},
  title        = {Pith review of: RIMMS: Runtime Integrated Memory Management System for Heterogeneous Computing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KRIE7U5N}},
  note         = {Machine review of arXiv:2507.20514}
}
read the original abstract

Efficient memory management in heterogeneous systems is increasingly challenging due to diverse compute architectures (e.g., CPU, GPU, FPGA) and dynamic task mappings not known at compile time. Existing approaches often require programmers to manage data placement and transfers explicitly, or assume static mappings that limit portability and scalability. This paper introduces RIMMS (Runtime Integrated Memory Management System), a lightweight, runtime-managed, hardware-agnostic memory abstraction layer that decouples application development from low-level memory operations. RIMMS transparently tracks data locations, manages consistency, and supports efficient memory allocation across heterogeneous compute elements without requiring platform-specific tuning or code modifications. We integrate RIMMS into a baseline runtime and evaluate with complete radar signal processing applications across CPU+GPU and CPU+FPGA platforms. RIMMS delivers up to 2.43X speedup on GPU-based and 1.82X on FPGA-based systems over the baseline. Compared to IRIS, a recent heterogeneous runtime system, RIMMS achieves up to 3.08X speedup and matches the performance of native CUDA implementations while significantly reducing programming complexity. Despite operating at a higher abstraction level, RIMMS incurs only 1-2 cycles of overhead per memory management call, making it a low-cost solution. These results demonstrate RIMMS's ability to deliver high performance and enhanced programmer productivity in dynamic, real-world heterogeneous environments.

Figures

Figures reproduced from arXiv: 2507.20514 by the authors.

Figure 1
Figure 1. Scenario with (a) redundant memory copies on data operated by two PE types and (b) elimination of [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. Contents of hete_Data data structure and underlying flow of new hete_Malloc and hete_Free APIs. CPU and other resources. The following subsections describe our design approach for each. The new data structure and the APIs are illustrated in [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. Overview of the hardware-agnostic memory management functions, memory management protocols, [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: Representative signal processing chains for validation: (a) FFT to IFFT flow, (b) Two FFTs to ZIP to [PITH_FULL_IMAGE:figures/full_fig_p012_4.png]
Figure 5
Figure 5. Figure 5: Execution time of 2FFT as a function of FFT size on ZCU102 using the reference system and RIMMS. [PITH_FULL_IMAGE:figures/full_fig_p013_5.png]
Figure 6
Figure 6. Figure 6: Execution time of 2FFT as a function of FFT size on Jetson AGX using the reference system and RIMMS. [PITH_FULL_IMAGE:figures/full_fig_p014_6.png]
Figure 7
Figure 7. Figure 7: Memory management overhead across problem sizes for a given block size and comparison against [PITH_FULL_IMAGE:figures/full_fig_p016_7.png]
Figure 8
Figure 8. Figure 8: Execution time of 3ZIP using CEDR, IRIS, RIMMS, and native CUDA as a function of ZIP size on [PITH_FULL_IMAGE:figures/full_fig_p017_8.png]
Figure 9
Figure 9. Figure 9: PD application DAG showing possible memory locations before and after FFT and ZIP nodes. Red [PITH_FULL_IMAGE:figures/full_fig_p019_9.png]
Figure 10
Figure 10. Figure 10: Allocation overheads when using different schemes with the PD application on ZCU102 platform. [PITH_FULL_IMAGE:figures/full_fig_p020_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

43 extracted references · 19 canonical work pages

  1. [1]

    ARM AMBA. 2010. AXI4-stream protocol specification. Volume IHI 51A (2010)

    work page 2010

  2. [2]

    Cédric Augonnet, Samuel Thibault, Raymond Namyst, and Pierre-André Wacrenier. 2011. StarPU: a unified platform for task scheduling on heterogeneous multicore architectures. Concurrency and Computation: Practice and Experience 23, 2 (2011), 187–198. https://doi.org/10.1002/cpe.1631 arXiv:https://onlinelibrary.wiley.com/doi/pdf/10.1002/cpe.1631

    doi:10.1002/cpe.1631 2011

  3. [3]

    Rossbach, and Onur Mutlu

    Rachata Ausavarungnirun, Joshua Landgraf, Vance Miller, Saugata Ghose, Jayneel Gandhi, Christopher J. Rossbach, and Onur Mutlu. 2017. Mosaic: A GPU Memory Manager with Application-Transparent Support for Multiple Page Sizes. In 2017 50th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO) . 136–150. , Vol. 1, No. 1, Article . Publication ...

    work page 2017

  4. [4]

    Razaz, Majid Alsagabi, and Sulaiman Al-Sowayan

    Mohammed Khaled Banafaa, Omer Pepeoglu, Ibraheem Shayea, Abdulraqeb Alhammadi, Zaid Ahmed Shamsan, Muneef A. Razaz, Majid Alsagabi, and Sulaiman Al-Sowayan. 2024. A Comprehensive Survey on 5G-and-Beyond Networks With UAVs: Applications, Emerging Technologies, Regulatory Aspects, Research Trends and Challenges. IEEE Access 12 (2024), 7786–7826. https://doi...

    arXiv 2024

  5. [5]

    Dreslinski, and Trevor Mudge

    Geoffrey Blake, Ronald G. Dreslinski, and Trevor Mudge. 2009. A survey of multicore processors.IEEE Signal Processing Magazine 26, 6 (2009), 26–37. https://doi.org/10.1109/MSP.2009.934110

    work page arXiv 2009

  6. [6]

    Behzad Boroujerdian, Ying Jing, Devashree Tripathy, Amit Kumar, Lavanya Subramanian, Luke Yen, Vincent Lee, Vivek Venkatesan, Amit Jindal, Robert Shearer, and Vijay Janapa Reddi. 2023. FARSI: An Early-stage Design Space Exploration Framework to Tame the Domain-specific System-on-chip Complexity. ACM Trans. Embed. Comput. Syst. 22, 2, Article 31 (jan 2023)...

    work page doi:10.1145/3544016 2023

  7. [7]

    Calderón, Leonidas ALEJANDROCALDERON, Carlos-F

    Alejandro J. Calderón, Leonidas ALEJANDROCALDERON, Carlos-F. Nicolás, and Francisco J. Cazorla. 2024. XeroZerox: Analysis and Optimization of GPU Memory Management for High-Integrity Autonomous Systems. IEEE Access 12 (2024), 77141–77155. https://doi.org/10.1109/ACCESS.2024.3406893

    work page arXiv 2024

  8. [8]

    Sheaffer, Sang-Ha Lee, and Kevin Skadron

    Shuai Che, Michael Boyer, Jiayuan Meng, David Tarjan, Jeremy W. Sheaffer, Sang-Ha Lee, and Kevin Skadron. 2009. Rodinia: A benchmark suite for heterogeneous computing. In 2009 IEEE International Symposium on Workload Charac- terization (IISWC). 44–54. https://doi.org/10.1109/IISWC.2009.5306797

    arXiv 2009

Show all 43 references
  1. [9]

    Cota, Paolo Mantovani, Giuseppe Di Guglielmo, and Luca P

    Emilio G. Cota, Paolo Mantovani, Giuseppe Di Guglielmo, and Luca P. Carloni. 2015. An Analysis of Accelerator Coupling in Heterogeneous Architectures. In Proceedings of the 52nd Annual Design Automation Conference (San Francisco, California) (DAC ’15). Association for Computin...

    2015

  2. [10]

    Dagum and R

    L. Dagum and R. Menon. 1998. OpenMP: an industry standard API for shared-memory programming. IEEE Computa- tional Science and Engineering 5, 1 (1998), 46–55. https://doi.org/10.1109/99.660313

    1998 doi

  3. [11]

    Alper Goksoy, Sahil Hassan, Anish Krishnakumar, Radu Marculescu, Ali Akoglu, and Umit Y

    A. Alper Goksoy, Sahil Hassan, Anish Krishnakumar, Radu Marculescu, Ali Akoglu, and Umit Y. Ogras. 2023. Theoretical Validation and Hardware Implementation of Dynamic Adaptive Scheduling for Heterogeneous Systems on Chip. Journal of Low Power Electronics and Applications 13, 4...

    2023 doi

  4. [12]

    Guthaus, J.S

    M.R. Guthaus, J.S. Ringenberg, D. Ernst, T.M. Austin, T. Mudge, and R.B. Brown. 2001. MiBench: A free, commercially representative embedded benchmark suite. InProceedings of the Fourth Annual IEEE International Workshop on Workload Characterization. WWC-4 (Cat. No.01EX538). 3–...

    2001

  5. [13]

    Anakhi Hazarika, Soumyajit Poddar, and Hafizur Rahaman. 2020. Survey on memory management techniques in heterogeneous computing systems. IET Computers & Digital Techniques 14, 2 (2020), 47–60. https://doi.org/10.1049/iet- cdt.2019.0092 arXiv:https://ietresearch.onlinelibrary.w...

    2020

  6. [14]

    John L Hennessy and David A Patterson. 2019. A New Golden Age for Computer Architecture. Commun. of the ACM 62, 2 (2019), 48–60

    2019

  7. [15]

    Mingqiang Huang, Ao Shen, Kai Li, Haoxiang Peng, Boyu Li, Yupeng Su, and Hao Yu. 2025. EdgeLLM: A Highly Efficient CPU-FPGA Heterogeneous Edge Accelerator for Large Language Models. IEEE Transactions on Circuits and Systems I: Regular Papers (2025), 1–14. https://doi.org/10.11...

    2025

  8. [16]

    2012.Memory Architecture and Management in an NoC Platform

    Axel Jantsch, Xiaowen Chen, Abdul Naeem, Yuang Zhang, Sando Penolazzi, and Zhonghai Lu. 2012.Memory Architecture and Management in an NoC Platform . Springer New York, New York, NY, 3–31. https://doi.org/10.1007/978-1-4419- 6778-7_1

    2012 doi

  9. [18]

    Robert Karam, Somnath Paul, Ruchir Puri, and Swarup Bhunia. 2017. Memory-Centric Reconfigurable Accelerator for Classification and Machine Learning Applications. J. Emerg. Technol. Comput. Syst. 13, 3, Article 34 (may 2017), 24 pages. https://doi.org/10.1145/2997649

    2017 doi

  10. [19]

    Hyojong Kim, Jaewoong Sim, Prasun Gera, Ramyad Hadidi, and Hyesoon Kim. 2020. Batch-Aware Unified Memory Management in GPUs for Irregular Workloads. In Proceedings of the Twenty-Fifth International Conference on Architec- tural Support for Programming Languages and Operating S...

    2020

  11. [20]

    Jungwon Kim, Seyong Lee, Beau Johnston, and Jeffrey S. Vetter. 2024. IRIS: A Performance-Portable Framework for Cross-Platform Heterogeneous Computing. IEEE Transactions on Parallel and Distributed Systems 35, 10 (2024), 1796–1809. https://doi.org/10.1109/TPDS.2024.3429010

    2024

  12. [21]

    Kalhan Koul, Jackson Melchert, Kavya Sreedhar, Leonard Truong, Gedeon Nyengele, Keyi Zhang, Qiaoyi Liu, Jeff Setter, Po-Han Chen, Yuchen Mei, Maxwell Strange, Ross Daly, Caleb Donovick, Alex Carsello, Taeyoung Kong, Kathleen Feng, Dillon Huff, Ankita Nayak, Rajsekhar Setaluri,...

    2025

  13. [22]

    Anish Krishnakumar, Umit Ogras, Radu Marculescu, Mike Kishinevsky, and Trevor Mudge. 2023. Domain-specific architectures: Research problems and promising approaches. ACM Transactions on Embedded Computing Systems 22, 2 (2023), 1–26

    2023

  14. [23]

    Jaewon Kwon, Yongju Lee, Hongju Kal, Minjae Kim, Youngsok Kim, and Won Woo Ro. 2023. McCore: A Holistic Management of High-Performance Heterogeneous Multicores. InProceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture (Toronto, ON, Canada) (MICRO ...

    2023

  15. [24]

    Alberto Lerner and Gustavo Alonso. 2024. Data Flow Architectures for Data Processing on Modern Hardware. In 2024 IEEE 40th International Conference on Data Engineering (ICDE) . 5511–5522. https://doi.org/10.1109/ICDE60146.2024. 00439

    2024

  16. [25]

    Arda, Umit Y

    Joshua Mack, Samet E. Arda, Umit Y. Ogras, and Ali Akoglu. 2022. Performant, Multi-Objective Scheduling of Highly Interleaved Task Graphs on Heterogeneous System on Chip Devices. IEEE Transactions on Parallel and Distributed Systems 33, 9 (2022), 2148–2162. https://doi.org/10....

    2022

  17. [26]

    Umut Suluhan, and Ali Akoglu

    Joshua Mack, Serhan Gener, Sahil Hassan, H. Umut Suluhan, and Ali Akoglu. 2023. CEDR-API: Productive, Performant Programming of Domain-Specific Embedded Systems. In 2023 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW). 16–25. https://doi.org...

    2023

  18. [27]

    Joshua Mack, Sahil Hassan, Nirmal Kumbhare, Miguel Castro Gonzalez, and Ali Akoglu. 2023. CEDR: A Compiler- integrated, Extensible DSSoC Runtime. ACM Trans. Embed. Comput. Syst. 22, 2, Article 36 (jan 2023), 34 pages. https://doi.org/10.1145/3529257

    2023 doi

  19. [28]

    Ogras, and Ali Akoglu

    Joshua Mack, Nirmal Kumbhare, Anish NK, Umit Y. Ogras, and Ali Akoglu. 2020. User-Space Emulation Framework for Domain-Specific SoC Design. In 2020 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW). 44–53. https://doi.org/10.1109/IPDPSW50202.2...

    2020

  20. [29]

    Sparsh Mittal and Jeffrey S. Vetter. 2015. A Survey of CPU-GPU Heterogeneous Computing Techniques. ACM Comput. Surv. 47, 4, Article 69 (jul 2015), 35 pages. https://doi.org/10.1145/2788396

    2015 doi

  21. [30]

    Abbass Nasser, Hussein Al Haj Hassan, Jad Abou Chaaya, Ali Mansour, and Koffi-Clément Yao. 2021. Spectrum sensing for cognitive radio: Recent advances and future challenge. Sensors 21, 7 (2021), 2408

    2021

  22. [31]

    John Nickolls, Ian Buck, Michael Garland, and Kevin Skadron. 2008. Scalable parallel programming with cuda: Is cuda the parallel programming model that application developers have been waiting for? Queue 6, 2 (2008), 40–53

    2008

  23. [32]

    d.].Jetson AGX Xavier Evaluation Board

    Nvidia AGX [n. d.].Jetson AGX Xavier Evaluation Board. Retrieved September 06, 2024 from https://www.nvidia.com/en- us/autonomous-machines/embedded-systems/jetson-agx-xavier/

    2024

  24. [33]

    Maurice Peemen, Arnaud A. A. Setio, Bart Mesman, and Henk Corporaal. 2013. Memory-centric accelerator design for Convolutional Neural Networks. In 2013 IEEE 31st International Conference on Computer Design (ICCD) . 13–19. https://doi.org/10.1109/ICCD.2013.6657019

    2013

  25. [34]

    Peralta-Ochoa, Pedro A

    Angélica M. Peralta-Ochoa, Pedro A. Chaca-Asmal, Luis F. Guerrero-Vásquez, Jorge O. Ordoñez-Ordoñez, and Edwin J. Coronel-González. 2023. Smart Healthcare Applications over 5G Networks: A Systematic Review. Applied Sciences 13, 3 (2023). https://doi.org/10.3390/app13031469

    2023 doi

  26. [35]

    Bharath Pichai, Lisa Hsu, and Abhishek Bhattacharjee. 2014. Architectural support for address translation on GPUs: designing memory management units for CPU/GPUs with unified address spaces. SIGARCH Comput. Archit. News 42, 1 (feb 2014), 743–758. https://doi.org/10.1145/265482...

    2014

  27. [36]

    Hill, and David A

    Jason Power, Mark D. Hill, and David A. Wood. 2014. Supporting x86-64 address translation for 100s of GPU lanes. In 2014 IEEE 20th International Symposium on High Performance Computer Architecture (HPCA) . 568–578. https: //doi.org/10.1109/HPCA.2014.6835965

    2014

  28. [37]

    Shi, H.-H.S

    W. Shi, H.-H.S. Lee, M. Ghosh, and C. Lu. 2004. Architectural support for high speed protection of memory integrity and confidentiality in multiprocessor systems. In Proceedings. 13th International Conference on Parallel Architecture and Compilation Techniques, 2004. PACT 2004...

    2004 arXiv

  29. [38]

    Umut Suluhan, Serhan Gener, Alexander Fusco, Joshua Mack, Ismet Dagli, Mehmet Belviranli, Cagatay Edemen, and Ali Akoglu

    H. Umut Suluhan, Serhan Gener, Alexander Fusco, Joshua Mack, Ismet Dagli, Mehmet Belviranli, Cagatay Edemen, and Ali Akoglu. 2024. A Runtime Manager Integrated Emulation Environment for Heterogeneous SoC Design with RISC-V Cores. In 2024 IEEE International Parallel and Distrib...

    2024

  30. [39]

    Hong Enriquez, Dejan Milojicic, Eitan Frachtenberg, and Sitao Huang

    Hongzheng Tian, Alok Mishra, Zhiheng Chen, Rolando P. Hong Enriquez, Dejan Milojicic, Eitan Frachtenberg, and Sitao Huang. 2025. HeteroBench: Multi-kernel Benchmarks for Heterogeneous Systems. In Proceedings of the 16th ACM/SPEC International Conference on Performance Engineer...

    2025

  31. [40]

    Gabriele Tombesi, Joseph Zuckerman, Paolo Mantovani, Davide Giri, Maico Cassel dos Santos, Tianyu Jia, David Brooks, Gu-Yeon Wei, and Luca P. Carloni. 2023. SoCProbe: Compositional Post-Silicon Validation of Heterogeneous NoC-Based SoCs. IEEE Design & Test 40, 6 (2023), 64–75....

    2023

  32. [41]

    Bram van Berlo, Amany Elkelany, Tanir Ozcelebi, and Nirvana Meratnia. 2021. Millimeter wave sensing: A review of application pipelines and building blocks. IEEE Sensors Journal 21, 9 (2021), 10332–10368

    2021

  33. [42]

    Rath Vannithamby and Shilpa Talwar. 2017. Towards 5G: Applications, requirements and candidate technologies . John Wiley & Sons

    2017

  34. [43]

    Xilinx ZCU102 [n. d.]. ZCU102 Evaluation Board. Retrieved September 06, 2024 from https://docs.amd.com/v/u/en- US/ug1182-zcu102-eval-bd

    2024

  35. [44]

    Georgios Zacharopoulos, Adel Ejjeh, Ying Jing, En-Yu Yang, Tianyu Jia, Iulian Brumar, Jeremy Intan, Muhammad Huzaifa, Sarita Adve, Vikram Adve, Gu-Yeon Wei, and David Brooks. 2023. Trireme: Exploration of Hierarchical Multi-level Parallelism for Hardware Acceleration. ACM Tran...

    2023 doi

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.