Prelookup — Control Systems/Lookup Tables
Control_Systems/Lookup_Tables/Prelookup · 1 input / 2 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.
Prelookup
Control Systems / Lookup Tables
Finds where the input sits on a breakpoint axis and publishes the position as a pair, without consulting any table: the index k of the interval the input falls in, and the fraction f of the way across that interval it sits, so that u ≈ bp[k] + f·(bp[k+1] − bp[k]).
Splitting the search from the table is the point of the block: several tables sharing one axis do the search once here and feed Interpolation Using Prelookup, instead of each repeating it.
Ports
- Input – the value u to locate, of any size [m,n]. Each entry is searched independently.
- Output k – the interval index, of the SAME size [m,n]. A whole number carried as a double, counted from zero, and never larger than n−2 – see the note below.
- Output f – the fraction, same size again. Inside the table it lies in [0,1]; outside it, under Linear extrapolation, it deliberately does not.
Parameters
- Breakpoints – the axis, as a row or column vector; both spell the same list. It must hold at least two strictly increasing values: a repeated breakpoint is a zero-width interval whose fraction is a division by zero, and a decreasing one describes no axis at all.
- Extrapolation Method – what to report for an input outside the
axis.
- Linear – the fraction continues past the end interval, so it goes negative below the first breakpoint and above 1 past the last. That is what lets a downstream interpolator extrapolate.
- Clip – the fraction is held in [0,1], pinning an out-of-range input to the nearer end of the axis.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
The index stops at n−2
The last breakpoint reports k = n−2 and f = 1, not k = n−1 and f = 0. Both name the same point, but only the first leaves an interval [k, k+1] for an interpolator to stand in – a k of n−1 would send it off the end of the table. This is Simulink's behaviour (verified against the R2026a block with breakpoints [−2 −0.5 0.3 1.4 2.6], where an input of 2.6 returns index 3, fraction 1) rather than a choice made here, and it is the difference that catches people comparing the two.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The axis is baked into the arithmetic at export time rather than exposed as a tunable parameter, and it has to be: the number of breakpoints decides how many branches the generated code has, so the axis and the structure of the code cannot be separated. The search is emitted as a chain of comparisons, which is the one shape all ten targets agree on.
The three HDL targets are not simulation-only. No divider is emitted: each interval's width is known at export time, so the fraction is a multiply by a constant reciprocal. The HDL caveat is range rather than accuracy – a signal is carried in Q16.16 there, so a breakpoint outside ±32767 cannot be represented.
Simulink bridge
Import and export, mapped to simulink/Lookup Tables/Prelookup.
"Breakpoints" to BreakpointsData and "Extrapolation Method" to
ExtrapMethod – the two values are Simulink's own strings, so that
mapping is 1:1 and lossless both ways. The block always writes
OutputSelection = Index and fraction, which is what having two
output ports means; Simulink's other two selections (index only, and the pair as a
bus) have no counterpart here. "Sampling Time (s)" goes to SampleTime,
as on every block.
Simulink's index output is an integer type (uint32 by default) while
every ICore signal is a double. The values agree exactly – the index is a
whole number on both sides – but a Simulink model reading the exported index
alongside doubles may need a Data Type Conversion, which is why the parity testbench
inserts one.
Notes
- Algebraic, with no state.
- Elementwise: both outputs carry the input's size, and each entry is searched on its own.
- Not linear, and so deliberately carries no state space – model reduction reports it as unmergeable rather than absorbing a chain of comparisons.
- See Interpolation Using Prelookup for the block that consumes this pair, and 1-D Lookup Table for the two steps done together in one block.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Lookup_Tables/Prelookup |
| family | Control_Systems/Lookup_Tables |
| solver environment class | ICoreBlock_0_Control_Systems_1_Lookup_Tables_2_Prelookup |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Lookup_Tables/Prelookup/ICoreBlock_0_Control_Systems_1_Lookup_Tables_2_Prelookup.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Lookup_Tables/Prelookup/ICoreBlock_0_Control_Systems_1_Lookup_Tables_2_Prelookup.h |
| default size on canvas | 90 × 70 px |
| ports at insert | 1 in, 2 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 | k |
| 3 | out | ICoreDouble | f |
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 |
|---|---|---|
Breakpoints | [10 20 30 40 50 60 70 80 90 100 110] | BreakpointsData |
Extrapolation Method | LUT::extrapComboSpec() | ExtrapMethod |
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/Lookup Tables/Prelookup |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
| always set | OutputSelection = Index and fraction |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Breakpoints | BreakpointsData | passes through |
Extrapolation Method | ExtrapMethod | Clip → Clip, Linear → Linear |
Caveat (shown to the user): Simulink's index output is an integer type (uint32 by default) and every ICore signal is a double; the values agree exactly, but a Simulink model mixing the exported index with doubles may need a Data Type Conversion. Simulink's other two output selections - index only, and the pair as a bus - have no counterpart here, so the block always writes OutputSelection = 'Index and fraction'
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).
Prelookup block — where does the input sit on this axis? k = the interval the input falls in f = how far across that interval it sits
Algebraic and stateless, elementwise over the input's size. No state space (see header).
THE SEARCH IS EMITTED AS A CHAIN OF COMPARISONS, one per breakpoint, which is the one shape all ten targets spell the same way - the three HDL backends and PLC Structured Text have no runtime-indexable constant array to binary-search. So the breakpoint COUNT decides how many branches the generated code has, and the breakpoints cannot be tunable parameters: they are part of the code's structure, not values it reads.
NO DIVIDER IS EMITTED. The fraction is (u - bp[i]) / (bp[i+1] - bp[i]) with a denominator that is known at export time, so every target multiplies by the reciprocal constant instead. That is what keeps the three HDL targets synthesizable rather than simulation-only.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 | out ICoreDouble-Out-1 |
|---|---|---|---|
| 0 | -2 | 0 | -1.2 |
| 0.4 | 0.5 | 0 | -0.95 |
| 0.8 | -2 | 0 | -1.2 |
| 1.2 | 0.5 | 0 | -0.95 |
| 1.6 | -2 | 0 | -1.2 |
| 2 | 0.5 | 0 | -0.95 |
| 2.4 | -2 | 0 | -1.2 |
| 2.8 | 0.5 | 0 | -0.95 |
| 3.2 | -2 | 0 | -1.2 |
| 3.6 | 0.5 | 0 | -0.95 |
| 4 | -2 | 0 | -1.2 |
| 4.4 | 0.5 | 0 | -0.95 |
| 4.8 | -2 | 0 | -1.2 |
| 5.2 | 0.5 | 0 | -0.95 |
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 … 0 |
ramp | Ramp: slope 1 from t = 0 | 0 … 0 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | 0 … 0 |
step | Step: 0 -> 1 at t = 1 s | 0 … 0 |
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__Lookup_Tables__Prelookup.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).