Generated reference › Prelookup — Control Systems/Lookup Tables
kind: generated#block#control-systems-lookup-tables

Prelookup — Control Systems/Lookup Tables

k,f

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#

FactValue
registered typeControl_Systems/Lookup_Tables/Prelookup
familyControl_Systems/Lookup_Tables
solver environment classICoreBlock_0_Control_Systems_1_Lookup_Tables_2_Prelookup
sourcesrc/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Lookup_Tables/Prelookup/ICoreBlock_0_Control_Systems_1_Lookup_Tables_2_Prelookup.cpp
headersrc/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Lookup_Tables/Prelookup/ICoreBlock_0_Control_Systems_1_Lookup_Tables_2_Prelookup.h
default size on canvas90 × 70 px
ports at insert1 in, 2 out
code generators implementedPython, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text

Ports#

#DirectionSignal typeDescription label
1inICoreDouble
2outICoreDoublek
3outICoreDoublef

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 variableDefaultSimulink parameter
Breakpoints[10 20 30 40 50 60 70 80 90 100 110]BreakpointsData
Extrapolation MethodLUT::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.

supportSupport::Both
Simulink pathsimulink/Lookup Tables/Prelookup
port-count rulePortsParam::None
SampleTime parameteryes
always setOutputSelection = Index and fraction
ICore configSimulink parameterValue translation
BreakpointsBreakpointsDatapasses through
Extrapolation MethodExtrapMethodClipClip, LinearLinear

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#

Prelookup — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per samplePrelookup — Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample-202012345t (s)in ICoreDouble-Out-0out ICoreDouble-Out-0out ICoreDouble-Out-1
tin ICoreDouble-Out-0out ICoreDouble-Out-0out ICoreDouble-Out-1
0-20-1.2
0.40.50-0.95
0.8-20-1.2
1.20.50-0.95
1.6-20-1.2
20.50-0.95
2.4-20-1.2
2.80.50-0.95
3.2-20-1.2
3.60.50-0.95
4-20-1.2
4.40.50-0.95
4.8-20-1.2
5.20.50-0.95

Every 4th of 60 samples, from the table stimulus.

The same rig also ran:

StimulusWhat it isOutput range
impulseImpulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair)0 … 0
rampRamp: slope 1 from t = 00 … 0
sineSine Wave: amplitude 1, 2 rad/s, no phase, no bias0 … 0
stepStep: 0 -> 1 at t = 1 s0 … 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).