Paper deep dive
HINT: Toward an Executable Hardware-Intent Representation Layer for LLM-Driven RTL Generation
Tairan Cheng, Yi Liu, Dongsheng Zuo, Zhengyuan Shi, Hongji Zhang, Xiangfei Hu, Maoshuo He, Hao Yan, Qiang Xu
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%
Last extracted: 8/13/2026, 3:19:52 AM
Summary
The paper introduces HINT, an executable hardware-intent intermediate representation layer designed to facilitate Large Language Model (LLM)-driven RTL generation. HINT separates microarchitecture definition from low-level RTL coding, making architectural decisions explicit and checkable before RTL lowering. Evaluations show that HINT produces contract-compliant synthesizable RTL in all tested cases, outperforming direct generation methods (C2RTL, C2HLSC) and manual implementations in terms of area reduction and convergence stability.
Entities (15)
Relation Signals (8)
HINT → enables → Pre-RTL Checking
confidence 95% · HINT makes RTL-relevant microarchitecture explicit, supports pre-RTL checking, and supplies explicit RTL-lowering obligations.
HINT → isevaluatedon → RealBench
confidence 95% · We evaluate HINT using... RealBench AES and SDC
HINT → isevaluatedon → Operator Cases
confidence 95% · Across seven operator cases... HINT-mediated route... produces contract-compliant synthesizable RTL on 7/7 cases
HINT → isevaluatedon → Vortex VPU
confidence 95% · together with a Vortex VPU synthesizing to 561.67k μm2
HINT → improves → RTL Generation Quality
confidence 90% · HINT reduces area by 5.0%–26.2% relative to five manual RTL implementations and by 8.9%–86.1% relative to five accepted Direct C2RTL results.
HINT → outperforms → C2HLSC
confidence 90% · C2HLSC... succeed on 1/5... HINT... produces contract-compliant synthesizable RTL on 7/7 cases
HINT → outperforms → C2RTL
confidence 90% · Direct C2RTL... succeed on 5/5... HINT... produces contract-compliant synthesizable RTL on 7/7 cases
HINT → replaces → Direct RTL Generation
confidence 85% · Generating implementation-quality RTL with large language models (LLMs) remains difficult because direct generation must resolve microarchitecture...
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Generating implementation-quality RTL with large language models (LLMs) remains difficult because direct generation must resolve microarchitecture while simultaneously producing and debugging low-level code. We present HINT, an executable hardware-intent intermediate representation layer between behavioral specifications or executable oracles and RTL. HINT makes RTL-relevant microarchitecture explicit, supports pre-RTL checking, and supplies explicit RTL-lowering obligations. We evaluate HINT using both a minimal single-agent flow and a full staged workflow. Across seven operator cases, the HINT-mediated route, with no post-synthesis QoR refinement, produces contract-compliant synthesizable RTL on 7/7 cases; Direct C2RTL and C2HLSC apply to five cases and succeed on 5/5 and 1/5, respectively. Under matched Design Compiler synthesis, HINT reduces area by 5.0\%--26.2\% relative to five manual RTL implementations and by 8.9\%--86.1\% relative to five accepted Direct C2RTL results. RealBench AES and SDC, together with a Vortex VPU synthesizing to 561.67k~$\mu\mathrm{m}^2$, further demonstrate specification-driven, protocol-rich, memory-rich, and hierarchical designs. In the controlled operator study, the HINT-mediated route shows better observed convergence and avoids the severe implementation-quality degradation seen in several direct-generation results.
Tags
Links
- Source: https://arxiv.org/abs/2608.07625v1
- Canonical: https://arxiv.org/abs/2608.07625v1
Trouble viewing inline? Open PDF directly →
Full Text
45,483 characters extracted from source content.
Expand or collapse full text
HINT: Toward an Executable Hardware-Intent Representation Layer for LLM-Driven RTL Generation Tairan Cheng The Chinese University of Hong Kong Hong Kong, China Yi Liu The Chinese University of Hong Kong Hong Kong, China Dongsheng Zuo The Chinese University of Hong Kong Hong Kong, China Zhengyuan Shi The Chinese University of Hong Kong Hong Kong, China Hongji Zhang The Chinese University of Hong Kong Hong Kong, China Xiangfei Hu Southeast University Nanjing, China Maoshuo He Southeast University Nanjing, China Hao Yan Southeast University Nanjing, China Qiang Xu The Chinese University of Hong Kong Hong Kong, China Abstract Generating implementation-quality RTL with large language mod- els (LLMs) remains difficult because direct generation must resolve microarchitecture while simultaneously producing and debugging low-level code. We present HINT, an executable hardware-intent in- termediate representation layer between behavioral specifications or executable oracles and RTL. HINT makes RTL-relevant microar- chitecture explicit, supports pre-RTL checking, and supplies explicit RTL-lowering obligations. We evaluate HINT using both a minimal single-agent flow and a full staged workflow. Across seven operator cases, the HINT-mediated route, with no post-synthesis QoR refine- ment, produces contract-compliant synthesizable RTL on 7/7 cases; Direct C2RTL and C2HLSC apply to five cases and succeed on 5/5 and 1/5, respectively. Under matched Design Compiler synthesis, HINT reduces area by 5.0%–26.2% relative to five manual RTL im- plementations and by 8.9%–86.1% relative to five accepted Direct C2RTL results. RealBench AES and SDC, together with a Vortex VPU synthesizing to 561.67k휇m 2 , further demonstrate specification- driven, protocol-rich, memory-rich, and hierarchical designs. In the controlled operator study, the HINT-mediated route shows bet- ter observed convergence and avoids the severe implementation- quality degradation seen in several direct-generation results. CCS Concepts • Hardware→Electronic design automation; High-level and register-transfer level synthesis; Hardware validation; Methodologies for EDA. Keywords EDA, LLM-assisted RTL generation, high-level synthesis, interme- diate representation ACM Reference Format: Tairan Cheng, Yi Liu, Dongsheng Zuo, Zhengyuan Shi, Hongji Zhang, Xi- angfei Hu, Maoshuo He, Hao Yan, and Qiang Xu. 2027. HINT: Toward an Executable Hardware-Intent Representation Layer for LLM-Driven RTL ASP-DAC 2027, Tokyo, Japan 2027. ACM ISBN 978-x-x-x-x/Y/M https://doi.org/10.1145/n.n Generation. In Proceedings of 32nd Asia and South Pacific Design Automa- tion Conference (ASP-DAC 2027). ACM, New York, NY, USA, 8 pages. https: //doi.org/10.1145/n.n 1 Introduction Large language models (LLMs) are rapidly improving in code gen- eration, long-horizon reasoning, and tool-assisted workflows, mak- ing their use in front-end hardware design increasingly plausi- ble [1,12,23]. For example, HORIZON reports 100% completion on the compact VerilogEval and RTLLM benchmarks [16,18,32], showing that current workflows handle compact RTL tasks well. The harder question is whether LLMs can generate correct, syn- thesizable RTL for designs with long specifications, interconnected state, and implementation-quality targets. Hardware generation is not simply software generation in Ver- ilog syntax. RTL remains far less represented in public corpora: in The Stack v2 [17], CodeV reports 80.6M Python data points but only 1.91M Verilog data points [34]. More fundamentally, behavioral in- tent rarely fixes the microarchitecture that determines correctness and quality of results (QoR). Direct RTL generation must infer it while simultaneously realizing and debugging ports, resets, clocks, and signal-level behavior. As designs grow, verification feedback therefore mixes architecture-level mistakes with RTL coding errors, making failures harder to localize and implementation QoR less stable. This coupling exposes a representation gap. A useful intermedi- ate representation layer should make RTL-relevant architectural decisions explicit and checkable, yet remain above cycle- and signal- level realization. We therefore introduce Hardware INTent repre- sentation layer (HINT), a specification-backed, executable repre- sentation between behavioral design intent and RTL. HINT makes typed transaction boundaries, owned state, bounded progress, con- trol/datapath organization, resource commitments, and RTL-lowering obligations explicit, turning RTL generation from open-ended struc- ture inference into constrained realization. Our evaluated instanti- ation expresses these hardware commitments in a restricted C-like executable form. HINT may be constructed from a textual specifi- cation, an executable C/C++ model, or both, so executable models strengthen verification without becoming a required input. arXiv:2608.07625v1 [cs.AR] 7 Aug 2026 ASP-DAC 2027, January 25–28, 2027, Tokyo, JapanCheng et al. The separation is particularly useful for complex designs. HINT is executed and repaired at transaction level before RTL exists, allow- ing functional and state-transition problems to be debugged with conventional compiler diagnostics, software debugging tools, and oracle comparison instead of immediately entering signal-level sim- ulation. Once accepted, its explicit microarchitecture commitments become RTL-lowering obligations. By keeping these high-impact decisions visible before low-level correctness repair dominates gen- eration, HINT directs model effort toward the part of RTL coding that most strongly determines implementation QoR, without requir- ing an external QoR predictor or repeated post-synthesis search. We evaluate HINT at two scales. In a controlled study of seven architecture-bearing operators, HINT covers and succeeds on 7/7 cases; Direct C2RTL and C2HLSC apply to five cases and succeed on 5/5 and 1/5, respectively. Under matched synthesis, it uses 5.0%– 26.2% less area than five manual implementations and 8.9%–86.1% less than five accepted Direct C2RTL results. We then apply the full staged workflow to RealBench AES and SDC [13] and a connected Vortex-derived non-floating-point VPU [29], spanning specification-driven IP, protocols, memory, and hierar- chy. All pass their declared checks, and the VPU synthesizes to 561.67k 휇m 2 . Contributions. This work contributes (1) a semantically defined, executable hardware-intent intermediate representation layer that exposes high-impact structural decisions in RTL generation; (2) a HINT-centered methodology that separates transaction-level con- struction and debugging from RTL realization governed by explicit lowering obligations; and (3) controlled and cross-scale evaluations spanning operators, RealBench IP, and a connected repository- derived VPU subsystem. 2 Related Work 2.1 LLM-Based RTL Generation and Agentic Flows Recent work has improved direct RTL generation through model specialization, discriminative guidance, automated feedback, and candidate search. BetterV introduces controlled generation with dis- criminative guidance, RTLCoder develops an RTL-specialized open model, AutoVCoder organizes automated generation and repair, and MCTS-RTL searches over candidate implementations [6,9,10,24]. AutoVeriFix uses Python reference model and coverage-refined tests to guide iterative Verilog correction through simulation mis- matches [28]. Its Python model serves as debugging oracle rather than an design commitment. Agentic workflows further improve planning, iteration, and tool use. These methods strengthen the model or its coding process, but their target artifact remains RTL, so architectural commitment and low-level realization are still per- formed within the same generation stage. CktEvo instead bench- marks repository-level evolution of existing RTL artifacts [25]; it addresses a complementary downstream setting rather than the pre-RTL representation studied here. Benchmark development has made this progress measurable. VerilogEval contains 156 short HDLBits exercises whose human- and machine-authored references average only 15.8 and 13.9 RTL lines, respectively, with no submodule hierarchy; RTLLM contains 30 arithmetic and logic designs with median/mean/maximum sizes of 52/86/518 lines [13,16,18]. HORIZON reports 100% comple- tion of both through a hands-free iterative tool-feedback loop [32], showing that these compact suites are becoming less discrimina- tive for strong workflows. More realistic suites retain a substantial gap: RealBench reports 13.3% formal@1 at module level and 0% at system level for o1-preview [13], while ChipBench reports 30.74% for its strongest evaluated model [33]. Benchmark choice. We therefore do not repeat VerilogEval or RTLLM. Their compact, mostly flat tasks remain useful tests of basic RTL coding. We instead focus on cases that expose more of the hardware-organization choices represented by HINT. Our operator cases add architecture-bearing datapath and control orga- nization; RealBench adds specification- and protocol-rich IP; and the connected Vortex VPU adds repository context and hierarchical integration. These cases test whether an intermediate representa- tion layer remains useful beyond short isolated modules. 2.2 High-Level and Intermediate Hardware Representations C-based high-level synthesis (HLS) compiles behavioral C/C++ into RTL through scheduling, allocation, binding, and related optimiza- tions [5,20]. More recently, C2HLSC uses an LLM to rewrite refer- ence C into Catapult-compatible HLS C, demonstrating that genera- tion at a higher abstraction level can substantially improve feasibil- ity [4]. Its output, however, remains behavioral HLS C: scheduling, binding, control generation, and much of the resulting hardware or- ganization are selected by the HLS tool. HINT instead requires the major architecture commitments to be explicit before RTL lowering. SystemC spans a different abstraction range. Transaction-level modeling supports system modeling and virtual prototyping with- out committing to detailed implementation timing [3,7]. Synthe- sizable or cycle-accurate SystemC can encode detailed hardware behavior, but does so through clocked processes, sensitivity, explicit waits, and cycle-level concurrency [2]. It therefore approaches the realization burden that HINT intentionally defers. Hardware compiler intermediate representations address dif- ferent stages of the flow. Calyx represents a supplied accelerator architecture through structural components and an explicit control schedule, while FIRRTL supports circuit transformation and lower- ing after hardware-generator elaboration [15,21]. MLIR and CIRCT provide broader reusable infrastructure for multi-level dialects and for transforming and lowering hardware representations [8,14]. CPPL uses a Python prompt-programming frontend to predeclare module interfaces, hierarchy, and instance connections, and asks the LLM to complete a statically checked JSON circuit body for CIRCT lowering [31]. Its checks establish circuit legality, including widths and structural bindings, while behavioral intent remains in natural-language descriptions and functional correctness is evalu- ated by external tests. These systems provide compiler machinery after a frontend sup- plies hardware or circuit structure. HINT targets the preceding LLM-facing architecture-authoring stage, where architecture com- mitments are made explicit and executable before RTL realization. HINT: Toward an Executable Hardware-Intent Representation Layer for LLM-Driven RTL GenerationASP-DAC 2027, January 25–28, 2027, Tokyo, Japan Table 1: Required HINT-layer obligations. Layer obligationDefined hardware meaning Program and object model Units, persistent child/helper instances, hierarchy, and explicit ownership. Types, interfaces, behavior Fixed-width objects, typed transaction boundaries, operators, and memory/buffer semantics. State, control, execution Current/next state, reset/commit, bounded progress, and combinational/FSM/phase/counter/pipeline models. Resource and QoR model Sharing, replication, reuse scope, staging, storage, and QoR-relevant annotations. RTL-lowering obligation Interface, state, datapath, schedule, and resource commitments carried into RTL. 3 HINT Representation Reference profile. HINT can support different executable forms for expressing the hardware commitments summarized in Table 1. Our experiments instantiate HINT with an engineer-defined, case- independent restricted C-like reference profile. The checker-enabled full workflow enforces the reference-profile specification. HINT is IR-like in role: it is an LLM-authorable, executable, and tool-checkable intermediate artifact whose accepted semantics con- strain downstream realization. Unlike a conventional compiler IR built around deterministic passes, HINT targets LLM-friendly archi- tecture authoring and leverages the flexibility of agentic construc- tion and lowering; its accepted architectural commitments bound the resulting implementation variation. Executable hardware semantics. A HINT design is a hierarchy of persistent units and instances, not a collection of software sub- routine activations. Each unit has typed boundary objects, owns its carried state, and exposes exactly one step entry point under its execution model: (표 푡 ,푠 푡+1 )= step H (푖 푡 ,푠 푡 ),(1) where푖 푡 ,표 푡 , and푠 푡 denote input, output, and unit-owned archi- tectural state. Here푡indexes an abstract advancement under the selected execution model, not necessarily an RTL clock cycle. A step observes current state, produces outputs and next state, and commits updates at its boundary. HINT can therefore be executed against a behavioral or transaction-level oracle before RTL exists. Module/IP-level granularity. HINT makes canonical microarchi- tecture commitments explicit without becoming cycle-accurate or signal-level code. It may commit to latency, staging, or resource schedules where required, but need not encode per-cycle signal assignments or RTL process structure. A HINT unit denotes a module/IP-level hardware block, and an instance denotes a per- sistent child block rather than a function call. Hierarchical designs are expressed by composing such units, without making HINT another RTL syntax. Canonical hardware form. In our reference profile, a conforming artifact is statically bounded, excludes dynamic allocation, recur- sion, unbounded behavior, and hidden side effects, and carries only architecture-relevant state. “Canonical” requires the selected ar- chitecture to remain visible through semantic objects; it does not require unique identifiers or a unique textual rendering. In the checker-enabled cross-scale workflow, the case-independent HINT Lint Checker validates permitted forms and tags, typed boundaries typedef struct /* inputs */ aes_req_t; typedef struct /* outputs */ aes_resp_t; enum IDLE, RUN, OUT ; typedef struct uint8_t st_cur, round_cur; uint8_t state_reg[16], out_reg[16]; /* key state omitted */ aes_state_t; // owned state //@hint.helper void round(const round_req_t *q, round_resp_t *y) /* round datapath omitted */ //@hint.unit void aes_step(const aes_req_t *req, aes_resp_t *resp, aes_state_t *s) uint8_t st_nxt = s->st_cur; // hold uint8_t round_nxt = s->round_cur; uint8_t state_nxt[16]; bool state_we = false; /* (1) output logic: observe current state */ resp->ready = (s->st_cur == IDLE); resp->done = (s->st_cur == OUT); copy16(resp->text_out, s->out_reg); /* (2) next-state logic */ switch (s->st_cur) case IDLE: if (req->ld) /* input capture omitted */ st_nxt = RUN; round_nxt = 0; break; case RUN: /* round_req construction omitted */ //@hint.helper_instance(name=rnd, helper=round) round(&round_req, &round_resp); /* set next values and write intents */ if (s->round_cur == 10) st_nxt = OUT; else round_nxt = s->round_cur + 1; break; case OUT: st_nxt = IDLE; break; default: st_nxt = IDLE; break; /* (3) state-register transfer / commit */ s->st_cur = st_nxt; s->round_cur = round_nxt; if (state_we) copy16(s->state_reg, state_nxt); /* other enabled commits omitted */ Figure 1: Canonical reference-profile excerpt for a shared- round AES unit. and references, state ownership and commit discipline, bounded progress, and instance/resource cardinality. Figure 1 shows these properties for a shared-round AES unit. For space, the figure omits the byte-level AES implementation logic; the complete HINT artifact includes this logic, and executable ac- ceptance checks its correctness rather than treating it as an unin- terpreted operation. The request, response, and state objects separate typed bound- aries from owned state. Within the state object, the control mode and round index encode bounded progress; outputs observe current state, next-state logic defaults to hold, and owned updates occur only at commit. The named round instance declares one datapath reused across all rounds. Thus, the skeleton fixes control, progress, and resource organization without specifying clocks, signals, or RTL process style. RTL-lowering obligations. HINT is an executable architecture contract, not a prompt-level plan or an RTL template. Its accepted interface, state, schedule, and resource commitments become ex- plicit obligations for RTL lowering, while local coding structure may vary. HINT–RTL comparison checks observable behavior and transaction timing rather than claiming a formal proof of inter- nal structural equivalence. Architectural changes require renewed HINT acceptance. ASP-DAC 2027, January 25–28, 2027, Tokyo, JapanCheng et al. Stage 0 Environment Preparation Stage 1 HINT Generation Stage 3 Synthesis Stage 2 HINT to RTL Lowering Hardware SPEC Ref Code (optional) Verification Harness Corner Cases Known Vectors Constrained Randoms planning high-level architecture Generated HINT code HINT RULES & format template input output input output Transaction level equivalence check HINT – RTL cosimulation Verified HINT Verify & Debug Loop Multi-agent reviewer- worker Flow（RQ2) Codex React Node(RQ1) HINT lowering obligations Generated RTL Optional Refinement Verified RTL Synopsys DC Compile_ultra QoR Report Micro-Architecture Change Required? Return to HINT fix RTL local Patch Yes No HINT Lint Checker Figure 2: Full HINT-centered flow used for cross-scale generation. The controlled operator study uses the reduced sequential workflow described in Sec. 5.1. 4 Methodology 4.1 Staged Architecture Construction and RTL Lowering Figure 2 shows the execution order. The HINT layer can be indepen- dent of any particular agent framework. In our experiments, the op- erator study uses one sequential Codex ReAct node with fixed feed- back, whereas RealBench and Vortex add canonical-form checking, environment construction, architecture review, and, when needed, ownership partitioning and integration. Both workflow configura- tions accept HINT through transaction-level checking before RTL lowering. Stage 0—Task and verification preparation. Inputs are a de- sign specification and, when available, an executable reference model or native tests; C/C++ serves as an oracle rather than a required HINT input. For raw benchmarks or repositories, the en- vironment agent resolves scope and dependencies, extracts inter- face/transaction/timing contracts, partitions by hardware owner- ship when needed, and builds the verification environment. Reference- model cases combine known vectors, directed corners, and constrained- random transactions; RealBench reuses native tests or locked test collateral derived from them. These assets and acceptance rules are frozen before generation and cannot be modified by design agents. Formal-checking scope. For the 8-bitHif8_mulcase, we addi- tionally use Synopsys Formality [27] to check netlist-level equiv- alence between the HINT-lowered and engineer-written imple- mentations. The remaining designs are outside the scope of our current formal tools and are accepted through transaction-level regression/co-simulation. Stage 1—HINT generation and acceptance. The agent first deter- mines the microarchitecture and encodes it as a HINT artifact using the reference profile in Sec. 3. In the checker-enabled full workflow, the case-independent HINT Lint Checker validates the canonical- form obligations described above. It reports structural violations but neither proposes a microarchitecture nor estimates QoR. In both workflow configurations, the executable HINT artifact is eval- uated using the Stage-0 reference or native checking environment with the same frozen tests or transactions, comparing outputs and boundary events at transaction level. Once the applicable checks pass, the accepted HINT artifact fixes the microarchitecture and governs RTL lowering. Stage 2—RTL lowering and acceptance. The lowering obligations guide realization of the accepted HINT artifact as synthesizable RTL without re-inferring the organization from behavioral code. Using the same frozen tests or transactions, the checking environment compares HINT and RTL for observable data and timing and, where available, also compares them with the reference model or original RTL; otherwise, the predeclared design specification supplies target latency. Realization errors may be repaired locally, but architectural changes return to Stage 1. Only RTL passing all applicable checks proceeds. Stage 3—Synthesis and QoR reporting. Accepted RTL is synthe- sized to report area, critical-path timing, and area–delay product (ADP). Optional synthesis feedback may request a local RTL repair or, if the architecture must change, a return to Stage 1; either path must repeat the applicable conformance and functional gates. For RQ1, the controlled HINT route stops at the first successful syn- thesis after correctness acceptance and does not use this optional refinement. Failure localization. The gates localize failures: where enabled, HINT Lint flags conformance defects; HINT–reference/test mis- matches expose transaction/state defects; HINT–RTL transaction mismatches expose behavioral or timing errors introduced during lowering; and synthesis reveals QoR pressure after correctness. Larger designs can thus be debugged with transaction traces before analysis moves to signal-level RTL. HINT: Toward an Executable Hardware-Intent Representation Layer for LLM-Driven RTL GenerationASP-DAC 2027, January 25–28, 2027, Tokyo, Japan Table 2: Controlled operator results. Case Target Latency HINT route Area/Timing/ADP/Debug Iter. Manual RTL Area/Timing/ADP Direct C2RTL Area/Timing/ADP/Debug Iter. C2HLSC flow Area/Timing/ADP/Debug Iter. Hif8_mul (pilot)01.58k/7.82/12.3/12.14k/8.67/18.5NANA Karatsuba08.90k/15.48/137.8/09.38k/15.08/141.3NANA CORDIC311.10k/15.89/176.0/112.28k/22.24/273.254.41k/59.85/3.26k/314.22k/16.48/234.4/11 SHA2566634.18k/17.15/586.1/542.75k/16.84/720.060.33k/19.59/1.18k/8134.19k/19.37/2.60k/17 ★ MD56837.25k/32.44/1.21k/339.66k/32.05/1.27k208.48k/614.24/128.06k/552.64k/30.60/1.61k/9 ★ AES C2HLSC 1468.14k/6.18/421.1/0NA489.85k/39.85/19.52k/0NC DES C2HLSC 1810.58k/6.98/73.9/1NA11.61k/6.71/77.9/1NC Accepted/applicable–7/75/55/51/5 Status: NA denotes an inapplicable route. NC denotes failure within budget to obtain a contract-compliant result that can be mapped by Design Compiler. Debug Iter. counts correctness-repair revisions. ★ denotes a C2HLSC output that misses the specified latency; its comparable-scale QoR is shown for context and excluded from strict QoR claims. 4.2 QoR Comparison Protocol For each case, all accepted generated RTL and all available original RTL are synthesized using the same technology library, Synopsys Design Compilercompile_ultraflow [26], scripts, optimization settings, timing constraints, and reporting conventions. Compar- isons are therefore made within a case rather than across unrelated timing regimes. Clocked operator cases use a fixed 1000-ns synthe- sis constraint, whereas the RealBench and VPU cases use prede- clared design-specific constraints; all compared implementations within a case share the same frozen constraint. Total cell area is the primary metric for comparing mapped logic complexity under that fixed regime, preventing one route from obtaining a smaller design merely through a looser clock target. We nevertheless report critical-path delay separately to expose timing degradation, and report area–delay product,ADP= 퐴 total ×푇 cp , as a supplementary combined metric following prior LLM-based hardware evaluation [25]. ADP does not replace the separate area and timing results. Available original RTL is treated as a same- flow implementation reference, not as a globally optimized human upper bound. Generated routes must satisfy their frozen functional, latency, and initiation-interval contracts where applicable. Artifact release. Experimental artifacts are available at https:// anonymous.4open.science/r/anonymous-project-612D/. The repos- itory is for the review process, and the complete release with HINT SPEC will be made upon publication. 5 Experiments 5.1 Experimental Design and Setup We answer two questions. RQ1 asks whether replacing direct RTL emission with the HINT-mediated construction, acceptance, and lowering route improves correctness convergence and implementa- tion QoR when orchestration is intentionally minimized. RQ2 asks whether the HINT approach remains usable for specification-driven IP, protocol-rich control, and a repository-derived hierarchical sub- system. The operator study provides controlled route-level evi- dence; RealBench and Vortex provide feasibility and scale evidence and are not pooled into the RQ1 comparison. Flow assignment. All runs use OpenAI’s GPT-5.3-Codex [22]. RQ1 uses one sequential Codex CLI ReAct run per route with a case-independent trigger and no case-specific architecture or re- pair guidance. The HINT route inserts construction of a pre-RTL artifact, while Direct C2RTL uses the same node to emit and revise RTL directly. The model, the frozen specification and contracts, any available oracle, the locked verifier, the correctness budget, and the orchestration remain fixed; RQ1 excludes the checker and multi-agent system used only in the RQ2 full workflow. HINT re- ceives the reference-profile specification, while C2HLSC follows its reproduced Catapult protocol [4]. Route-level ablation and convergence scope. The HINT-mediated route is an integrated representation workflow requiring construc- tion, executable acceptance, and RTL lowering across multiple agen- tic stages; its appropriate ablation unit is therefore the route rather than individual components. RQ1 treats this route as a pluggable ablation unit: inserting it gives the HINT route, while removing it yields the matched Direct C2RTL route. To prevent the additional HINT stages from conferring a search advantage, they share the route-level correctness budget without a stage reset, and HINT is frozen at its first successful synthesis, whereas Direct C2RTL may continue post-synthesis QoR refinement. The comparison is thus conservative for HINT. ReAct revisions are adaptive rather than independent pass@k samples; counting them as such would mischaracterize dependent repairs as fresh generations. In this agent setting with a strong base model and stateful tool feedback, we therefore characterize observed convergence by within-budget acceptance and correctness-repair revisions (Debug Iter.). A non-corrective post-freeze source audit found that each low- ered RTL retained the control, schedule, and resource organization declared in HINT. RQ2 uses the checker-enabled full workflow. RQ1 Guidance and iteration fairness. All routes share one 20- revision correctness budget. The controller returns only raw com- piler, testbench, or synthesis diagnostics, and the Codex ReAct node chooses every diagnosis and edit without human RTL/HINT edits or candidate selection. Post-synthesis QoR refinement steps for Direct C2RTL and C2HLSC are not included in the reported correctness-debug count. Targets and synthesis. Target latency and initiation interval (I) are extracted from reference RTL when available and otherwise fixed manually before generation. For each case, the design speci- fication and targets are then frozen and shared unchanged by all applicable routes. Accepted RTL is synthesized with SKY130 [11] ASP-DAC 2027, January 25–28, 2027, Tokyo, JapanCheng et al. under Sec. 4.2. Each comparison shares the same library, scripts, constraints, and reporting convention, and only contract-satisfying outputs enter strict QoR comparisons. 5.2 Controlled Operator Study (RQ1) Cases and comparison coverage. RQ1 coversHif8_mul[19], Karatsuba, CORDIC [30], SHA256, MD5, and the C2HLSC AES/DES tasks [4]. HINT covers all seven; manual RTL covers five, and Direct C2RTL/C2HLSC apply to five. Hif8_mul lacks reference C, Karat- suba’s C model is only a multiplication expression and omits the intended recursive architecture, and AES/DES lack manual RTL; Table 2 reports all applicable routes without counting NA as fail- ure. We apply one width-only lint correction to Karatsuba manual RTL.Hif8_mulis a pilot in which an engineer authored the HINT artifact and Codex mechanically lowered it to RTL. Target latency is reported in cycles, area in휇m 2 , critical-path timing in ns, and ADP in 10 3 휇m 2 ·ns; suffix “k” denotes×10 3 , and latency 0 denotes a combinational contract. Correctness and convergence. HINT produces contract-compliant, synthesizable RTL on all 7/7 cases. On the five cases commonly applicable to all three generated routes, HINT and Direct C2RTL each succeed on 5/5, compared with 1/5 for C2HLSC. Implementation QoR. Under matched synthesis constraints, HINT reduces area by 5.0%–26.2% relative to the five manual implemen- tations and improves ADP in all five comparisons. Relative to the five accepted Direct C2RTL results, HINT reduces area by 8.9%– 86.1% and improves ADP in every comparison. CORDIC is the only strictly accepted C2HLSC comparison, where HINT is 22% smaller and slightly faster. Each reported HINT result corresponds to the first successful synthesis after correctness acceptance, with- out synthesis-driven candidate selection or QoR refinement. Why HINT may benefit QoR. HINT separates high-impact mi- croarchitectural decisions from low-level generation details and carries them into RTL through its lowering obligations, which can improve cross-case QoR consistency. The resulting organization can differ substantially from manual RTL but does not guarantee an optimal implementation. Figure 3 gives a concrete example of this structural difference: manual RTL carries full angles into a late decode and uses variable small-constant multiplication, whereas HINT-derived RTL carries compact tags, predecodes control, and exposes compensation as shift–add logic. Under the same synthesis flow, combinational area is nearly identical, while the HINT-derived organization reduces sequential cells from 164 to 117 and noncombinational area by 28.4%; total area falls from 12.28k to 11.10k휇m 2 and the critical path from 22.24 to 15.89 ns. 5.3 Cross-Scale Studies (RQ2) Cases and verification. We evaluate RealBench AES and SDC with their native environments [13]; E203 is omitted because its released CPU-top harness provides only short pin-level stimuli without processor workloads. For Vortex commitfe8168b[29], a C++ extract frozen before generation produces 48 directed and 500 seeded-random root transactions covering configuration/CSR behavior, OPIVV/OPIVI/OPIVX/OPMVV/OPMVX families, zero Manual RTL: full angle, late decode/multiply reg signed [15:0] s1_theta_r, s2_theta_r, s3_theta_r; assign s4_case_1 = (s3_theta_r < 0) && ...; assign s4_k_sel = s4_case_1 ? ... : s4_case_2 ? ... : ...; assign s4_x_mul = $signed(1'b0,s4_k_sel) * $signed(s4_y_shr_res); HINT-derived RTL: compact, predecoded control reg [2:0] q0_tag, q1_tag; reg [3:0] q2_gain, q2_sh_v; if (q1_tag == TAG0) begin d2_gain = s2_neg ? s2_k0 : s2_k2; d2_sh_v = s2_neg ? 4'd13 : 4'd14; end f_du = (f_gain[0] ? f_v_sh_e : 0) + (f_gain[1] ? f_v_sh_e <<< 1 : 0) + ...; Figure 3: CORDIC example comparing two functionally matched RTL organizations. Table 3: Cross-scale implementation results. Design/block HINT LOC RTL LOC Area (휇m 2 ) Timing (ns) RealBench AES40755059,5015.77 RealBench SDC1,5791,73296,4267.18 Vortex VPU top2,7443,541561,66714.69 vcfg46165414,6474.64 vrf358248177,24511.49 int_exec80970794,41114.54 mv_mask46538039,5905.62 vlsu651871160,72013.35 Table 4: Protocol- and repository-scale feature coverage. Design/block Module features RealBench SDC Communication- and control-intensive SD-card controller spanning Wishbone slave/master traffic, SD command/data protocols, DMA, descriptor/FIFO progress, CRC/status/interrupt state, dynamic clocking, and dual-edge-visible timing. Vortex-derived VPU Major protocol- and memory-rich vector component of the RISC-V-based Vortex GPU: a connected 128-bit non-floating-point subsystem with RVV-style configuration/CSR state, 32 architectural vector registers, SEW 8/16/32 integer/multiply/mask/move execution, masked commit, and unit-stride memory request/response handling. and short lengths, and unit-stride memory widths 1/2/4. Tables 3 and 4 report implementation scale and feature coverage. RealBench results. Neither RealBench case provides reference C. Generated AES passes the native functional, reset, and exact- latency checks, while generated SDC passes its native protocol tests. Under the same synthesis flow, generated SDC uses 96.43k versus 99.62k휇m 2 for the original RTL, while its critical path is 7.18 versus 5.11 ns. The two implementations thus show an area–timing trade-off. Vortex-derived non-floating-point VPU. During Stage 0, the VPU’s non-floating-point scope is partitioned by hardware owner- ship into the five blocks in Table 3. For each block, both HINT and RTL pass co-simulation against the same pinned C++ oracle before recomposition; the physically connected design is then checked HINT: Toward an Executable Hardware-Intent Representation Layer for LLM-Driven RTL GenerationASP-DAC 2027, January 25–28, 2027, Tokyo, Japan again at the top transaction boundary, so the evaluation does not reduce to five isolated module tests. The connected VPU synthesizes to 561.67k휇m 2 . Table 3 shows the block-level breakdown; the relatively large VRF and VLSU areas reflect the absence of memory macros in our library, so their storage and buffering must be implemented with standard-cell registers. 6 Conclusion This work presents HINT, an executable and checkable hardware- intent intermediate representation layer that makes high-impact microarchitectural decisions explicit before RTL realization and carries them as lowering obligations. In the controlled operator study, the HINT-mediated route shows better observed convergence than the generated baselines and produces consistently competi- tive area and timing QoR without post-synthesis QoR refinement; RealBench and the Vortex-derived VPU further demonstrate appli- cability to protocol-rich IP and connected hierarchy. By separating architecture construction from signal-level repair, HINT exposes high-impact implementation choices before RTL coding begins. Its layer obligations and reference profile provide a foundation for reusable intent artifacts and future checking, exploration, and lowering tools. References [1]Meisam Abdollahi, Seyedeh Faegheh Yeganli, Mohammad (Amir) Baharloo, and Amirali Baniasadi. 2025. Hardware Design and Verification with Large Language Models: A Scoping Review, Challenges, and Open Issues. Electronics 14, 1 (2025), 120. doi:10.3390/electronics14010120 [2] Accellera Systems Initiative. 2016. SystemC Synthesizable Subset Lan- guage Reference Manual, Version 1.4.7.Accellera Systems Initiative. https://w.accellera.org/images/downloads/standards/systemc/SystemC_ Synthesis_Subset_1_4_7.pdf [3]Lukai Cai and Daniel Gajski. 2003. Transaction Level Modeling: An Overview. In Proceedings of the First IEEE/ACM/IFIP International Conference on Hard- ware/Software Codesign and System Synthesis. 19–24. doi:10.1109/CODESS.2003. 1275250 [4]Luca Collini, Siddharth Garg, and Ramesh Karri. 2025. C2HLSC: Leveraging Large Language Models to Bridge the Software-to-Hardware Design Gap. ACM Trans. Des. Autom. Electron. Syst. 30, 6, Article 96 (Oct. 2025), 24 pages. doi:10. 1145/3734524 [5]Jason Cong, Bin Liu, Stephen Neuendorffer, Juanjo Noguera, Kees Vissers, and Zhiru Zhang. 2011. High-Level Synthesis for FPGAs: From Prototyping to De- ployment. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 30, 4 (2011), 473–491. doi:10.1109/TCAD.2011.2110592 [6] Matthew DeLorenzo, Animesh Basak Chowdhury, Vasudev Gohil, Shailja Thakur, Ramesh Karri, Siddharth Garg, and Jeyavijayan Rajendran. 2024. Make Every Move Count: LLM-based High-Quality RTL Code Generation Using MCTS. arXiv preprint arXiv:2402.03289 (2024). arXiv:2402.03289 [cs.LG] [7]Adam Donlin. 2004. Transaction Level Modeling: Flows and Use Models. In Proceedings of the International Conference on Hardware/Software Codesign and System Synthesis. 75–80. doi:10.1109/CODESS.2004.240821 [8]Schuyler Eldridge, Prithayan Barua, Aliaksei Chapyzhenka, Adam Izraelevitz, Jack Koenig, Chris Lattner, Andrew Lenharth, George Leontiev, Fabian Schuiki, Ram Sunder, Andrew Young, and Richard Xia. 2021. MLIR as Hardware Compiler Infrastructure. In Workshop on Open-Source EDA Technology (WOSET). https: //woset-workshop.github.io/PDFs/2021/a06.pdf [9]Wenji Fang, Yao Lu, Shang Liu, Qijun Zhang, Ceyu Xu, Lisa Wu Wills, Hongce Zhang, and Zhiyao Xie. 2025. RTLCoder: Fully Open-Source and Efficient LLM- Assisted RTL Code Generation Technique. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 44, 4 (2025), 1448–1461. [10]Mingzhe Gao, Jieru Zhao, Zhe Lin, Wenchao Ding, Xiaofeng Hou, Yu Feng, Chao Li, and Minyi Guo. 2024. AutoVCoder: A Systematic Framework for Automated Verilog Code Generation using LLMs. arXiv:2407.18333 [cs.AR] https://arxiv. org/abs/2407.18333 [11]Google and SkyWater Technology. 2026. Open Source Process Design Kit for the SkyWater SKY130 Process Node. https://github.com/google/skywater-pdk. Accessed 2026-04-10. [12]Zhuolun He, Yuan Pu, Haoyuan Wu, Tairu Qiu, and Bei Yu. 2025. Large Language Models for EDA: Future or Mirage? ACM Trans. Des. Autom. Electron. Syst. 30, 6, Article 90 (Oct. 2025), 53 pages. doi:10.1145/3736167 [13] Pengwei Jin, Di Huang, Chongxiao Li, Shuyao Cheng, Yang Zhao, Xinyao Zheng, Jiaguo Zhu, Shuyi Xing, Bohan Dou, Rui Zhang, Zidong Du, Qi Guo, and Xing Hu. 2025. RealBench: Benchmarking Verilog Generation Models with Real-World IP Designs. arXiv:2507.16200 [cs.LG] https://arxiv.org/abs/2507.16200 [14]Chris Lattner, Mehdi Amini, Uday Bondhugula, Albert Cohen, Andy Davis, Jacques Pienaar, River Riddle, Tatiana Shpeisman, Nicolas Vasilache, and Olek- sandr Zinenko. 2021. MLIR: Scaling Compiler Infrastructure for Domain Specific Computation. In 2021 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). 2–16. [15] Patrick S. Li, Adam Izraelevitz, and Jonathan Bachrach. 2016. Specification for the FIRRTL Language. Technical Report UCB/EECS-2016-9. EECS Department, Uni- versity of California, Berkeley. https://w2.eecs.berkeley.edu/Pubs/TechRpts/ 2016/EECS-2016-9.pdf [16]Mingjie Liu, Nathaniel Pinckney, Brucek Khailany, and Haoxing Ren. 2023. In- vited Paper: VerilogEval: Evaluating Large Language Models for Verilog Code Generation. In 2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD). 1–8. doi:10.1109/ICCAD57390.2023.10323812 [17]Anton Lozhkov, Raymond Li, Loubna Ben Allal, Federico Cassano, Joel Lamy- Poirier, Nouamane Tazi, Ao Tang, Dmytro Pykhtar, Jiawei Liu, Yuxiang Wei, Tianyang Liu, Max Tian, Denis Kocetkov, Arthur Zucker, Younes Belkada, Zi- jian Wang, Qian Liu, Dmitry Abulkhanov, Indraneil Paul, Zhuang Li, Wen-Ding Li, Megan Risdal, Jia Li, Jian Zhu, Terry Yue Zhuo, Evgenii Zheltonozhskii, Nii Osae Osae Dade, Wenhao Yu, Lucas Krauß, Naman Jain, Yixuan Su, Xuanli He, Manan Dey, Edoardo Abati, Yekun Chai, Niklas Muennighoff, Xiangru Tang, Muh- tasham Oblokulov, Christopher Akiki, Marc Marone, Chenghao Mou, Mayank Mishra, Alex Gu, Binyuan Hui, Tri Dao, Armel Zebaze, Olivier Dehaene, Nicolas Patry, Canwen Xu, Julian McAuley, Han Hu, Torsten Scholak, Sebastien Paquet, Jennifer Robinson, Carolyn Jane Anderson, Nicolas Chapados, Mostofa Patwary, Nima Tajbakhsh, Yacine Jernite, Carlos Muñoz Ferrandis, Lingming Zhang, Sean Hughes, Thomas Wolf, Arjun Guha, Leandro von Werra, and Harm de Vries. 2024. StarCoder 2 and The Stack v2: The Next Generation. arXiv:2402.19173 [cs.SE] https://arxiv.org/abs/2402.19173 [18]Yao Lu, Shang Liu, Qijun Zhang, and Zhiyao Xie. 2024. RTLLM: An Open-Source Benchmark for Design RTL Generation with Large Language Model. In 2024 29th Asia and South Pacific Design Automation Conference (ASP-DAC). 722–727. doi:10.1109/ASP-DAC58780.2024.10473904 [19]Yuanyong Luo, Zhongxing Zhang, Richard Wu, Hu Liu, Ying Jin, Kai Zheng, Minmin Wang, Zhanying He, Guipeng Hu, Luyao Chen, Tianchi Hu, Junsong Wang, Minqi Chen, Dmitry Mikhaylov, Vladimir Korviakov, Maxim Bobrin, Yuhao Hu, Guanfu Chen, and Zeyi Huang. 2024. Ascend HiFloat8 Format for Deep Learning. arXiv preprint arXiv:2409.16626 (2024). https://arxiv.org/abs/2409.16626 [20]Razvan Nane, Vlad-Mihai Sima, Christian Pilato, Jongsok Choi, Blair Fort, Andrew Canis, Yu Ting Chen, Hsuan Hsiao, Stephen Brown, Fabrizio Ferrandi, Jason Anderson, and Koen Bertels. 2016. A Survey and Evaluation of FPGA High- Level Synthesis Tools. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 35, 10 (2016), 1591–1604. doi:10.1109/TCAD.2015.2513673 [21]Rachit Nigam, Samuel Thomas, Zhijing Li, and Adrian Sampson. 2021. A Com- piler Infrastructure for Accelerator Generators. In Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS). 804–817. doi:10.1145/3445814.3446712 [22] OpenAI. 2026. GPT-5.3-Codex Model. https://developers.openai.com/api/docs/ models/gpt-5.3-codex. OpenAI API documentation, accessed 2026-04-10. [23] Jingyu Pan, Guanglei Zhou, Chen-Chia Chang, Isaac Jacobson, Jiang Hu, and Yiran Chen. 2025. A Survey of Research in Large Language Models for Electronic Design Automation. ACM Transactions on Design Automation of Electronic Systems 30, 3 (2025), 34:1–34:21. doi:10.1145/3715324 [24]Zehua Pei, Huiling Zhen, Mingxuan Yuan, Yu Huang, and Bei Yu. 2024. BetterV: Controlled Verilog Generation with Discriminative Guidance. In International Conference on Machine Learning. PMLR, 40145–40153. [25]Zhengyuan Shi, Jingxin Wang, Tairan Cheng, Changran Xu, Weikang Qian, and Qiang Xu. 2026. CktEvo: Repository-Level RTL Code Benchmark for Design Evolution. arXiv preprint arXiv:2603.08718 (2026). [26]Synopsys, Inc. 2026. Design Compiler: Timing, Area, Power, & Test Opti- mization. https://w.synopsys.com/implementation-and-signoff/rtl-synthesis- test/design-compiler.html. Accessed: 2026-04-14. [27] Synopsys, Inc. 2026.Formality Equivalence Checking.https: //w.synopsys.com/implementation-and-signoff/signoff/formality- equivalence-checking.html. Accessed: 2026-07-16. [28]Yan Tan, Xiangchen Meng, Zijun Jiang, and Yangdi Lyu. 2026. AutoVeriFix: Automatically Correcting Errors and Enhancing Functional Correctness in LLM- Generated Verilog Code. In 2026 31st Asia and South Pacific Design Automation Conference (ASP-DAC). 526–532. doi:10.1109/ASP-DAC66049.2026.11420300 [29]Blaise Tine, Krishna Praveen Yalamarthy, Fares Elsabbagh, and Hyesoon Kim. 2021. Vortex: Extending the RISC-V ISA for GPGPU and 3D-Graphics. In Proceed- ings of the 54th Annual IEEE/ACM International Symposium on Microarchitecture ASP-DAC 2027, January 25–28, 2027, Tokyo, JapanCheng et al. (MICRO ’21). ACM, 754–766. doi:10.1145/3466752.3480128 [30]Anu Verma, Khyati Kiyawat, Bishnu Prasad Das, and Pramod Kumar Meher. 2023. An Efficient Scaling-Free Folded Hyperbolic CORDIC Design Using a Novel Low-Complexity Power-of-2 Taylor Series Approximation. IEEE Transactions on Very Large Scale Integration (VLSI) Systems 31, 8 (2023), 1167–1177. doi:10.1109/ TVLSI.2023.3281078 [31] Shuo Yin, Yihe Wang, Lancheng Zou, Xufeng Yao, Tinghuan Chen, Chen Bai, Zhengrong Wang, Tsung-Yi Ho, and Bei Yu. 2026. CPPL: A Circuit Prompt Programming Language. arXiv:2605.17892 [cs.AR] https://arxiv.org/abs/2605. 17892 [32]Cunxi Yu, Chenhui Deng, Nathaniel Pinckney, and Brucek Khailany. 2026. Agentic Hardware Design as Repository-Level Code Evolution. arXiv:2606.28279 [cs.AR] doi:10.48550/arXiv.2606.28279 [33]Zhongkai Yu, Chenyang Zhou, Yichen Lin, Hejia Zhang, Haotian Ye, Junxia Cui, Zaifeng Pan, Jishen Zhao, and Yufei Ding. 2026. ChipBench: A Next- Step Benchmark for Evaluating LLM Performance in AI-Aided Chip Design. arXiv:2601.21448 [cs.AI] https://arxiv.org/abs/2601.21448 [34]Yang Zhao, Di Huang, Chongxiao Li, Pengwei Jin, Muxin Song, Yinan Xu, Ziyuan Nan, Mingju Gao, Tianyun Ma, Lei Qi, Yansong Pan, Zhenxing Zhang, Rui Zhang, Xishan Zhang, Zidong Du, Qi Guo, and Xing Hu. 2025. CodeV: Empowering LLMs with HDL Generation through Multi-Level Summarization. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (2025), 1–1. doi:10. 1109/TCAD.2025.3604320