OmniSim: Simulating Hardware with C Speed and RTL Accuracy for High-Level Synthesis Designs

Cong Hao; Rishov Sarkar

REVIEW 3 major objections 5 minor 1 cited by

OmniSim: Simulating Hardware with C Speed and RTL Accuracy for High-Level Synthesis Designs

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

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

Pith's one-line read The paper claims that HLS designs with cyclic dataflow dependencies and non-blocking FIFO accesses—previously unsimulatable at C level—can be simulated at C speed with RTL-accurate functionality and cycle counts, by orchestrating threads ar

desk verdict Extends HLS C-level simulation to non-blocking and cyclic dataflow designs with real speedups, but a static-schedule assumption about blocking writes may break the core query-resolution mechanism. read the letter →

arxiv 2508.19299 v1 pith:DMFG36R7 submitted 2025-08-25 cs.AR cs.PF

Rishov Sarkar , Cong Hao This is my paper

classification cs.ARcs.PF

keywords HLSsimulationdataflowdesignsnon-blockingFIFOcycle-accuratemulti-threadedC/RTLco-simulationdeadlockdetectionincremental

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

OmniSim sets out to close the gap between C simulation and RTL co-simulation for High-Level Synthesis (HLS). The paper identifies a class of dataflow designs—cyclic dependencies, infinite loops, and non-blocking FIFO reads and writes—that commercial HLS tools explicitly declare unsimulatable at the C level, and shows that the root cause is a mismatch: software thread scheduling replaces hardware timing. Its claim is that a simulator can restore correctness by maintaining FIFO tables that record the exact hardware cycle of every FIFO access, and letting a dedicated performance thread answer full/empty queries from those tables. If right, designers get both functionality and cycle-accurate performance for these designs at near-C speed, without generating RTL. The paper demonstrates the claim on eleven such designs, matching co-simulation outputs and cycle counts while running roughly 31x faster on average.

What carries the argument

The central mechanism is a set of FIFO read/write tables maintained by a dedicated performance thread. Each table records every committed read or write with its exact hardware cycle; when a functionality thread hits a non-blocking FIFO operation, it pauses with a query, and the performance thread resolves it by comparing cycles in the table (for example, a write succeeds only if the corresponding read happened earlier). Supporting structures—a partial simulation graph for cycle computation, a query pool for unresolved queries, and a task tracker for deadlock detection—let the threads overlap while keeping timing independent of OS scheduling.

What would settle it

Take a Type C design where two threads issue non-blocking writes to each other's FIFOs at the same earliest hardware cycle, so each query's target is another thread's unresolved future event. If RTL co-simulation shows one of these writes should succeed (or the design should deadlock) while OmniSim's earliest-query-as-false rule makes it fail, the central correctness claim is refuted.

Watch

Extended reading notes

Core claim

The central discovery is that functionality and performance simulation of HLS dataflow designs cannot always be decoupled: in Type B and Type C designs, the outcome of a non-blocking FIFO access depends on the exact hardware cycle, so functional correctness requires timing information. OmniSim achieves this by running one software thread per module, plus a performance thread that owns FIFO read/write tables, a partial simulation graph, and a query pool; threads pause at non-blocking accesses and the performance thread resolves whether the FIFO is full or empty at that cycle. This lets OmniSim simulate designs previously unsupported by any HLS tool, and because the timing tables are shared, t

Load-bearing premise

The load-bearing premise is the heuristic that, when no query can be resolved, the earliest unresolved query can safely be answered as false because all threads are at or beyond that cycle; if that misclassifies a real access, OmniSim could produce wrong functional or cycle results or fail to detect a deadlock.

Editorial extensions

If this is right

HLS users can verify functionality and get cycle-accurate latency for cyclic, non-blocking dataflow designs before RTL generation.
C/RTL co-simulation can be replaced by OmniSim for these designs, cutting simulation from minutes or hours to seconds, with up to 35.9x speedup reported.
FIFO size changes can be evaluated incrementally in microseconds when the stored query constraints still hold, enabling fast design-space exploration.
Large Type A designs also run faster because functionality and performance threads execute in an overlapped manner.
Deadlock detection becomes available at C level, distinguishing true design deadlocks from temporary stalls without hanging the simulator.

