dac-writing-style

name	dac-writing-style
description	Use when drafting or tightening the prose of an ACM/IEEE Design Automation Conference (DAC) Research Manuscript, covering the QoR-forward first-page arc, stating the design-automation contribution as a measured delta, fitting a complete argument into six double-column pages plus a references-only page, building column-width EDA figures, and third-person self-citation for double-blind review.

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.
2. 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).
3. 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]."
4. 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>