dac-review-process
GitHub解析DAC会议论文评审流程，涵盖双盲TPC审查、单轮接受/拒绝决策及无大修机制。重点阐述‘创新性+质量指标’双重标准，对比架构类会议差异，并提供基于审稿意见的拒稿原因分析与应对策略。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill dac-review-process -g -y
SKILL.md
Frontmatter
{
"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
Version History
- 9f86f09 Current 2026-07-19 15:12
