dac-artifact-evaluation

name	dac-artifact-evaluation
description	Use when packaging the code, benchmarks, and flows behind an ACM/IEEE Design Automation Conference (DAC) Research Manuscript into a credible, reusable artifact — given that DAC has historically run no formal artifact-evaluation or badge-issuing track (verify per cycle), so the goal is reviewer credibility and community reuse via open EDA flows and DOI-archived releases, not an ACM badge.

DAC Artifact Evaluation

Read the venue reality first. Unlike the software-engineering venues (FSE/ICSE/ISSTA) and the computer-architecture venues (MICRO/ISCA/HPCA), DAC has historically not operated a standing, badge-issuing artifact-evaluation track for research manuscripts; whether the current cycle adds one is 待核实 (resources/official-source-map.md). So do not build for an ACM badge that DAC does not award. Build instead for the two things that actually matter at DAC: making a skeptical reviewer trust your QoR numbers and making the community able to reuse and cite your work.

What an EDA artifact is for at DAC

Goal	What it buys you	How it is earned
Reviewer credibility	A QoR claim that reads as real, not cherry-picked	Standard benchmarks, disclosed flow, a runnable path
Community reuse	Citations and follow-on work built on your tool	Clean open-source release, good docs, a license
Contest/leaderboard standing	Recognition on ISPD/TAU/CAD-contest tasks	A tool that runs on the contest harness

There is no badge to chase, so the design target is a package a stranger can run and a reviewer would believe — not a checklist an evaluator scores.

Packaging plan for an EDA artifact

[Flow]        pin the toolchain: OpenROAD / ABC / Yosys / KLayout versions, or a Docker image;
              avoid "install these commercial tools yourself" as the only path
[Benchmarks]  ship or clearly reference the exact benchmark release (ISPD/EPFL/ISCAS/ITC/TAU/
              CircuitNet) with its version
[PDK/library] include the open PDK/library used (Nangate/ASAP7) or document the NDA-gated one
[README]      what it is; how to install; how to run one small demo in minutes; how to reproduce
              each headline QoR number; expected runtime and outputs
[Mapping]     an explicit table: paper claim -> script + benchmark -> expected QoR result
[Seeds]       fixed seeds and a note on nondeterminism for stochastic/RL flows
[License]     an OSI-approved license so others can build on it
[Archive]     deposit a versioned release in a DOI-issuing archive (Zenodo/Software Heritage) after
              acceptance for a stable citation

The clean-machine, bounded-time test

Even without formal evaluators, assume a reviewer or a future user gives your package a short, bounded try on a clean machine. Design the first ten minutes to succeed:

• A one-command small demo that runs a tiny circuit through your tool and prints a recognizable QoR number.
• No dependency on the authors' cluster, private PDK, or a live license server for the demo path.
• A clear separation between the fast demo and the slow full-benchmark reproduction (which may take hours on large designs — say so).

Anonymized review artifact vs public release

• At submission (double-blind): if you link the artifact for reviewers, anonymize it exactly like the paper — no author/lab names, no personal repos, no cluster paths, no commercial-flow fingerprints. Reviewers are not required to open it, so it can only strengthen a paper that already stands on six pages.
• After acceptance: replace anonymized placeholders with the public, licensed, DOI-archived release cited in the camera-ready; this is the version the community reuses.

Worked vignette: packaging a placement tool + benchmarks

A paper contributes an ML-guided placer evaluated on ISPD circuits. A credible, reusable package: a Docker image with the placer and an OpenROAD flow pre-built; a run_demo.sh that places one small ISPD circuit and reports wirelength/DRC in under a minute; a reproduce/ directory whose scripts regenerate each per-benchmark table with fixed seeds; a claim-to-script-to-benchmark mapping in the README; the exact ISPD release and an open PDK; the trained model checkpoint and the train/test design split; and an MIT/Apache license. State plainly which numbers are turnkey and which need the slow full-suite run on a large machine.

Calibration

• Do not assume a DAC artifact badge exists; verify the current cycle before promising one.
• If DAC or a co-located workshop does introduce an artifact/open-source track in a given year, re-read its specific rules — do not assume ACM SIGSOFT-style badge names transfer.
• The payoff is credibility and citations; budget the artifact accordingly, not as a graded deliverable.

Output format

[Artifact goal]   reviewer credibility / community reuse / contest harness
[Contents]        tool + flow versions / benchmarks + version / PDK / model + split / license
[Ten-minute test] does install + small demo succeed on a clean machine? yes/no
[Claim mapping]   claim -> script -> benchmark -> expected QoR present? yes/no
[Anon vs public]  anonymized review artifact / DOI-archived public release planned? yes/no
[Badge check]     does this cycle actually run an artifact track? verify -> yes/no/待核实