Reading between the lines

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

The same FIFO-table orchestration could generalize to other hardware primitives with timing-dependent outcomes, such as shared memories, event counters, or mutex-based access controls.
The earliest-cycle query heuristic, if proven sound, could become the basis for a formal correctness argument: a total order on hardware cycles plus the FIFO-table invariants might certify query resolution without needing RTL simulation.
The Type A/B/C taxonomy could be adopted by HLS tool vendors as a compatibility classification for C-level simulation, steering future language features toward explicit support for non-blocking streaming and feedback loops.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

OmniSim deserves a serious referee. The core contribution is real: a C-level simulation scheme for HLS dataflow designs with non-blocking FIFO accesses and cyclic dependencies, which commercial tools explicitly say they can't handle. The Type A/B/C taxonomy is a useful framing, and the coupled func/perf simulation with FIFO timing tables is a clever and plausible way to get correct timing without RTL. The experiments support the main claim on the eleven presented designs: functional outputs match co-sim, cycle counts are within 0.2%, and speedups over co-sim and LightningSimV2 are credible.

That said, there's a gap in the mechanism. Blocking writes are treated as informative requests, not queries, and threads that do only blocking writes assume infinite FIFO depth and never pause. The paper never explains what happens when a thread mixes blocking writes with later NB accesses. If a blocking write would stall because the FIFO is full, the thread's local cycle for a subsequent NB query is taken from the un-stalled static schedule, not from the real post-stall hardware cycle. Since Table 2 resolves NB queries by comparing source and target cycles, a too-early source can flip the query result and silently change functional behavior. The finalization pass recomputes total cycles but doesn't revisit already-resolved queries. The paper gives no invariant that guarantees each NB query's local cycle is the true hardware cycle, and it's not obvious why that should hold in mixed designs. Their benchmark set may simply not contain a module that does both blocking writes and NB accesses; that's luck, not proof.

Other issues are smaller: the title's 'RTL accuracy' overstates the measured 0.09% average and 0.2% max error; the eleven designs are all author-created; and the simulator source isn't released, only the benchmarks. These are fixable. The blocking-write issue is load-bearing and needs an answer--either a proof that the local cycle invariant holds, or a mechanism to handle the stall.

For the right reader--anyone working on HLS performance simulation or dataflow tooling--this paper is worth engaging with. The ideas are new and the evaluation is honest. I'd send it to peer review, but flag the blocking-write case to the authors as a condition.

Referee Report

3 major / 5 minor

Summary. The paper presents OmniSim, a C-level simulation framework for HLS dataflow designs that aims to support designs with non-blocking FIFO accesses, cyclic dependencies, and multiple behaviors after FIFO access (taxonomy Types A/B/C). OmniSim couples functionality simulation and performance simulation by running one Func Sim thread per dataflow module, coordinated by a central Perf Sim thread that maintains FIFO read/write tables and a partial simulation graph. The paper claims that this approach enables simulation of eleven previously unsupported Type B/C designs with output matching C/RTL co-simulation and cycle counts within 0.2%, while achieving up to 35.9x speedup over co-simulation and up to 6.61x speedup over LightningSimV2 on Type A benchmarks. The paper also introduces a deadlock-detection heuristic, incremental simulation for FIFO depth changes, and several runtime optimizations.

Significance. If the correctness gaps are closed, OmniSim would be a meaningful advance for HLS verification: it addresses a class of dataflow designs that commercial and academic HLS tools explicitly do not support, and it does so without fitting parameters to the co-simulation results (the cycle counts are derived from static schedules and the simulation graph). The taxonomy of Type A/B/C designs and the thread-orchestration mechanism are useful conceptual contributions. However, the evaluation is limited to 11 small, author-created examples, and the paper's own text acknowledges the absence of real-world Type B/C benchmarks. The claimed accuracy is 'near-RTL' rather than exact 'RTL accuracy', as reflected in Figure 8(a). The strengths are the novelty of supporting non-blocking/cyclic dataflow at C level, the external validation against co-simulation, and the demonstrated speedups on the authors' benchmarks.

