Dac author response

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):

1. Fix factual errors first — a reviewer who thinks you did not compare against tool X when Table 2 does; point to the table.
2. 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.
3. Address scalability with data — cite the largest-benchmark runtime already in the paper, or give the missing figure.
4. 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