Pith. sign in

REVIEW 4 major objections 5 minor 55 references

Aligning Netlist to Source Code using SynAlign

T0 review · 4 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

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

Pith's one-line read SynAlign automatically maps annotated post-optimized netlists to original source code without source locators.

desk verdict First credible graph-alignment approach for netlist-to-source mapping, but the headline accuracy numbers are measured on renamed netlists and dont_touch-preserved nets, so the strong claims outrun the evaluation. read the letter →

arxiv 2501.00921 v1 pith:NXW5DY5T submitted 2025-01-01 cs.AR cs.CL

Sakshi Garg , Jose Renau This is my paper · ORCID
classification cs.ARcs.CL
keywords netlist-to-sourcealignmentsynthesisback-annotationgraphRTLdebuggingcriticalpathtraceabilitynetworkChiselVerilog
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

SynAlign is an automated method for tracing cells in a synthesized, optimized gate-level netlist back to the lines of the original HDL source code, without requiring compilers or synthesis tools to carry source-locator metadata. The paper claims that by treating preserved net names and top-level inputs/outputs as anchors, and then propagating matches through the surrounding connection topology, it can recover the correct source location for annotated netlist cells 50–93% of the time across Verilog and Chisel designs. The practical value is that designers could trace critical-path timing failures to specific source lines in seconds rather than in days of manual correlation, and they could use aggressive optimizations such as flattening and retiming without losing the link back to RTL. The paper also reports resilience to net-rename noise, with alignment accuracy holding until roughly 60% of net names are changed.

What carries the argument

The load-bearing mechanism is the directed net graph with Resolved Points (RPs): nets in both the reference graph (G_ref) and the synthesized graph (G_synth) that have been confidently aligned. Start Resolved Points (SRPs) and End Resolved Points (ERPs) are computed for each net through topological traversal from anchor points; a net in G_synth whose SRPs and ERPs are identical to a net in G_ref is a full match, while half matching accepts a match on only one side, and partial matching scores candidates by shared resolved neighbors. Surrounding matching uses the observation that if all directly connected nodes share one source line, the unresolved node is likely at that line too. The algorithm deliberately aligns the sequential subgraph first (typically about 14% of the netlist), then the combinational logic, keeping the overall complexity below quadratic.

What would settle it

Take a moderately sized design, synthesize it with aggressive retiming and with every internal net renamed to a fresh temporary name (keeping only top-level ports), then run SynAlign on a random sample of annotated cells; if accuracy does not fall well below the reported 50–93% range, the anchor-dependence premise is contradicted, and if it does drop, the noise-tolerance claim is bounded by anchor survival.

Watch

Extended reading notes

Core claim

The paper's central claim is that alignment between a post-synthesis netlist and source code is possible from structure alone: if the synthesis tool preserves a small fraction of net names (typically 5–20%) plus the top-level I/O, those anchors supply start and end points, and iterative full, half, partial, and surrounding matching over the directed net graphs walks the remaining nets back to source-code lines. Across all examined benchmarks, SynAlign correctly identifies the source code location 50–93% of the time, with full and surrounding matches reported as perfectly accurate and half/partial matches carrying the error. The NL2NL experiments show tolerance to approximately 60% random net renames without accuracy loss, and even 100% combinational-name noise when sequential names are preserved. The authors present this as the first automated correlation between netlists and source code separated by multiple tools, including for fully flattened and optimized designs.

Load-bearing premise

The method assumes that synthesis leaves enough stable reference points—top-level inputs/outputs plus the few preserved net names—and enough of the surrounding connection structure intact for matches to propagate; if a flow renames or optimizes away almost every anchor and breaks the local topology, the alignment has no reliable starting point and accuracy degrades.

Editorial extensions

If this is right

  • Frontend designers can receive early timing and power feedback tied to specific source lines before the backend handoff.
  • Design teams can enable flattening and retiming without giving up the ability to trace critical-path cells back to RTL.
  • Backend-to-frontend timing reviews can shift from manual, multi-day netlist tracing to a lookup that returns a source line in seconds.
  • The same structural approach works across synthesis tools and HDLs, provided the HDL can emit Verilog with line-of-code information.
  • SynAlign can produce useful mappings even when a large fraction of net names are changed during synthesis, as long as enough sequential anchors survive.

