Skip to content
All work
01Hardware-assisted emulation and verificationSynopsys·2026 — Present

Timing-driven resynthesis

A netlist optimization flow that improved structure without reasoning about timing, and the work to make timing constraints part of the decision.

C++Netlist optimizationGraph traversalTopological sortingLock-free multithreadingMemory optimization

My contribution

I work on synthesis and optimization for the emulation platform, on netlist optimization algorithms in C++. I added timing-driven resynthesis support.

Context

ZeBu is a high-performance, hardware-assisted emulation and verification platform. Designs are compiled through a synthesis flow into a netlist the emulator can execute, and the quality of that netlist determines both how much design fits and how fast it runs.

Resynthesis is the stage that restructures an already-mapped netlist, rewriting local regions of the graph to produce a better implementation of the same logic. It operates on a very large directed acyclic graph, and it runs inside a compile flow where both runtime and memory are constrained.

The problem

The resynthesis flow optimized primarily for structural objectives such as depth and area. Those are reasonable proxies: a shallower, smaller netlist is usually a faster one.

But they are proxies. A restructuring that reduces depth on average can still leave the paths that actually matter unimproved, because structural cost says nothing about which paths are critical. Timing constraints were not considered during resynthesis in the same way.

01

Making timing part of the decision

My contribution introduced consideration of timing constraints during resynthesis. Rather than evaluating a candidate transformation purely on how it changes structure, the flow also accounts for what it does to timing, so effort is spent where it changes the outcome instead of being spread evenly across the graph.

This is a change in what the optimizer is allowed to know. Structural cost is local: you can compute it from the region being rewritten. Timing is not: arrival times propagate forward from inputs, required times propagate backward from outputs, and the slack at any point in the graph depends on the entire cone around it.

  • Arrival time, propagated forward through the graph
  • Required time, propagated backward from timing endpoints
  • Delay characteristics of the mapped elements
Local rewriting against global timingA netlist graph in which a small region is rewritten locally, while arrival times propagate forward from inputs and required times propagate backward from outputs across the whole graph.REWRITTEN REGION — LOCAL COSTinputsendpointARRIVAL TIME — PROPAGATES FORWARDREQUIRED TIME — PROPAGATES BACKWARDStructural cost can becomputed from the regionalone.Slack cannot. It dependson the whole cone aroundthe rewrite.

Structural cost is local to the rewritten region. Timing is a global property of the graph, which is what makes combining them the interesting part.

02

Working at netlist scale

Everything here happens on graphs large enough that asymptotics and constant factors both matter. The work is graph traversal and topological ordering: visiting nodes in dependency order so that propagated values are always computed from settled inputs, and doing it without repeatedly re-walking regions that have not changed.

The code is multithreaded and lock-free in the paths that matter. That is a deliberate constraint rather than a flourish: at this scale, contention on a shared structure costs more than the work being protected, so the data structures are shaped so that threads do not need to coordinate in the first place.

Memory optimization is a first-class concern for the same reason. A representation that is a few bytes larger per node is a materially larger working set across a full design, and working-set size shows up directly in traversal time.

Where timing enters the resynthesis flowA mapped netlist enters resynthesis, which rewrites local regions. Optimization previously judged those rewrites on structural objectives alone. Timing constraints now feed the same decision, and the result is a netlist restructured with the constrained paths in mind.Designmapped netlist01Resynthesislocal rewrite02Optimizationdepth · area03Timingarrival · required04Resulttiming-aware05CONSTRAINTS FEED THE DECISIONStages 01–03 were already there. The contribution is that stage 04 now reaches back into stage 03,so a rewrite is judged on what it does to the constrained paths and not only on structure.

Where the contribution sits in the flow: timing constraints now reach back into the optimization decision rather than being evaluated after it.

The hard part

Local rewriting against a global property

Resynthesis is a local transformation. Timing is a global property. Every time you rewrite a region, you invalidate timing information for everything downstream of it, and recomputing that fully after each candidate transformation makes the flow too slow to use.

So the difficulty is not "consider timing." It is considering timing at a cost proportional to what actually changed, while keeping the structural quality the flow already delivered. A timing-aware pass that regresses area or depth has not improved anything; it has moved the problem.

Result

Resynthesis now takes timing constraints into account alongside the structural objectives it already optimized for, so restructuring effort is directed at the paths that constrain the design rather than distributed uniformly.

Internal benchmark results for this work are not published here.

Engineering takeaway

A local transformation judged against a global property is a different problem from a local transformation judged locally, and the cost of knowing the difference has to stay proportional to what changed.