Pith. sign in

REVIEW 3 major objections 7 minor 1 cited by

Efficiency, Expressivity, and Extensibility in a Close-to-Metal NPU Programming Interface

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

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

Pith's one-line read A deferred-resolution API lets all 27 tested NPU designs be expressed with 25.53% less code and functionally equivalent output.

desk verdict Solid API redesign for IRON with rigorous expressivity checks; efficiency claim rests on author-written SLOC/Halstead proxies, so the 'designer efficiency' headline needs softening. read the letter →

arxiv 2504.18430 v1 pith:DKIUI7X2 submitted 2025-04-25 cs.SE

Erika Hunhoff , Joseph Melber , Kristof Denolf , Andra Bisca , Samuel Bayliss , Stephen Neuendorffer , Jeff Fifield , Jack Lo
show 3 more authors
Pranathi Vasireddy Phil James-Roxby Eric Keller
This is my paper · ORCID
classification cs.SE
keywords efficiencyexpressivityextensibilityNPUprogrammingIRONdeferredresolutionTensorAccessPatternplacement
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

This paper argues that the programming interface of a close-to-metal NPU toolkit is a place where large usability gains can be made without changing the abstraction level. It presents a new IRON API, layered above the existing MLIR-based IRON interface, that delays MLIR generation until a design is resolved, infers object-fifo endpoints and names, and introduces Worker, Runtime, and Program constructs. The paper claims this interface lets all 27 evaluated designs be re-expressed with an average 25.53% SLOC reduction and lower Halstead vocabulary and effort, while 20 of 27 designs produce identical MLIR after declaration ordering and aggregate latency differs by less than 0.09%. It further claims the new placement and data-transformation interfaces are extensible, demonstrated by a 64-line sequential placer and a 277-line 2-D tensor tiler. If these claims hold, performance engineers can write and maintain NPU designs more cheaply without giving up low-level control.

What carries the argument

The load-bearing mechanism is deferred resolution, implemented by a resolvable Python interface: instead of constructing MLIR operations at Python-object creation time, objects such as ObjectFifo, Worker, Runtime, and Program store a description and only emit MLIR when resolve_program invokes their resolve methods. This single change removes required duplication, such as a core block and its object-fifo endpoint each naming the same tile, allows names and depths to be defaulted, and creates a natural interception point for the Placer interface, whose make_placement method calls place on every Placeable component before generation. A second mechanism is taplib's TensorAccessPattern, a tensor shape plus sizes, strides, and offset, and TensorAccessSequence, a list of matching taps, with access-count and access-order maps that let alternative DMA configurations be checked for access equivalence, meaning identical access maps, rather than exact numeric equality. The Worker/Runtime/Program decomposition carries the rest: task definition is separated from how a task is configured and sequenced, which is what lets metaprogramming fill in arbitrary Python values at resolve time.

What would settle it

Have a group of programmers who did not design the new API rewrite the same 27 designs from the paper using only its documentation, then compare SLOC, Halstead metrics, generated MLIR, and measured latency; if the average reduction does not reproduce or any rewritten design produces different numerical output on identical inputs, the headline efficiency and expressivity claims would be falsified.

Watch

Extended reading notes

Core claim

The central discovery is that an API designed around deferred resolution can make a low-level accelerator programming toolkit substantially more concise while preserving its output. Every Python object in the new IRON interface inherits from a resolvable class, so MLIR operations are only created when resolve_program is called; this lets ObjectFifo declarations omit endpoint locations, auto-generate names and handles, and lets the new Worker/Runtime/Program structure separate task definition from configuration. Across 27 designs spanning copying kernels to a streaming edge-detection pipeline, the new interface yields, on average, 25.53% fewer lines of code and lower Halstead vocabulary and effort. Functionality is preserved: after normalizing declaration order, 20 of 27 designs generate identical MLIR; three designs use DMA sizes and strides that differ but are access-equivalent; four differ only in broadcast recipient ordering; and the sum of average latencies across designs differs by under 0.09%, attributed to noise. The same interface adds a Placer hook and a TensorAccessPattern/TensorAccessSequence library, and the paper shows both can be extended by non-compiler engineers to generate valid designs.

