Co-Designing Analog and Digital RTL at the Interface Boundary

The analog team hands off bias and behavior requirements, while the digital team returns control RTL and register definitions. Their boundary in a mixed-signal IC is not fixed architecture. It shifts as bias networks change, control fields are added, and system needs determine which parameters must be programmable. Verification difficulty concentrates there, where each team's tools, methods, and assumptions are most likely to diverge.

Skycore's RTL generation and verification agent operate on the digital side of this boundary by design. Transistor-level tools and mixed-signal methods already serve the analog circuitry well. The weaker point is the interface layer: control logic for the analog block, boundary-probing testbench infrastructure, and assertions that catch digital violations of constraints required by analog behavior.

This post covers our interface approach, the RTL produced at that boundary, and where the verification agent adds detail versus where engineers must choose manually.

Mapping the Interface Boundary

A typical RF block has three analog-digital interface layers:

Configuration signals: Control logic sends these digital outputs to the analog block as programmed operating settings. Examples include bias current select bits, gain mode bits, frequency band select, and calibration DAC codes. The digital register file drives them and holds them steady during ordinary analog operation.

Status signals: The analog block sends these digital inputs to control logic as status flags. Examples include PLL lock detect, over-temperature flag, and ADC overflow bit. Digital firmware reads them through the status register map.

Calibration interfaces: Two-way digital paths serve calibration algorithms in the digital domain. Examples include amplitude calibration sequences for a quadrature modulator and an automatic frequency calibration handshake for a VCO. They combine configuration writes with status reads in a defined temporal pattern.

Skycore covers configuration and status layers completely in generated RTL. For calibration interfaces, it produces the state machine and register map structure, but not the algorithm itself, such as which correction coefficients to apply and when. That choice remains with the engineer because it depends on the analog block's calibration behavior.

Boundary Port Naming

One frequent source of mixed-signal integration bugs is a port-name mismatch between digital control RTL and the analog block's Verilog behavioral model or SPICE wrapper. The analog team names bias select signals by its convention, while the digital team gives matching outputs different names. A top-level netlist then exposes the mismatch during integration simulation.

Skycore requires explicit port names in the block description instead of deriving them from register-map field names. Generated RTL uses those names exactly, with a one-to-one mapping from register fields to output ports recorded in the generated header comment:

// Generated by Skycore from lna_ctrl_v2 block description
// Interface boundary ports (analog side):
//   lna_bias_sel[2:0]  <- LNA_CFG.bias_sel[2:0]
//   lna_gain_mode[1:0] <- LNA_CFG.gain_mode[1:0]
//   lna_lock_det       -> LNA_STATUS.lock_det (read-only)

module lna_ctrl (
  input  logic       clk, rst_n,
  // SPI interface
  input  logic       sclk, mosi, cs_n,
  output logic       miso,
  // Analog interface boundary
  output logic [2:0] lna_bias_sel,
  output logic [1:0] lna_gain_mode,
  input  logic       lna_lock_det
);

Generated RTL port names should match the names agreed for the analog block. That agreement must precede RTL generation. Skycore does not settle team naming disputes. It exposes them at specification time instead of integration time.

Probing the Interface in the Testbench

The generated testbench adds a boundary-check layer between digital control RTL and an analog-block stub. This stub is not a complete analog behavioral model. It is a response model: for configuration signals from the digital logic, which analog status signals should it return?

The stub is a parameterized SystemVerilog module whose response tables come from the block description. For an LNA, it might return lock detect after a programmable settle time, assert an over-temperature flag when a bias mode exceeds a thermal threshold, and acknowledge a requested gain mode when valid:

// Skycore-generated analog boundary stub for lna_ctrl testbench
module lna_analog_stub #(
  parameter int LOCK_SETTLE_CYCLES = 200,
  parameter int THERMAL_BIAS_LIMIT = 6   // bias_sel >= 6 triggers OT flag
) (
  input  logic [2:0] lna_bias_sel,
  input  logic [1:0] lna_gain_mode,
  output logic       lna_lock_det,
  output logic       lna_over_temp
);
  int settle_cnt;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) settle_cnt <= 0;
    else if (settle_cnt < LOCK_SETTLE_CYCLES) settle_cnt <= settle_cnt + 1;
  end

  assign lna_lock_det  = (settle_cnt == LOCK_SETTLE_CYCLES);
  assign lna_over_temp = (lna_bias_sel >= THERMAL_BIAS_LIMIT[2:0]);
endmodule

The stub does not model the actual analog circuit precisely. Settle time is estimated from the spec, and the thermal threshold is simplified. Its job is to exercise digital status paths and show how firmware handles analog feedback. Whether the circuit settles in 200 cycles or 180 cycles belongs in Spectre simulation, not the digital control testbench.

Boundary Assertions

The key assertions in a mixed-signal interface testbench are behavioral constraints, not structural protocol checks, which belong in the SPI/I2C verification layer. They express assumptions the analog block makes about digital control and catch violations when the digital side is wrong during integration.

A real LNA control interface may require that gain mode stay unchanged while PLL lock detect is low, because the new mode's bias table is invalid before reference lock. Bias select must not exceed the thermal limit without a shutdown request first. Calibration mode must not begin while gain mode select is in high-power class. Standard protocol assertions do not capture these analog operating constraints.

Skycore derives behavioral boundary assertions from constraint annotations in the block description. The engineer who understands the analog block's requirements records the constraints once; the verification agent converts them to SVA assertions that run in every testbench simulation. When a new firmware engineer writes control sequences that violate one of these constraints, simulation reports the assertion before the code reaches the analog integration testbench.

Co-Design Timing Challenge

In practice, analog and digital teams define the interface while both designs are underway. The analog team is deciding which parameters need programming, while the digital team decides how many register bits each field gets. The definition changes as both sides converge, so RTL must be revised with every interface update.

This is where regeneration helps most. Adding a port or renaming a signal in the block description takes a few minutes. Regenerating RTL and the boundary stub takes another few minutes. The revised RTL can enter simulation and regression immediately, without manually updating RTL, testbench, and assertion files separately.

This does not remove co-design difficulty. Agreement on the interface is the hard part, not its implementation. Once that agreement exists, Skycore speeds implementation, lowers the cost of late interface changes, and supports refining the interface toward correctness earlier in the project.

What Skycore Leaves Out in Mixed-Signal

Scope, precisely: Skycore generates RTL for digital control plus testbench infrastructure for boundary probing. It does not create analog behavioral models beyond simplified boundary stubs, mixed-signal simulation setups for Spectre or ADE, or the top-level integration testbench linking digital RTL with the full analog schematic for system verification.

Those tasks rely on the mixed-signal team's analog tools and expertise. Skycore focuses on the digital control interface and boundary verification artifacts. Its aim within that scope is faster movement from specification change to working simulation, since that loop carries much of the schedule risk in mixed-signal IC development.