When you generate behavioral RTL for an RF block, one early session decision is the HDL format to target. SystemVerilog is not always the answer. Verilog-2001 remains suitable for particular flow configurations, and the practical gap between the two languages matters more in RF behavioral modeling than in digital RTL design. This post explains our approach to that choice.
When Verilog-2001 Still Fits
Verilog-2001 contains the RTL constructs needed for most RF behavioral blocks. An LNA model, mixer conversion-gain block, or VCO frequency-versus-control-voltage map can be written in Verilog-2001 without a meaningful loss of expressiveness. The constructs relevant to RF modeling, including real-number nets, parameterized modules, generate blocks, and analog-style assignments in an always block, are available and well-supported.
The main case for Verilog-2001 is simulator compatibility. If an existing EDA flow uses an older Questa setup, and the model must replace a Verilog netlist in mixed-signal simulation, Verilog-2001 avoids adding SystemVerilog compilation dependencies to a flow not built around them. That is a practical constraint for teams placing generated behavioral blocks beside existing IP without upgrading the complete simulation environment.
SystemVerilog Benefits for RF Blocks
SystemVerilog adds three RF-relevant improvements: typed ports, interface constructs, and assertion integration.
Typed ports are useful in real-number behavioral models. In Verilog-2001, a real-number port uses real, while its assignment meaning remains informal: no standard notation says whether it carries dBm power or linear voltage. SystemVerilog does not completely resolve that issue, but typed variable declarations and package-level type definitions help teams enforce shared signal-domain conventions. A module with a parameter defining its input power domain is clearer and easier to move to another block than one that depends on comments.
// SystemVerilog: package-level type for power domain signals
package rf_types_pkg;
typedef real power_dbm_t;
typedef real freq_hz_t;
typedef real nf_db_t;
endpackage
// Module port using package type
import rf_types_pkg::*;
module lna_behavioral #(
parameter real NF_TYP_DB = 2.3,
parameter real GAIN_TYP_DB = 16.5,
parameter real P1DB_DBM = -10.0
)(
input power_dbm_t pin_dbm,
input freq_hz_t freq_hz,
output power_dbm_t pout_dbm,
output nf_db_t nf_actual_db
);SystemVerilog interfaces shorten the port list for blocks crossing a defined boundary. An LNA with power, frequency, bias enable, gain control mode, and temperature input becomes unwieldy in Verilog-2001. An interface can group those signals for both the DUT and testbench, reducing boilerplate and lowering the chance that the testbench drives the wrong port.
Assertion integration is the third benefit. SystemVerilog assertions (SVA) are native to UVM verification environments. With the DUT written in SystemVerilog and SVA assertions embedded, the simulator can observe them directly without extra binding steps. For RF behavioral blocks, inline SVA can check bias stability, out-of-range inputs, and frequency-domain output limits.
How Skycore Picks the Format
Skycore uses the target EDA tool in the session description to select the HDL format. A Cadence Virtuoso session produces Verilog-2001 by default unless SystemVerilog is requested explicitly. A Questa-targeted session produces SystemVerilog with UVM-compatible testbench scaffolding, since the simulator supports the language and its assertion integration is immediately useful.
Without a specified target tool, Skycore selects SystemVerilog when the description includes verification requirements. The reason is straightforward: testbenches with inline assertions and coverage groups use features native to SystemVerilog, while Verilog-2001 requires added adaptation. Generating Verilog-2001 for a block destined for a UVM testbench creates avoidable integration work.
The Behavioral Model Is Independent of Language
An RF behavioral LNA model has the same functional content whether its outer HDL is Verilog-2001 or SystemVerilog. Gain calculation, compression approximation, and noise figure scaling perform the same operations in both. The language changes port declarations, interface structure, assertion syntax, and simulator compatibility, not the RF physics represented by the model.
Changing the output format is therefore inexpensive when the target EDA environment changes. A team can begin with Verilog-2001 for a legacy flow and regenerate SystemVerilog after advancing its simulation environment. The specification stays the same, so the new session only changes the format parameter.
VHDL Note
Skycore receives questions about VHDL output, especially from European aerospace and defense teams maintaining legacy VHDL flows. Current output supports Verilog and SystemVerilog only. VHDL output is planned as a configuration option for flows that require it, but it is unavailable in the current early-access release. For now, the API export function can produce Verilog-2001, which teams may manually wrap in a VHDL component interface for mixed-language simulation. Teams that have used this approach consider it workable.