Polynomial — Control Systems/Base Blocks
Control_Systems/Base_Blocks/Polynomial · 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.
Polynomial
Control Systems / Base Blocks
Evaluates a polynomial at every entry of its input, entry by entry. The
coefficients are given in descending powers, so
[1 -2 0.5] is y = u² − 2u + 0.5.
Ports
- Input – the signal u, of any size [m,n]. The polynomial is applied to each entry independently; this is not a matrix polynomial.
- Output – the evaluated signal y, of the SAME size [m,n]. The block never reshapes a signal.
Parameters
- Polynomial Coefficients – a row vector in descending
powers, highest first, with the constant term last. Its length is the order plus
one, so
[1 0 0]is u²,[3 -1]is 3u − 1, and a single value is a constant. At least one coefficient is required; leading zeros are allowed and simply lower the effective order. - Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The coefficients are inlined into the generated arithmetic at export time rather than exposed as a tunable parameter: the number of them is what the emitted expression is shaped by, so changing one on the generated core would mean re-emitting it anyway.
Every target evaluates by Horner's rule – the nested form
((c₀u + c₁)u + c₂)u + c₃ – and not by
summing powers. The two are not the same computation in floating point, so this
is what keeps the ten targets agreeing with each other and with the block's own
simulation.
The three HDL targets are simulation-only. Horner needs nothing but
multiplies and adds, which the Q16.16 datapath has, but a polynomial multiplies
the signal by itself once per order and that format saturates at ±32768
while resolving only 1.5×10⁻⁵. Rather than ship a core that
silently overflows on a cubic, the generated HDL converts at the port boundary
and evaluates in real – correct in simulation, but not offered
as synthesizable.
Simulink bridge
Import and export, mapped to simulink/Math Operations/Polynomial.
"Polynomial Coefficients" to Coefs, passed through as the vector it
is – the descending-power convention is the same on both sides, so nothing
is reordered crossing over.
The Simulink block has no SampleTime parameter, so the
rate is not carried across: it stays on the ICore side, and a block
configured with an explicit positive rate reports that the rate did not
cross.
The two blocks' defaults differ, deliberately. Simulink's is a
six-coefficient thermocouple fit; this block defaults to [1 0 0],
which is u². Nothing is lost by that: the coefficients are always written
out explicitly on export, so a block that crosses carries its own values either
way.
Notes
- Algebraic, with no state: the output depends only on the current input.
- Deliberately carries no state space at any order. A polynomial of order two or more is not linear; a first-order one would be, but the order is a config the user can change at any time, and a state space that was valid for one setting and stale for the next is worse than none. Model reduction reports the block as unmergeable throughout.
- The polynomial is applied entry by entry. A matrix polynomial – one using matrix multiplication for the powers – is a different operation and is not what this block or Simulink's computes.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Base_Blocks/Polynomial |
| family | Control_Systems/Base_Blocks |
| solver environment class | ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Polynomial |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Base_Blocks/Polynomial/ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Polynomial.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Base_Blocks/Polynomial/ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Polynomial.h |
| default size on canvas | 90 × 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 |
|---|---|---|
Polynomial Coefficients | [1 0 0] | Coefs |
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/Math Operations/Polynomial |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Polynomial Coefficients | Coefs | passes through |
Caveat (shown to the user): the coefficients are in descending powers on both sides, so they cross unchanged; the two blocks' DEFAULTS differ - Simulink's is a six-coefficient thermocouple fit and this block's is [1 0 0] - which costs nothing, since the coefficients are always written out explicitly on export
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).
Polynomial -- a polynomial evaluated at every entry of the input The coefficients are in DESCENDING powers, exactly as MATLAB's polyval takes them, so [1 -2 0.5] is u^2 - 2u + 0.5. Measured against Simulink R2026a on [2 -1; 0.5 3] rather than assumed: its output and polyval's agree entry for entry, isequal true.
EVERY BACKEND USES HORNER'S RULE, and that is a correctness decision rather than a speed one. Nesting
((c0*u + c1)*u + c2)*u + c3
and summing c0*u^3 + c1*u^2 + c2*u + c3 are not the same computation in floating point. The reference this suite compares against is the C++ compute_h below, which nests; a target that summed powers instead would differ by a rounding error that grows with the order and with |u|, and on the HDL targets - where the quantum is 1.5e-5 rather than an ULP - it would not stay small. hornerExpr() writes the nest once and every target renders it.
HDL IS SIMULATION-ONLY here. Horner is only multiplies and adds, which the Q16.16 datapath can do - but a polynomial of order n multiplies the signal by itself n times, and Q16.16 saturates at +/-32768 while carrying only 1.5e-5 of resolution. A cubic on an input of a few units is already pushing both ends of that, so the generated cores convert at the port boundary and evaluate in
real, which is correct in simulation but not offered as synthesizable. Reference for the same choice: Recursive IIR, Variable Transport Delay.Algebraic and stateless. No state space -- see the header for why, including why the first-order case does not get one either.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 |
|---|---|---|
| 0 | -2 | 4 |
| 0.4 | 0.5 | 0.25 |
| 0.8 | -2 | 4 |
| 1.2 | 0.5 | 0.25 |
| 1.6 | -2 | 4 |
| 2 | 0.5 | 0.25 |
| 2.4 | -2 | 4 |
| 2.8 | 0.5 | 0.25 |
| 3.2 | -2 | 4 |
| 3.6 | 0.5 | 0.25 |
| 4 | -2 | 4 |
| 4.4 | 0.5 | 0.25 |
| 4.8 | -2 | 4 |
| 5.2 | 0.5 | 0.25 |
Every 4th of 60 samples, from the table stimulus.
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 … 33.64 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | 0 … 1 |
step | Step: 0 -> 1 at t = 1 s | 0 … 1 |
Plotted: table — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample
Category static · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Base_Blocks__Polynomial.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).