major comments (3)

[§6.2 Step 3, Table 1, §2.2.1] The handling of finite-capacity blocking writes is inconsistent and potentially load-bearing. Section 2.2.1 states that a blocking write to a full FIFO stalls until space is available, but Section 6.2 Step 3 says only that Func Sim threads pause on empty FIFO reads, with the exception of threads that perform only blocking writes, which 'assume infinite FIFO depth and do not pause.' Table 1 lists FifoRead/Write as informative requests, not queries. Section 7.1, however, states that all threads blocked on 'empty FIFO reads or full FIFO writes' constitute a deadlock, implying blocking writes do stall. For a thread that mixes blocking writes with later NB accesses, the local cycle counter will advance past a full-FIFO blocking write without modeling the stall; the NB query's source cycle is then taken from the un-stalled schedule. The resolution rules in Table 2 compare source and target cyc
[§7.1, footnote 7] The deadlock-detection heuristic that an unresolved query at the earliest cycle can be 'safely resolved as false' is not formally justified. The footnote argues that all threads have progressed to at least the cycle of the earliest unresolved query, and that threads stalled on blocking reads must remain paused until that time. However, a thread paused on a blocking read is at the cycle of its read attempt, which can be earlier than the earliest query; the mere fact that it remains paused does not establish that its local cycle is greater than or equal to the query cycle. The unblocking write may occur later, and the read's completion cycle would then be later, not earlier. Without a precise invariant, the rule could misclassify a query and produce incorrect functional results or fail to detect a genuine deadlock. Given that deadlock detection is a central contribution, a rigorous proof (
[§8.1.1, Fig. 8(a), Title] The empirical evidence for the central claims is limited and the accuracy claim is overstated. The eleven Type B/C designs are all author-created, and the text admits the dataset 'consists mostly of smaller examples' and 'does not limit OmniSim's generality.' Moreover, Figure 8(a) shows cycle-count deviations of up to +0.2% from co-simulation, so the title's 'RTL Accuracy' is not literally supported. To support the generality claim, the evaluation should include at least some externally sourced or substantially larger Type B/C designs, and the accuracy claim should be aligned with the data (e.g., 'near-RTL accuracy').

minor comments (5)

[Title / Abstract] The title says 'RTL Accuracy' while the abstract and Figure 8(a) show near-RTL accuracy with small deviations. Consider changing the title to 'Near-RTL Accuracy' or an equivalent phrase to match the reported results.
[Abstract, §8.2.1, §9] The speedup numbers are inconsistent: the abstract and §8.2.1 state 30.7x geomean and 35.9x best, Figure 8(b) labels show '36x', and the conclusion says 'average speedup of 32.1x'. Please reconcile the averages and use consistent notation.
[Fig. 8(a)] The labels 'Exact', '+0.1%', '+0.2%' are ambiguous—clarify whether they refer to percentage error in cycle counts and make the exact values readable.
[§3.1] The definition of Type B ('only one possible program behavior per FIFO access') is a bit underspecified: it is not clear whether 'behavior' means the control-flow path taken after the access or the effect on data state. A precise formulation would help the reader apply the taxonomy.
[§6.1.1] The LLVM pass that 'identifies dataflow functions' is not described; a brief explanation of the heuristics or criteria would improve reproducibility.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: OmniSim's Type B/C cycle counts are validated externally against co-simulation; the only self-citation (LightningSim) is background and not load-bearing.

full rationale

