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

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