Load-bearing premise

The load-bearing premise is that the 27 chosen designs, and the fact that the API's authors rewrote them, represent how typical IRON users write and will write NPU programs, so the measured code reductions and the expressivity claim generalize beyond these examples.

Editorial extensions

If this is right

  • Performance engineers can prototype and maintain NPU designs with about a quarter less code, with the savings concentrated in repetitive placement, naming, and DMA-description boilerplate.
  • The new API coexists with the old one, so existing IRON designs can migrate incrementally rather than being rewritten at once.
  • Because placement is a Placer hook, automated search over placements becomes a normal extension point rather than a compiler rewrite.
  • Access equivalence gives a practical correctness criterion for DMA-level tiling choices: two configurations that produce the same access maps may be treated as interchangeable.
  • The tiny aggregate latency difference, under 0.09%, supports using the new interface as a drop-in replacement in performance-sensitive designs.

Reading between the lines

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

  • The deferred-resolution pattern is not tied to IRON's specific constructs; other MLIR-based accelerator frontends that suffer from construction-order constraints could adopt the same resolvable-object design and likely realize similar boilerplate reductions, though this paper does not test that transfer.
  • Access maps could be repurposed as an automated oracle: property-based tests for tiling generators could assert that generated taps have the intended access count and order, catching logical tiling errors before hardware runs.
  • Because the same authors rewrote both versions, the 25.53% figure is an upper-bound estimate of the efficiency gain; independent users unfamiliar with the library would be the fair test.
  • The Placer interface's simplicity, 64 lines for a functional placer, suggests design-space-exploration tools, such as randomized or search-based placement tuning, could be built entirely at the Python level.
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 paper presents a new Python API for IRON, an MLIR-based toolkit for programming AMD XDNA NPUs at a close-to-metal level. The API introduces deferred resolution of MLIR constructs, refines the ObjectFifo interface with handles and inferred endpoints, adds Worker/Runtime/Program abstractions, provides an extensible Placer interface for automatic placement, and includes taplib, a library for expressing and reasoning about DMA data transformations via TensorAccessPatterns and TensorAccessSequences. The contributions are evaluated on 27 IRON designs: the authors report a 25.53% average SLOC reduction and lower Halstead metrics, claim that all designs remain expressible (20 of 27 generate identical MLIR after controlling for declaration order, 3 are access-equivalent, and 4 differ only in broadcast recipient order), and demonstrate that aggregate latency differs by less than 0.09% between old and new versions. Extensibility is illustrated through a SequentialPlacer implementation and a TensorTiler2D data-transformation generator.

Significance. If the claims hold, this work offers a meaningful improvement to a real, open-source NPU programming toolkit. The strongest parts are the expressivity and extensibility evaluations: the MLIR comparison is a concrete, machine-checkable check of functional equivalence, and the custom Placer and TensorTiler2D are working, non-trivial extensions that validate the extension interfaces. The paper is also commendable for evaluating on 27 designs of varied complexity, for openly acknowledging that the metrics are imperfect, and for integrating the API into the public mlir-aie repository. The main weakness is that the central 'designer efficiency' claim rests on SLOC and Halstead metrics, which are indirect proxies for human effort and may be biased by the fact that all rewrites were performed by the API authors. This is an external-validity concern rather than an internal contradiction, but it affects the paper's headline claim.

