Transport Delay — Control Systems/Continues
Control_Systems/Continues/Transport_Delay · 1 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.
Transport Delay
Control Systems / Continues
Holds the input back by a fixed transit time and replays it unchanged – a pipeline, a conveyor of constant speed, a propagation lag:
y(t) = u(t − T)
The delay T is a parameter, not a signal, so it is fixed for the whole run. It is rounded to a whole number of samples, and while the delay still reaches back past the start of the run the block emits its configured Initial Output.
Ports
- Input – the transported signal, of any size [m,n]. Every entry is delayed by the same T; there is no cross-coupling between entries.
- Output – the delayed signal, the SAME size [m,n] as the input.
Parameters
- Delay Time (s) – scalar, the transit time in seconds. Defaults to 1, matching Simulink. It is rounded to whole samples, so at the default 0.01 s rate a delay of 0.07 is seven samples exactly. Zero or less makes the block a pass-through. The buffer is sized from this value, so a longer delay costs proportionally more memory and nothing else.
- Initial Output – scalar, what the block emits for the first T seconds, before anything sent at t = 0 has arrived. 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, 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 transit line as its state, pre-filled with the initial output.
Because the delay is a parameter rather than a port, it is resolved to
a whole sample count at export time and baked into the generated code: the
buffer depth and the read offset are both constants, and no target computes an
address at run time. The three HDL backends therefore emit a plain shift
register and never need the fixed-point fx_to_int conversion the
variable-delay blocks rely on, which also means none of the fixed-point rounding
caveats that come with a delay arriving on a port apply here. Retuning the delay
after export means re-exporting.
Simulink bridge
Import and export, mapped to simulink/Continuous/Transport Delay.
"Delay Time (s)" to DelayTime, "Initial Output" to
InitialOutput. The block always implies PadeOrder = 0:
it realizes the delay as a true transit line, never as a Padé rational
approximation, so a Simulink block carrying a non-zero order is reported on
import rather than silently accepted as equivalent.
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 BufferSize has no counterpart
either: ICore sizes the line from the delay itself, so it cannot be set too
small.
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: T/dt + 1 past values of the input.
- 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 transit 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^(−sT), which no finite A/B/C/D expresses. Model reduction therefore refuses it, which is correct rather than a limitation – a delay cannot be merged into a rational plant.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Continues/Transport_Delay |
| family | Control_Systems/Continues |
| solver environment class | ICoreBlock_0_Control_Systems_1_Continues_2_Transport_Delay |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Continues/Transport_Delay/ICoreBlock_0_Control_Systems_1_Continues_2_Transport_Delay.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Continues/Transport_Delay/ICoreBlock_0_Control_Systems_1_Continues_2_Transport_Delay.h |
| default size on canvas | 100 × 70 px |
| ports at insert | 1 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 | — |
| 2 | 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 |
|---|---|---|
Delay Time (s) | 1 | DelayTime |
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/Transport Delay |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| always set | PadeOrder = 0 |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Delay Time (s) | DelayTime | passes through |
Initial Output | InitialOutput | passes through |
Caveat (shown to the user): Simulink's Transport 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. Simulink's BufferSize has no counterpart - ICore sizes the transit line from the delay itself, so it cannot be set too small
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).
Transport Delay block — y(t) = u(t - T), a FIXED transit time The signal-domain counterpart of simulink/Continuous/Transport Delay, and the block Entity Transport Delay's description points at: same transit line, but the delay is a CONFIG rather than a port.
y(t) = u(t - T)
That one difference is what makes this block much cheaper than the variable-delay pair. T is known when the model is built, so:
- the ring buffer is sized to exactly k + 1 slots, k = round(T / dt) -- there is no
"capacity" to configure and no way to ask for more delay than the buffer holds;
- the read offset is a CONSTANT, so no target has to derive an address at run time. The
three HDL backends emit a plain shift register and never touch fx_to_int, which is the whole reason the variable blocks are more expensive in hardware.
Implementation, matching Entity Transport Delay slot for slot so the two read side by side: buffer[head] = u (the current sample) y = buffer[(head - k + N) mod N] N = k + 1 head = (head + 1) mod N With N = k + 1 the read slot reduces to (head + 1) mod N -- the oldest entry, i.e. the one about to be overwritten. The general form is kept for readability.
k = 0 is direct feedthrough, and every target special-cases it to a plain copy rather than going through a one-slot buffer: on the HDL targets the buffer write is REGISTERED, so reading back the slot just written would return the previous lap's contents (the rule that cost First Order Hold a 192% residual). For k >= 1 the read slot is never the written slot, so those read correctly from the pre-clock register file.
Discrete by nature: the line advances one slot per SAMPLE, so dt is the block's own rate, and T is rounded to that resolution.
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 … 1 |
ramp | Ramp: slope 1 from t = 0 | 0 … 4.8 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -0.9962 … 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__Transport_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).