OmniSim's central claim—cycle-accurate, RTL-matching simulation of Type B/C dataflow designs—does not reduce to its inputs. Cycle counts are produced by composing per-module static schedules with FIFO read/write tables and a partial simulation graph (Secs. 5.2, 6.2), then checked against external C/RTL co-simulation (Fig. 8(a), Table 3). No parameter is fitted to the co-sim outputs, and no query-resolution rule is defined in terms of the reported cycle count. The only self-citations are to the authors' LightningSim work (e.g., Sec. 8.1.3, 'we benefit from the high accuracy of LightningSim's simulation graph approach atop which OmniSim was developed'); this is background and is independently validated by the co-sim comparisons. Two limitation-adjacent assumptions are correctness risks, not circularity: (1) Sec. 6.2 Step 3 exempts blocking-write-only threads by assuming infinite FIFO depth, which can understate stalls in finite-FIFO designs and thereby shift NB-query source cycles used in Table 2; and (2) Sec. 7.1's earliest-query-resolves-false deadlock heuristic is an unproven ordering invariant. These could threaten accuracy in edge cases, but they are not cases where the prediction is definitionally equal to the input or where a fitted parameter is renamed as a prediction. Overall, no significant circularity.

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

OmniSim has no fitted free parameters; its cycle counts are computed from static schedules and a simulation graph. It relies on standard assumptions about HLS static schedules and on an ad hoc heuristic for query resolution that is not formally proven. The FIFO tables are a new data structure with experimental but not formal validation.

assumptions (4)

domain assumption The static schedule output of C synthesis is an accurate model of hardware operation timing.
OmniSim derives dynamic stages and cycle counts from the HLS static schedule (Sec 6.1); if the schedule is inaccurate, the computed cycle counts will be wrong.
domain assumption The simulation graph longest-path analysis correctly computes total latency.
The paper relies on this method, inherited from LightningSim (Sec 5.1, 6.2), and validates it against co-simulation on 11 designs, but assumes it is general.
ad hoc to paper The rule that an unresolved query at the earliest cycle can be resolved as false guarantees forward progress and correctness.
Introduced in Sec 7.1 without formal proof; this heuristic is load-bearing for avoiding simulator deadlock and for making progress when queries cannot be resolved.
domain assumption The LLVM IR instrumentation and runtime library faithfully capture all FIFO and AXI accesses.
Implementation-level assumption; if any hardware intrinsic is missed or mis-instrumented, the FIFO tables and simulation graph will diverge from real hardware behavior.

invented entities (1)

FIFO read/write tables independent evidence
purpose: Track the exact hardware cycle of each FIFO read and write so non-blocking queries can be resolved against hardware timing rather than OS thread scheduling.
The tables are experimentally validated by matching co-simulation cycle counts within 0.2% on 11 designs, but no formal proof of their correctness is given.

how reviews work

0 comments

Cite this review

Pith. "Pith review of OmniSim: Simulating Hardware with C Speed and RTL Accuracy for High-Level Synthesis Designs." pith.science (2026). https://pith.science/paper/DMFG36R7

@misc{pith2026250819299,
  author       = {Pith},
  title        = {Pith review of: OmniSim: Simulating Hardware with C Speed and RTL Accuracy for High-Level Synthesis Designs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DMFG36R7}},
  note         = {Machine review of arXiv:2508.19299}
}

read the original abstract

High-Level Synthesis (HLS) is increasingly popular for hardware design using C/C++ instead of Register-Transfer Level (RTL). To express concurrent hardware behavior in a sequential language like C/C++, HLS tools introduce constructs such as infinite loops and dataflow modules connected by FIFOs. However, efficiently and accurately simulating these constructs at C level remains challenging. First, without hardware timing information, functional verification typically requires slow RTL synthesis and simulation, as the current approaches in commercial HLS tools. Second, cycle-accurate performance metrics, such as end-to-end latency, also rely on RTL simulation. No existing HLS tool fully overcomes the first limitation. For the second, prior work such as LightningSim partially improves simulation speed but lacks support for advanced dataflow features like cyclic dependencies and non-blocking FIFO accesses. To overcome both limitations, we propose OmniSim, a framework that significantly extends the simulation capabilities of both academic and commercial HLS tools. First, OmniSim enables fast and accurate simulation of complex dataflow designs, especially those explicitly declared unsupported by commercial tools. It does so through sophisticated software multi-threading, where threads are orchestrated by querying and updating a set of FIFO tables that explicitly record exact hardware timing of each FIFO access. Second, OmniSim achieves near-C simulation speed with near-RTL accuracy for both functionality and performance, via flexibly coupled and overlapped functionality and performance simulations. We demonstrate that OmniSim successfully simulates eleven designs previously unsupported by any HLS tool, achieving up to 35.9x speedup over traditional C/RTL co-simulation, and up to 6.61x speedup over the state-of-the-art yet less capable simulator, LightningSim, on its own benchmark suite.