major comments (3)
  1. [Section VII-A, Abstract] The claim that the new API 'increase[s] efficiency of designers' (abstract, Section I) is not directly supported by SLOC and Halstead metrics. These metrics measure textual properties of source code, not designer effort, error rates, or time-to-completion. Section VII-A states 'These metrics are imperfect,' but the abstract and conclusion present the efficiency result as established. The authors should either soften the claim to 'code brevity' or 'reduction in code size and complexity metrics,' or provide additional evidence linking the metric reductions to designer efficiency—for example, a small user study or a detailed qualitative discussion of how the removed boilerplate corresponds to cognitive load. The fact that both the 'before' and 'after' versions were written by the API authors should also be discussed as a potential bias.
  2. [Section VII-B] The MLIR comparison procedure is not fully specified. The paper says 'Controlling for the order of declarations, 20 of 27 designs generate identical MLIR,' but it does not describe how declaration order was normalized or how the comparison was performed mechanically. More importantly, for the three designs (GEMM, MVAdd, MTranspose) that differ in runtime DMA transfer sizes and strides, the paper asserts that the access patterns are 'access equivalent' and therefore functionally equivalent. This inference should be justified: access equivalence as defined in taplib (same access order and count maps) must be shown to imply equivalence of the generated DMA behavior in the IRON context, including any effects on synchronization or performance. Please provide the normalization procedure and a precise argument for why access equivalence is sufficient for functional equivalence.
  3. [Section VII-A2] The Halstead analysis is presented in a way that is difficult to interpret. The sentence 'Across all designs for all negative Halstead metrics ... the average of the metric is lower for designs written post-contribution' is ambiguous: it is unclear what 'negative Halstead metrics' means and which of the Halstead metrics (volume, difficulty, effort, vocabulary, length, etc.) were actually computed. Only vocabulary and effort are shown in Figure 5. The authors should specify the complete set of Halstead metrics considered, report the direction and magnitude of change for each, and clarify whether the claim holds for every metric or only for a subset. This matters because the efficiency claim is partly based on these numbers.
minor comments (7)
  1. [Section V-2] The statement 'The default depth of ObjectFifos is set to 2 (due to the prevalence of ping-pong buffers)' is a design choice worth explaining briefly; it would help to note that this default can be overridden per ObjectFifo.
  2. [Section V-3] The sentence 'A runtime sequence does not have the freedom to represent arbitrary computations' is evocative but could be expanded: clarifying that this restriction is intentional and distinguishes runtime sequencing from core computation would help readers understand the design rationale.
  3. [Figure 2] The two code listings in Figure 2 are central to understanding the paper, but the small font and dense layout make them hard to read in a single-column format. Please consider a larger font or splitting the figure.
  4. [Table I] Rows with multiple variants (e.g., Copy ×3, VReduce ×3) list three SLOC pairs without labels. Adding short variant names (e.g., 'Copy DMA', 'Copy kernel', 'Copy external kernel') would make the table easier to interpret.
  5. [Section VII-B] The latency comparison reports an average percentage difference of 3.36% and an aggregate difference of less than 0.09%, but no per-design values, confidence intervals, or statistical tests are provided. A small table or plot of per-design latency differences would strengthen the claim that the differences are attributable to system noise.
  6. [Section VII-C1] The SequentialPlacer is described as rudimentary and able to yield invalid placements, which is appropriately honest. It might be worth adding a sentence explaining that the Placer interface supports fallback to manual placement, as demonstrated by GEMM and ResNetConv2x.
  7. [Section VIII] The related-work section mentions prior work on AI Engine programming models [23], [25] but does not provide a direct comparison of efficiency or expressivity with the proposed API. A brief comparison would help position the contributions.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's claims are empirical comparisons against a pre-existing IRON interface and measured hardware artifacts, not derivations from its own inputs.

full rationale

This paper reports no formal derivation, fitted model, or predicted quantity. The central claims are measured: a 25.53% average SLOC reduction and lower Halstead metrics are computed from 27 before/after design pairs (Section VII-A), expressivity is checked by comparing generated MLIR and runtime latency against the pre-existing IRON implementation (Section VII-B), and extensibility is demonstrated by constructing working Placer and TensorTiler2D extensions (Section VII-C). None of these results is defined in terms of the new API's own output: the 'before' versions are written with the existing IRON interface, and the 'after' versions are compared against that external baseline, including a functional equivalence check via generated MLIR and measured latency. The only self-referential element is that the API's authors also wrote the rewritten designs, which is a potential evaluator-bias or external-validity threat rather than a circularity: the paper itself concedes the metrics are imperfect and that the designs are intended to capture representative trends. No load-bearing argument reduces to a self-citation, and no uniqueness theorem or fitted parameter is imported from prior author work to force the conclusion. Accordingly, the circularity score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claims rest on no fitted parameters and introduce no new physical entities. The key assumptions are the representativeness of the evaluation corpus, the validity of code metrics as proxies for designer effort, and the correctness of the underlying MLIR and hardware descriptions, all of which are either stated or inherited from cited prior work.

