Bias — Control Systems/Base Blocks
Control_Systems/Base_Blocks/Bias · 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.
Bias
Control Systems / Base Blocks
Adds a constant offset to its input: y = u + b, applied entry by entry. The offset is a block parameter, not a signal, so the block shifts a signal without needing a source wired into a Sum.
Ports
- Input – the signal u, of any size [m,n].
- Output – the shifted signal y. It takes the input's size [m,n] whenever the bias is a scalar or the same size as the input; a scalar input against a matrix bias expands the other way round and the output takes the bias's size, which is the only case in which this block changes a signal's dimensions.
Parameters
- Bias – the offset b. A scalar is added to every entry
(Simulink's scalar expansion); a matrix must be the size of the input signal, or
meet a scalar input, and is then added entry for entry. Defaults to
0, which passes the signal through unchanged. - 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 bias is exposed as a tunable parameter on the generated core –
params in the software targets, a parameter port on the three HDL
cores, a VAR_INPUT on the function block in Structured Text –
so it can be retuned on the deployed core without re-exporting. It is not
inlined into the arithmetic.
The three HDL targets carry the addition in Q16.16 fixed point and are fully synthesizable: adding two fixed-point values of the same format needs no shift, no divider and no function call. Note that the bias crosses into the core as a Q16.16 parameter, so an offset finer than one quantum (1.5×10-5) is not representable there.
Simulink bridge
Import and export, mapped to simulink/Math Operations/Bias, with
"Bias" going to the Bias parameter as a pass-through value.
The rate does NOT cross: Simulink's Bias block defines no
SampleTime parameter at all, so the entry sets
hasSampleTimeParam = false and "Sampling Time (s)" stays on the
ICore side. Writing the parameter anyway would be a hard set_param
error in MATLAB rather than a warning, aborting the whole generated script.
Simulink's SaturateOnIntegerOverflow has no counterpart either: it
governs integer and fixed-point data types, and ICore signals are doubles.
Notes
- Algebraic, with no state: the output depends only on the current input.
- Affine, not linear, so the block deliberately carries no state space. y = u + b does not pass through the origin, and A/B/C/D has nowhere to hold the constant – model reduction reports the block as unmergeable rather than absorbing an offset it cannot represent. A Bias of exactly zero is not treated as a special case: it would be a state space that stopped existing the moment the user typed a number.
- To add two signals rather than a signal and a constant, use Sum.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Base_Blocks/Bias |
| family | Control_Systems/Base_Blocks |
| solver environment class | ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Bias |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Base_Blocks/Bias/ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Bias.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Base_Blocks/Bias/ICoreBlock_0_Control_Systems_1_Base_Blocks_2_Bias.h |
| default size on canvas | 70 × 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 |
|---|---|---|
Bias | 0 | Bias |
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/Bias |
| 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 |
|---|---|---|
Bias | Bias | passes through |
Caveat (shown to the user): the rate does not cross: Simulink's Bias block defines no SampleTime parameter, so "Sampling Time (s)" stays on the ICore side
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).
Bias block -- add a constant offset y = u + b, entry by entry, with Simulink's scalar expansion in both directions: a scalar bias broadcasts over any signal, and a scalar signal broadcasts over a matrix bias. Any other pairing must agree entry for entry. Algebraic and stateless, no state space (see the header -- the block is AFFINE, not linear, and that is a different reason from Abs's).
The bias is a TUNABLE parameter on every generated core rather than a constant inlined into the arithmetic: an offset is exactly the kind of value a user retunes on deployed hardware (a sensor zero, a set-point trim) without wanting to re-export, which is the same call Gain makes for its gain matrix and the opposite of the one Sum makes for its signs.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 |
|---|---|---|
| 0 | -2 | -2 |
| 0.4 | 0.5 | 0.5 |
| 0.8 | -2 | -2 |
| 1.2 | 0.5 | 0.5 |
| 1.6 | -2 | -2 |
| 2 | 0.5 | 0.5 |
| 2.4 | -2 | -2 |
| 2.8 | 0.5 | 0.5 |
| 3.2 | -2 | -2 |
| 3.6 | 0.5 | 0.5 |
| 4 | -2 | -2 |
| 4.4 | 0.5 | 0.5 |
| 4.8 | -2 | -2 |
| 5.2 | 0.5 | 0.5 |
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 … 5.8 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -1 … 0.9996 |
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__Bias.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).