The demo shows a prompt such as "design a 2.4 GHz LNA with 15 dB gain and less than 2.5 dB noise figure" becoming a Verilog module. It compiles, has suitable ports, and appears credible. Downstream simulation and reuse can expose the gap.
A demo does not reveal the testbench result. Nor does it show what happens three weeks later when the supply changes from 1.8 V to 1.5 V but the parameters cannot support it. Synthesis may also reject constructs legal in theory yet unroutable on the target process node.
This post examines the distance between "generates plausible Verilog" and "generates usable RTL." While building Skycore, we have encountered that gap often enough to understand its present boundary and its remaining limits.
Reliable Cases: Behavioral Models with Explicit Spec Parameters
Today, natural-language RTL generation works best for RF behavioral models with measurable numeric specs. Consider an LNA with NF, gain, supply, and frequency range; a mixer with conversion gain, IIP3, and port impedances; or a VCO with tuning range and phase noise floor at a specified offset frequency.
This category works because the route from prose spec to RTL structure is defined. NF maps to a computation in the always block, gain to a parameter, and compression to a saturation function with an input threshold. The translation is involved but determinate: the same spec should produce the same behavioral structure, with parameterization as the main variation.
The RTL is synthesizable in the behavioral-model sense: it elaborates without errors, simulates properly, and gives useful mixed-signal simulation results. It is not meant for physical synthesis to silicon, because behavioral RF models are not used that way. Simulation is the target environment.
// Example: well-defined behavioral generation from explicit spec
// Input description: "LNA, 2.4 GHz center, BW 150 MHz,
// NF typ 2.3 dB, Gain 16.5 dB, P1dB_in -10 dBm,
// S11 better than -10 dB, supply 1.8V, temp -40 to 85C"
// Generated: parameterized module with all spec values as
// top-level parameters, frequency-dependent gain function,
// NF computation per Friis formula, compression function
// tied to P1DB_IN_DBM parameter, S11 rolloff model.
// Each parameter annotated with spec source in comment.Failure Cases: Ambiguous or Incomplete Specs
This method quickly fails when the specification lacks clarity or detail. "Design an LNA for 5G NR band n77" is acceptable in a review, but insufficient for RTL generation. Band n77 spans 3.3 to 4.2 GHz, or 900 MHz across multiple channel configurations. Product NF depends on the link budget, receive-chain architecture, and target sensitivity, none of which appears in that sentence.
A language model not required to ask questions will infer absent values from training data and produce an LNA for a plausible 5G NR use case. Yet plausible is not product-correct. If the link budget assigns 2.0 dB to the first stage while the model assumes 2.8 dB from common examples, its RTL may pass its own testbenches and still miss the system requirement.
Skycore declines generation when required spec parameters are absent and identifies each missing item. That seems less impressive than plausible output, but failure is cheaper. An engineer can answer "missing: NF target, supply voltage, frequency range" in thirty seconds. Discovering a wrong NF assumption after simulation and review costs the invested engineering time.
Synthesizability Is Not Simulatability
For RF blocks, "can be simulated" differs from "can be synthesized to logic gates." Behavioral RF models use real-number data types, which standard cell logic cannot synthesize. Real-number ports and variables exist for simulation and have no synthesized-netlist equivalent. This is intentional: the models serve system simulation, not physical synthesis.
The problem starts when an RTL generator uses synthesis constructs, such as integer ports, registered logic, and always_ff blocks, in a behavioral RF model. The code may compile, simulate, and look correct at nominal conditions. Its structure is still unsuitable: a synthesis-targeted LNA behavioral model tries to serve two purposes and properly serves neither.
Skycore labels generated modules by simulation context: behavioral models use real ports and target mixed-signal simulation. Digital control interface modules use standard synthesizable constructs. The two categories remain separate. Generation rules enforce this, and every generated file has a context comment block at its top.
Human Review Still Matters
Three areas in our early-access projects consistently need human review, even with a well-specified input description:
Parameter range plausibility. A generator may create a syntactically valid module with NF of 0.1 dB, gain of 40 dB, and P1dB of +10 dBm at a 1.8 V supply because its rules set no physical limits. A reviewer will see that this combination is physically implausible for a single-stage LNA on any realistic CMOS process. Generation lacks process-level constraints; the engineer has them. Checking values against the process node is quick, but not automatable.
Interface compatibility with adjacent blocks. An LNA model using real-number power ports may be valid in isolation. Its convention must match the neighboring blocks in the same simulation. If the receive chain expects a current-domain LNA output while the generated module provides a power-domain (dBm) output, both can compile and still produce meaningless results. Compatibility requires system context, not just an isolated block description.
Verification completeness judgment. The generated testbench checks stated requirements, not omitted ones. Engineers familiar with the block and application may identify gaps: an LNA specification for an application expecting a nearby strong interferer is incomplete if it omits out-of-band blocker rejection. That knowledge comes from receiver experience and cannot be supplied by automated generation.
A Practical Reliability Threshold
Our early-access work indicates a practical threshold for RF behavioral blocks when the spec is complete, every required numeric parameter is stated, the block fits generator scope (LNA, mixer, VCO, PA behavioral, baseband filter, synthesizer loop), and an engineer reviews the result at parameter level.
In those conditions, generated RTL needs minor changes before simulation in roughly one in four sessions, and none in the other three. Changes usually adjust parameters or interface conventions rather than structure. For a medium-complexity RF behavioral block requiring two days of verification-engineer work, this cuts time to first simulation.
Generated output still cannot proceed directly to tapeout-blocking sign-off without human review. Edge-case generation must improve, along with testbench creation for corner-case failures. These gaps should narrow as RF block training data grows and the verification agent gets better at generating corner-case coverage without every scenario being specified.
Implications for the Design Workflow
The useful model today is not "replace the RTL engineer," but "reach a reviewable first draft sooner." Engineers still inspect parameters, interface compatibility, and verification completeness. They no longer need to write the module declaration, port list, parameter assignments, gain function, noise computation, and compression term from scratch. Once the spec is clear, that mechanical work saves time.
Teams using Skycore well treat generated output as a basis for review and iteration, not a finished product. Generation creates a complete, commented, parameterized module. Review checks parameter validity and interface conventions against the surrounding simulation. Iteration adds tests absent from the spec. This three-step workflow is faster than a blank file while retaining the rigor RF IC design requires.