assumptions (4)
  • domain assumption MLIR operations must be complete and properly placed in the context at construction time, which motivates deferred resolution.
    Section V-1 states MLIR requires an operation to be complete at construction and properly placed in the MLIR context. The new API's deferred resolution is built around this constraint, and the paper's claims of reduced duplication assume this constraint is real and binding.
  • domain assumption The 27 benchmark designs cover the key features and patterns supported by IRON.
    Section VII-B asserts coverage of L2 memory, shared memory, tiling, broadcast, split/join, window, skip, pipeline, metaprogramming, and NPU columns. If the corpus misses important IRON patterns, the expressivity claim is overgeneralized.
  • domain assumption SLOC and Halstead metrics are meaningful proxies for designer efficiency.
    Section VII-A says 'These metrics are imperfect, but we posit...'. The efficiency result rests on this assumption; no user study is reported.
  • domain assumption AMD XDNA NPU hardware behaves as described in the cited architecture paper [41], including explicit data movement, locks, and DMA capabilities.
    The entire IRON toolkit and the new API assume the described hardware semantics. The paper does not independently verify hardware behavior; it relies on prior documentation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Efficiency, Expressivity, and Extensibility in a Close-to-Metal NPU Programming Interface." pith.science (2026). https://pith.science/paper/DKIUI7X2

@misc{pith2026250418430,
  author       = {Pith},
  title        = {Pith review of: Efficiency, Expressivity, and Extensibility in a Close-to-Metal NPU Programming Interface},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DKIUI7X2}},
  note         = {Machine review of arXiv:2504.18430}
}
read the original abstract

Accelerators such as neural processing units (NPUs) deliver an enticing balance of performance and efficiency compared to general purpose compute architectures. However, effectively leveraging accelerator capabilities is not always simple: low-level programming toolkits may require substantial developer effort while high-level programming toolkits may abstract critical optimization features. This work aims to increase efficiency of designers using IRON, a toolkit for close-to-metal NPU performance engineers. We provide an updated programmer interface to IRON containing new and refined programming constructs. The new interface includes extensible features for placement and data transformation. These contributions are evaluated in terms of 1) efficiency, with analysis showing ~26% average reduction in lines of code and decreases in Halstead metrics for a variety of designs; 2) expressivity, demonstrating the new interface supports the wide range of features and patterns already supported by IRON; and 3) extensibility, illustrating the new tooling for placement and tiling can be extended to accommodate common use-cases.

Figures

Figures reproduced from arXiv: 2504.18430 by the authors.

Figure 1
Figure 1. Simplified diagram of an AMD XDNA™ NPU such as found in Ryzen™ 7040 processors [41]. A. AMD XDNA™ NPU Architecture An AMD XDNA™ neural processing unit (NPU) con￾sists of several types of tiles arranged spatially in a two￾dimensional grid connected by a streaming interconnect. NPUs are designed for power- and area-efficient inference: the AMD XDNA™ NPU found in Ryzen™ 7040 and 8040 SoCs provides >10 trillion operatio… view at source ↗
Figure 2
Figure 2. A matrix-scalar addition IRON design written without (2a) and with (2b) contributions. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Heat maps generated by taplib representing access order (top) and access count (bottom). 5) Primitives for on-the-fly Data Transformations: One point of complexity stands out in Fig. 2b: the sizes and strides (lines 19-20). Reasoning about transformations from just looking at sizes and strides can be difficult. To address this, we create taplib, a library containing two primitive ab￾stractions for expressing and rea… view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Average percent decrease of SLOC per design. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. HeteroMosaic: Exposing and Exploiting Heterogeneous Execution Opportunities for Energy-Efficient Edge LLM Inference

    cs.DC 2026-07 conditional novelty 7.0 of 10

    HeteroMosaic uses micro-batching and trace-guided co-optimization to split edge LLM prefill across iGPU and NPU, achieving up to 1.73-2.05x speedups and 45.3% energy reduction on AMD Ryzen AI.

