ICCAD is the reference conference for electronic design automation — the methods and tools that sit between a finished netlist and manufacturable silicon. For a team planning a tape-out, it is useful in two distinct ways: as an early signal of which design and verification techniques are becoming practical, and as a reality check on how far a published result sits from anything that closes on real PDKs and real schedules.
This article documents what is verifiable about the 2026 edition — dates, deadlines and announced speakers — and how to read the programme without over-reading it.
What ICCAD Actually Is
The International Conference on Computer-Aided Design is jointly sponsored by IEEE and ACM and is described by the organisers as the premier forum for exploring new challenges and identifying emerging technologies in electronic design automation research. Coverage runs from device and circuit level up through system level, as well as post-CMOS design.
Unlike DAC or DATE, ICCAD is primarily a technical conference with a small trade-show component. The practical consequence for a reader is that the proceedings are method-heavy: what gets published is algorithms, flows and tool techniques rather than product announcements.
The conference has run since 1982 and was held in San Jose, California for most of its history. The 2026 edition is the 45th.
The 2026 Edition, Verified
ICCAD 2026 runs 8–12 November 2026 in San Jose, California. The organisers publish the submission calendar on the conference site; the dates that actually bind a paper are mapped below, including the camera-ready deadline that was reported as extended.
Four keynotes are announced on the conference site: Paul Cunningham (System Verification Group, Cadence), Vaughn Betz (University of Toronto / Cerebras Systems), Ralph Wittig (AMD) and Chia-Lin Yang (National Taiwan University).
The affiliations are the signal, not the names. A verification-focused keynote from the largest EDA vendor, an FPGA-to-silicon path from a Toronto–Cerebras profile, an AMD perspective on large-scale compute, and an academic systems view together mark where the tool flow is being pushed: verification cost, architectural specialisation and post-scaling design.
What the Call for Papers Covers
The call for papers lists fourteen topic areas. For a team planning silicon, three of them map directly onto the risk that sits between a finished design and working parts: physical design, verification and test, and manufacturability.
- System modelling: HW/SW co-design, simulation and heterogeneous SoCs
- AI and accelerators: neural network hardware, AI algorithms, CAD for AI
- Embedded systems and edge computing: cyber-physical systems, FPGAs, CGRAs
- Security: hardware trust, encryption and side-channel attack prevention
- Efficiency: low-power and approximate computing
- Logic synthesis: technology mapping and optimisation
- Physical design: floorplanning, placement, routing and CTS
- Verification and test: formal verification, emulation, ATPG and post-silicon debug
- Analysis: timing, power and signal integrity optimisation
- Manufacturability: DFM, yield estimation and reliability analysis
- Analog/mixed-signal: RF device modelling and EM simulation
- Nanoscale and post-CMOS: emerging devices, nanophotonics and field-coupled technologies
- Advanced computing paradigms: non-von Neumann, quantum, DNA, neuromorphic and green computing
- Bio-CAD: microfluidics, bio-sensors and synthetic biology
How a Chip Team Should Read an EDA Conference
An EDA paper demonstrates that a method worked on the benchmarks the authors chose. The gap between that and a production flow is where most of the risk lives: benchmark coverage, runtime on real designs, tool integration and foundry qualification are rarely part of the published claim.
The practical read is directional. If the same technique appears across several groups and consecutive editions, it is moving toward the mainstream flow and is worth asking your tool vendor about. A single striking result on a narrow benchmark set is a research milestone, not a schedule change.
For teams working with outside implementation support, the useful question to ask any provider citing conference results is which of the claimed gains survive on your design, your library and your PDK version.
