dac-topic-selection

DAC Topic Selection

Decide the venue and the track before drafting. DAC — the ACM/IEEE **Design Automation

Conference, "The Chips to Systems Conference" — is the premier forum for electronic design

automation (EDA)** and chip/system design. Its distinguishing structural fact, absent from the

academic architecture venues, is that DAC hosts **two peer-reviewed paper tracks with different

review models: the double-blind, archival Research Manuscript** track and the industry-facing

Engineering Track. Picking the wrong track wastes a full cycle just as surely as picking the

wrong conference.

The two questions, in order

1. Is this a DAC contribution at all? DAC rewards work that advances how chips and systems are

designed, automated, verified, or secured — a new placement/routing algorithm, a synthesis or

verification technique, an ML-for-EDA method, a hardware-security defense, a design methodology

with measured QoR impact. A pure computer-architecture result (a new microarchitecture, a cache

policy) whose EDA/automation angle is incidental is respected and then routed to ISCA/MICRO/HPCA.

1. Research Manuscript or Engineering Track? This is the DAC-specific fork. Route by whether the

core deliverable is a novel, archival research contribution evaluated against baselines

(Research) or a deployed industrial design/flow/methodology lesson from practice (Engineering).

Research Manuscript vs Engineering Track

| Signal in your project | Track | Why |

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

| Novel algorithm/technique with QoR gains vs prior art, generalizable | Research Manuscript | Double-blind, archival on ACM DL; judged on novelty + evidence |

| An empirical or ML-for-EDA study that changes what the field believes | Research Manuscript | Archival research contribution |

| A real tapeout/flow experience, tool-deployment lesson, or methodology from industry | Engineering Track | Practitioner audience; separate committee; presentation-first |

| Front-end design, back-end design, IP, or embedded SW/HW practice you want peers to learn from | Engineering Track | Its named scope; not required to out-QoR a baseline |

| Result too early/small for archival novelty but timely | Late Breaking Results | Short poster-style track, later deadline |

The trap for academics: submitting a solid-but-incremental flow improvement to the Research track

where it dies on novelty, when the Engineering Track would have welcomed it as a practice lesson.

The trap for practitioners: hiding a genuinely novel algorithm in the Engineering Track and losing

the archival citation record.

Sibling-venue routing (EDA and architecture)

| Signal in your project | Better home | Why |

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

| Broad EDA/chip-design contribution, ready now, DAC deadline nearer | DAC Research | The flagship EDA venue; largest audience and industry reach |

| Deeper CAD-algorithm focus, or DAC deadline already passed | ICCAD | The other top EDA venue; complementary fall calendar |

| European community, design-and-test emphasis | DATE | Design, Automation and Test in Europe (distinct venue) |

| Asia-Pacific community, ASP-DAC's January cycle fits | ASP-DAC | Asia and South Pacific DAC (distinct venue) |

| Core is a microarchitecture / accelerator idea, EDA is incidental | ISCA / MICRO / HPCA | Computer-architecture flagships, different reviewer pool |

| Test/reliability depth | ITC / VTS | Test-community venues |

| Analog/RF circuit design as the contribution | ISSCC / CICC / VLSI | Circuits venues, not the EDA-algorithm venue |

> Name-collision guard: ASP-DAC and DATE are not DAC; they have their own calls and

> deadlines. And "DAC" in a circuits paper often means digital-to-analog converter — a valid DAC

> research topic, not the conference.

Contribution shapes DAC Research rewards

• A new EDA algorithm + tool + QoR evaluation — synthesis, placement, routing, timing, power,

verification, or test, showing measured PPA (power/performance/area), wirelength, timing

slack, or runtime gains over the strongest prior technique on standard benchmarks.

• ML for EDA — learning-based placement, routing, synthesis, timing/IR-drop prediction, or an

agentic/foundation-model approach to a design task, with a fair non-ML or prior-ML baseline.

• Hardware security — a concrete attack or defense (side-channel, Trojan, IP protection,

post-quantum primitive, supply-chain integrity) with a threat model and measured overhead.

• Design methodology / system-level — chiplet integration, 3D-IC, near-memory, or a cross-layer

methodology whose payoff is demonstrated on a realistic design.

• Emerging technology — quantum EDA, in-memory/neuromorphic, or approximate computing, with an

automation or design-quality contribution rather than a device-physics one.

The QoR-impact and model-swap tests

• QoR-impact test: state your gain in the field's own currency — "X% wirelength / Y% total

negative slack / Z× runtime at equal quality." If you cannot phrase the contribution as a

measured QoR delta or a new capability, the Research track will read it as incremental.

• Model-swap test (for ML-for-EDA): if you swap the learner for another, does the EDA lesson

survive? If the paper is really about a model architecture with a toy EDA wrapper, it is an ML

paper and routes to an ML venue; DAC wants the design-automation lesson.

Cheap reconnaissance before committing

[Scope]    scan the last two DAC programs (dblp, ACM DL) for your subarea
           -> 3+ recent papers = a reviewer pool exists; 0 = mismatch or ICCAD/DATE fit
[Benchmarks] does a standard suite exist for your problem (ISPD, EPFL, ISCAS/ITC, TAU, CircuitNet)?
           -> reviewers expect it; a private-benchmark-only evaluation is a scored weakness
[Calendar] DAC manuscript deadline is ~November; ICCAD is later, ASP-DAC is January, DATE differs
           -> route to the nearest honest fit rather than idling a cycle

Decision procedure

[Is it EDA/chip-design?] automation/verification/security/methodology contribution? -> DAC candidate
[Track fork] novel + archival + baselined -> Research Manuscript
             industrial practice/deployment lesson -> Engineering Track
             timely but early -> Late Breaking Results
[Sibling check] CAD-algorithm depth & fall timing -> ICCAD; architecture core -> ISCA/MICRO/HPCA;
                circuits core -> ISSCC/CICC
[Verdict] DAC Research / DAC Engineering / sibling venue, with a one-line QoR-framed reason

Run this before the writing skills; a wrong track or venue decision wastes every later step. When

the verdict is DAC Research, continue with dac-workflow for the November-anchored calendar and

dac-writing-style for the 6+1-page paper shape.