Reading between the lines

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

  • Because the paper ties accuracy to the survival of anchor links, a natural extension is to predict per-design confidence from the measured fraction of preserved net names, turning the 50–93% range into a flow-specific estimate.
  • The anchor-plus-topology recipe might transfer to tracing other transformed representations, such as optimized compiler IR back to source, though the paper only demonstrates the synthesis setting and synthesis noise is unusually high.
  • A product extension the paper leaves implicit is a GUI that lets a user click a critical-path cell and jump directly to the corresponding RTL line, with full and surrounding matches flagged as high-confidence and half/partial matches flagged as uncertain.
  • Since full and surrounding matches are reported as always accurate while half and partial matches carry the error, a practical deployment could surface only high-confidence matches by default and hide lower-confidence ones.
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

4 major / 5 minor

Summary. The paper presents SynAlign, a tool that aims to automatically map annotated post-synthesis netlists back to the original HDL source code without relying on source locators. The method builds a reference graph (Gre_f) from HDL with line-of-code information and a synthesized graph (Gsynth) from the netlist, then aligns them using anchor points (preserved names and top-level I/O), full+half matching, partial matching, and surrounding matching. The evaluation uses two approaches: an automated netlist-to-netlist (NL2NL) test where a fraction of net names are randomly renamed, and a manual accuracy evaluation where selected variables are preserved with dontTouch/keep directives before synthesis. The paper reports 50-93% manual accuracy across designs and claims tolerance to up to 61% design net changes.

Significance. If the claimed results hold, SynAlign would give chip designers a practical way to trace critical-path cells to RTL lines across multiple synthesis tools, which is a real pain point in iterative design. The manuscript provides a clearly specified algorithm at pseudocode level and a reproducible NL2NL evaluation methodology, which are strengths. However, the evaluation does not currently exercise the central use case: aligning arbitrary post-optimized cells that were not explicitly preserved through synthesis. The reported accuracy figures apply to specially protected nets, and the noise-tolerance claim is based on renaming, not structural transformations. The core idea is promising and the algorithmic description is a useful starting point, but the evidence presented is not yet sufficient to support the paper's headline claims.

major comments (4)
  1. [Abstract; Section 3.1, Listing 4, Figure 5] The claim that SynAlign 'can tolerate up to 61% design net changes without impacting alignment accuracy' is not supported by the NL2NL evaluation. Listing 4 shows that Vsynth is generated by appending '_changed' to a randomly selected subset of net names in Vref; no synthesis transformations such as flattening, retiming, resource sharing, or logic restructuring are applied. The graph topology therefore remains identical, and the experiment measures robustness to name loss, not structural change. The abstract should clearly state that this is name-noise tolerance, or the experiment must be redesigned to include actual synthesis-induced modifications.
  2. [Section 3.2, steps 1-3; Section 4] The Manual Accuracy Evaluation only tests nets that were explicitly preserved through synthesis. Step 1 marks the left-hand side of selected assignment lines as 'dontTouch', Step 3 requires 'keep' or 'set_dont_touch' plus punching through the design in DC, and then the annotated net name is manually changed. The resulting 50-93% accuracy is therefore an accuracy for deliberately preserved nets, not for arbitrary post-optimized netlist cells. Designers tracing critical-path cells would typically annotate ordinary combinational gates or muxes that are not protected. Section 4 concedes that 'This work relies on the availability of Anchor links,' but the experiments never measure behavior when anchors are scarce or when the target net is not preserved. An evaluation on non-preserved, optimization-heavy nets, or a clearly scoped claim that the method only applies to preserved nets, is needed.
  3. [Section 2.3; Table 2; Figure 8] The calc_wt() weighting function in Listing 3 is introduced as being 'based on experiments with benchmarks PipelinedCPU and SingleCycleCPU', and those same two benchmarks appear in the evaluation results in Table 2. Since Figure 8 shows that Partial Matching contributes a substantial fraction of alignments (about 50% for RocketTile_DC), tuning this weighting on the same designs used for reporting accuracy risks self-fitting. The authors should either hold out the tuning designs, report cross-validated accuracy, or perform a sensitivity analysis over the 5x multiplier to show that the reported results are not dependent on this choice.
  4. [Section 2; Table 1] The claim that SynAlign's overall time complexity is 'less than quadratic' is not established. The per-stage complexity O((md-a)*m'd) is quadratic in the worst case unless additional structural properties are proved, and the statement that combinational cells are separated by sequential cells is an informal observation rather than a bound. If the complexity claim is a contribution, the paper should either prove a sub-quadratic bound for the targeted design class or explicitly present the complexity as empirical. As written, Table 1 does not substantiate the 'less than quadratic' statement.