Figures

Figures reproduced from arXiv: 2508.19299 by the authors.

**Figure 2.** Accurately simulating hardware functionality and [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗

**Figure 4.** Taxonomy, classification, and examples of dataflow designs. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗

Figures from the paper (4 more)

**Figure 5.** Figure 5: illustrates the key differences between LightningSim and OmniSim. LightningSim adopts a two-stage simulation model that fully decouples functionality simulation from performance simulation. This approach is effective for Type A designs, but is fundamentally limiting …

**Figure 6.** Figure 6: Overview of the OmniSim workflow compared to LightningSim. LightningSim executes functionality simulation [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]

**Figure 7.** Figure 7: Execution workflow of OmniSim. Func Sim threads (yellow background) and the Perf Sim thread (green background) [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

**Figure 8.** Figure 8: Comparisons of OmniSim’s (a) cycle-accuracy and [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

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

Three-Dimensional Continuous Multi-Walled Carbon Nanotubes Network-Toughened Diamond Composite
cond-mat.other 2025-08 unverdicted novelty 6.0 of 10

A diamond-MWCNT composite with a continuous three-dimensional sp2-sp3 network is claimed to reach about 91.6 GPa hardness and 36.4 MPa·m^1/2 fracture toughness, roughly six times tougher than synthetic diamond.

Reference graph

Works this paper leans on

27 extracted references · 21 canonical work pages · cited by 1 Pith paper

[1]

[n. d.]. Verilator. https://www.veripool.org/verilator/

work page
[2]

Mohammed Abderehman, Jayprakash Patidar, Jay Oza, Yom Nigam, Tm Abdul Khader, and Chandan Karfa. 2022. FastSim: A Fast Simulation Framework for High-Level Synthesis. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 41, 5 (May 2022), 1371–1385. doi:10.1109/TCAD.2021.3090339

work page arXiv 2022
[3]

Stefan Abi-Karam, Rishov Sarkar, Dejia Xu, Zhiwen Fan, Zhangyang Wang, and Cong Hao. 2023. INR-Arch: A dataflow architecture and compiler for arbitrary- order gradient computations in implicit neural representation processing. In2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD) . IEEE, 1–9

work page 2023
[4]

Stefan Abi-Karam, Rishov Sarkar, Dejia Xu, Zhiwen Fan, Zhangyang Wang, and Cong Hao. 2023. INR-Arch: A Dataflow Architecture and Compiler for Arbitrary- Order Gradient Computations in Implicit Neural Representation Processing. In Proceedings of the 42nd IEEE/ACM International Conference on Computer-Aided Design (ICCAD ’23). Association for Computing Machi...

work page 2023
[5]

AMD. [n. d.]. Vitis High-Level Synthesis. https://www.xilinx.com/products/ design-tools/vivado/high-level-design.html

work page
[6]

Suhail Basalama and Jason Cong. 2025. Stream-HLS: Towards Automatic Dataflow Acceleration. In Proceedings of the 2025 ACM/SIGDA International Symposium on Field Programmable Gate Arrays. 103–114

work page 2025
[7]

Andrew Canis, Jongsok Choi, Mark Aldham, Victor Zhang, Ahmed Kammoona, Jason H Anderson, Stephen Brown, and Tomasz Czajkowski. 2011. LegUp: high- level synthesis for FPGA-based processor/accelerator systems. In Proceedings of the 19th ACM/SIGDA international symposium on Field programmable gate arrays . 33–36

work page 2011
[8]

Hongzheng Chen, Niansong Zhang, Shaojie Xiang, Zhichen Zeng, Mengjia Dai, and Zhiru Zhang. 2024. Allo: A programming model for composable accelerator design. Proceedings of the ACM on Programming Languages 8, PLDI (2024), 593– 620

work page 2024

Show all 27 references

[9]

Young-Kyu Choi, Yuze Chi, Jie Wang, and Jason Cong. 2020. FLASH: Fast, Parallel, and Accurate Simulator for HLS. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 39, 12 (Dec. 2020), 4828–4841. doi:10.1109/TCAD. 2020.2970597

2020
[10]

Fabrizio Ferrandi, Vito Giovanni Castellana, Serena Curzel, Pietro Fezzardi, Michele Fiorito, Marco Lattuada, Marco Minutoli, Christian Pilato, and Antonino Tumeo. 2021. Invited: Bambu: an Open-Source Research Framework for the High- Level Synthesis of Complex Applications. In...

2021
[11]

Licheng Guo, Yuze Chi, Jason Lau, Linghao Song, Xingyu Tian, Moazin Khatti, Weikang Qiao, Jie Wang, Ecenur Ustun, Zhenman Fang, Zhiru Zhang, and Jason Cong. 2023. TAPA: A Scalable Task-Parallel Dataflow Programming Framework for Modern FPGAs with Co-Optimization of HLS and Phy...

2023 doi
[12]

Sagar Karandikar, Howard Mao, Donggyu Kim, David Biancolin, Alon Amid, Dayeol Lee, Nathan Pemberton, Emmanuel Amaro, Colin Schmidt, Aditya Chopra, et al. 2018. FireSim: FPGA-accelerated cycle-exact scale-out system simulation in the public cloud. In 2018 ACM/IEEE 45th Annual I...

2018
[13]

Ryan Kastner, Janarbek Matai, and Stephen Neuendorffer. 2018. Parallel Pro- gramming for FPGAs. arXiv:1805.03648 [cs] doi:10.48550/arXiv.1805.03648

2018 doi arXiv
[14]

Youngsoo Kim, Shrikant Jadhav, and Clay S Gloster. 2016. Dataflow to hardware synthesis framework on fpgas. In 2016 International Symposium on Computer Architecture and High Performance Computing Workshops (SBAC-PADW). IEEE, 91–96

2016
[15]

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). IEEE, 5511–5522

2024
[16]

Tony Nowatzki, Vinay Gangadhar, Newsha Ardalani, and Karthikeyan Sankar- alingam. 2017. Stream-dataflow acceleration. In Proceedings of the 44th Annual International Symposium on Computer Architecture . 416–429

2017
[18]

Rishov Sarkar, Stefan Abi-Karam, Yuqi He, Lakshmi Sathidevi, and Cong Hao
[19]

Rishov Sarkar and Cong Hao. 2023. LightningSim: Fast and Accurate Trace- Based Simulation for High-Level Synthesis. In2023 IEEE 31st Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM) . IEEE, Marina Del Rey, CA, USA, 1–11. doi:10.1109/FCCM572...

