brycewang-stanford DAC Author Response
Handle reviews with DAC's process in mind. The single most important fact: DAC's Research-Manuscript
review has historically been TPC-driven without an author rebuttal period, and whether the
current cycle runs one is 待核实 (resources/official-source-map.md). So this skill covers two
situations, and the second is the common one.
Situation A — the cycle runs a response period (verify first)
If — and only if — the live DAC cycle offers an author response, treat it as a short, factual correction channel, not a debate. EDA reviewers reject mostly on baseline fairness, benchmark credibility, and scalability; a response moves a borderline paper when it supplies a number or corrects a factual misreading, and moves nothing when it argues taste.
Priorities for a tight EDA rebuttal (assume a strict word budget):
- Fix factual errors first — a reviewer who thinks you did not compare against tool X when Table 2 does; point to the table.
- Answer the baseline objection with evidence — if a reviewer names a stronger baseline, report the number if you have it, or commit precisely to what you will add and why it will not change the conclusion.
- Address scalability with data — cite the largest-benchmark runtime already in the paper, or give the missing figure.
- Concede cheaply, defend what matters — accept small corrections plainly; spend your words on the one or two objections that actually decide the paper.
Do not promise experiments you cannot run before camera-ready, and do not introduce author-revealing information — the response is still within double-blind.
[Reviewer 2] "No comparison to [SOTA router]."
Response: We compare against [SOTA router] in Table 2 (columns 4-6); on the full ISPD set we reduce
overflow by X% at equal wirelength. We will make this comparison more prominent.
Situation B — no rebuttal, then a reject (the common case)
With no response channel, the review packet arrives with the decision. The productive use of DAC reviews is then to repair the paper and reroute it well. DAC, ICCAD, DATE, and ASP-DAC share reviewer pools and criteria, so a DAC reviewer's objection is very likely to resurface at the next venue — answer it in the paper, not in a letter no one will read.
Turn the reviews into a fix list:
| DAC review objection | Fix before resubmitting elsewhere |
|---|---|
| Weak/untuned baseline | Add the strongest SOTA tool, tuned to equal effort, before ICCAD/DATE |
| Private benchmarks only | Re-run on ISPD/EPFL/ISCAS/ITC/TAU so the QoR is comparable |
| Scalability doubted | Add million-cell-scale results and runtime |
| Gain not isolated | Add the ablation the reviewer implicitly asked for |
| Incremental novelty | Extend the mechanism, or reframe honestly for a journal (TCAD/TODAES) |
If you reroute to a journal (TCAD/TODAES), a response letter does exist
Journals do run revise-and-resubmit with a point-by-point response. There, write the letter DAC
never asked for: map every reviewer point to a tracked change, quote the review, state the change,
and give the new number. That is where the discipline of ../dac-experiments pays off — a rejected
DAC paper with a strong QoR story often becomes a clean journal accept.
What never works
- Arguing novelty by assertion — "our approach is fundamentally different" without a QoR delta persuades no EDA reviewer.
- Blaming the benchmarks — if the standard suite does not flatter you, that is a signal, not an excuse.
- Waiting for a rebuttal that may not come — build the paper so it needs no rebuttal; the baseline and benchmark choices must be unimpeachable at submission.
Output format
[Response mode] rebuttal (cycle confirmed) / no-rebuttal reroute / journal response letter
[Decision driver] baseline | benchmark | scalability | novelty | clarity
[Point map] each review point -> factual correction | evidence | conceded | reframe
[If rerouting] target venue (ICCAD/DATE/ASP-DAC/TCAD) + the top fix to make first
[Anonymity] response (if any) free of author-revealing info? yes/no