minor comments (5)
  1. [Section 2.3, Listing 3] The calc_wt() function divides by mismatches, but if the synthesized set and reference set are identical, mismatches is zero and the division is undefined. The paper should specify how this edge case is handled (e.g., returning a large constant).
  2. [Section 3.3] The heading 'Performace evaluation' contains a typo; it should read 'Performance evaluation'.
  3. [Section 3.2, paragraph after step 5] The text says 'Figure 5 shows manual marking accuracies,' but Figure 5 is the NL2NL accuracy plot for RocketTile. The manual accuracy results appear to be in Figure 8. This cross-reference should be corrected.
  4. [Section 2, paragraph before Section 2.1] 'Inn digital systems like RocketTile' should read 'In digital systems like RocketTile'.
  5. [Figure 8 description] The description of the crossed part of the bars as 'marked with X' is difficult to interpret without a visible legend in the text; a textual description or a proper legend would improve clarity.

Circularity Check

1 steps flagged · score 2.0 of 10

Mild self-tuning of the partial-matching weight on two evaluation benchmarks; the central alignment claim is otherwise structurally independent.

  1. fitted input called prediction [Section 2.3 (Partial Matching, Listing 3) with evaluation benchmarks in Table 2 and Figures 6/8]
    "We formulated a calc_wt() function based on experiments with benchmarks PipelinedCPU and SingleCycleCPU [27, 28], where match_wt is directly proportional to the number of matches."

    The free weight 5 in calc_wt() was chosen on PipelinedCPU and SingleCycleCPU, and those same two designs are then used in the reported accuracy evaluation (Table 2; Figures 6 and 8). For those designs the accuracy result is partially a report of the tuning set rather than an out-of-sample prediction. The circularity is bounded: the weight is a coarse heuristic rather than a fitted accuracy model, most benchmarks (Mac, Ibtida, Marmot, RocketTile, UnoptRocketTile) were not used to set it, and the NL2NL and manual protocols provide independent structural checks, so the central claim does not reduce to the fit.

full rationale

The main derivation chain is SynAlign's anchor-based graph alignment: same-name Anchor Points seed resolved points, and Full+Half, Partial, and Surrounding matching propagate alignments through graph topology. That chain is not defined in terms of the output it predicts; aligning a synthesized net to a source line requires real structural evidence. The 61% tolerance figure comes from NL2NL testing, which only renames nets and leaves topology unchanged; that is a limited evaluation rather than a circular reduction, and the manual evaluation, although restricted to dont_touch-preserved variables, still requires the matcher to find the correct LoC after the annotated net's name is manually changed. The only concrete tuning loop is calc_wt() being developed on PipelinedCPU and SingleCycleCPU while those designs also appear in the benchmark tables; this mildly compromises those two data points but does not force the reported 50-93% accuracy. Overall the paper is not circular in its core method; the main weaknesses are external-validity limitations, not self-derivation.

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

The central claim does not introduce new physical or formal entities. The only tuned values are the calc_wt multiplier and the surrounding-node count k, both empirically chosen. The important axioms are domain assumptions about how much structure synthesis preserves, which the paper itself flags in the limitations section.

free parameters (2)
  • calc_wt weight multiplier (5) = 5
    Chosen based on experiments with PipelinedCPU and SingleCycleCPU in Section 2.3; this multiplier directly affects partial-match ranking and therefore the reported accuracy on those and other benchmarks.
  • k (average surrounding-node count) = 5
    Used in the complexity expression O(2*k*(m-a)); the paper states it was determined empirically in Section 2.4, though it does not directly affect accuracy.
