EDAthon 2026
Augest 20th, 2026
City University of Hong Kong
Sponsored by IEEE CEDA; IEEE CEDA Hong Kong Chapter
Organized by City University of Hong Kong
City University of Hong Kong
Sponsored by IEEE CEDA; IEEE CEDA Hong Kong Chapter
Organized by City University of Hong Kong
The EDAthon 2026 (EDA programming contest) will be held as an on-site contest at City University of Hong Kong (CityUHK) on Aug 20th (Thu), 2026.
EDAthon is a whole-day programming contest that features interesting and challenging topics in Electronic Design Automation (EDA). This year, the contest focuses on using AI agents to assist tasks across the EDA workflow. Participants will explore how agents can read design files, invoke EDA tools, analyze tool feedback, debug errors, and iteratively improve design quality in realistic EDA scenarios. The contest will involve solving interesting problems in the broad context of Computer-Aided Design (CAD) of integrated circuits and systems. The problems will cover multiple stages of the EDA pipeline, including RTL generation and repair, RTL-level PPA optimization, global routing closure, and layout verification/repair. It will emphasize teamwork, problem-solving skills, programming techniques, and the effective use of agentic workflows for EDA applications.
The contest is open to two-person teams of graduate students or senior undergraduate students currently full-time enrolled in a university. During the contest, students will be given the problem statements, benchmark data, and some sample test data. The answers will be judged based on their correctness, quality of results, and compliance with the given constraints using hidden benchmarks. We will provide a limited quota of DeepSeek API access, together with the required EDA toolchains and the OpenCode environment, so that teams can focus on developing agentic solutions for the given EDA tasks.
Contact the contest Chair (Nan Guan at nanguan@cityu.edu.hk) for any questions about the contest, including invitation letters.
Jul 6th, 2026: Call for participation released, open for enrollment
Aug 5th, 2026: Registration deadline (email nanguan@cityu.edu.hk if you need registrate after deadline, we may still be able to accommodate new teams)
Aug 20th, 2026: Contest date
9am-3pm: EDAthon2026 Contest
3:00-3:30pm: Break
3:30-5:00pm: Mini-seminar
5:00 pm: Award Presentation
Agent Environment
Each team will use one shared Docker container as the only allowed AI-agent execution environment. The container provides an opencode-based coding agent configured with contest-provided DeepSeek access. Although each team has two members and two PCs, both members must work through the same contest-provided container.
The container also includes the required EDA toolchains and benchmark evaluation scripts. Installed tools include Icarus Verilog 12.0[1], Verilator[2], Yosys[3], ABC[4], OpenSTA[5], OpenROAD/OpenROAD-flow-scripts[6], KLayout[7], Python-based evaluation utilities, and the required benchmark platform files such as ASAP7 and Nangate45. Contestants may use opencode to read problem statements, inspect and modify source files, run compilation, simulation, synthesis, physical-design, DRC, and evaluation commands, analyze failures, and iteratively improve their submissions.
No external AI services, additional DeepSeek tokens, personal API keys, online coding assistants, model APIs, or tools outside the provided contest environment may be used during the contest.
Reference:
[1] https://github.com/steveicarus/iverilog
[2] https://github.com/verilator/verilator
[3] https://github.com/YosysHQ/yosys
[4] https://github.com/berkeley-abc/abc
[5] https://github.com/The-OpenROAD-Project/OpenSTA
[6] https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts
RTL design is the starting point of most digital integrated circuit design flows. Designers describe the behavior of a hardware module using languages such as Verilog or SystemVerilog, and the RTL code is later simulated, synthesized, and implemented by downstream EDA tools. However, writing correct RTL is often tedious: even small mistakes in signal width, control logic, reset behavior, or state transitions can cause simulation failures.
In this problem, contestants will work on RTL code completion tasks derived from the CVDP benchmark. Each task provides a natural-language description, starter RTL code, metadata, and a simulation-based testbench. The target RTL files contain partial code, and the goal is to complete or modify the implementation so that the design satisfies the specification and passes the provided tests.
The evaluation will be based on functional correctness. Contestants may use AI agents to inspect the prompt, read the RTL files, run the testbench, analyze simulation failures, and iteratively improve the code. The final submission should contain the completed RTL implementation for each task.
Reference:
[1] Pinckney, Nathaniel, et al. "Comprehensive Verilog design problems: A next-generation benchmark dataset for evaluating large language models and agents on rtl design and verification." arXiv preprint arXiv:2506.14074 (2025).
After an RTL design is functionally correct, designers often need to optimize it for PPA: power, performance, and area. Different RTL implementations of the same behavior may lead to very different synthesis results. For example, a design with unnecessary registers, redundant logic, or inefficient arithmetic expressions may pass all functional tests but still produce a larger or slower circuit.
In this problem, contestants will work on RTL optimization tasks derived from the Pluto benchmark. Each task provides a behavior description, a required module interface, an unoptimized reference implementation, and a testbench. The goal is to implement an optimized module that preserves the same behavior as the reference design while improving the hardware quality after synthesis.
The submissions will first be checked for functional correctness using simulation. Correct designs will then be evaluated using synthesis-based PPA metrics such as area, timing, and power. Contestants are encouraged to use AI agents to understand the reference design, rewrite the RTL, run simulation and synthesis tools, and search for better implementations.
Reference:
[1] Abdelatty, Manar, et al. "Pluto: A Benchmark for Evaluating Efficiency of LLM-generated Hardware Code." arXiv preprint arXiv:2510.14756 (2025).
Physical design transforms a synthesized netlist into a physical layout. After placement and clock tree synthesis, global routing estimates how wires should be routed across the chip and checks whether the available routing resources are sufficient. If the design is too congested, the global router may report overflow, meaning that some regions require more routing resources than available
In this problem, contestants will work on global routing closure tasks derived from ChiPBench. Each task starts from a frozen post-CTS design state. The placement and clock tree are already fixed, and contestants are not required to rerun the full physical design flow. Instead, they will tune the global routing configuration to reduce congestion and help the design complete global routing successfully.
For each design, contestants will be given the post-CTS design database, timing constraints, and related metadata. The expected submission is a Tcl configuration file used before global routing. The evaluation will focus on routing overflow, congestion, wirelength, via count, and possible timing or power side effects. The main objective is to turn difficult congested cases into routable designs while maintaining good routing quality.
Reference:
[1] Wang, Zhihai, et al. "Benchmarking end-to-end performance of ai-based chip placement algorithms." Advances in Neural Information Processing Systems 38 (2026).
At the end of the physical design flow, layouts must pass design rule checking (DRC). DRC verifies whether the shapes in the layout satisfy manufacturing rules such as minimum spacing, minimum width, enclosure, and via-related constraints. A layout with DRC violations may not be manufacturable, even if its circuit function is correct.
In this problem, contestants will work on layout repair tasks based on ASAP7 design rules. Each task provides a layout script, the corresponding layout data, and a DRC report describing the original violations. The goal is to modify the layout script to repair the existing violations while avoiding new violations and preserving the required structure and connectivity.
The evaluator will rerun KLayout DRC on the repaired layout and compare the new DRC report with the original one. The score will consider how many violations are repaired, whether new violations are introduced, and whether the repaired layout passes sanity and connectivity checks. Contestants may use AI agents to inspect the DRC report, reason about layout geometry, edit the layout script, and iteratively verify the repair.
Reference:
[1] Shahariar, M. K. Fahim. “DAC 2026 DRC Benchmark: Benchmark for Evaluating LLMs on ASAP7 KLayout DRC Repair and Detection.” GitHub, github.com/mkfahim/DAC26_DRC_Benchmark. Accessed 5 July 2026.
9am-3pm: EDAthon2026 Contest
3:00-3:30pm: Break
3:30-5:00pm: Mini-seminar
5:00 pm: Award Presentation
Each team consists of two members and will have access to two PCs, one for each member. Each team may access only one Docker container during the contest.
Participants cannot use any additional DeepSeek tokens or any other AI services to help solve the problems.
Participants cannot use or read any of their existing code or paper materials (USB, documents, printed/written materials, notes) during the contest.
Participants cannot access websites (e.g., Google, GitHub) freely during the contest. They cannot use online open-source projects beyond what's provided for each question.
Participants may access a list of basic reference websites (cpp reference, python reference, numpy reference, math reference) provided by organizers.
All problem background information has been finalized and given on this webpage. Detailed questions & test cases will be provided when the contest starts at 9 am, Aug 20th.
Participants can resubmit their solution to each question multiple times.
Nan Guan, City University of Hong Kong
Fengbin Tu, Hong Kong University of Science and Technology
Zhiyao Xie, Hong Kong University of Science and Technology
Zhiding Liang, Chinese University of Hong Kong
Can Li, The Universit of Hong Kong
Chaojian Li, Hong Kong University of Science and Technology
Hongce Zhang, Hong Kong University of Science and Technology