Varying Delay — Control Systems/Linear Parameter Varying
Control_Systems/Linear_Parameter_Varying/Varying_Delay · 2 input / 1 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text
Description#
The block's own DESCRIPTION_HTML, rendered verbatim — the same text the config dialog's info panel and the library navigator show. Fix a wrong sentence in the block's .cpp (R-D9), never here.
Varying Delay
Control Systems / Linear Parameter Varying
Delays the input by an amount that is itself a signal, and interpolates between the two stored samples either side of it:
y(t) = u(t − Td(t))
Whatever the delay port reads at time t is how far back the block reaches on that tick. The delay is given in seconds; a delay that falls between two samples is a linear blend of them, weighted by how far between them it lands, so the output moves smoothly as the delay sweeps rather than jumping a whole sample at a time. A delay of zero is direct feedthrough.
This is what distinguishes it from Variable Time Delay, which is otherwise the same idea: that block rounds the delay to the nearest whole sample, a documented approximation, and so steps its output as the delay crosses a half-sample boundary. Reach for this one inside a parameter-varying model, where the delay is a scheduling signal that moves continuously, and for that one when whole-sample resolution is enough.
Its sibling Variable Transport Delay reads the same port as a transit rate and integrates it instead – a different block, not a different setting.
Ports
- u – the delayed signal, of any size [m,n]. This is what comes out delayed.
- d – the delay in seconds, a scalar [1,1]. It applies to the whole signal, not per entry. Negative values are clamped to zero – nothing arrives before it was sent – and values beyond Maximum Delay (s) are clamped to it.
- Output – the delayed signal, the SAME size [m,n] as u.
Parameters
- Maximum Delay (s) – scalar, the longest delay the block can represent, in seconds. Defaults to 10, matching Simulink. It sets the depth of the transit line: a requested delay beyond it is clamped rather than growing the buffer, because a line that reallocates mid-run is a latency spike on a real target. Cost is proportional – at a 0.01 s rate the default is 1000 stored samples per signal entry – so set it to the largest delay you actually need rather than leaving headroom.
- Initial Output – scalar, what the block emits while the delay still reaches back past the start of the run. Defaults to 0. The whole buffer is pre-filled with it, so a run starts from a defined line rather than from samples that were never taken.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period. It is the spacing of the samples the blend interpolates between, and the unit the maximum delay is counted in, so it is part of the arithmetic and not merely a schedule. A shorter step brings the two blended samples closer together and so tracks a fast-moving delay more faithfully.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. Each carries the ring buffer as its state, pre-filled with the initial output, and performs the same two-slot blend as the simulation. Only 1/dt and the depth are baked in as constants; the delay itself is read from its port every tick.
The three HDL targets carry the line as a slot × element register
file and derive the read address in hardware, using the generated fixed-point
package's fx_to_int – an arithmetic shift by the fraction
width, which is floor() and so splits the delay the same way the software
targets do; the fraction left over is one Q16.16 multiply. A zero whole part is
special-cased to the input rather than read back from the buffer: the write is
registered, so on that tick the addressed slot still holds its previous contents,
and reading it would return the value from a whole lap ago instead of the sample
just written. The OLDER of the two slots is never the one being written, so it
always reads correctly. Note that the register file is sized from
Maximum Delay (s), so a generous bound is paid for in flip-flops –
keep it tight for a synthesizable core.
Note that on the HDL targets the delay arrives already quantized to the Q-format, one quantum being about 1.5×10−5, and the blend weight is carried in the same format. That shows up as a small proportional error rather than as a jump: unlike the rounding sibling, where a quantum either side of a half-sample boundary selects a different sample entirely, here it only nudges the weight. It is inherent to carrying a time in fixed point, not a defect of the generated core.
Simulink bridge
Import and export, mapped to cstblocks/Linear Parameter Varying/Varying
Delay. "Maximum Delay (s)" to TdMax, "Initial Output" to
u0. The block always implies PadeOrder = 0, since the
delay is realized as a true transit line and never as a Padé
approximation, and TdMin = 0, since a negative delay is clamped to
zero here rather than floored at a configured minimum. A Simulink block carrying
either at a different value is reported on import rather than silently
accepted.
TdFixed, bufsize and FixedBuffer have
no ICore counterpart: the transit line is sized from Maximum Delay (s) and
the sampling time rather than from a buffer length in samples.
This block has no SampleTime parameter in Simulink –
it is continuous there, and the measured dialog carries neither
SampleTime nor Ts – so "Sampling Time (s)" stays
on the ICore side and does not cross. Its discrete sibling does carry one,
under the name Ts.
⚠ The parity suite checks this bridge only at whole-sample delays, and
that is a property of the harness rather than of the block: both sides are driven
from From Workspace with interpolation off, so Simulink holds its
input between samples while this block blends two distinct stored values. They
disagree by construction on a fractional delay. The interpolation itself is
certified by code-export verification, which compares against ICore's own solver
and drives the delay port freely.
Notes
- Stateful: Maximum Delay / dt + 1 past values of the signal port.
- Discrete by nature – the line advances one slot per sample, so the block always runs at its own rate rather than being pushed through a continuous solver's stages.
- Sub-sample delay IS interpolated, linearly, between the two stored samples either side of it – which is the whole difference from Variable Time Delay. The blend is exact for a signal that is itself linear between samples, and approximates anything else; shorten the sampling time where that matters.
- Not linear in the state-space sense, and so deliberately carries no state space: a pure delay is the transcendental factor e^(−sd), which no finite A/B/C/D expresses, and a time-varying one is not even time-invariant.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Linear_Parameter_Varying/Varying_Delay |
| family | Control_Systems/Linear_Parameter_Varying |
| solver environment class | ICoreBlock_0_Control_Systems_1_Linear_Parameter_Varying_2_Varying_Delay |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Linear_Parameter_Varying/Varying_Delay/ICoreBlock_0_Control_Systems_1_Linear_Parameter_Varying_2_Varying_Delay.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Linear_Parameter_Varying/Varying_Delay/ICoreBlock_0_Control_Systems_1_Linear_Parameter_Varying_2_Varying_Delay.h |
| default size on canvas | 110 × 80 px |
| ports at insert | 2 in, 1 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | u |
| 2 | in | ICoreDouble | d |
| 3 | out | ICoreDouble | — |
Ports the constructor creates. A block whose port list changes with its configuration adds or removes ports at load time; the count above is the one a freshly inserted block has.
Configuration variables#
| Config variable | Default | Simulink parameter |
|---|---|---|
Maximum Delay (s) | 10 | TdMax |
Initial Output | 0 | u0 |
Every block also carries Sampling Time (s) from ICoreBlockSolverEnvironment: zero or less inherits the solver's rate, a positive value runs the block at that period.
Simulink bridge#
| support | Support::Both |
| Simulink path | cstblocks/Linear Parameter Varying/Varying Delay |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| always set | PadeOrder = 0, TdMin = 0 |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Maximum Delay (s) | TdMax | passes through |
Initial Output | u0 | passes through |
Caveat (shown to the user): the delay arrives on a port in seconds and the block INTERPOLATES between the two buffered samples either side of it, which is what the LPV block does. Simulink's TdMin, TdFixed, bufsize and FixedBuffer have no ICore counterpart: the transit line is sized from Maximum Delay (s) and the sampling time rather than from a buffer length, and a delay below zero is clamped rather than floored at a configured minimum
Catalog contract: src/ICoreSDK/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The lists agree. check_block_descriptions.py finds no disagreement between the description's Ports, Parameters, Code export and Simulink bridge lists and the code's.
The verdict above is
tools/docs/check_block_descriptions.py(P7.1), which compares LISTS. It cannot read a sentence: "stateless" on a block with a state, an initial-value semantic the recursion does not implement, a "not synthesizable" caveat the HDL banner contradicts. That is the agent audit (P7.3) on BLOCK_DESCRIPTION_AUDIT.md, and this tool's green is not a substitute for one.
File banner (developer view)#
The top comment of the block's .cpp — the maths, the realization and the export strategy, addressed to whoever changes it. It must not contradict the description above (P7.5).
Varying Delay block — y(t) = u(t - Td(t)), INTERPOLATED between the two samples either side The Linear Parameter Varying delay: cstblocks/Linear Parameter Varying/Varying Delay.
y(t) = u(t - Td(t))
⚠ THE INTERPOLATION IS THE WHOLE BLOCK, and it is why this is not a second catalog entry on
Control_Systems/Continues/Variable_Time_Delay. That block is the right semantic family and is already bridged to simulink/Continuous/Variable Time Delay, but its own description states that it ROUNDS the delay to whole samples -- a deliberate, documented approximation. This one blends. Folding the path onto it would assert a mapping that computes something measurably different, which is the one thing a catalog entry must never do.Implementation: the same ring buffer of capacity+1 past values, pre-filled with the configured initial output, read through TWO slots instead of one. buffer[head] = u (the current sample) ticks = clamp(Td / dt, 0, capacity) k0 = clamp(floor(ticks), 0, capacity - 1) frac = ticks - k0 in [0, 1] a = buffer[(head - k0) mod N] the NEWER of the two b = buffer[(head - k0 - 1) mod N] the OLDER y = a + frac * (b - a) head = (head + 1) mod N k0 = 0, frac = 0 is direct feedthrough, unchanged. k0 is capped at capacity-1 rather than capacity so that k0+1 is always a valid slot; at the maximum delay frac is then 1, which reads the oldest slot exactly, so the cap costs nothing at the boundary.
Discrete by nature: the line advances one slot per SAMPLE, so dt is the block's own rate. The interpolation is what lets a delay BETWEEN two samples still mean something at that rate.
⚠ PARITY CANNOT TEST THE INTERPOLATION, and must not try. The harness drives both sides from
From Workspacewith Interpolate 'off', i.e. a piecewise-constant input, so Simulink returns a held value while this block blends two distinct stored samples: they disagree BY CONSTRUCTION on any fractional delay. The parity testbench therefore uses delays that are whole multiples of the step, which is exactly where the two agree, and says so in its header -- the same resolution parity_test_Variable_Time_Delay.m already uses. The interpolation is certified by EXPORT VERIFICATION, which compares ICore against ICore and drives the delay port freely. That split is the one Variable_Transport_Delay's rig comment states for the same reason.Code export: all ten targets.
Sample results#
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | 0 … 0 |
ramp | Ramp: slope 1 from t = 0 | 0 … 0 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -1 … 0.9974 |
table | Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample | -2 … 3 |
Plotted: step — Step: 0 -> 1 at t = 1 s
Category dynamic · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Linear_Parameter_Varying__Varying_Delay.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).