| name | dac-review-process |
| description | Use when reasoning about how an ACM/IEEE Design Automation Conference (DAC) Research Manuscript is evaluated, covering double-blind TPC review, the novelty-plus-QoR decision criteria, program-committee discussion, the accept/reject (no major-revision) outcome, the ~20-25% selectivity, and how DAC's industry-facing, single-shot process differs from the architecture venues' rebuttal-and-revision cycles. |
DAC Review Process
Model the pipeline before interpreting any single review. DAC's Research-Manuscript review is
double-blind, Technical-Program-Committee-driven, and single-shot: papers are reviewed against
novelty and measured design-quality impact, discussed by the committee, and get a binary
accept/reject — there is no journal-style Major Revision round. Anchor to the DAC 2026 cycle
facts in resources/official-source-map.md.
Process model
- Submission and review run on Softconf/START with double-blind anonymity: reviewers do not
see author identities, and the manuscript must be scrubbed of identifying content.
- Each paper is read by multiple TPC members drawn from the relevant subcommittee (physical
design, logic synthesis, verification/test, ML-for-EDA, security, embedded, etc.). Reviewers
weigh novelty over prior art, technical soundness, the strength and fairness of the QoR
evidence, relevance/impact to design automation, and clarity.
- The committee discusses borderline papers to reach the final verdict; a strong advocate who
can answer the objections carries a paper through discussion.
- Decisions are essentially accept or reject (a fraction may be steered to a poster/LBR-style
outcome per cycle — 待核实). There is no revise-and-resubmit within the cycle; a rejected
paper reroutes to ICCAD/DATE/ASP-DAC or a journal.
- Research selectivity is historically ~20-25% (verify each cycle).
Reading a decision against the criteria
| Signal in the reviews | Underlying criterion | Author reality |
|---|
| "Incremental over [prior tool]" | Novelty | Structural; the delta must be reframed or the idea extended before reroute |
| "Baseline is weak / untuned" | Evidence fairness | Often fatal at DAC — the QoR comparison is the paper |
| "Only private benchmarks" | Evidence credibility | Add a recognized suite; results on toy circuits do not persuade |
| "Runtime/scalability unclear" | Soundness/impact | EDA reviewers care about scaling to realistic design sizes |
| "Unclear where the gain comes from" | Soundness | Missing ablation isolating the contribution |
Novelty-plus-QoR: the DAC bar
DAC is an engineering research venue: a beautiful idea with no measured QoR advantage rarely
survives, and a large QoR number with thin novelty gets read as an engineering result, not a
research contribution. Winning papers pair a genuinely new mechanism with a fair,
benchmark-grounded QoR gain (PPA, wirelength, timing slack, coverage, or runtime) over the
strongest prior technique. The most common reject cause is not a broken idea but an
unconvincing comparison — a baseline the reviewer does not accept as state of the art or as
fairly tuned.
How DAC differs from its siblings
- vs. ISCA / MICRO / HPCA (architecture): those venues run author rebuttals and, in some
years, revision rounds, and reward microarchitectural novelty. DAC's research review has
historically been TPC-driven without a standing author-response period (待核实 for DAC
2026) and rewards design-automation novelty measured in QoR. Do not carry an architecture
rebuttal playbook into DAC.
- vs. FSE / ICSE (software): no journal-style Major Revision, no ACM artifact-badging track, and
a much tighter 6+1-page budget. DAC evidence is QoR on EDA benchmarks, not empirical-SE
studies.
- vs. ICCAD / DATE / ASP-DAC (sibling EDA): overlapping reviewer pools and criteria but
different calendars and committees — a DAC reject is a natural ICCAD/DATE/ASP-DAC candidate,
but never assume shared deadlines or that the same reviewers see it.
Who reads you
Expect subarea-matched EDA experts who will check whether your baseline is the real state of the
art, whether the benchmarks are standard and reported honestly (all circuits, not a
cherry-picked subset), whether runtime and scalability are credible for realistic designs, and
whether an ablation shows the gain comes from your mechanism. Vague "we improve QoR" claims
without per-benchmark tables get caught, not skimmed.
Where author leverage actually exists
[Before submission] topic/subcommittee tags + a real abstract -> reviewer pool (largest lever)
[Manuscript] a fair, tuned, state-of-the-art baseline on standard benchmarks + an ablation
[Discussion] a champion reviewer who can answer the objections carries the paper
[After reject] no appeal; reroute to ICCAD/DATE/ASP-DAC or TCAD/TODAES with the reviews addressed
Because DAC has historically had no author rebuttal, the leverage is almost entirely
front-loaded: you cannot talk a reviewer out of a weak-baseline finding after submission, so the
baseline and benchmark choices must be unimpeachable before the November deadline.
Misreadings to avoid
- Expecting a rebuttal to save the paper — do not budget on a response window DAC may not run.
- Treating a big QoR number as sufficient — without novelty it reads as an Engineering-Track
result.
- Assuming one champion is enough without evidence — the discussion turns on answers to the
other reviewers' concrete objections, not enthusiasm.
- Projecting last year's process — deadline, selectivity, and whether any response step exists
are decided per edition.
Output format
[Process stage] pre-submission / under review / decided
[Decision driver] novelty | evidence fairness | benchmark credibility | scalability | clarity
[Criterion map] each review point -> which criterion it invokes
[Leverage plan] the pre-submission action (baseline/benchmark/ablation) that would have moved it
[Reroute target] ICCAD / DATE / ASP-DAC / TCAD if rejected, with the fix to make first
