Variable Time Delay — Control Systems/Continues
Control_Systems/Continues/Variable_Time_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.
Variable Time Delay
Control Systems / Continues
Delays the input by an amount that is itself a signal, applied as of now:
y(t) = u(t − d(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 and rounded to a whole number of samples, so a delay of zero is direct feedthrough.
This is the "variable time delay" reading of a moving delay. Its sibling, Variable Transport Delay, takes the same port to mean a transit rate and integrates it instead; the two agree exactly while the delay is constant and diverge as soon as it moves. Pick this block when the delay is simply "how stale the signal is right now", and that one when you are modelling material carried down a pipe at a varying speed.
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 resolution the delay is rounded to, and the unit the maximum delay is counted in, so it is part of the arithmetic and not merely a schedule.
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 indexes it with the rounded delay exactly as the simulation does. 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 rounds the same way the software targets do.
A zero delay 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. 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. A requested delay sitting within that of a half-sample boundary can round to a neighbouring sample count there but not on the software targets. That is inherent to carrying a time in fixed point, not a defect of the generated core; keep the delay away from exact half-sample values if it matters.
Simulink bridge
Import and export, mapped to simulink/Continuous/Variable Time Delay.
"Maximum Delay (s)" to MaximumDelay, "Initial Output" to
InitialOutput. The block always implies
VariableDelayType = "Variable time delay" – that parameter is
the only thing distinguishing this Simulink block from Variable Transport Delay,
which shares its BlockType – and PadeOrder = 0,
since the delay is realized as a true transit line and never as a
Padé approximation. A Simulink block carrying either at a different value
is reported on import rather than silently accepted.
This block has no SampleTime parameter in Simulink –
it is a continuous block there – so "Sampling Time (s)" stays on the ICore
side and does not cross.
Simulink's block is continuous and interpolates between stored points, while this one rounds to whole samples. The two agree exactly when the delay is a whole multiple of the step size, and differ by up to half a sample when it is not.
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.
- The delay is rounded to whole samples, so sub-sample delay is not interpolated. Shorten the sampling time for finer resolution.
- 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/Continues/Variable_Time_Delay |
| family | Control_Systems/Continues |
| solver environment class | ICoreBlock_0_Control_Systems_1_Continues_2_Variable_Time_Delay |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Continues/Variable_Time_Delay/ICoreBlock_0_Control_Systems_1_Continues_2_Variable_Time_Delay.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Continues/Variable_Time_Delay/ICoreBlock_0_Control_Systems_1_Continues_2_Variable_Time_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 | MaximumDelay |
Initial Output | 0 | InitialOutput |
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 | simulink/Continuous/Variable Time Delay |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| always set | VariableDelayType = Variable time delay, PadeOrder = 0 |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Maximum Delay (s) | MaximumDelay | passes through |
Initial Output | InitialOutput | passes through |
Caveat (shown to the user): Simulink's Variable Time Delay is continuous and interpolates between buffered points; this block rounds the delay to whole samples. The two agree exactly when the delay is a whole multiple of the step size. It shares its BlockType with Variable Transport Delay, so VariableDelayType is pinned here to keep the two apart in both directions
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).
Variable Time Delay block — y(t) = u(t - d(t)), the delay applied NOW The signal-domain counterpart of simulink/Continuous/Variable Time Delay, which is the VariableTransportDelay block with VariableDelayType = "Variable time delay".
y(t) = u(t - d(t))
The delay arrives on its own port in SECONDS and is applied AS OF NOW: whatever d reads at time t is how far back this tick reaches. That is the whole distinction from the sibling Variable Transport Delay block, which treats d as a transit RATE and integrates it -- see that block's header. The two agree exactly whenever d is constant, and diverge as soon as it moves, which is why they are two blocks rather than one with a mode.
RELATIONSHIP TO Entity Transport Delay. That block realizes the same arithmetic, and its description points here: it is deliberately Support::None because Simulink's Entity Transport Delay is a SimEvents block over entities rather than signals. This block is the one that actually crosses the bridge, and it states its bound the way Simulink does -- "Maximum Delay" in SECONDS, rather than a ring-buffer depth in samples.
Implementation: a ring buffer of capacity+1 past values, all pre-filled with the configured initial output so a delay reaching past the start of the run reads that rather than a zero that was never sampled. buffer[head] = u (the current sample) k = clamp(round(d / dt), 0, capacity) y = buffer[(head - k + capacity + 1) mod (capacity + 1)] head = (head + 1) mod (capacity + 1) k = 0 is direct feedthrough, which is what a zero delay should be.
Discrete by nature: the line advances one slot per SAMPLE, so dt is the block's own rate.
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.9996 |
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__Continues__Variable_Time_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).