Most LLM-based hardware research frames the task as prompt-to-RTL generation: describe what you want, get a netlist. That framing is wrong for real hardware work. Real hardware development is evolutionary -- a major revision starts by changing intended behavior and then updating a previously validated implementation. Starting from scratch each revision would throw away the validation history that makes the existing design trustworthy. Zhao et al. name this gap explicitly and build around it.
Their framework refines a feature request into an executable contract before any RTL changes. The contract specifies what must hold at the externally visible transactional level -- behavior-level reference, observation semantics, checking semantics -- while leaving how the RTL implements it open. Once the contract is approved, the remaining stages run automatically: Plan derives cross-version semantic deltas and localizes affected RTL regions via mutation-based semantic probing, then Implement and Validate drive the RTL update under proof-guided checking and iterative repair. The case study is a TPU datapath block under data-format changes. Legacy-aware RTL update converges to functional correctness under the contract without regenerating the design.
The constraint being removed is the gap between specs and implementations that has no formal bridge. Currently, a spec change propagates to RTL through engineering judgment, code review, and simulation -- a coordination chain that is error-prone at every handoff. An executable contract that both humans can approve and tools can check against closes that loop. The implementation can change; the contract defines what must stay true. That is the shape of spec-as-source-of-truth for hardware.
The tooling question is whether this pattern scales from a TPU datapath case study to production SoCs with hundreds of interacting blocks and multi-team ownership of each. That is not answered here. What is answered is that the problem formulation is correct: hardware evolution is version iteration under a contract, not prompt-to-RTL generation, and tools that do not model that distinction are building the wrong thing.