First Order Hold — Control Systems/Continues
Control_Systems/Continues/First_Order_Hold · 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.
First Order Hold
Control Systems / Continues
Reconstructs a sampled signal as a piecewise-linear one. Where a zero-order hold repeats each sample as a staircase, a first-order hold joins successive samples with straight lines, so the output is continuous and its slope is the input's average rate of change over each interval.
With Tu the update period, tₖ = k·Tu the update instants and u[k] the input latched there, for t in (tₖ, tₖ₊₁]:
y(t) = u[k−1] + (u[k] − u[k−1]) · (t − tₖ) / Tu
The ramp therefore arrives at u[k] exactly at tₖ₊₁: the reconstruction lags the input by one update period, which is the cost of interpolating between two known samples rather than extrapolating past the latest one. Applied entry by entry.
Ports
- Input – the signal u to reconstruct, of any size [m,n]. It is latched once per update period; what it does between latches is not seen.
- Output – the piecewise-linear reconstruction y, of the SAME size [m,n]. The block never reshapes a signal.
Parameters
- Initial Output – scalar, the value produced at t = 0 alone, before any ramp exists. Defaults to 0, as in Simulink. From the first evaluation onward the output follows the samples, so this seeds exactly one point.
- Update Period (s) – how often the input is latched, and hence the length of one ramp. Defaults to 1. It must be a positive whole multiple of "Sampling Time (s)"; anything else is reported rather than rounded, because a mis-placed update instant is a visibly different signal and not a small error.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period. Here it is how finely the ramp is drawn, which is a different thing from the update period above: with the two equal the block is evaluated only at its own update instants and degenerates to a one-period delay, so a genuine first-order hold needs a sampling time shorter than its update period.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The interval is carried as an integer tick count, M = Update Period / Sampling Time, baked in at export time, and the ramp fraction is the integer remainder over M – so a generated core needs no clock, no division by a time step and no floating-point comparison against an update instant. The exported state is the two samples being interpolated, one pair per entry, plus the counter.
Simulink bridge
Import and export, mapped to simulink/Continuous/First Order Hold
(BlockType FirstOrderHold – note this is a
different block from the Discrete library's masked "First-Order Hold").
"Initial Output" pairs with InitialOutput.
OutputAlgorithm is always written as
Slow (Avoid Overshoot), the interpolating algorithm implemented
here; Simulink's other choice, Fast (Minimize Error), is
reported on import rather than silently accepted.
"Update Period (s)" does NOT cross, and it has no Simulink counterpart
to cross to: the Simulink block takes its update rate from the sample time of
the signal driving it, which is a property of the source rather than of the
block. Exporting a model therefore carries the period on the ICore side only, and
the driving signal in Simulink must be given that same sample time for the two to
agree. "Sampling Time (s)" does NOT cross either: this Simulink block
defines no SampleTime parameter. The solver-tuning parameters
ErrorTolerance and AllowContinuousInput have no ICore
counterpart and are left at their Simulink defaults.
Notes
- Stateful: two samples per entry, plus one tick counter for the block.
- Discrete by nature – the block latches and ramps on its own tick, so it always runs at its own rate rather than being pushed through a continuous solver's stages.
- One update period of lag. This is inherent to the interpolating algorithm, not an implementation artifact: the ramp across an interval cannot be drawn until the sample it ends on has arrived.
- Not linear in the state-space sense, and so deliberately carries no state space: the block is a resampler, and its input/output relation depends on where each evaluation falls inside the update interval rather than on a fixed A/B/C/D.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Continues/First_Order_Hold |
| family | Control_Systems/Continues |
| solver environment class | ICoreBlock_0_Control_Systems_1_Continues_2_First_Order_Hold |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Continues/First_Order_Hold/ICoreBlock_0_Control_Systems_1_Continues_2_First_Order_Hold.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Continues/First_Order_Hold/ICoreBlock_0_Control_Systems_1_Continues_2_First_Order_Hold.h |
| default size on canvas | 80 × 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 |
|---|---|---|
Initial Output | 0 | InitialOutput |
Update Period (s) | 1 | not crossed |
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/First Order Hold |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| deliberately not crossed | Update Period (s) |
| always set | OutputAlgorithm = Slow (Avoid Overshoot) |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Initial Output | InitialOutput | passes through |
Caveat (shown to the user): "Update Period (s)" does not cross: the Simulink block takes its update rate from the sample time of the signal driving it, so the driving signal there must be given the same period for the two sides to agree. "Sampling Time (s)" does not cross either - this Simulink block defines no SampleTime parameter
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).
First Order Hold block — piecewise-LINEAR reconstruction of a sampled signal A zero-order hold repeats each sample as a staircase. A FIRST-order hold joins them with straight lines instead: over each update interval the output ramps from the PREVIOUS sample to the CURRENT one, so the reconstruction is continuous and its slope is the sampled signal's average rate over that interval.
With Tu the update period, t_k = k*Tu the update instants and u[k] the input latched there, for t in (t_k, t_{k+1}]: y(t) = u[k-1] + (u[k] - u[k-1]) * (t - t_k) / Tu so the ramp ARRIVES at u[k] exactly at t_{k+1}: the reconstruction lags the input by one update period, which is the price of interpolating rather than extrapolating. u[-1] is taken to be u[0], which makes the first interval flat, and the output at t = 0 alone is the configured "Initial Output".
Verified sample-for-sample against Simulink R2026a's simulink/Continuous/First Order Hold (BlockType FirstOrderHold) with Tu = 0.03 recorded at 0.01: u = [1, 2, -1, 3, ...] gives y = 0 (t=0), then 1, 1, 1, 1.3333, 1.6667, 2, 1, 0, -1, 0.3333, ... -- flat over the first interval, then ramps arriving exactly on the sample values at the update instants.
TWO RATES, AND WHY THE BLOCK NEEDS BOTH. "Update Period (s)" is how often the input is latched -- the length of one ramp. "Sampling Time (s)" is how often the block is EVALUATED, and hence how finely the ramp is drawn. They are genuinely different things here: a block evaluated only at its own update instants could never emit anything but u[k-1], which is a unit delay, not a first-order hold. Simulink needs no such parameter because it takes the update rate from the driving signal's sample time; ICore has no equivalent notion, so the period is configured (see the bridge note in the description).
The interval is counted in TICKS, not measured against a clock: M = round(Tu/dt) ticks per update, k = n/M, and the ramp fraction is (n mod M)/M. Exact by construction, where t/Tu would land a hair either side of an integer and latch a sample one step early or late -- which on this block is not a rounding error but a visibly different signal.
Stateful: the two samples being interpolated plus the tick counter. Held in members rather than the solver state vector -- nothing here is integrated. Discrete by nature.
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 … 4.8 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -0.7568 … 0.9894 |
table | Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample | -2 … 2 |
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__First_Order_Hold.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).