Reference graph

Works this paper leans on

50 extracted references · 47 canonical work pages · cited by 1 Pith paper

  1. [1]

    Xilinx first 7nm device: Versal AI Core (VC1902)

    Sagheer Ahmad, Sridhar Subramanian, Vamsi Boppana, Shankar Lakka, Fu-Hing Ho, Tomai Knopp, Juanjo Noguera, Gaurav Singh, and Ralph Wittig. Xilinx first 7nm device: Versal AI Core (VC1902). In 2019 IEEE Hot Chips 31 Symposium (HCS), Cupertino, CA, USA, August 18-20, 2019, pages 1–28. IEEE, 2019

    work page 2019

  2. [2]

    https://www.amd.com/en/products/adaptive-socs-and-fpgas/ technologies/ai-engine.html

    AI Engine: Meeting the compute demands of next-generation ap- plications. https://www.amd.com/en/products/adaptive-socs-and-fpgas/ technologies/ai-engine.html. Accessed 5 January 2025

    work page 2025

  3. [3]

    https://docs.amd.com/r/en-US/ am020-versal-aie-ml/AIE-ML-Trace-and-Profiling

    AIE-ML trace and profiling. https://docs.amd.com/r/en-US/ am020-versal-aie-ml/AIE-ML-Trace-and-Profiling. Accessed 5 January 2025

    work page 2025

  4. [4]

    Evalua- tion of Halstead and cyclomatic complexity metrics in measuring defect density

    Mahmoud Alfadel, Armin Kobilica, and Jameleddine Hassine. Evalua- tion of Halstead and cyclomatic complexity metrics in measuring defect density. In 2017 9th IEEE-GCC Conference and Exhibition (GCCCE) , pages 1–9, 2017

    work page 2017

  5. [5]

    https://www.amd.com/en/developer/ resources/ryzen-ai-software.html

    AMD Ryzen™ AI software. https://www.amd.com/en/developer/ resources/ryzen-ai-software.html. Accessed 5 January 2025

    work page 2025

  6. [6]

    https://www.amd.com/en/newsroom/press-releases/ 2024-6-2-amd-unveils-next-gen-zen-5-ryzen-processors-to-p.html, June 2024

    AMD unveils next-gen “Zen 5” Ryzen processors to power advanced AI experiences. https://www.amd.com/en/newsroom/press-releases/ 2024-6-2-amd-unveils-next-gen-zen-5-ryzen-processors-to-p.html, June 2024. Accessed 5 January 2025

    work page 2024

  7. [7]

    C. T. Bailey and W. L. Dingee. A software study using Halstead metrics. SIGMETRICS Perform. Eval. Rev. , 10(1):189–197, January 1981

    work page 1981

  8. [8]

    Landscape of high-performance Python to develop data science and machine learning applications

    Oscar Castro, Pierrick Bruneau, Jean-S ´ebastien Sottet, and Dario Torre- grossa. Landscape of high-performance Python to develop data science and machine learning applications. ACM Computing Surveys , 56(3), October 2023

    work page 2023