assumptions (4)
  • domain assumption Synthesis tools preserve a sufficient set of anchor net names (top-level ports and some sequential nets).
    Section 2 and Section 4 state alignment relies on Anchor links; the paper cites a typical 5-20% preserved net-name rate. If this rate drops to zero for some synthesis flow, the algorithm loses its starting points.
  • domain assumption The structural topology of the reference and synthesized graphs remains similar enough that SRP/ERP sets identify correct correspondences after flattening and retiming.
    This is the core premise of the algorithm; it is not proven and is validated only empirically on selected benchmarks.
  • domain assumption A reference graph with line-of-code information can be generated for any HDL translatable to Verilog.
    Section 1 states the approach applies to HDLs translated to Verilog with LoC info; Chisel emission and Verilog source handling are assumed to provide this graph.
  • domain assumption The datatype of driver nodes for equivalent nets is preserved through synthesis.
    Section 2.1 states the datatype of the driver node for Anchor Points is the same; this is used to prune matching candidates.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Aligning Netlist to Source Code using SynAlign." pith.science (2026). https://pith.science/paper/NXW5DY5T

@misc{pith2026250100921,
  author       = {Pith},
  title        = {Pith review of: Aligning Netlist to Source Code using SynAlign},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NXW5DY5T}},
  note         = {Machine review of arXiv:2501.00921}
}
read the original abstract

In current chip design processes, using multiple tools to obtain a gate-level netlist often results in the loss of source code correlation. SynAlign addresses this challenge by automating the alignment process, simplifying iterative design, reducing overhead, and maintaining correlation across various tools. This enhances the efficiency and effectiveness of chip design workflows. Improving characteristics such as frequency through iterative design is essential for enhancing accelerators and chip designs. While synthesis tools produce netlists with critical path information, designers often lack the tools to trace these netlist cells back to their original source code. Mapping netlist components to source code provides early feedback on timing and power for frontend designers. SynAlign automatically aligns post-optimized netlists with the original source code without altering compilers or synthesis processes. Its alignment strategy relies on the consistent design structure throughout the chip design cycle, even with changes in compiler flow. This consistency allows engineers to maintain a correlation between modified designs and the original source code across various tools. Remarkably, SynAlign can tolerate up to 61\% design net changes without impacting alignment accuracy.

Figures

Figures reproduced from arXiv: 2501.00921 by the authors.

