Picture this: a fresh RTL design lands, and before it ever goes through place and route you already have a credible read on its congestion, timing, IR drop, thermal, and stress profile, grounded in how similar designs actually turned out at signoff.
The idea is old. Early estimation has always been the holy grail of shifting decisions left: catch the routability problem, the IR hotspot, the thermal risk while it's still cheap to fix, instead of waiting days for backend runtime to confirm what you feared. What's new is that training a model to do this well finally looks plausible, if we can get past a data problem that's kept it out of reach.
The premise is straightforward. There are countless finished designs sitting in signoff-clean state, and each one is a labeled example: this RTL and this floorplan produced this congestion, this timing, this IR and thermal outcome. That's exactly the training set you'd want.
The trouble is the data actively resists being used this way. It's scattered across old, tool-specific text formats, written for a human to skim rather than a model to parse. And even one block's worth (millions of gates, hundreds of millions of geometries, multi-gigabyte reports) is too big and too messy to drop into a training pipeline, never mind doing it consistently across designs from different vendors' tools.
Getting past that is mostly a data-engineering problem, and a nasty one. You need something that can ingest a finished design quickly and turn it into a consistent, structured feature set no matter which vendor produced the original. That consistency is the whole ballgame; without it, cross-design training never gets off the ground.
The part we find more interesting is the features themselves, the ones that actually correlate with outcomes rather than just describing the design. As a crude example, here are some possible features:
1. How close multi-bit flip-flops sit to memory instances, a layout pattern that can hint at congestion or timing risk before a single net is routed.
2. Whether timing-critical instances tend to land near routing congestion or IR hotspots, a sign that a certain logic structure keeps ending up in trouble spots across many designs, not just one.
3. How "scenic" a critical path's net is likely to be, meaning how far its estimated route deviates from the direct distance between endpoints. A path forced to detour around macros or blockages picks up extra wirelength and delay, so this ratio is a rough proxy for timing risk before a single net is actually routed.
You won't find any of these pre-computed in a standard signoff report. They're derived, the kind of feature that only becomes tractable once you can traverse full-scale design data fast and compute relationships across domains rather than reporting on each in isolation.
A model trained on enough real, feature-rich examples could hand RTL and floorplanning teams a much better place to start than gut feel, and give an agentic flow something concrete to reason from before it commits to a direction that takes days to check.