Show all 50 references
  1. [9]

    Exploiting the expressiveness of cyclo-static dataflow to model multimedia implementations

    Kristof Denolf, Marco Bekooij, Johan Cockx, Diederik Verkest, and Henk Corporaal. Exploiting the expressiveness of cyclo-static dataflow to model multimedia implementations. EURASIP Journal on Advances in Signal Processing , 2007:1–14, 2007

    2007

  2. [10]

    Parallel computing experiences with CUDA

    Michael Garland, Scott Le Grand, John Nickolls, Joshua Anderson, Jim Hardwick, Scott Morton, Everett Phillips, Yao Zhang, and Vasily V olkov. Parallel computing experiences with CUDA. IEEE Micro, 28(4):13–27, 2008

    2008

  3. [11]

    EX- PRESS: A framework for execution time prediction of concurrent CNNs on Xilinx DPU accelerator

    Shikha Goel, Rajesh Kedia, Rijurekha Sen, and M Balakrishnan. EX- PRESS: A framework for execution time prediction of concurrent CNNs on Xilinx DPU accelerator. ACM Trans. Embed. Comput. Syst. , 24(1), November 2024

    2024

  4. [12]

    Applying Halstead software science on different pro- gramming languages for analyzing software complexity

    Nikhil Govil. Applying Halstead software science on different pro- gramming languages for analyzing software complexity. In 2020 4th International Conference on Trends in Electronics and Informatics (ICOEI)(48184), pages 939–943, 2020

    2020

  5. [13]

    https://radon.readthedocs.io/en/latest/intro.html# halstead-metrics

    Halstead metrics. https://radon.readthedocs.io/en/latest/intro.html# halstead-metrics. Accessed 7 January 2025

    2025

  6. [14]

    Software complexity analysis using Halstead metrics

    T Hariprasad, G Vidhyagaran, K Seenu, and Chandrasegar Thirumalai. Software complexity analysis using Halstead metrics. In 2017 Inter- national Conference on Trends in Electronics and Informatics (ICEI) , pages 1109–1113, 2017

    2017

  7. [15]

    Harris, K

    Charles R. Harris, K. Jarrod Millman, St ´efan J. van der Walt, Ralf Gommers, Pauli Virtanen, David Cournapeau, Eric Wieser, Julian Tay- lor, Sebastian Berg, Nathaniel J. Smith, Robert Kern, Matti Picus, Stephan Hoyer, Marten H. van Kerkwijk, Matthew Brett, Allan Haldane, Jaim...

    2020

  8. [16]

    Deep residual learning for image recognition

    Kaiming He, Xiangyu Zhang, Shaoqing Ren, and Jian Sun. Deep residual learning for image recognition. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (CVPR) , June 2016

    2016

  9. [17]

    PyCUDA and PyOpenCL: A scripting- based approach to GPU run-time code generation

    Andreas Kl ¨ockner, Nicolas Pinto, Yunsup Lee, Bryan Catanzaro, Paul Ivanov, and Ahmed Fasih. PyCUDA and PyOpenCL: A scripting- based approach to GPU run-time code generation. In Proceedings of the 2019 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, Paral...

    2019

  10. [18]

    HeteroCL: A multi-paradigm pro- gramming infrastructure for software-defined reconfigurable computing

    Yi-Hsiang Lai, Yuze Chi, Yuwei Hu, Jie Wang, Cody Hao Yu, Yuan Zhou, Jason Cong, and Zhiru Zhang. HeteroCL: A multi-paradigm pro- gramming infrastructure for software-defined reconfigurable computing. In Proceedings of the 2019 ACM/SIGDA International Symposium on Field-Progra...

    2019

  11. [19]

    Numba: a LLVM- based Python JIT compiler

    Siu Kwan Lam, Antoine Pitrou, and Stanley Seibert. Numba: a LLVM- based Python JIT compiler. In Proceedings of the Second Workshop on the LLVM Compiler Infrastructure in HPC , LLVM ’15, New York, NY , USA, 2015. Association for Computing Machinery

    2015

  12. [20]

    Black: The uncompromising Python code formatter

    Łukasz Langa and contributors to Black. Black: The uncompromising Python code formatter. https://github.com/psf/black. Accessed 5 January 2025

    2025

  13. [21]

    MLIR: Scaling compiler infrastructure for domain specific computation

    Chris Lattner, Mehdi Amini, Uday Bondhugula, Albert Cohen, Andy Davis, Jacques Pienaar, River Riddle, Tatiana Shpeisman, Nicolas Vasi- lache, and Oleksandr Zinenko. MLIR: Scaling compiler infrastructure for domain specific computation. In 2021 IEEE/ACM International Symposium ...

    2021

  14. [22]

    Kevin Lee and Kai-Ting. Wang. PyDSL: A Python subset for a better MLIR programming experience (part II). https://llvm.org/devmtg/ 2024-10/slides/quicktalks/Wang-PyDSL.pdf, 2022

    2024

  15. [23]

    An End-to-End Programming Model for AI Engine Architectures

    Maksim Levental. An End-to-End Programming Model for AI Engine Architectures. PhD thesis, University of Chicago, June 2024

    2024

  16. [24]

    nelli: a lightweight frontend for MLIR, 2023

    Maksim Levental, Alok Kamatar, Ryan Chard, Kyle Chard, and Ian Foster. nelli: a lightweight frontend for MLIR, 2023

    2023

  17. [25]

    An end-to-end programming model for AI Engine architectures

    Maksim Levental, Arham Khan, Ryan Chard, Kyle Chard, Stephen Neuendorffer, and Ian Foster. An end-to-end programming model for AI Engine architectures. In Proceedings of the 14th International Sympo- sium on Highly Efficient Accelerators and Reconfigurable Technologies (HEART)...

    2024

  18. [26]

    mlir-python-extras

    Maksim Levintal. mlir-python-extras. https://github.com/makslevental/ mlir-python-extras. Accessed 28 December 2024

    2024

  19. [27]

    A survey of coarse-grained reconfig- urable architecture and design: Taxonomy, challenges, and applications

    Leibo Liu, Jianfeng Zhu, Zhaoshi Li, Yanan Lu, Yangdong Deng, Jie Han, Shouyi Yin, and Shaojun Wei. A survey of coarse-grained reconfig- urable architecture and design: Taxonomy, challenges, and applications. ACM Comput. Surv., 52(6), October 2019

    2019

  20. [28]

    Levering MLIR to design for AI Engines on Ryzen™ AI

    Jack Lo, Joseph Melber, Kristof Denolf, Phil James-Roxby, and Samuel Bayliss. Levering MLIR to design for AI Engines on Ryzen™ AI. https://github.com/Xilinx/mlir-aie/blob/main/ docs/conferenceDescriptions/micro24TutorialDescription.md, April

  21. [29]

    Leveraging the IRON AI Engine API to program the Ryzen™ AI NPU

    Joseph Melber, Kristof Denolf, and Andrew Schmidt. Leveraging the IRON AI Engine API to program the Ryzen™ AI NPU. https://github.com/Xilinx/mlir-aie/blob/main/docs/ conferenceDescriptions/micro24TutorialDescription.md, Nov 2024. 57th IEEE/ACM International Symposium on Microa...

    2024

  22. [30]

    Canal: A flexible interconnect generator for coarse-grained reconfigurable arrays

    Jackson Melchert, Keyi Zhang, Yuchen Mei, Mark Horowitz, Christo- pher Torng, and Priyanka Raina. Canal: A flexible interconnect generator for coarse-grained reconfigurable arrays. IEEE Computer Architecture Letters, 22(1):45–48, 2023

    2023

  23. [31]

    https://github.com/Xilinx/ mlir-aie

    mlir-aie: MLIR-based AI Engine toolchain. https://github.com/Xilinx/ mlir-aie. Accessed 5 January 2025

    2025

  24. [32]

    https://mlir.llvm.org/docs/Bindings/Python/

    MLIR Python bindings. https://mlir.llvm.org/docs/Bindings/Python/. Accessed 28 December 2024

    2024

  25. [33]

    The OpenCL specification

    Aaftab Munshi. The OpenCL specification. In 2009 IEEE Hot Chips 21 Symposium (HCS) , pages 1–314, 2009

    2009

  26. [34]

    https://www.intel.com/ content/www/us/en/developer/tools/openvino-toolkit/overview.html

    Intel® distribution of OpenVINO™ toolkit. https://www.intel.com/ content/www/us/en/developer/tools/openvino-toolkit/overview.html. Ac- cessed 8 January 2025

    2025

  27. [35]

    Chong, and Matthew Farrens

    Mark Oskin, Frederic T. Chong, and Matthew Farrens. HLS: combining statistical and symbolic simulation to guide microprocessor designs. In Proceedings of the 27th Annual International Symposium on Computer Architecture, ISCA ’00, page 71–82, New York, NY , USA, 2000. Associati...

    2000

  28. [36]

    https://github.com/Xilinx/llvm-aie

    peano: AI Engine fork of LLVM. https://github.com/Xilinx/llvm-aie. Accessed 28 December 2024

    2024

  29. [37]

    https://github.com/roskakori/pygount

    pygount. https://github.com/roskakori/pygount. Accessed 5 January 2025

    2025

  30. [38]

    https://www.qualcomm

    Qualcomm® neural processing SDK for AI. https://www.qualcomm. com/developer/software/neural-processing-sdk-for-ai. Acessed 8 Jan 2025

    2025

  31. [39]

    https://github.com/rubik/radon

    radon. https://github.com/rubik/radon. Accessed 5 January 2025

    2025

  32. [40]

    The future of fast code: Giving hardware what it wants

    Jonathan Ragan-Kelley. The future of fast code: Giving hardware what it wants. https://youtu.be/vU3ryvZYlkk?si=Zk-jRdYFqQ3jcbJp, June

  33. [41]

    AMD XDNA™ NPU in Ryzen™ AI processors

    Alejandro Rico, Satyaprakash Pareek, Javier Cabezas, David Clarke, Baris Ozgul, Francisco Barat, Yao Fu, Stephan M ¨unz, Dylan Stuart, Patrick Schlangen, Pedro Duarte, Sneha Date, Indrani Paul, Jian Weng, Sonal Santan, Vinod Kathail, Ashish Sirasao, and Juanjo Noguera. AMD XDN...

    2024

  34. [42]

    44th ACM SIGPLAN International Conference on Programming Language Design and Implementation (PLDI’24) Keynote

  35. [43]

    Boosting per- formance optimization with interactive data movement visualization

    Philipp Schaad, Tal Ben-Nun, and Torsten Hoefler. Boosting per- formance optimization with interactive data movement visualization. In SC22: International Conference for High Performance Computing, Networking, Storage and Analysis , pages 1–16, 2022

    2022

  36. [44]

    https://mlir.llvm.org/docs/Dialects/SCFDialect/

    ‘scf’ dialect. https://mlir.llvm.org/docs/Dialects/SCFDialect/. Accessed 28 December 2024

    2024

  37. [45]

    https://github.com/llvm/torch-mlir

    Torch-MLIR. https://github.com/llvm/torch-mlir. Accessed 5 January 2025

    2025

  38. [46]

    Philippe Tillet, H. T. Kung, and David Cox. Triton: an intermediate language and compiler for tiled neural network computations. In Pro- ceedings of the 3rd ACM SIGPLAN International Workshop on Machine Learning and Programming Languages, MAPL 2019, page 10–19, New York, NY , ...

    2019

  39. [47]

    https://xilinx.github.io/XRT/2024.2/ html/index.html

    Xilinx runtime (XRT) architecture. https://xilinx.github.io/XRT/2024.2/ html/index.html. Accessed 5 January 2025

    2024

  40. [48]

    Bandwidth-aware loop tiling for DMA-supported scratchpad memory

    Mingchuan Wu, Ying Liu, Huimin Cui, Qingfu Wei, Quanfeng Li, Limin Li, Fang Lv, Jingling Xue, and Xiaobing Feng. Bandwidth-aware loop tiling for DMA-supported scratchpad memory. In Proceedings of the ACM International Conference on Parallel Architectures and Compilation Techni...

  41. [2020]

    Association for Computing Machinery

  42. [2024]

    ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS’24) Tutorial

Pith tools

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