Figure 1
Figure 1. SynAlign Vs. current industrial practice. The current chip design process typically involves weekly meetings between backend and frontend teams to discuss timing information and map critical paths. Due to the com￾plexity of this task, some teams avoid aggressive optimiza￾tion techniques like flattening to simplify the process. We propose SynAlign, a tool that automatically maps an￾notated post-optimized netlists to … view at source ↗
Figure 2
Figure 2. (a) Source code example with aligned part highlighted. (b) Reference graph (𝐺𝑟𝑒 𝑓 ). (c) synthesized graph (𝐺𝑠𝑦𝑛𝑡ℎ) with annotations. subgraph and the next for the pending-to-identify combina￾tional subgraph. Nets aligned during matching passes also function as RPs for subsequent stages. Nets with identical Start and End RPs are marked as equivalent, and this process continues until no new matches are found. Unresol… view at source ↗
Figure 4
Figure 4. We leverage this information to align more nodes [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figures from the paper (9 more)
Figure 3
Figure 3. Figure 3: Concept demonstration of Surrounding Matching with collapsing nodes. 4 [PITH_FULL_IMAGE:figures/full_fig_p004_3.png]
Figure 4
Figure 4. Figure 4: Surrounding Matching depicting the surrounding cells with same LoC used to resolve the source location of node “op”. Another step in Surrounding Matching involves collapsing two nodes, as illustrated in [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 6
Figure 6. Figure 6: NL2NL accuracy testing in all the Verilog (V) and Chisel (C) designs 3.2 Manual Accuracy Evaluation While NL2NL evaluation offers valuable insights, it does not account for structural changes introduced by synthesis tools. Hence, we set up the Manual Accuracy Evaluatio…
Figure 5
Figure 5. Figure 5 [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 8
Figure 8. Figure 8: Plot depicting the breakdown of different match￾ing functions with the total benchmark accuracy on top of the bars. Sequential and combinational partial matching is combined as Partial. Similar case for Full+Half matching functions. names: 85% compared to 79% in Manual…
Figure 7
Figure 7. Figure 7: (a) Original net to be preserved (W), (b) punched net, (c) Punched nets connected back [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 9
Figure 9. Figure 9: Total Execution Time Variation as per Netlist Size. Benchmark Size (k gates) [PITH_FULL_IMAGE:figures/full_fig_p008_9.png]
Figure 10
Figure 10. Figure 10: Breakdown of different matching functions for all the Benchmarks [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 11
Figure 11. Figure 11: Average time taken by different matching func￾tions for random net alignment in RocketTile_Yosys. net name annotations in each benchmark. It highlights that a trivial function variation can occur depending on the node annotated. This is reflected in Full+Half Matching…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

55 extracted references · 55 canonical work pages

  1. [1]

    https://www.chisel-lang

    Chisel Users Community, Get Me Verilog. https://www.chisel-lang. org/docs/resources/faqs#get-me-verilog. Online; accessed on 16 April 2024

    work page 2024

  2. [2]

    https://docs.google.com/ document/d/1fOSRdyZR2w75D87yU2Ma9h2-_lEPL4NxvhJGJd- s5pk/edit#heading=h.56zyi32ygm3b

    Circt weekly discussion notes. https://docs.google.com/ document/d/1fOSRdyZR2w75D87yU2Ma9h2-_lEPL4NxvhJGJd- s5pk/edit#heading=h.56zyi32ygm3b

    work page

  3. [3]

    https://docs.google.com/ document/d/1fOSRdyZR2w75D87yU2Ma9h2-_lEPL4NxvhJGJd- s5pk/edit#heading=h.awos2k698n33

    Circt weekly discussion notes. https://docs.google.com/ document/d/1fOSRdyZR2w75D87yU2Ma9h2-_lEPL4NxvhJGJd- s5pk/edit#heading=h.awos2k698n33

    work page

  4. [4]

    https://clang.llvm.org/doxygen/ group__CINDEX__LOCATIONS.html#details

    clang: Physical source locations. https://clang.llvm.org/doxygen/ group__CINDEX__LOCATIONS.html#details

    work page

  5. [5]

    https://github.com/ chipsalliance/rocket-chip?tab=readme-ov-file#building-the-project

    Generating verilog in Rocket Chip Generator. https://github.com/ chipsalliance/rocket-chip?tab=readme-ov-file#building-the-project . Online; accessed on 16 April 2024

    work page 2024

  6. [6]

    https://llvm.org/docs/ HowToUpdateDebugInfo.html#when-to-drop-an-instruction- location

    How to update debug info: A guide for llvm pass authors — llvm 17.0.0git documentation. https://llvm.org/docs/ HowToUpdateDebugInfo.html#when-to-drop-an-instruction- location

    work page

  7. [7]

    https://llvm.org/docs/ HowToUpdateDebugInfo.html

    How to update debug info: A guide for llvm pass authors — llvm 17.0.0git documentation. https://llvm.org/docs/ HowToUpdateDebugInfo.html

    work page

  8. [8]

    https://google

    Ideas and projects - xls: Accelerated hw synthesis. https://google. github.io/xls/ideas_and_projects

    work page

Show all 55 references
  1. [9]

    https://github.com/nturley/netlistsvg

    netlistsvg. https://github.com/nturley/netlistsvg. Online; accessed on 21 May 2019

    2019

  2. [10]

    https://web.open-source-silicon.dev/t/442348/has-anyone- tried-using-the-keep-synthesis-attribute-is-follo

    openLane. https://web.open-source-silicon.dev/t/442348/has-anyone- tried-using-the-keep-synthesis-attribute-is-follo . Online; accessed on 16 April 2024

    2024

  3. [11]

    https://llvm.org/docs/SourceLevelDebugging.html

    Source level debugging with llvm — llvm 17.0.0git documentation. https://llvm.org/docs/SourceLevelDebugging.html

  4. [12]

    https://www.synopsys.com/verification/debug/verdi.html

    verdi. https://www.synopsys.com/verification/debug/verdi.html

  5. [13]

    https://discourse.llvm.org/t/get-source-location-details-from-ir- code-function-pass/57372 , Jan 2021

    Get source location details from ir code (function pass) 2021. https://discourse.llvm.org/t/get-source-location-details-from-ir- code-function-pass/57372 , Jan 2021

    2021

  6. [14]

    https://github.com/google/xls, 2021

    XLS: Accelerated HW Synthesis. https://github.com/google/xls, 2021. Online; accessed on 9 August 2021. 11

    2021

  7. [15]

    https://github.com/llvm/circt,

    CIRCT: Circuit IR Compilers and Tools. https://github.com/llvm/circt,

  8. [16]

    Patterson, Brian Richards, Colin Schmidt, Stephen Twigg, Huy Vo, and Andrew Water- man

    Krste Asanović, Rimas Avizienis, Jonathan Bachrach, Scott Beamer, David Biancolin, Christopher Celio, Henry Cook, Daniel Dabbelt, John Hauser, Adam Izraelevitz, Sagar Karandikar, Ben Keller, Donggyu Kim, John Koenig, Yunsup Lee, Eric Love, Martin Maas, Albert Magyar, Howard Ma...

    2016

  9. [17]

    Chisel: constructing hardware in a scala embedded language

    Jonathan Bachrach, Huy Vo, Brian Richards, Yunsup Lee, Andrew Waterman, Rimas Avižienis, John Wawrzynek, and Krste Asanović. Chisel: constructing hardware in a scala embedded language. In DAC Design Automation Conference 2012, pages 1212–1221. IEEE, 2012

    2012

  10. [18]

    Balogh, G.R

    G.D. Balogh, G.R. Mudalige, I.Z. Reguly, S.F. Antao, and C. Bertolli. Op2-clang: A source-to-source translator using clang/llvm libtooling. In 2018 IEEE/ACM 5th Workshop on the LLVM Compiler Infrastructure in HPC (LLVM-HPC), pages 59–70, 2018

    2018

  11. [19]

    Message- passing algorithms for sparse network alignment

    Mohsen Bayati, David F Gleich, Amin Saberi, and Ying Wang. Message- passing algorithms for sparse network alignment. ACM Transactions on Knowledge Discovery from Data (TKDD) , 7(1):1–31, 2013

    2013

  12. [20]

    Utils: add source locators by mwachs5 · pull request 2496 · chipsalliance/chisel

    chipsalliance. Utils: add source locators by mwachs5 · pull request 2496 · chipsalliance/chisel. https://github.com/chipsalliance/chisel3/ pull/2496, Apr

  13. [21]

    Source information via macros, rfc · issue 147 · chip- salliance/chisel

    chipsalliance. Source information via macros, rfc · issue 147 · chip- salliance/chisel. https://github.com/chipsalliance/chisel3/issues/147, Apr 2016

    2016

  14. [22]

    Case study: Soc performance verification and static verification of rtl parameters

    Prokash Ghosh and Srivastava Rohit. Case study: Soc performance verification and static verification of rtl parameters. In 2019 20th Inter- national Workshop on Microprocessor/SoC Test, Security and Verification (MTV), pages 65–72. IEEE, 2019

    2019

  15. [23]

    Timothy Edwards, Russell Friesenhahn, matt venn, Amr A

    Hagiwara-shc, Jeff DiCorpo, Manar, Marwan Abbas, Kareem Farid, Mohamed Kassem, R. Timothy Edwards, Russell Friesenhahn, matt venn, Amr A. Gouhar, Mohamed Shalan. Marmot RISC-V SoC. https: //github.com/Hagiwara-shc/marmot_asic.git, 2022. Online; accessed on March 2024

    2022

  16. [24]

    Refining network alignment to improve matched neighborhood con- sistency

    Mark Heimann, Xiyuan Chen, Fatemeh Vahedian, and Danai Koutra. Refining network alignment to improve matched neighborhood con- sistency. In Proceedings of the 2021 SIAM International Conference on Data Mining (SDM), pages 172–180. SIAM

    2021

  17. [25]

    Regal: Representation learning-based graph alignment

    Mark Heimann, Haoming Shen, Tara Safavi, and Danai Koutra. Regal: Representation learning-based graph alignment. In Proceedings of the 27th ACM international conference on information and knowledge management, pages 117–126, 2018

    2018

  18. [26]

    James Cherry. OpenSTA. https://github.com/abk-openroad/OpenSTA. Online; accessed on 5 September 2019

    2019

  19. [27]

    dinocpu/cpu.scala (pipelinedcpu) at main · jlpteach- ing/dinocpu

    jlpteaching. dinocpu/cpu.scala (pipelinedcpu) at main · jlpteach- ing/dinocpu. https://github.com/jlpteaching/dinocpu/blob/main/src/ main/scala/pipelined/cpu.scala

  20. [28]

    dinocpu/cpu.scala (singlecyclecpu) at main · jlpteach- ing/dinocpu

    jlpteaching. dinocpu/cpu.scala (singlecyclecpu) at main · jlpteach- ing/dinocpu. https://github.com/jlpteaching/dinocpu/blob/main/src/ main/scala/single-cycle/cpu.scala

  21. [29]

    Network alignment: Theory, algorithms, and applica- tions

    Ehsan Kazemi. Network alignment: Theory, algorithms, and applica- tions. Technical report, EPFL, 2016

    2016

  22. [30]

    The graph isomor- phism problem: its structural complexity

    Johannes Kobler, Uwe Schöning, and Jacobo Torán. The graph isomor- phism problem: its structural complexity . Springer Science & Business Media, 2012

    2012

  23. [31]

    Release chisel v3.5.0 · chipsalliance/chisel

    Jack Koenig. Release chisel v3.5.0 · chipsalliance/chisel. https://github. com/chipsalliance/chisel3/releases/tag/v3.5.0, Jan 2001

    2001

  24. [32]

    Release chisel v3.5.5 · chipsalliance/chisel

    Jack Koenig. Release chisel v3.5.5 · chipsalliance/chisel. https://github. com/chipsalliance/chisel3/releases/tag/v3.5.5, Nov 2001

    2001

  25. [33]

    Release chisel v3.6.0-m1 · chipsalliance/chisel

    Jack Koenig. Release chisel v3.6.0-m1 · chipsalliance/chisel. https: //github.com/chipsalliance/chisel3/releases/tag/v3.6.0-M1, Dec 2001

    2001

  26. [34]

    Release chisel v3.6.0-m2 · chipsalliance/chisel

    Jack Koenig. Release chisel v3.6.0-m2 · chipsalliance/chisel. https: //github.com/chipsalliance/chisel3/releases/tag/v3.6.0-M2, Jan 2001

    2001

  27. [35]

    Aligning users across social networks using network embedding

    Li Liu, William K Cheung, Xin Li, and Lejian Liao. Aligning users across social networks using network embedding. In Ijcai, volume 16, pages 1774–1780, 2016

    2016

  28. [36]

    Design and Application of a Co-Simulation Framework for Chisel

    Ryan Lund. Design and Application of a Co-Simulation Framework for Chisel. PhD thesis, MA thesis. EECS Department, University of California, Berkeley, 2021

    2021

  29. [37]

    Reset logic verification of an iod at system on chip level using gatesim

    Kakarlamudi Lakshmi Maidhili, Fazal Noorbasha, Allamsetty Vamsi, and Kakarla Hari Kishore. Reset logic verification of an iod at system on chip level using gatesim. International Journal, 8(7), 2020

    2020

  30. [38]

    Understanding logic equivalence check (lec) flow and its challenges, and proposed solution

    Priyambada Mishra. Understanding logic equivalence check (lec) flow and its challenges, and proposed solution. https://www.design- reuse.com/articles/51622/understanding-logic-equivalence-check- lec-flow-and-its-challenges-and-proposed-solution.html . Accessed: 2024-10-07

    2024

  31. [39]

    Timothy Edwards, Amr A

    Muhammad Hadir Khan, R. Timothy Edwards, Amr A. Gouhar, Manar, Mohamed Kassem, Mohamed Shalan, AireenAmirJalal, matt venn, Jeff DiCorpo. SoC - Google SKY130 Shuttle (ibtida). https://github.com/ hadirkhan10/caravel_ibtida_soc.git, 2021. Online; accessed on March 2024

    2021

  32. [40]

    Equivalence checking of retimed circuits

    Karolína Netolická et al. Equivalence checking of retimed circuits . PhD thesis, Massachusetts Institute of Technology, 2005

    2005

  33. [41]

    Equality saturation theory exploration à la carte

    Anjali Pal, Brett Saiki, Ryan Tjoa, Cynthia Richey, Amy Zhu, Oliver Flatt, Max Willsey, Zachary Tatlock, and Chandrakana Nandi. Equality saturation theory exploration à la carte. Proceedings of the ACM on Programming Languages, 7(OOPSLA2):1034–1062, 2023

    2023

  34. [42]

    Verilog HDL: a guide to digital design and synthesis , volume 1

    Samir Palnitkar. Verilog HDL: a guide to digital design and synthesis , volume 1. Prentice Hall Professional, 2003

    2003

  35. [43]

    A Guide on Logical Equivalence Checking - Flow, Challenges, and Bene- fits

    Prathmesh Oza Pratik Patel and Rakesh Parmar. A Guide on Logical Equivalence Checking - Flow, Challenges, and Bene- fits. https://www.design-reuse.com/articles/45547/a-guide-on-logical- equivalence-checking-flow-challenges-and-benefits.html

  36. [44]

    Timothy Edwards, Russell Friesenhahn, Johan Eu- phrosine, Amr A

    Shashank, Jeff DiCorpo, Manar, Marwan Abbas, Kareem Farid, Mo- hamed Kassem, R. Timothy Edwards, Russell Friesenhahn, Johan Eu- phrosine, Amr A. Gouhar, matt venn, Mohamed Gaber, Mohamed Shalan. Dual mac unit array with a single sigmoid activation function. https://github.com/...

    2022

  37. [45]

    There and back again: A netlist’s tale with much egraphin’

    Gus Henry Smith, Zachary D Sisco, Thanawat Techaumnuaiwit, Jing- tao Xia, Vishal Canumalla, Andrew Cheung, Zachary Tatlock, Chan- drakana Nandi, and Jonathan Balkind. There and back again: A netlist’s tale with much egraphin’. arXiv preprint arXiv:2404.00786 , 2024

    2024 arXiv

  38. [46]

    Design Compiler User Guide

    Synopsys Inc. Design Compiler User Guide

  39. [47]

    Primetime static timing analysis.https://www.synopsys

    Synopsys, Inc. Primetime static timing analysis.https://www.synopsys. com/implementation-and-signoff/signoff/primetime.html. Online; accessed on 26 April 2019

    2019

  40. [48]

    The Verilog® hardware description language

    Donald Thomas and Philip Moorby. The Verilog® hardware description language. Springer Science & Business Media, 2008

    2008

  41. [49]

    LiveHD: A Productive Live Hardware Development Flow

    Sheng-Hong Wang, Rafael Trapani Possignolo, Haven Blake Skinner, and Jose Renau. LiveHD: A Productive Live Hardware Development Flow. IEEE Micro, 40(4):67–75, 2020

    2020

  42. [50]

    Yosys manual

    Clifford Wolf. Yosys manual. Retrieved January, 16:2021, 2021

    2021

  43. [51]

    Yosys Open SYnthesis Suite

    Clifford Wolf. Yosys Open SYnthesis Suite. https://github.com/ YosysHQ/yosys, 2022. Online; accessed on December 2022

    2022

  44. [52]

    Graph isomorphism problem

    Viktor N Zemlyachenko, Nickolay M Korneenko, and Regina I Tyshke- vich. Graph isomorphism problem. Journal of Soviet Mathematics , 29:1426–1481, 1985

    1985

  45. [53]

    Final: Fast attributed network align- ment

    Si Zhang and Hanghang Tong. Final: Fast attributed network align- ment. In Proceedings of the 22nd ACM SIGKDD international conference on knowledge discovery and data mining , pages 1345–1354, 2016

    2016

  46. [54]

    Caper: Coarsen, align, project, refine-a general multilevel framework for network alignment

    Jing Zhu, Danai Koutra, and Mark Heimann. Caper: Coarsen, align, project, refine-a general multilevel framework for network alignment. 12 In Proceedings of the 31st ACM International Conference on Information & Knowledge Management, pages 4747–4751, 2022. 13

    2022

  47. [2022]

    Online; accessed on 12 August 2022

    2022

Pith tools

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