2023
[20]

In 2023 IEEE International Symposium on High- Performance Computer Architecture (HPCA)

FlowGNN: A Dataflow Architecture for Real-Time Workload-Agnostic Graph Neural Network Inference. In 2023 IEEE International Symposium on High- Performance Computer Architecture (HPCA). IEEE, Montreal, QC, Canada, 1099–

2023
[21]

Siemens. [n. d.]. Catapult High-Level Synthesis and Verification. https://eda.sw. siemens.com/en-US/ic/catapult-high-level-synthesis/
[22]

Xilinx. 2021. Basic Examples for Vitis HLS. GitHub

2021
[23]

Rishov Sarkar, Rachel Paul, and Cong Hao. 2024. LightningSimV2: Faster and Scalable Simulation for High-Level Synthesis via Graph Compilation and Optimization. In 2024 IEEE 32nd Annual International Symposium on Field- Programmable Custom Computing Machines (FCCM) . IEEE, Orla...

2024
[24]

Xiaofan Zhang, Haoming Lu, Cong Hao, Jiachen Li, Bowen Cheng, Yuhong Li, Kyle Rupnow, Jinjun Xiong, Thomas Huang, Honghui Shi, Wen-Mei Hwu, and Deming Chen. 2020. SkyNet: A Hardware-Efficient Method for Object Detection and Tracking on Embedded Systems.Proceedings of Machine L...

