Discrete Varying Transfer Function — Control Systems/Linear Parameter Varying

Discrete Varying Transfer Function

Control Systems / Linear Parameter Varying

A first-order discrete transfer function whose coefficients arrive as signals, so the filter may be re-scheduled on every sample. It is realized in transposed direct form II – a single state s, rather than separate input and output histories:

y[k] = b₀[k]·u[k] + s[k−1]
s[k] = b₁[k]·u[k] − a₁[k]·y[k]

equivalently y/u = (b₀ + b₁z⁻¹) / (1 + a₁z⁻¹). The denominator is monic by contract: a₁ is the tail, the leading 1 is implied, and the a term is subtracted.

Ports

• u – the signal to filter, of any size [p,q]. The filter is SISO and applied independently to every entry, each carrying its own state s, but all entries share the one coefficient triple.
• b0 – the direct-feedthrough numerator coefficient for this sample.
• a1 – the denominator tail for this sample. Note the port order is (u, b0, a1, b1), matching Simulink exactly: the coefficients interleave as a₁, b₁, a₂, b₂… after b₀, which is not the grouping the names suggest.
• b1 – the one-sample-delayed numerator coefficient.
• Output – y, the same size as u.

Parameters

• Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period. Everything else about this block arrives on ports, so there is nothing else to tune.

Code export

All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The coefficients are emitted as reads of the b0/a1/b1 signals rather than as constants, so a generated core re-schedules with them exactly as the simulation does. The three HDL targets carry the recursion in Q16.16 fixed point; coefficients arriving on a port are quantized to that grid.

Simulink bridge

Import and export, mapped to cstblocks/Linear Parameter Varying/Discrete Varying Transfer Function (the library is cstblocks, not the "Control System Toolbox" display name, which add_block does not accept). The coefficients need no parameter mapping at all – on both sides they are signals – and the port order is identical.

The order is fixed at one, and this is the block's real limitation. Simulink's N and Feedthrough move ports (2N+2 inputs with feedthrough, 2N+1 without), while an ICore block's port list is structural, so both are always written out fixed: N = 1 and Feedthrough = on. That keeps the bridge exact and lossless for the shape it does support instead of approximately right for all of them. Two of these in series realize a second-order section.

"Sampling Time (s)" DOES cross, but under Simulink's own name for it here: this block's rate parameter is Ts, not SampleTime. Emitting the standard name would be a hard set_param error that aborts the whole generated script.

Notes

• Discrete only, and stateful: a single state s per entry of the signal, starting at zero.
• The realization is part of the specification here, not an implementation detail. Direct form I, direct form II and this transposed form all realize the same transfer function and agree exactly while the coefficients hold still – they become three different systems the moment the coefficients move. This block matches Simulink's to 4·10⁻¹⁶ with all three coefficients varying, where direct form I would be out by ~0.8.
• Stability is the user's responsibility, in a way it is not on a fixed-coefficient filter. |a₁| ≥ 1 for even a few samples can start a divergence the block never recovers from, and nothing here can prevent it: the coefficients are signals, and their trajectory is not known until the run.
• Use Discrete Transfer Function instead whenever the coefficients are constant – it bakes them into the generated code, which is both faster and exact.