dac-writing-style

DAC Writing Style

Use this while writing the body. DAC Research Manuscripts live inside a **6-page double-column

budget** (plus a references-only page), so the writing discipline is not "explain everything" but

"prove one design-automation contribution, in the field's own QoR currency, in six dense pages."

DAC reviewers are EDA experts under time pressure; they decide fast whether the paper has a real,

measured advance.

The DAC first-page arc

Front-load the contribution. By the end of the first column-and-a-half a reviewer should know:

1. The design problem — a concrete EDA/chip-design task (placement, timing closure, functional

verification, IR-drop prediction, IP protection) that the community recognizes.

1. Why the current state is inadequate — the specific limitation of the best existing tool or

technique, ideally with a number (it does not scale past N cells, it leaves X% negative slack).

1. The contribution as a measured delta — the new mechanism and the headline QoR result:

"we reduce total negative slack by X% at equal area with Y× lower runtime versus [state of the

art] on [standard benchmark]."

1. Why it generalizes — that the mechanism is not a one-benchmark trick.

Do not open with "AI has transformed chip design." Open with the design problem and the number.

State the contribution as a QoR claim

The EDA community speaks in PPA (power, performance, area), plus wirelength, timing slack

(WNS/TNS), routability/DRC, coverage, and runtime. A DAC contribution is strongest when phrased

as a delta in those units against a named baseline:

• Weak: "Our method improves quality and is efficient."
• Strong: "On the ISPD placement benchmarks our router reduces total wirelength by X% and DRC

violations by Y% while completing in Z× less runtime than [baseline]."

Every headline claim in the abstract and introduction should reappear as a per-benchmark row in a

results table, not just an average.

Living in six double-column pages

The budget is the constraint that shapes the paper:

• One contribution, deep. Six pages cannot carry three loosely related ideas; pick the strongest

and develop it fully. A sprawling paper reads as thin at DAC.

• Method before menagerie. Spend pages on the mechanism and the evaluation, not on a long

taxonomy or a tutorial of standard EDA background the reviewers already know.

• Tables over prose for results. A compact per-benchmark table communicates more per square inch

than paragraphs; DAC reviewers read tables first.

• Cut the roadmap. "Section 2 covers... Section 3 covers..." is dead weight at six pages; let

section headings do that work.

• References go on the seventh page only. Body content there is a desk-reject; plan the argument

to end at page six.

EDA figures that survive double-column at 9-10 pt

• Design figures (floorplans, layouts, congestion/heatmaps, netlist graphs) must be **legible at

column width** — roughly half of a US-letter page wide. Test every figure at final size.

• Label axes with the real QoR units; a curve with no units persuades no one.
• Prefer a clear flow diagram of the technique over a dense algorithm listing when space is

scarce; move full pseudocode to the body only if it earns its space.

• Color heatmaps must still read in grayscale and for color-blind reviewers.

Third-person self-citation (double-blind)

Because review is double-blind, refer to your own prior work in the third person: not "in our

earlier tool [7]" but "the prior technique [7]." Keep acknowledgements, funding, and grant numbers

out of the review version entirely; they return in the camera-ready.

Common DAC prose failures

| Failure | Why it costs you | Fix |

|---|---|---|

| QoR claim only as an average | Reviewers suspect a few benchmarks carry it | Per-benchmark table; report all circuits |

| Baseline unnamed or "a standard method" | Reads as evasive about the real state of the art | Name the strongest prior tool and its tuning |

| Background eats two pages | Leaves no room for the contribution | Assume EDA literacy; cut to the delta |

| Figures illegible at column width | Reviewer cannot verify the claim | Rebuild at final size, real units |

| First-person self-citation | De-anonymizes under double-blind | Third-person throughout |

Output format

[First-page arc]  design problem -> inadequacy (with a number) -> QoR delta -> generality? present?
[QoR framing]     headline claim stated in PPA/wirelength/slack/runtime vs a named baseline? yes/no
[Budget]          body within 6 double-column pages? references-only 7th page clean?
[Figures]         legible at column width, real units, grayscale-safe? yes/no
[Anonymity]       self-citations third-person; acks/funding removed? yes/no
[Cut list]        <lowest-value paragraphs/figures to reclaim space>