Paper deep dive
LATCH: LLM-Assisted Timing Closure Harness for Post-Route FPGA Optimisation
Shu Gu, Matthew Youngman, Yuqin Zhao, Cristian Sestito, Ali Siddique, Ramesh Krishnamurthy, Danial Chitnis, Themis Prodromakis
Intelligence
Status: not_run | Model: - | Prompt: - | Confidence: 0%
Entities (0)
Relation Signals (0)
No relation signals yet.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Post-route FPGA timing closure remains expert-dependent and computationally expensive. We present LATCH (LLM-Assisted Timing Closure Harness), a two-layer framework that separates large language model (LLM) orchestration from deterministic FPGA implementation and evaluation. Across sixteen designs and seven LLMs, a single-iteration study compares three agent control granularities - expert-written recipes, direct EDA operations and LLM-constructed procedures - to ask how much control an agent needs per attempt. Functional-pass rates are 98.2%, 71.4% and 17.9%, respectively; yet direct operations give slightly larger 3.4% median Fmax gains when passing, versus 3.2% for recipes. This exposes a trade-off between execution reliability and timing improvement. Informed by this trade-off, a multi-iteration study fixes the action tier at expert recipes to ask how repeated attempts are best organised, comparing a fitted deterministic heuristic with sequential LLM reasoning, branching exploration and knowledge base-guided exploration within 12 checkpoints per run. Branching raises mean maximum-frequency improvement from 10.5% (sequential) to 16.0%, and the knowledge base to 20.3%, improving 15 of 16 designs. Characterisation across 2,421 recipe attempts profiled their gain and validation rates, showing hard-block re-placement gives the largest cumulative mean gain at 41.4MHz.
Tags
Links
- Source: https://arxiv.org/abs/2610.16625v1
- Canonical: https://arxiv.org/abs/2610.16625v1
Trouble viewing inline? Open PDF directly â
Full Text
79,947 characters extracted from source content.
Expand or collapse full text
1 LATCH: LLM-Assisted Timing Closure Harness for Post-Route FPGA Optimisation Shu Gu, Matthew Youngman, Graduate Student Member, IEEE, Yuqin Zhao, Cristian Sestito, Member, IEEE, Ali Siddique, Ramesh Krishnamurthy, Danial Chitnis, and Themis Prodromakis, Senior Member, IEEE AbstractâPost-route FPGA timing closure remains expert- dependent and computationally expensive. We present LATCH (LLM-Assisted Timing Closure Harness), a two-layer framework that separates large language model (LLM) orchestration from deterministic FPGA implementation and evaluation. Across six- teen designs and seven LLMs, a single-iteration study compares three agent control granularities â expert-written recipes, direct EDA operations and LLM-constructed procedures â to ask how much control an agent needs per attempt. Functional-pass rates are 98.2%, 71.4% and 17.9%, respectively; yet direct operations give slightly larger 3.4% medianF max gains when passing, versus 3.2% for recipes. This exposes a trade-off between execution reliability and timing improvement. Informed by this trade-off, a multi-iteration study fixes the action tier at expert recipes to ask how repeated attempts are best organised, comparing a fitted deterministic heuristic with sequential LLM reasoning, branching exploration and knowledge base-guided exploration within 12 checkpoints per run. Branching raises mean maximum- frequency improvement from 10.5% (sequential) to 16.0%, and the knowledge base to 20.3%, improving 15 of 16 designs. Characterisation across 2,421 recipe attempts profiled their gain and validation rates, showing hard-block re-placement gives the largest cumulative mean gain at 41.4 MHz. Index TermsâElectronic design automation (EDA), FPGA, large language model (LLM), LLM agents, timing closure. I. INTRODUCTION Timing closure seeks to meet a designâs target frequency by diagnosing failing paths and modifying placement and routing (P&R), physical optimisation, or constraints to improve F max . This remains a critical but expert-dependent stage because the appropriate intervention is determined by design-specific physical bottlenecks [1] and their interactions across many available optimisation options [2]. Each trial can require a full P&R run, with large circuits taking hours or even days [2], [3]. An autonomous timing-optimisation method could reduce this cost by selecting interventions from physical evidence. Machine learning (ML) has been applied across the EDA flow to improve engineering productivity, either by predicting This work was supported by the Engineering and Physical Sciences Research Council (EPSRC) AI Hub for Productive Research and Innovation in eLectronics (APRIL) under Grant No. EP/Y029763/1, and by the Royal Academy of Engineering (RAEng) Chair in Emerging Technologies under Grant No. CiET1819/2/93. (S. Gu and M. Youngman contributed equally to this work. Corresponding author: Matthew Youngman). S. Gu, M. Youngman, Y. Zhao, C. Sestito, A. Siddique, R. Krishnamurthy and T. Prodromakis are with the Centre for Electronics Frontiers, Institute for Integrated Micro and Nano Systems, School of Engineering, The University of Edinburgh, U.K. (email: m.j.youngman@sms.ed.ac.uk). D. Chitnis is with the Institute for Integrated Micro and Nano Systems, School of Engineering, The University of Edinburgh, U.K. physical outcomes earlier in the flow [4] or by selecting tool settings more intelligently [5]. Within FPGA timing optimisation, predictive models estimate post-route net delay during placement [6], calibrate delay inside differentiable timing-driven placement [7], and weight global placement by predicted criticality [8]. By acting inside the placement algorithm, these methods improve the next implementation but cannot choose a local repair for an existing routed checkpoint. Autotuners instead learn which tool settings or optimisation sequences to try: InTime [9] and LAMDA [10] rank tool- parameter combinations, DATuner [2] allocates trials across parameter-space partitions, and FlowTune builds optimisation sequences stage by stage, favouring sub-sequences with better measured results [3]. These autotuners remove manual tuning, but every candidate costs at least a partial implementation rerun and each model is learned within a single designâs campaign. As a result, these methods remain bound to costly iterations and generalise poorly to unseen designs. Where a learned placement policy has reportedly generalised, it relied on pre-training over earlier designs [11], with cross-design generalisation as an open research problem [5]. Large language models (LLMs) target these learning and generalisation limitations because they can reason over textual and structured evidence [12], compare it with tool docu- mentation or prior examples [13], [14], and select actions from tool feedback without fitting a new selector for each design [15]. This is attractive for timing optimisation, where useful evidence appears in timing reports, logs, constraint files and optimisation histories [13]. Physical implementation nevertheless exposes a hardware-specific failure mode termed the syntax trap, where LLM outputs can appear plausible as text, scripts or RTL code while remaining physically ineffective, unsafe or disconnected from downstream imple- mentation behaviour [16]. This trap is severe in backend design because public physical-design data is scarce, locked behind licenses, and expensive to generate [17], [18]. Physical-design benchmarks confirm the gap, as agents degrade on geometric reasoning and power, performance and area (PPA) trade- offs [19], and on tool-centric, long-horizon workflows [20]. Existing LLM systems therefore often work around the implemented state rather than improving it directly, generating scripts or templated implementation flows [25], re-running flow parameters or constraints [22], [21], or rewriting RTL through optimisers [26] or end-to-end design agents [27]. Recent ASIC systems move closer to the physical-design problem by editing P&R designs directly through engineering arXiv:2610.16625v1 [cs.AI] 12 Oct 2026 2 TABLE I SELECTED LEARNING-BASED APPROACHES TO BACKEND TIMING AND PHYSICAL OPTIMISATION. GROUPS, FROM TOP: ML-BASED, LLM-BASED, AND THIS WORK (SHADED). ENTRIES REFER TO THE REPORTED EXPERIMENTS. WorkTarget / InputDesignsTiming- feedback loop Physical modification Knowledge reuse SearchControl-level study InTime (2015) [9]FPGA / RTL6â F âParallel batchesNR DATuner (2017) [2]FPGA / RTL15 (10+5)â F âAdaptive batchesNR LAMDA (2019) [10]FPGA / RTL5â E â F,E âMulti-stage batchesNR Nexus (2025) [21]FPGA / RTL + constraints14â F NRSequential refinementNR ORFS-agent (2025) [22]ASIC / RTL + PDK3 (2 nodes)â F âParallel batchesNR FluxEDA (2026) [23]ASIC / routed design1 (ECO case)â D âSequential + rollbackNR PACT (2026) [24]FPGA / routed DCP35 DCPsâ D âRanked sequentialNR Single-iteration studyFPGA / routed DCP16Ăâ D ĂSingle submissionâ Multi-iteration studyFPGA / routed DCP16â D â K Sequential / branchingĂ â: explicitly supported;Ă: excluded by the stated study; NR: not reported in the reviewed version. Timing feedback: candidate implementation measurements guide further optimisation. Physical modification: F, flow re-execution; D, edits to an existing physical design; E, LAMDAâs search evaluation replays pre-collected tool measurements. Knowledge reuse: supplementary procedural knowledge or experience across trials, not merely an action catalogue; K, the KB-enabled multi-iteration variant. Control-level study: a common-backend comparison of recipe selection, direct operations and constructed procedures; NR does not exclude other ablations. Designs count backend cases, not models or trials: ORFS evaluates three circuits at two nodes, FluxEDAâs entry covers its ECO case and PACT counts DCP instances; both studies here use the same 16 designs. change orders (ECOs). RSR schedules ECO sizing, threshold- voltage and buffering commands, guided by retrieved expert scheduling strategies and result feedback [14], while FluxEDA keeps commercial tool sessions alive so that an agent can apply such edits and roll back rejected steps [23]. Concurrent with this work, PACT demonstrates LLM-guided ECO tuning of routed FPGA checkpoints by ranking typed edits, applying them sequentially and retaining only valid timing-improving results [24]. PACT thereby establishes routed FPGA check- point editing as a strong application of LLMs to backend EDA. Yet how LLMs fit into the backend flow remains an open question: how much action freedom can an agent use reliably, how efficiently can it navigate the timing-optimisation search space, and which aspects of its harness best supply backend design expertise. Table I summarises how prior ML- and LLM- based systems address these dimensions. This paper therefore presents LATCH (LLM-Assisted Tim- ing Closure Harness), a two-layer framework that improves post-route FPGA F max to investigate how LLMs behave in backend EDA. The deterministic execution layer characterises each checkpoint, applies physical modifications and validates the result. The LLM orchestration layer interprets backend evidence, requests additional analysis when needed and ranks the next action to try. This separation lets the paper study LLM decision-making whilst keeping implementation, validation and measurement deterministic. Contributions are as follows: 1) We introduce LATCH, a reproducible framework for LLM-orchestrated post-route FPGA F max improvement. Its protocol-mediated interface isolates LLM reasoning from deterministic EDA execution, providing an exten- sible framework: https:// github.com/ aprilaihub/ LATCH 2) We contribute nine engineer-written expert optimisation recipes encoding physical-design expertise as executable actions. Each targets a known timing failure mode and is profiled by measured value and validation risk. 3) We characterise the trade-off between FPGA backend action freedom, execution reliability and timing im- provement in a single-iteration study that compares three granularities of agent control. We then fix the most reliable recipe tier in a multi-iteration ablation study to explore design search mechanism effectiveness by comparing branching exploration and knowledge base guidance with sequential reasoning and a fitted heuristic. 4) We evaluate the framework on sixteen post-route FPGA designs, using seven LLMs in the single-iteration study, three LLMs in the multi-iteration ablation study, struc- tural legality checks on every candidate, and simulation- based functional checking on the published result. The single-iteration study identifies a trade-off between action reliability and timing gain: recipes are more reliable, while passing direct operations achieve a slightly higher me- dian improvement. The multi-iteration study therefore fixes the recipe interface to examine how search and knowledge reuse affect optimisation. Branching and knowledge base guidance improve mean gains over sequential reasoning, while comparisons with the fitted heuristic reveal differences in generalisation to held-out designs. The remainder of the paper is organised as follows: Section I describes the LATCH frame- work and expert recipes, Section I presents the benchmarks and both studies, Section IV discusses limitations and how each can be resolved, and Section V concludes. I. METHODOLOGY LATCH guides the selection of timing-optimisation pro- cedures for an implemented FPGA design using two vendor tools. AMD Vivado 2025.1 targets FPGA implementation, physical optimisation and timing analysis, and RapidWright 2025.2.1-beta reads and writes the post-P&R netlist directly to reach transformations Vivado does not expose [28]. Both act on a design checkpoint (DCP), which stores the FPGA implemented netlist together with its P&R. The framework is organised in two layers (Fig. 1): the deterministic execution backend performs analysis, modification and measurement, and the orchestration layer decides which modification to attempt on a selected DCP, using an agent that reasons over the evidence the backend supplies. The two layers run as servers communicating through the Model Context Protocol (MCP). 3 Fig. 1. Checkpoint-based FPGA optimisation framework. Design evidence informs the choice of an expert optimisation recipe, direct EDA operations or a constructed procedure. The backend executes proposed modifications and evaluates checkpoints, only retaining validated candidates that improveF max . A. System Overview 1) Inputs and outputs: Each optimisation step starts from a retained DCP selected as its parent. The pipeline then produces one candidate DCP from that parent, which joins the retained set if it passes the validation checks of Section I-C4. The framework therefore improves frequency by selecting among retained DCPs across optimisation steps rather than rebuilding the design from RTL. The run also carries two supporting state objects. The search history records the retained check- points, their eligibility for expansion, and the ordered actions and measured outcomes leading to each branch, including attempts recorded elsewhere in the search. The knowledge base (Section I-C2) holds design-independent notes on each recipe, distilled from exhaustive offline trials, and supplies prior expectation where the current evidence is silent. 2) The optimisation step: The optimisation loop starts with Deterministic Analysis, which extracts a fixed evidence set from the parent DCP, including timing reports, critical logic paths, placement spread, and routing detour (defined in Sec- tion I-B1). This evidence is then provided to the agent in the orchestration layer. When the fixed summary is not sufficient, the agent may request additional read-only probes of the DCP through Deep Analysis to locate the root cause of the timing limitation more precisely. Probes query the cached analysis of the parent, so repeated queries cost no additional tool time, or run additional tool analysis to supply new evidence. When the agent believes it has enough evidence, it performs Action Selection, choosing the next optimisation from the supplied evidence at one of the three nested control levels in Fig. 1. At the coarsest, the agent may select from a fixed catalogue of expert optimisation recipes, each a sequence of engineer-written transforms targeting a specific timing failure mode. The recipesâ internal command sequence and targeting rules are supplied entirely by the framework (Section I-B). With direct EDA operations, the agent gains finer control, specifying a single placement, routing or physical-optimisation call and naming the cells, nets or regions to act on through allow-listed tool command language (TCL) commands; the recipes remain available alongside them. At the finest level, constructed optimisation procedures add target construction, allowing the agent to build bounded intermediate targeting, grouping or spatial logic, for example collecting the nets on the critical path, filtering them by routing detour, and routing the remainder. Because all three levels compile to the same fixed set of Vivado and RapidWright commands, the agentâs use of each degree of freedom can be evaluated, with tool abstraction, proposal selection and execution performance isolated as separate effects. The selected action then returns to the backend as a typed call, which the Execution Pipeline applies deterministically in Vivado or RapidWright. 3) Validation, comparison, and search update: Validation and Comparison closes the loop, checking whether the candi- date checkpoint is legal, re-measuring timing, and comparing the result with its parent. We define an optimisation step as one pass through this loop, from a parent checkpoint to one evaluated candidate. A valid candidate returns to the search space and may become a later parent; an invalid or regressive candidate remains in the run record but is not expanded further. A run is the ordered set of optimisation steps explored from the initial checkpoint, organised by the two search patterns of Fig. 2: sequential and branching. In sequential search, the framework expands one retained checkpoint at a time; in branching search, it keeps multiple retained checkpoints on the frontier and may expand more than one of them within the same run budget. To choose the next expansion, the scheduler ranks legal checkpointâaction pairs across the whole frontier by the priority score the agent assigned to each pair, so the next parent is the checkpoint named by the highest-ranked pair. Branches use the same step mechanism and, acting on different checkpoints, may run concurrently. The runâs budget, 4 Fig. 2. Illustrated example of sequential and branching optimisation patterns with retained checkpoints. An invalid attempt leaves its parent available, and branching allows alternative changes to start from the same checkpoint. The run history records applied changes and measured outcomes. Numerical values illustrate the workflow rather than experimental results. TABLE I EXPERT OPTIMISATION RECIPES. ALL USE VIVADO;â ADDITIONALLY USES RAPIDWRIGHT FOR NETLIST MODIFICATION. RecipeFunction fanout â Splits timing-critical high-fanout nets by a factor of two to eight to reduce loading and routing delay. auto_pblockDefines a region from critical-path spread and fabric resources, then unplaces and re-implements the design inside. net_swapTargets problematic critical connections to reduce routing-related delay. phys_optRuns Vivado physical optimisation after placement and routing, including replication, cell resizing and register movement. lut_cone â Merges LUT-dominated critical logic cones to reduce logic depth and path delay. retimeMoves registers across combinational logic to reduce delay between sequential stages. memory_path_optOptimises critical paths involving embedded BRAMs using memory-aware physical optimisation. hardblock_relocateImproves physical locality between timing-critical hard blocks and the surrounding logic. congestion_spreadRedistributes logic in congested regions to reduce routing pressure. the number of checkpoints a run may produce, is fixed in advance, as are the depth, expansion and concurrency of branching. Every proposal, action and measured outcome is written to the run record, so a run can be inspected, resumed or reproduced, and the record itself becomes evidence. B. The Deterministic Execution Backend The deterministic backend provides the implementation and evaluation interface between optimisation decisions and the physical FPGA design. The agent may propose backend oper- ations, but analysis probing, execution, checkpoint generation and timing evaluation remain backend-controlled, so optimisa- tion performance is determined by the commands that change the DCPâs physical implementation. This section describes how the backend extracts analysis evidence and executes the expert-written recipes, the one action tier the framework authors in advance, each a fixed procedure embedding an engineerâs expertise. The finer tiers (Section I-A2) have no such fixed procedure, because the agent generates them at run time from the same EDA tool operations. 1) Design analysis and diagnostic extraction: Before op- timisation, the backend performs a deterministic analysis of the input implementation: Vivado opens the input checkpoint, parses its timing summary to extract the worst negative slack (WNS), total negative slack (TNS), and number of failing endpoints, and queries the clock period to determine the target clock frequency and the achievable operating frequency. For a clock period T clk and measured WNS, the backend estimates the achievable frequency as F max = 1000 T clk â WNS MHz,(1) where timing violations correspond to WNS < 0. Structural and physical diagnostics complement the timing report. Vivado identifies critical high-fanout nets and extracts the cells and pins lying on the most critical paths, which RapidWright uses to measure the physical spread of critical- path cells (maximum and average cell distances) and the routing detour of critical connections, identifying those whose routed length considerably exceeds their direct physical sep- aration. High spread indicates excessive interconnect distance and motivates region-constrained placement, whereas large detours identify candidates for cell re-placement. The resulting diagnostic set D comprises WNS, TNS, F max , the number of failing endpoints N fail , critical high-fanout nets N fanout , critical-path information P crit and physical placement charac- teristics S place . 2) Expert optimisation recipes: The backend exposes a catalogue of expert optimisation recipes, each with a fixed sequence of examination, modification, implementation and evaluation operations directed at one class of timing bottle- neck; Table I lists the nine forming the expert-written recipe action tier used throughout this study. Because a recipeâs internal command sequence is supplied by the framework, selecting it commits the agent to a known implementation procedure rather than an arbitrary tool invocation. The catalogue is organised around the physical causes of critical-path delay identified by the deterministic and deep analysis. Placement-oriented recipes act on where logic sits: auto_pblock re-implements the design within a region derived from critical-path spread, suiting designs whose critical logic is dispersed across the fabric, while hardblock_relocate improves locality between timing- 5 critical hard blocks and the surrounding soft logic. Because embedded block random access memories (BRAMs) and digital signal processing (DSP) columns are fixed in the fabric, hardblock_relocate acts on the placement and registering of the logic around them, which bounds its yield on memory-dense designs. Routing-oriented recipes act on how logic is connected (net_swap, congestion_spread and fanout), with the fanout split factor bounded between two and eight to avoid excessive replication. Logic and sequential recipes act on the structure of the path itself: lut_cone merges lookup table (LUT)-dominated critical cones to reduce logic depth, and retime moves registers across combi- national logic to balance delay between sequential stages. Finally, memory_path_opt targets paths through BRAMs, and phys_opt applies Vivadoâs general physical optimisa- tion after placement and after routing. The recipes also differ in where they execute, which matters more for reliability than the ambition of the transformation. Seven perform their modification inside Vivado and inherit its incremental optimisation semantics, under which a transforma- tion is retained only where the tool measures an improvement. The remaining two, fanout and lut_cone, modify the netlist in RapidWright and write an intermediate checkpoint that Vivado reopens and reroutes, gaining direct access to placement and connectivity that Vivado does not expose but leaving the vendor toolâs gated loop: the returned design is checked for legality when reopened, but no intermediate improvement guarantee applies to the modification itself. Section I-C shows that validation risk concentrates almost entirely in these two recipes. 3) Timing verification and quantitative feedback: Every optimisation is evaluated using implementation-level timing data: the backend records the initial WNS and clock period before modification, re-evaluates timing after the candidate has been routed, converts the result to an achievable F max using (1), and compares it with the baseline. For an initial implementation D 0 and an optimised implementation D i , the changes âWNS = WNS(D i )â WNS(D 0 ) and âF max = F max (D i )â F max (D 0 ) are positive for an improvement. The backend tracks the best observed WNS across a run, retains TNS and the failing-endpoint count from the initial report, and inspects route status after each physical modification so that routing errors are identified before a timing result is accepted. The objective continues to reward improvement after timing is met. F max in (1) rises with positive WNS, and no run terminates on reaching WNS â„ 0. C. The LLM Agent Orchestration Layer At each step, the agent occupying the pipelineâs decision stage is given the current design state and the actions avail- able at the active control level of Section I-A2. What the agent returns therefore depends on this tool abstraction level: at the recipe interface it returns a ranked choice over the optimisation recipe catalogue, whereas at the direct-operation and constructed-procedure interfaces it submits an executable proposal, which it may revise in response to construction feedback before committing. Fig. 3. Analysis prompt for a recipe-selection decision. The design state, diagnosis, and available agent control interfaces â which change depending on which control level is available to the agent â are injected (purple), while the underlying template remains (black). A typical agent response is shown (green), ending in the ranked candidate list and the selected action. Fig. 4. Example knowledge base recipe description, allowing the agent to reason about a recipeâs use case from generalised, non-benchmark-specific past information. 1) Prompt construction: The diagnostic evidence extracted before each decision (timing summaries, critical-path com- position, and the relevant cell, net, and placement context), together with the recipes or operations available at the active control level, is inserted into a fixed prompt template alongside the task description and the required response format (Fig. 3). At the recipe interface, the agent returns a ranked list of candidate actions each scored for priority and risk, with a stated confidence and evidence basis. A fixed, deterministic rule then selects the candidate to execute: highest priority wins, with ties broken by the stated confidence, then by lower risk, then by checkpoint and catalogue order, after two filters exclude the recipe last applied to a checkpoint and any recipe 6 sequence already attempted. Stating evidence and uncertainty before committing to a score gives the agent room to reason explicitly and leaves a traceable record of why a recipe was preferred, whether or not that reasoning proves right. 2) The knowledge base: This supports action selection at the recipe tier by providing additional information to the agent. Each recipe holds one entry (Fig. 4), distilled from an offline, exhaustive execution of all nine recipes across the known benchmark designs rather than authored from first principles, with the same fields: the mechanism the recipe acts through, the design conditions under which it tends to help or hurt, and the ceiling on what it can achieve. Because checkpoints differ in function, resource mix, and implementation method, numeric thresholds measured on one rarely transfer to another, so findings are generalised into qualitative conditions rather than measured values, for example a large, disposable place- ment rather than a percentage, so that the same entry describes a recipeâs behaviour on a design the exploration never saw. Entries are injected as an explicitly labelled prior, and the agent is instructed to cite them as prior evidence rather than as evidence about the design in front of it. Backend timing- closure knowledge resides largely in vendor-specific interfaces and engineering experience unlikely to appear in training data; the knowledge base therefore supplies it as in-context learning. 3) Deep analysis and the bounded decision loop: When the cause of a violation remains ambiguous, the agent may request evidence beyond the fixed deterministic analysis through a bounded read-only probe loop, in each turn either issuing probes or returning its selection. Probes expose existing ev- idence without creating new design states, refining the de- scription of the current DCP only. Ten probes are available in three families: three re-run current-design reports for tim- ing, routing, and resource utilisation; five retrieve established search evidence, including the DCPâs state and parentâs F max gain, stored diagnosis, ancestor recipe outcomes, outcomes in other branches, and validation errors and warnings; and two summarise broader search history through recurring recipe sequences and comparable prior cases. The available set is decision-dependent: all ten are offered at the root; eight at ordinary checkpoints, omitting routing and utilisation reports already measured; and seven after validation failure, omitting timing. This deep analysis loop is used only in the multi-iteration study, as the single-iteration study focuses on splitting plan- ning and tool abstraction. To prevent scaling token costs, it is bounded at six commands for the root decision step and four at every other DCP step. Because this bounds evidence- gathering rather than reasoning, a session can reach the bound before returning a ranking; in the reported experiments, such a session terminated without a model ranking and received a fixed ordering over the legal candidate set at neutral priority. The bound applies identically at every level, so comparisons between levels are unaffected, although a substituted choice describes the fallback rather than the agent. A subsequent sweep with a raised bound reduced substitution to below 1% of sessions and did not improve achieved frequency, confirming that the reported results are not an artefact of the bound. 4) Validation and recovery: Every candidate DCP must be shown to be both a physically legal design and to agree with the design it replaces on the applied tests before it can be trusted, using two checks that differ in cost and frequency. Structural validation, which establishes physical validity, runs on every candidate: the implementation logs and the route-status report are parsed to confirm that the produced checkpoint reopens, that routing completed with no unrouted nets or routing errors, and that timing can be re-measured on the designâs target clock rather than on an all-clock summary. Functional checking, whose success is a functional pass, is reserved for the single candidate selected as a runâs published result, which in the single-iteration study is each trialâs com- mitted candidate, since it requires simulation and establishes agreement for the applied tests rather than formal equivalence: a precheck is followed by five deterministic simulation runs of 200 input vectors each, and the candidateâs outputs are compared against those of the starting design; a byte-identical candidate inherits its parentâs certificate rather than being re- simulated. An action that proves infeasible to execute is retried once automatically; a candidate that fails either check, or regresses relative to its parent, is excluded from further search and the step reverts to its parent checkpoint, while its execution record is retained in the run history. I. RESULTS A. Benchmark and Experimental Constraints Evaluation uses sixteen post-route implementation DCPs: fifteen drawn from the FPL 2026 AMD Competition bench- marks [29] and one from RapidWright [30]. The set spans roughly two orders of magnitude in instance count, from approximately 3k to 325k LUTs and FFs, covers soft-logic-, memory- and arithmetic-dominated resource mixes, and was selected to span the range of achievable timing slack, with baseline frequencies from 406 MHz, where WNS is under 1 ns, down to 48.2 MHz, where WNS is â19.2 ns. Several designs therefore yield substantial frequency to almost any intervention, while others are limited by logic depth or by delay internal to a hard block and hence have limited yield to any method examined here. The corpus is partitioned into three groups: eight known designs (the development set), whose characteristics and per- formance were assessed before full evaluation and were used to develop the knowledge base and fit the deterministic pol- icy described in Section I-C; five re-implementations from design families represented in that fitting set; and three out- of-family designs from families not represented in it, the latter two groups forming the eight held-out designs. This partition separates designs used to establish and tune the method from those reserved to test generalisation. It applies only to the multi-iteration study, whose knowledge base and fitted heuristic were derived from the known designs; the single-iteration study uses no knowledge base and reports all sixteen designs together. B. Single-Iteration Agent Control Study This study examines how agent control affects the reliability and timing gain of a single optimisation step across 16 FPGA 7 designs and seven LLMs: Claude Sonnet 5, DeepSeek v4 Flash and Pro, Gemini 3.6 Flash, and GPT-5.6 Luna, Sol, and Terra. The dataset contains one selected outcome per designâ model pair under Expert optimisation recipes, Direct EDA operations, and Constructed procedures, giving 112 trials per condition and 336 in total. The recipe condition permits only recipe selection; the other conditions retain inherited interfaces but explicitly request direct operations or a constructed pro- cedure. We therefore measure outcomes under capability-use instructions, with actual execution of the requested capability assessed separately. No knowledge base is used in this study. For each design, all conditions share the starting checkpoint, base observations, read-only query definitions, and planning limits: four model turns, eight query items, three construction- feedback rounds, and normally 65,536 input bytes including interface documentation. The LLM may query the design and correct construction errors before committing at most one pro- posal for execution and scoring, without subsequent revision using measured candidate timing. Each proposal allows up to eight statements, including at most four placement, routing, or physical-optimisation calls. PicoBlazeArray uses the 2025.1 checkpoint (starting F max = 350.8 MHz). Its 21 selected outcomes come from 38 started engineering attempts, with provider changes and dated DeepSeek endpoints (Flash-0731 and Pro-0813). Contin- uations follow the approved engineering sequence rather than maximum performance. The final constructed-procedure con- tinuations admitted up to 262,144 input bytes; earlier attempts and direct operations admitted 65,536. These are protocol exceptions rather than independent optimisation repeats or a frozen replay. Three tool-deadline timeouts count as unsuc- cessful trials in the pass-rate denominator; their unmeasured timing changes are not imputed as zero. A physically valid result passes the execution, output, and routing checks. Functional evaluation follows Section I-C4. A functional pass requires all prescribed checks to pass; out- put mismatch denotes differing outputs, and functional check incomplete denotes validation-infrastructure errors preventing completion. The end-to-end functional-pass rate is the fraction of each conditionâs 112 trials achieving a functional pass. The signed timing change âF max of Section I-B3 is taken relative to the starting (root) checkpoint, and Figs. 5 and 7 re- port it as per-trial percentage improvement, 100 âF max /F root max ; implementation case studies use MHz. Byte-identical check- points receive zero change. Distributions and the designâ model matrix retain all functional passes. Timing improvement requires a functional pass and âF max > 0; outcome-rate denominators include all assigned trials. Fig. 5 summarises functional-pass rates and timing improve- ments across the three control conditions. Recipes achieve a 98.2% pass rate (110/112), direct operations 71.4% (80/112), and constructed procedures 17.9% (20/112). All recorded physically valid candidates pass the functional checks; the remaining trials yield no validated functional-pass output. Among functional passes, direct operations yield a slightly higher median improvement than recipes (+3.4% versus +3.2%), but improve timing in fewer of the 112 assigned trials (67 versus 91). Constructed procedures have a median (a) Functional pass rate 0% 25% 50% 75% 100% 98.2% (110/112) 71.4% (80/112) 17.9% (20/112) (b) F max improvement (%) -30% -20% -10% 0% 10% 20% 30% 40% 50% +3.2% n = 110 +3.4% n = 80 +0.0% n = 20 Expert optimisation recipes Direct EDA operations Constructed procedures Fig. 5. Reliability and timing improvement across 16 designs and seven LLMs (112 trials per condition). (a) End-to-end functional-pass rates, with passing and total trial counts. (b) PercentageF max improvement relative to each trialâs starting checkpoint, for functional-pass trials only. Points show individual trials with horizontal jitter for visibility. Boxes span the interquartile range; whiskers extend to the most extreme observations within 1.5 times that range. Labelled lines mark medians. Zero and negative improvements are retained. % of all trials (16 per model and condition) (a) Direct EDA operations ProposalExecutionPhysically valid result Functional pass Timing improved Claude Sonnet 5100%94%75%75%56% DeepSeek v4 Flash94%94%94%94%88% DeepSeek v4 Pro100%75%62%62%56% Gemini 3.6 Flash100%94%81%81%62% GPT-5.6 Luna100%38%38%38%19% GPT-5.6 Sol100%81%62%62%62% GPT-5.6 Terra100%31%31%31%31% (b) Constructed procedures ProposalExecutionPhysically valid result Functional pass Timing improved Claude Sonnet 588%81%81%81%0% DeepSeek v4 Flash6%6%6%6%0% DeepSeek v4 Pro6%0%0%0%0% Gemini 3.6 Flash6%0%0%0%0% GPT-5.6 Luna25%25%25%25%0% GPT-5.6 Sol6%0%0%0%0% GPT-5.6 Terra19%6%6%6%6% 0 25 50 75 100 Fig. 6. Progression from proposal generation to timing improvement for (a) Direct EDA operations and (b) Constructed procedures. Each row represents 16 trials for one LLM. Percentages are calculated over all 16 trials, with each stage retaining only trials that satisfy all preceding stages. The final stage requires a functional pass and âF max > 0. improvement of 0%: 10 of their 20 passing trials show no change, eight regress, and two improve. Fig. 6 tracks progression from qualifying proposalsâ executable submissions in the requested interfaceâto timing 8 Benchmark Initial F max (MHz) boom_soc48.2 vexriscv_re-place310.2 amd_mini_isp307.1 logicnets_jscl403.6 finn_radioml284.9 rosetta_digit-recognition367.0 rosetta_optical-flow324.9 corescore_500_mod344.2 boom_soc_v277.2 amd_mini-isp_v2288.0 rosetta_3d-rendering_v2236.7 vexriscv_re-place_v2397.5 vtr_mcml_v269.3 fir_symmetric_systolic405.7 fir_systolic_transposed355.5 picoblazearray350.8 (a) Expert optimisation recipes Functional pass (%) 10.914.310.914.314.314.310.9100 31.531.531.531.531.531.537.4100 22.222.222.222.222.222.222.2100 2.42.42.42.42.42.486 0.03.20.03.23.23.23.2100 0.00.00.00.00.00.00.0100 0.10.10.10.10.10.10.1100 0.70.70.70.70.70.75.8100 6.76.74.76.76.76.76.7100 33.232.233.232.233.232.286 3.43.43.43.43.43.43.4100 0.00.00.00.00.00.00.0100 2.13.42.13.43.43.43.4100 6.710.010.010.010.06.26.2100 0.10.10.70.10.10.70.1100 0.61.21.20.01.20.00.0100 100.0100.0100.0100.093.8100.093.8Functional pass (%) Claude Sonnet 5 DeepSeek v4 FlashPro Gemini 3.6 Flash GPT-5.6 LunaSolTerra (b) Direct EDA operations Functional pass (%) 14.514.529 31.523.826.725.137.437.486 22.230.329.731.631.631.686 2.429.023.62.43.12.42.4100 0.23.21.823.257 0.01.62.30.07.72.986 0.10.15.64.9-0.76.90.1100 0.70.70.05.857 5.314 33.233.240.337.640.333.286 12.43.410.73.43.43.486 0.00.00.0-2.00.00.086 0.33.42.43.557 6.46.19.16.46.010.086 0.00.16.20.90.00.10.1100 0.60.029 75.093.862.581.243.875.068.8Functional pass (%) Claude Sonnet 5 DeepSeek v4 FlashPro Gemini 3.6 Flash GPT-5.6 LunaSolTerra -50 -25 0 25 50 F max improvement (%) No functional pass Fig. 7. Designâmodel timing outcomes under (a) Expert optimisation recipes and (b) Direct EDA operations. Each numeric cell shows percentageF max improvement relative to the starting checkpoint for one functional-pass trial; Ă denotes no functional pass. InitialF max gives the starting frequency in MHz. Designs are ordered by increasing initialF max ; both panels use the same design and model ordering and a common colour scale. Row pass percentages are calculated across seven models; column pass percentages are calculated across sixteen designs. TABLE I PHYSICAL CASE STUDIES. SELECTED AND BEST DENOTE THE LLM-SELECTED RECIPE AND BEST RECORDED RECIPE FROM THE SAME STARTING CHECKPOINT; DIRECT DENOTES DIRECT OPERATIONS. DELAYS DESCRIBE EACH OUTPUTâS WORST SETUP PATH. RESOURCES DESCRIBE THE INPUT. Circuit / modelOutputâF max WNS Logic Route Limiting-path structure (MHz)(ns)(ns)(ns) LogicNets / DeepSeek v4 Flash Selected recipe+9.5â0.921 0.514 1.887 LUT / multiplexer path 30.8k LUTs, 1.7k FFs,Best recorded recipe+98.0â0.494 0.509 1.467 LUT / multiplexer path 0 DSPs, 0 BRAMsDirect operations+117.0â0.421 0.562 1.340 LUT / multiplexer path FINN RadioML / GPT-5.6 SolSelected recipe+9.1â1.801 1.135 2.198 12-level carry/LUT path 73.6k LUTs, 45.8k FFs,Best recorded recipe+54.4â1.347 1.155 1.566 12-level carry/LUT path 0 DSPs, 24.5 BRAMsDirect operations+66.1â1.249 2.405 0.196 Six-RAMB36E2 cascade improvement. Execution requires a direct EDA operation be- yond recipe selection in panel (a), or use of a procedure- created intermediate object by a subsequent operation in panel (b). Unlike Fig. 5, later stages count only trials that also execute the requested capability. Of the 112 direct-operation trials, 111 produce qualifying proposals; 81 (72.3%) execute the capability, 71 pass functional checks, and 60 improve tim- ing. For constructed procedures, only 25 of 112 trials produce qualifying proposals; 19 execute and pass, and one improves timing, so their largest loss occurs before a qualifying proposal is produced. Model differences are also substantial: DeepSeek v4 Flash executes direct operations and passes on 15 designs, improving 14, whereas Claude Sonnet 5 executes constructed procedures and passes on 13 designs but improves none, so successful execution does not necessarily yield a timing gain. Fig. 7 shows that the effect of additional control depends on both design and LLM. On vexriscv_re-place, switch- ing from recipes to direct operations increases the timing improvement from +31.5% to +37.4% for GPT-5.6 Sol, but reduces it from +31.5% to +23.8% for DeepSeek v4 Pro. On boom_soc, all seven LLMs pass with recipes, whereas only DeepSeek v4 Flash and GPT-5.6 Sol pass with direct operations, with similar gains to their recipe results. Additional control can therefore increase or reduce timing gains, or fail to produce a functional-pass result. Table I compares selected recipes, the highest-F max recorded functional-pass recipes from the same starting check- points, and direct-operation results, with execution traces and critical-path reports revealing the corresponding physical changes. On LogicNets, DeepSeek v4 Flash unroutes and unplaces the design, then applies placement, physical opti- misation, routing, and final physical optimisation; its +117.0 MHz gain exceeds both its selected phys_opt recipe (+9.5 MHz) and the best recorded recipe (+98.0 MHz), whereas DeepSeek v4 Proâs +95.2 MHz direct-operation gain exceeds only its selected recipe. On FINN RadioML, GPT-5.6 Sol re-places the design and applies physical optimisation and routing, gaining +66.1 MHz as the worst setup path shifts from the 12 carry/LUT levels seen in both recipe outputs to six cascaded RAMB36E2 blocks, changing the structure limiting frequency. On vexriscv_re-place, DeepSeek v4 Proâs direct operations yield less gain than its selected recipe: lower 9 DeterministicLLM-based Benchmark Set Initial F max (MHz) (a) Fitted heuristic (b) Sequential reasoning (c) Branching exploration (d) Knowledge base- guided exploration Functional pass (%) Best ÎF max MHz (%) boom_socK48.2 vexriscv_re-placeK310.2 amd_mini_ispK307.1 logicnets_jsclK403.6 finn_radiomlK284.9 rosetta_digit-recognitionK367.0 rosetta_optical-flowK324.9 corescore_500_modK344.2 boom_soc_v2R77.2 amd_mini-isp_v2R288.0 rosetta_3d-rendering_v2R236.7 vexriscv_re-place_v2R397.5 vtr_mcml_v2R69.3 fir_symmetric_systolicO405.7 fir_systolic_transposedO355.5 picoblazearrayO350.8 91.027.068.729.389.020.285.989.991.6102.2100+49.3 (102.2) 51.431.531.531.532.632.641.942.832.642.8100+159.5 (51.4) 32.733.222.223.623.629.432.630.033.231.6100+102.0 (33.2) 23.810.32.42.44.317.723.823.824.13.860+97.2 (24.1) 21.13.23.23.210.220.120.117.320.121.287+60.5 (21.2) 15.90.00.00.02.114.315.010.711.715.7100+58.2 (15.9) 4.80.10.10.15.65.65.63.94.94.8100+18.3 (5.6) 0.09.30.70.77.49.39.39.39.39.3100+32.1 (9.3) 14.89.49.99.526.416.516.69.022.625.8100+20.4 (26.4) 41.540.943.340.733.238.339.739.740.340.2100+124.7 (43.3) 21.13.43.43.73.726.226.316.420.126.3100+62.2 (26.3) 0.00.00.00.00.00.00.40.00.00.0100+1.7 (0.4) 0.03.43.43.43.53.43.43.53.43.4100+2.4 (3.5) 0.011.411.411.410.110.011.410.110.610.1100+46.2 (11.4) 0.00.10.10.11.61.62.31.63.32.6100+11.9 (3.3) 0.01.51.92.01.51.51.51.31.51.5100+7.0 (2.0) Functional pass (%) 100.0100.0 Sonnet 100.0 Gemini 95.8 Luna 100.0 Sonnet 100.0 Gemini 93.8 Luna 100.0 Sonnet 100.0 Gemini 93.8 Luna F max improvement (%) Set key K known (development set) R held out, same family O held out, out of family 01020304050 Fig. 8. Best functional-passF max improvement per benchmark for (a) the deterministic fitted heuristic and the LLM-based levels (b) sequential reasoning, (c) branching exploration and (d) knowledge base-guided exploration, each with Claude Sonnet 5, Gemini 3.6 Flash and GPT-5.6 Luna (best of three repeats). TABLE IV IMPLEMENTATION RESULTS FOR THREE DESIGNS, COMPARING THE INPUT CHECKPOINT WITH THE ABLATION LEVELS. Circuit / Model / ResourcesOutput âF max (MHz) WNS (ns) Logic (ns) Route (ns) Limiting-path structure BOOM SoC GPT-5.6 Luna 227k LUTs, 98k FFs, 61 DSPs, 161 BRAMs Input checkpointââ19.162 2.001 18.471 27-level LUT path to load queue Fitted heuristic+43.9â9.283 2.0728.675 20-level LUT path to I-cache BRAM Sequential reasoning+14.1â14.463 1.220 15.001 16-level LUT path to register file Branching exploration+41.4â9.583 2.6238.351 34-level LUT/multiplexer path to register file Knowledge base-guided+49.3â8.685 1.9828.314 19-level LUT/carry path to register file AMD mini-ISP v2 Gemini 3.6 Flash 3.2k LUTs, 4.5k FFs, 40 DSPs, 12 BRAMs Input checkpointââ1.902 0.3942.711 5-level LUT path to line-buffer BRAM Fitted heuristic+119.5â0.884 1.9090.397 6-level DSP multiply path Sequential reasoning+124.7â0.853 1.9230.350 6-level DSP multiply path Branching exploration+110.2â0.941 1.9110.451 6-level DSP multiply path Knowledge base-guided +116.2â0.904 1.9250.400 6-level DSP multiply path Symmetric FIR Claude Sonnet 5 0.7k LUTs, 22.6k FFs, 680 DSPs, 0 BRAMs Input checkpointââ0.465 0.0781.999 Delay-line register to DSP input Fitted heuristic+0.0â0.465 0.0781.999 Unchanged; only attempt rejected Sequential reasoning+46.2â0.213 0.9951.048 2-level DSP adder-tree cascade Branching exploration+41.1â0.238 0.1301.963 Valid signal to DSP clock enable Knowledge base-guided+41.1â0.238 0.1301.963 Valid signal to DSP clock enable logic delay is outweighed by increased routing delay (2.160 versus 1.840 ns) on the worst setup path. C. Multi-Iteration, Expert Recipes Ablation Study Where the single-iteration study asked how much control to give the LLM within one attempt, this study asks how repeated attempts should be organised to efficiently navigate the design space. Given the single-iteration trade-off between reliability and reward, this study fixes the action tier at the nine expert recipes of Table I, which execute identically in both studies, and varies only the selection mechanism over multi-iteration runs to isolate selection from execution. Four mechanisms are compared. The fitted heuristic ranks recipes from measured physical features without a language model. Sequential reasoning replaces that ranking with LLM-driven selection along a sequential trajectory. Branching exploration retains that procedure and adds parallel expansion, evaluating several candidates from one checkpoint and continuing from the best that validates. Knowledge base-guided exploration retains branching and adds the knowledge base described in Section I-C. The last three form a strict inclusion chain, so differences between adjacent levels isolate the added mech- anism, while the heuristic is an independent deterministic baseline sharing the same action tier and validation gating. All levels receive the same maximum budget of twelve DCPs per benchmark run. Three of the seven previously characterised LLMs span the costâcapability range: GPT-5.6 Luna and Gemini 3.6 Flash as low-cost options, the latter among the stronger prior performers, and Claude Sonnet 5 as a high- capability reference. The heuristic is a deterministic, non-learning baseline that establishes the studyâs floor condition, fitted onto the DCP and recipe results from the known benchmarks .... At each step it measures four properties of the current design state: 10 the proportion of critical-path delay attributable to routing versus logic, the depth of the critical logic chain, the count of instantiated hard-block resources, and the load on the most heavily driven net, each selected for a documented physical link to at least one recipeâs mechanism of action and for statistical prominence in differentiating the best recipe in the prior study. It then applies the single highest-scoring recipe; it never branches, hedges between candidates, or revises its scoring rule within a run. For recipe f and standardised feature vectorz, the score is score f = ÎČ f + X i w f,i z i ,(2) where ÎČ f is the recipeâs mean percentage frequency improve- ment across the fitting corpus, and the summation is the design-conditioned adjustment; selection is by arg max with deterministic tie-breaking. A recipe therefore starts from its average worth and is moved up or down by how far the current design differs from the fitting corpus. Coefficients were fitted by ridge regression against percentage rather than absolute improvement, so that designs with dissimilar baseline clocks contribute comparably, with regularisation strength selected by sweeping several orders of magnitude under leave-one-design- out validation. Fig. 8 reports, for every benchmark, the best functional- pass F max improvement of the fitted heuristic and of each LLM at each LLM-based ablation level. The fitted heuristic and knowledge base-guided exploration reach equivalent cor- pus means, 19.9% and 20.3%, against 10.5% for sequential reasoning and 16.0% for branching exploration, but the per- design results show opposite successes. On the known designs, the fitted heuristic shows the strongest F max improvement, because it was fitted on those circuits, yet on the held- out designs it returns no improvement on five of eight, and on the known corescore 500mod. On picoblazearray, whose 660 memory blocks lie far beyond the fitted range of 250, the policy selected auto_pblock, which regressed the design, giving an example where the fitted heuristic cannot reliably extrapolate its selection rule to sufficiently unusual designs. On two further designs, corescore 500mod and firsystolictransposed, the selected recipe auto_pblock could not place the design inside its region, so routing failed on an unplaced netlist, and on the remaining three the selected recipes executed successfully but regressed the design. A fitted policy carries no representation of its own uncertainty, so an out-of-range design produces a confident commitment instead of an abstention, and adding a rejection rule to (2) would drive the heuristic to overfit the corpus, an issue already requiring careful management. In contrast, the three model- driven ablations return a positive gain on 14, 16, and 15 of 16 designs respectively, including every out-of-family design, suggesting an ability to generalise across unseen benchmarks. Table IV examines this generalisation at the physical level, taking one design from each partition with the LLM that achieved its best result. On BOOM SoC, GPT-5.6 Luna with knowledge base-guided exploration improves F max by 49.3 MHz: the framework diagnosed the worst path as routing- dominated, with 18.5 of its 20.5 ns spent in wiring, and applied memory_path_opt, whose re-placement reduced that route delay to 8.3 ns. On the held-out AMD mini-ISP, Gemini 3.6 Flash achieves the largest gain in the study, 124.7 MHz; here every level removes the wire-bound path into a line-buffer BRAM, after which the limit lies inside a DSP multiplier, so the levels converge on similar results. On the out-of-family symmetric FIR filter, Claude Sonnet 5 improves F max by 46.2 MHz where the fitted heuristic returns nothing. In this case, the reason was the valid signal driving the clock enables of the DSP adder tree: a second phys_opt pass re-optimised that path and moved the limit into the adder tree itself, whereas Sonnetâs branching runs stopped after a single pass. Every ablation nonetheless performs better on designs it has already seen: mean improvement on the development set against the held-out set is 30.1% against 9.7% for the fitted heuristic, 12.7% against 8.4% for sequential reasoning, 20.9% against 11.1% for branching exploration, and 28.6% against 11.9% for knowledge base-guided exploration; since the knowledge base was distilled from the same known de- signs, part of its advantage remains design-specific. Sequential reasoning underperforms structurally rather than through weaker inference. Approximately 68% of a designâs best observed result is reachable within a single intervention, so a single-trajectory search commits to one opening and cannot recover from a poor one, nor efficiently from an invalid checkpoint, because expanding one candidate at a time forfeits the remaining budget. Evaluating three openings instead of one gives breadth at the root rather than depth and accounts for approximately +8.6 MHz of gain, close to two-thirds of branching explorationâs 14.2 MHz advantage over sequential reasoning. Breadth pays at the root because depth rewards little beyond it: within branching-capable runs, the share of physically valid DCP improvement attempts achieving no further gain over their own original DCP rises from 9.2% among the opening candidates to 34.4% beyond them, so roughly a third of the checkpoint budget beyond the opening step is spent on attempts that do not advance the search. This stems from the recipes themselves: they act only on currently-failing paths and commit only improvements, so repeated application searches already-harvested ground; for example, phys_opt returns approximately +22 MHz on first application and under +5 MHz on repetition. Fig. 9 relates recipe usage to each recipeâs average cumula- tive F max improvement over the starting DCP and validation pass rate. The heuristic spends 77% of its attempts on the two highest-yielding recipes (Fig. 9a), against 0.6% for sequential reasoning and 11% for branching exploration, so selection, not execution, is the binding constraint on the model-driven levels; the knowledge base recovers this to 21% by em- bedding expert knowledge without altering recipes. Fig. 9b tabulates each recipeâs mean gain beside its validation pass rate, and what each recipe physically changes explains the remaining per-design variation. Hard-block-oriented recipes cannot relocate fixed memory and arithmetic columns, so their effectiveness depends on how much surrounding soft logic can be profitably re-placed. This is evident in the BOOM SoC case of Table IV, where the recipeâs outcome varies with the starting placement. Furthermore, hardblock_relocate is 11 Fig. 9. Effectiveness of the expert recipes across the multi-iteration study. (a) Share of each ablation levelâs recipe attempts spent on each recipe. (b) Each recipeâs meanF max improvement per attempt, measured from the starting DCPs, and the share of its attempts passing physical validation. Fig. 10. Cost assessment across multi-iteration runs, (a) language-model expense againstF max improvement for every model-driven run, (b) phase time decomposed by pipeline stage beside the elapsed wall time. the best-performing recipe on six of sixteen designs, yet, on picoblazearray, its 660 small cores already sit beside their memory blocks, leaving little scope for re-placement. Second, auto_pblock unplaces and re-places the whole design within one region, so its risk lies in whether a given design fits that region rather than in the timing limits: it is reliable on twelve designs, but it fails on over 89% of attempts on the other four. Validation outcomes are likewise structural: four recipes, executing wholly within Vivado, passed validation on all 1,477 of their attempts, whereas fanout and lut cone, the two recipes that export the netlist to RapidWright and write it back, forfeiting that guarantee, passed on only 38.2% and 76.4%. Validation critically guarded against results that only appear to succeed: on firsystolictransposed, a partially placed autopblock output reported a 105 MHz gain with positive slack and was rejected. In this study, correctness was therefore secured by the execution boundary rather than by the reasoning that selected the action. Two measures of duration assess the cost of running the optimisation (Fig. 10). Phase time attributes each attemptâs duration to the pipeline stage responsible and sums across attempts; wall time is the runâs own elapsed duration. Their ratio indicates the degree of concurrency achieved: it averages 1.66Ă for branching exploration and 1.69Ă for knowledge base-guided exploration (Fig. 10b), below the ideal 3.0Ă under full overlap of three branch candidates, while remaining below unity for non-branching levels because some elapsed time is not attributed to a labelled stage. This suggests strong utilisation but opportunity for optimising runtime further. Median language-model cost per run varies roughly twentyfold across the three LLMs for a difference in mean improvement of under a percentage point (Fig. 10a), so among the three LLMs tested, model choice mainly affected cost rather than achieved frequency, consistent with the single-iteration study, in which no LLM dominated across designs. Language-model analysis accounts for 4.6â6.7% of phase time and tool ex- ecution with diagnostics for 91â92% at every level, so the economic case for orchestration rests on issuing effective tool invocations, not on inexpensive inference. The fitted heuristic 12 (a) Single iteration (b) Multi-iteration (c) Best result per design DeterministicLLM-based Benchmark Set Initial F max (MHz) Expert recipe Direct EDA operations Fitted heuristic Sequential reasoning Branching exploration KB-guided exploration ÎF max (MHz) ÎF max (%) Method, LLM Recipes boom_socK48.2 vexriscv_re-placeK310.2 amd_mini_ispK307.1 logicnets_jsclK403.6 finn_radiomlK284.9 rosetta_digit-recognitionK367.0 rosetta_optical-flowK324.9 corescore_500_modK344.2 boom_soc_v2R77.2 amd_mini-isp_v2R288.0 rosetta_3d-rendering_v2R236.7 vexriscv_re-place_v2R397.5 vtr_mcml_v2R69.3 fir_symmetric_systolicO405.7 fir_systolic_transposedO355.5 picoblazearrayO350.8 14.3 +6.9 14.5 +7.0 91.0 +43.9 68.7 +33.1 89.0 +42.9 102.2 +49.3 +49.3102.2 MI KB-guided, Luna POâșRTâșMPâșNS 37.4 +116.0 37.4 +116.0 51.4 +159.5 31.5 +97.7 41.9 +130.0 42.8 +132.9 +159.551.4 MI heuristic, no LLM HBâșMPâșHB 22.2 +68.2 31.6 +97.0 32.7 +100.4 33.2 +102.0 32.6 +100.0 33.2 +102.0 +102.033.2 MI KB-guided, Gemini LCâșPOâșMP 2.4 +9.7 29.0 +117.0 23.8 +95.9 10.3 +41.7 23.8 +95.9 24.1 +97.2 +117.029.0 SI direct, DS Flash direct operations 3.2 +9.1 23.2 +66.1 21.1 +60.2 3.2 +9.1 20.1 +57.2 21.2 +60.5 +66.123.2 SI direct, Sol direct operations 0.0 +0.0 7.7 +28.3 15.9 +58.2 0.0 +0.0 15.0 +55.1 15.7 +57.7 +58.215.9 MI heuristic, no LLM APâșHB 0.1 +0.3 6.9 +22.4 4.8 +15.7 0.1 +0.4 5.6 +18.3 4.9 +15.9 +22.46.9 SI direct, Sol direct operations 5.8 +20.0 5.8 +20.0 0.0 +0.0 9.3 +32.1 9.3 +32.1 9.3 +32.1 +32.19.3 MI branching, Gemini POâșMP 6.7 +5.2 5.3 +4.1 14.8 +11.4 9.9 +7.6 26.4 +20.4 25.8 +19.9 +20.426.4 MI branching, Sonnet POâșMPâșCS 33.2 +95.6 40.3 +116.1 41.5 +119.5 43.3 +124.7 39.7 +114.4 40.3 +116.2 +124.743.3 MI sequential, Gemini POâșRTâșPOâșLCâșAP 3.4 +8.0 12.4 +29.4 21.1 +50.0 3.7 +8.8 26.3 +62.2 26.3 +62.2 +62.226.3 MI branching, Luna POâșMPâșPO 0.0 +0.0 0.0 +0.0 0.0 +0.0 0.0 +0.0 0.4 +1.7 0.0 +0.0 +1.70.4 MI branching, Luna POâșAP 3.4 +2.4 3.5 +2.4 0.0 +0.0 3.4 +2.4 3.5 +2.4 3.5 +2.4 +2.43.5 MI branching, Sonnet LCâșRT 10.0 +40.6 10.0 +40.6 0.0 +0.0 11.4 +46.2 11.4 +46.2 10.6 +43.0 +46.211.4 MI sequential, Gemini POâșRTâșPO 0.7 +2.5 6.2 +22.0 0.0 +0.0 0.1 +0.5 2.3 +8.3 3.3 +11.9 +22.06.2 SI direct, DS Pro direct operations 1.2 +4.2 0.6 +2.1 0.0 +0.0 2.0 +7.0 1.5 +5.4 1.5 +5.4 +7.02.0 MI sequential, Luna POâșCSâș...âșCSâșPO (9) Functional pass (%) 98.271.4100.097.596.296.2 best of 7 LLMs, 1 trial each1 runbest of 3 LLMs, 5 runs (Luna Ă3) Cell key 33.2 +102.0 â best ÎF max (%) â same result (MHz) F max improvement (%) Recipe key PO phys_opt RT retime MP memory_path_opt HB hardblock_relocate AP auto_pblock NS net_swap CS congestion_spread LC lut_cone FO fanout Set key K known (development set) R held out, same family O held out, out of family 01020304050 Fig. 11. Summary of both studies: best functional-passF max improvement per benchmark. (a) Single-iteration study: best of seven LLMs, one trial each, under expert recipes and direct EDA operations. (b) Multi-iteration study: the deterministic fitted heuristic (one run) and the LLM-based levels (best of three LLMs over five runs, three of them GPT-5.6 Luna repeats). (c) The best result per design, with the method, LLM and recipe sequence that achieved it. finishes sooner only because its ranking is fixed before the run begins: once its top-ranked recipes are spent, it self- terminates after two to four checkpoints, where the model- driven levels re-diagnose and consume the full allowance. Per attempt it is the slowest level in the study, because its two highest-scoring recipes (hardblock_relocate and memory_path_opt) are also the longest to run. IV. DISCUSSION Comparing the studies design by design exposes effects hidden by their corpus means (Fig. 11). In the single-iteration study, direct operations matched or exceeded the best recipe result on fourteen of the sixteen designs, despite passing functional checks in 71.4% of trials against 98.2% for recipes. The multi-iteration study reverses this pattern: iterative recipe selection exceeds the best single recipe attempt on all sixteen designs and exceeds the best direct-operation attempt on eleven, with one tie. The four remaining direct-operation wins are narrow, ranging from 1.3 to 4.9 percentage points. This contrast is consistent with approximately 68% of a designâs best observed result being reachable in one intervention: direct operations can access an effective intervention immediately, whereas recipes gain from selecting and composing reliable actions. An effective deployment could therefore begin with recipes and escalate to direct operations when a measured bottleneck remains unresolved. Further study should establish which design evidence could trigger this change in agent control and how the remaining budget should be divided between action breadth and continued recipe search. Unlike the fitted heuristic, the LLM-based harness improves unseen designs because physical bottlenecks vary too widely for a fixed selection rule to remain well calibrated. Among the LLMs tested, model choice changed cost by roughly twentyfold in the multi-iteration study but mean improvement by under a percentage point, and no LLM dominated across designs in the single-iteration study. This result places the main opportunity in the harness rather than in model selection alone: broader recipes, better evidence retrieval, and explicit uncer- tainty handling could improve coverage and generalisation. The present catalogue remains weighted toward placement and routing, with only lut cone restructuring combinational logic. Critical-cone technology remapping, donât-care-based resynthesis, or deeper pipelining could reach logic-dominated bottlenecks, but netlist-rewriting actions would require for- mal or broader equivalence checking beyond the sampled simulation used here. Structural and functional validity also does not ensure a frequency gain when an action crosses a tool boundary, so a commit-only-if-improved check should be reapplied at each boundary. The harness evidence remains bounded by one device family, toolchain, and tool version, and by a knowledge base distilled from the eight known designs. Larger benchmark sets, other vendors, and independently constructed or continuously updated knowledge bases are needed to test whether the harness is truly transferable. Finally, the same checkpoint-and- validate architecture could target power and area improvement, at the added complexity of multi-objective trade-offs, and its MCP-based interface provides a natural boundary for connect- ing additional capability, including front-end RTL generators. 13 V. CONCLUSION This paper presented LATCH, a two-layer framework separating LLM orchestration from deterministic execution for post-route FPGA frequency improvement across sixteen designs. In a single attempt with seven LLMs, expert recipes passed functional checks in 98.2% of trials, direct EDA operations in 71.4% and constructed procedures in 17.9%, though passing direct operations had a higher median gain of +3.4% against +3.2% for expert recipes. Within twelve DCPs per run, mean improvement rose from 10.5% (sequential) to 16.0% (branching) and 20.3% (knowledge base), matching the fitted heuristicâs 19.9%. Per-design best gains spanned 0.4% to 102.2%, from iterated recipe selection on twelve designs and one direct-operation attempt on four. ACKNOWLEDGMENT The authors thank the AMD University Programme for Vivado licenses, and the FPLâ26 Agentic FPGA Backend Optimization Competition Organisers for setting the challenge, providing benchmarks, and drafting the baseline software. We used Claude Sonnet 5, DeepSeek v4 Flash & v4 Pro, Gemini 3.6 Flash, OpenAI GPT-5.6 Luna, GPT-5.6 Sol, GPT-5.6 Terra as part of the framework development and experimental evaluation; we used Claude Opus 5 to proofread the author- written manuscript text. REFERENCES [1] Z. Di, R. Tao, J. Mai, L. Chen, and Y. Lin, âLEAPS: Topological- layout-adaptable multi-die FPGA placement for super long line minimization,â IEEE Transactions on Circuits and Systems I: Regular Papers, vol. 71, no. 3, p. 1259â1272, Mar. 2024. [Online]. Available: https://doi.org/10.1109/TCSI.2023.3340554 [2] C. Xu, G. Liu, R. Zhao, S. Yang, G. Luo, and Z. Zhang, âA parallel bandit-based approach for autotuning FPGA compilation,â in Proceedings of the 2017 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, 2017, p. 157â166. [Online]. Avail- able: https://w.csl.cornell.edu/ ⌠zhiruz/pdfs/datuner-fpga2017.pdf [3] W. L. Neto, Y. Li, P.-E. Gaillardon, and C. Yu, âFlowTune: End- to-end automatic logic optimization exploration via domain-specific multiarmed bandit,â IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 42, no. 6, p. 1912â1925, Jun. 2023. [Online]. Available: https://doi.org/10.1109/TCAD.2022.3213611 [4] Z. Di, R. Tao, L. Chen, Q. Wu, and Y. Lin, âImbalanced large graph learning framework for FPGA logic elements packing prediction,â IEEE Transactions on Circuits and Systems I: Express Briefs, vol. 71, no. 4, p. 2034â2038, Apr. 2024. [Online]. Available: https://doi.org/10.1109/TCSII.2023.3334247 [5] G. Huang et al., âMachine learning for electronic design automation: A survey,â ACM Transactions on Design Automation of Electronic Systems, vol. 26, no. 5, Jun. 2021. [Online]. Available: https: //doi.org/10.1145/3451179 [6] T. Martin, G. Grewal, and S. Areibi, âA machine learning approach to predict timing delays during FPGA placement,â in 2021 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW), Jun. 2021, p. 124â127. [Online]. Available: https://doi.org/10.1109/IPDPSW52791.2021.00026 [7] Y.-K. Lin, Z. Xiong, and D. Z. Pan, âDifferentiable timing-driven FPGA placement with smooth optimization and ML-based delay calibration,â in 2025 IEEE/ACM International Conference on Computer Aided Design (ICCAD), Oct. 2025, p. 1â9. [Online]. Available: https://doi.org/10.1109/ICCAD66269.2025.11240642 [8] H. Jiang et al., âCritical path aware timing-driven global placement for large-scale heterogeneous FPGAs,â IEEE Transactions on Computer- Aided Design of Integrated Circuits and Systems, 2026, early Access. [Online]. Available: https://doi.org/10.1109/TCAD.2026.3678497 [9] N. Kapre, B. Chandrashekaran, H. Ng, and K. Teo, âDriving timing convergence of FPGA designs through machine learning and cloud computing,â in 2015 IEEE 23rd Annual International Symposium on Field-Programmable Custom Computing Machines, 2015, p. 119â126. [10] E. Ustun, S. Xiang, J. Gui, C. Yu, and Z. Zhang, âLAMDA: Learning- assisted multi-stage autotuning for FPGA design closure,â in 2019 IEEE 27th Annual International Symposium on Field-Programmable Custom Computing Machines, 2019, p. 74â77. [Online]. Available: https://w.csl.cornell.edu/ ⌠zhiruz/pdfs/lamda-fccm2019.pdf [11] A. Mirhoseini et al., âA graph placement methodology for fast chip design,â Nature, vol. 594, no. 7862, p. 207â212, Jun. 2021. [Online]. Available: https://doi.org/10.1038/s41586-021-03544-w [12] J. Pan, G. Zhou, C.-C. Chang, I. Jacobson, J. Hu, and Y. Chen, âA survey of research in large language models for electronic design automation,â ACM Transactions on Design Automation of Electronic Systems, vol. 30, no. 3, Feb. 2025. [Online]. Available: https://doi.org/10.1145/3715324 [13] J. Nainani, C.-T. Ho, A. Dhurka, and H. Ren, âTiming analysis agent: Autonomous multi-corner multi-mode (MCMM) timing debugging with timing debug relation graph,â 2025, arXiv:2504.11502. [Online]. Available: https://arxiv.org/abs/2504.11502 [14] Y. Ouyang, Y. Luo, D. Zuo, and Y. Ma, âRetrieve, schedule, reflect: LLM agents for chip QoR optimization,â 2026, arXiv:2603.13767. [Online]. Available: https://arxiv.org/abs/2603.13767 [15] C. Liu and D. Chitnis, âEEsizer: LLM-based AI agent for sizing of analog and mixed signal circuit,â IEEE Transactions on Circuits and Systems I: Regular Papers, vol. 73, no. 6, p. 3825â3834, Jun. 2026. [Online]. Available: https://doi.org/10.1109/TCSI.2025.3646359 [16] M. Youngman, C. Sestito, and T. Prodromakis, âLLMs in digital EDA: A perspective on shifting roles from generation to orchestration,â 2026, arXiv:2608.27184. [Online]. Available: https://arxiv.org/abs/2608.27184 [17] B.-Y. Wu et al., âEDA corpus: A large language model dataset for enhanced interaction with OpenROAD,â in 2024 IEEE LLM Aided Design Workshop (LAD), 2024, arXiv:2405.06676. [Online]. Available: https://arxiv.org/abs/2405.06676 [18] W. Fu et al., âA generalize hardware debugging approach for large language models semi-synthetic, datasets,â IEEE Transactions on Circuits and Systems I: Regular Papers, vol. 72, no. 2, p. 623â636, Feb. 2025. [Online]. Available: https://doi.org/10.1109/TCSI.2024.3487486 [19] P. Liu, N. Xu, J. Tang, Y. Cao, and C. Ding, âBridging the last mile of circuit design: PostEDA-Bench, a hierarchical benchmark for PPA convergence and DRC fixing,â 2026, arXiv:2605.06936. [Online]. Available: https://arxiv.org/abs/2605.06936 [20] Q. Li et al., âPDAgent-Bench: Characterizing, grounding, and architecting LLM/VLM agents for VLSI physical design,â 2026, arXiv:2606.17253. [Online]. Available: https://arxiv.org/abs/2606.17253 [21] H. Sami, M. ul Islam, S. Charas, A. Gandhi, P.-E. Gaillardon, and V. Tenace, âNexus: A lightweight and scalable multi-agent framework for complex tasks automation,â 2025, arXiv:2502.19091. [Online]. Available: https://arxiv.org/abs/2502.19091 [22] A. Ghose, A. B. Kahng, S. Kundu, and Z. Wang, âORFS-agent: Tool-using agents for chip design optimization,â in 2025 ACM/IEEE 7th Symposium on Machine Learning for CAD (MLCAD), 2025, p. 1â13. [Online]. Available: https://doi.org/10.1109/MLCAD65511.2025. 11189204 [23] Z. Chen, Z. Song, Y. Li, Q. Sun, and C. Zhuo, âFluxEDA: A unified execution infrastructure for stateful agentic EDA,â 2026, arXiv:2603.25243. [Online]. Available: https://arxiv.org/abs/2603.25243 [24] H. Lin, K. Li, L. Wang, and Z. Wang, âPACT: Post-route agentic checkpoint tuning for FPGA timing closure,â 2026, arXiv:2608.23602v2; accepted to FPT 2026. [Online]. Available: https://arxiv.org/abs/2608. 23602v2 [25] H. Wu et al., âChatEDA: A large language model powered autonomous agent for EDA,â IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 43, no. 10, p. 3184â3197, Oct. 2024. [Online]. Available: https://doi.org/10.1109/TCAD.2024.3383347 [26] W. Fang et al., âDr. RTL: Autonomous agentic RTL optimization through tool-grounded self-improvement,â 2026, arXiv:2604.14989. [Online]. Available: https://arxiv.org/abs/2604.14989 [27] R. Krishna, S. Krishna, and D. Chin, âDesign conductor 2.0: An agent builds a TurboQuant inference accelerator in 80 hours,â 2026, arXiv:2605.05170. [Online]. Available: https://arxiv.org/abs/2605.05170 [28] C. Lavin and A. Kaviani, âRapidWright: Enabling custom crafted implementations for FPGAs,â in 2018 IEEE 26th Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM), 2018, p. 133â140. [Online]. Available: https://doi.org/10. 1109/FCCM.2018.00030 14 [29] AMD, âAgentic FPGA backend optimization competition @ FPLâ26,â GitHub repository, 2026, accessed: Sep. 29, 2026. [Online]. Available: https://github.com/Xilinx/fpl26optimizationcontest [30] RapidWright, âPre-implemented modules â Part I,â RapidWright Documentation, 2026, accessed: Sep. 29, 2026. [Online]. Available: https://w.rapidwright.io/docs/PreImplementedModulesPartI.html Shu Gu received the M.Eng. (Hons.) degree in elec- tronics and computer science from the University of Edinburgh, Edinburgh, U.K., in 2025. He is currently pursuing a Ph.D. degree with the School of Engi- neering at the same university. His research interests include electronic design automation, FPGA design and timing optimisation, and the application of large language models to hardware design workflows. Matthew Youngman (Graduate Student Member, IEEE) received the M.Eng. degree in general en- gineering, specialising in electronics, from Durham University, Durham, U.K., in 2024. Following a software engineering role in industry, he is currently pursuing a Ph.D. degree with the School of Engi- neering, University of Edinburgh, Edinburgh, U.K. His research interests include large language model multi-agent systems for backend electronic design automation, particularly how agents can coordinate deterministic tools across the EDA design flow. Yuqin Zhao is a Research Associate at the APRIL AI Hub, University of Edinburgh, U.K. He received his Ph.D. in Electronic and Electrical Engineering from the University of Sheffield, U.K. His research focuses on high-performance heterogeneous com- puting and AI-assisted hardware design, particularly FPGA/SoC systems, hardwareâsoftware task alloca- tion, high-level synthesis, and design automation. His current research interests include generative AI and large language models for electronic design au- tomation, intelligent hardwareâsoftware co-design, FPGA acceleration, and AI-assisted hardware verification. Cristian Sestito (Member, IEEE) is a Research Fellow at the Centre for Electronics Frontiers, Uni- versity of Edinburgh, U.K. He earned his B.Sc. (2016) and M.Sc. (2019) in Electronic Engineering, followed by a Ph.D. in Information and Commu- nication Technologies (2023), from the University of Calabria, Italy. His PhD focused on the design and FPGA implementation of convolutional neural networks, with particular emphasis on dilated and transposed convolutions. During 2021â2022, he was a Visiting Scholar at Heriot-Watt University, Edin- burgh, U.K. where he worked on neural network compression techniques. His current research interests include digital AI accelerator design, software simulators for neuromorphic AI, and AI-assisted electronic design automation frameworks. Ali Siddique is currently a Research Associate in AI for Circuits and Systems Design Automation with the Institute for Integrated Micro and Nano Systems, University of Edinburgh, U.K. Previously, he was a Research Associate with the Advanced Proces- sor Technologies Group, University of Manchester, U.K., where he worked on neuromorphic and edge AI hardware within the EU-funded CONVOLVE project. His research focuses on neuromorphic com- puting, spiking neural networks, online and on- chip learning, FPGA-based AI accelerators, and hardware-software co-design. His research interests also include agentic AI for hardware design automation and hardware-aware optimization using metaheuristic methods such as Grey Wolf Optimization. He is particularly in- terested in developing efficient and deployable learning systems that combine algorithmic flexibility with low-cost hardware implementation. Ramesh Krishnamurthy is a Research Associate in AI for Electronics Testing and Verification Au- tomation with the APRIL AI Hub at the Univer- sity of Edinburgh, U.K. He received the B.E. de- gree in Electronics and Communication Engineering from Visvesvaraya Technological University, India, in 2014, the M.Sc. degree in Embedded Systems from the University of Twente, The Netherlands, in 2021, and the Ph.D. degree in Computer Science from the University of Antwerp, Belgium, in 2025. His doctoral research focused on formal analysis of nonlinear model-predictive control, combining learning-based controller approximation, formal verification, and worst-case execution-time analysis for embedded and safety-critical systems. His current research interests include formal verification, AI-assisted hardware verification, agentic AI for electronic design automation, and trustworthy computing systems. Danial Chitnis received an MSc in Microelectronics at Bristol, UK, in 2008, and a DPhil in Engineering Science from the University of Oxford in 2013, and then joined the Department of Biomedical Physics at UCL, London, as a postdoctoral researcher. In 2017, he joined The University of Edinburgh as a Chancellorâs Fellow in Electronics. His research focuses on using machine learning and artificial intelligence to improve the design and testing of integrated circuits and electronic systems. Themis Prodromakis (Senior Member, IEEE) re- ceived the bachelorâs degree in electrical and elec- tronic engineering from the University of Lincoln, U.K., the M.Sc. degree in microelectronics and telecommunications from the University of Liver- pool, U.K., and the Ph.D. degree in electrical and electronic engineering from Imperial College Lon- don, U.K. He then held a Corrigan Fellowship in nanoscale technology and science with the Centre for Bio-Inspired Technology, Imperial College Lon- don, and a Lindemann Trust Visiting Fellowship with the Department of Electrical Engineering and Computer Sciences, Uni- versity of California at Berkeley, USA. He was a Professor of nanotechnology at the University of Southampton, U.K. He holds the Regius Chair of Engineering at the University of Edinburgh. He is currently a Royal Academy of Engineering Chair in emerging technologies and a Royal Society Indus- try Fellowship. His background is in electron devices and nanofabrication techniques. His current research interests include memristive technologies for advanced computing architectures and biomedical applications. He is a fellow of the Royal Society of Chemistry, the British Computer Society, the IET, and the Institute of Physics.