2020
[25]

Faber, Roger D

Chenfeng Zhao, Clayton J. Faber, Roger D. Chamberlain, and Xuan Zhang. 2024. HLPerf: Demystifying the Performance of HLS-based Graph Neural Networks with Dataflow Architectures. ACM Trans. Reconfigurable Technol. Syst. (April 2024). doi:10.1145/3655627 13

2024 doi
[26]

Xilinx. 2022. Vitis Accel Examples’ Repository. GitHub

2022
[1112]

doi:10.1109/HPCA56546.2023.10071015

2023
[2023]

In 2023 IEEE International Symposium on High- Performance Computer Architecture (HPCA)

FlowGNN: A dataflow architecture for real-time workload-agnostic graph neural network inference. In 2023 IEEE International Symposium on High- Performance Computer Architecture (HPCA). IEEE, 1099–1112

2023

Pith tools

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

[1] [1]

[n. d.]. Verilator. https://www.veripool.org/verilator/

work page

[2] [2]

Mohammed Abderehman, Jayprakash Patidar, Jay Oza, Yom Nigam, Tm Abdul Khader, and Chandan Karfa. 2022. FastSim: A Fast Simulation Framework for High-Level Synthesis. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 41, 5 (May 2022), 1371–1385. doi:10.1109/TCAD.2021.3090339

work page arXiv 2022

[3] [3]

Stefan Abi-Karam, Rishov Sarkar, Dejia Xu, Zhiwen Fan, Zhangyang Wang, and Cong Hao. 2023. INR-Arch: A dataflow architecture and compiler for arbitrary- order gradient computations in implicit neural representation processing. In2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD) . IEEE, 1–9

work page 2023

[4] [4]

Stefan Abi-Karam, Rishov Sarkar, Dejia Xu, Zhiwen Fan, Zhangyang Wang, and Cong Hao. 2023. INR-Arch: A Dataflow Architecture and Compiler for Arbitrary- Order Gradient Computations in Implicit Neural Representation Processing. In Proceedings of the 42nd IEEE/ACM International Conference on Computer-Aided Design (ICCAD ’23). Association for Computing Machi...

work page 2023

[5] [5]

AMD. [n. d.]. Vitis High-Level Synthesis. https://www.xilinx.com/products/ design-tools/vivado/high-level-design.html

work page

[6] [6]

Suhail Basalama and Jason Cong. 2025. Stream-HLS: Towards Automatic Dataflow Acceleration. In Proceedings of the 2025 ACM/SIGDA International Symposium on Field Programmable Gate Arrays. 103–114

work page 2025

[7] [7]

Andrew Canis, Jongsok Choi, Mark Aldham, Victor Zhang, Ahmed Kammoona, Jason H Anderson, Stephen Brown, and Tomasz Czajkowski. 2011. LegUp: high- level synthesis for FPGA-based processor/accelerator systems. In Proceedings of the 19th ACM/SIGDA international symposium on Field programmable gate arrays . 33–36

work page 2011

[8] [8]

Hongzheng Chen, Niansong Zhang, Shaojie Xiang, Zhichen Zeng, Mengjia Dai, and Zhiru Zhang. 2024. Allo: A programming model for composable accelerator design. Proceedings of the ACM on Programming Languages 8, PLDI (2024), 593– 620

work page 2024