Shift Arithmetic — Control Systems/Logic And Bit Operations
Control_Systems/Logic_And_Bit_Operations/Shift_Arithmetic · 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.
Shift Arithmetic
Control Systems / Logic And Bit Operations
Shifts the bits and the binary point of its input, which on a real signal is one scaling by a power of two: y = u · 2e, with the exponent e = B + d·A – A the Bit Shift Number, B the Binary Point Shift Number and d equal to +1 going left and −1 going right. The scaling is applied entry by entry, so a matrix signal is treated element for element and the signal's size is unchanged.
Ports
- Input – the signal u to be shifted, of any size [m,n].
- Output – y, of the SAME size [m,n] as the input.
Parameters
- Bit Shift Number – A, the number of bit positions to shift, as a whole-number scalar. Defaults to 8, as in Simulink. Its sign follows the direction below; a NEGATIVE value is accepted only in the bidirectional direction, where it means a shift the other way.
- Binary Point Shift Number – B, the number of places to move the binary point, as a whole-number scalar. Defaults to 0, as in Simulink. It always adds to the exponent, whichever direction is selected – moving the binary point left multiplies the value by two per place, and that does not change with the bit shift's direction.
- Bit Shift Direction – which way A counts. This selects the sign of
one term rather than retuning it.
- Left – e = B + A. A left shift multiplies.
- Right – e = B − A. A right shift divides.
- Bidirectional – the default, as in Simulink, and identical to Right except that A may be negative, which shifts left instead.
- 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. All three choices are resolved at export time into the single scale 2e, which is inlined as a literal rather than exposed as a tunable parameter – the shift counts are structural, like Sum's signs. The three HDL targets are fully synthesizable, the scale being an ordinary Q16.16 multiply.
Simulink bridge
Import and export, mapped to simulink/Logic and Bit Operations/Shift
Arithmetic. "Bit Shift Number" to BitShiftNumber and "Binary Point Shift
Number" to BinPtShiftNumber as plain pass-through values; "Bit Shift
Direction" to BitShiftDirection, one option for one option (Left,
Right, Bidirectional), so that round trip is lossless.
BitShiftNumberSource is always written as Dialog: a shift count
arriving on a second input port is not offered here, and pinning the source is what keeps
the two sides comparing the same block. CheckOORBitShift is pinned
off and DiagnosticForOORShift to None – both
are Simulink diagnostics about shifting past the width of a fixed-point type, and this
block has no such type to shift past.
The Simulink block defines no SampleTime parameter, so
"Sampling Time (s)" does not cross – a block left at the inheriting
default loses nothing, and one given an explicit period is reported rather than
silently dropped.
Notes
- Algebraic, with no state: the output depends only on the current input.
- Linear, and unlike the rest of this family it carries a state space – y = D·u with D = 2e·I – so model reduction can absorb it into a neighbouring plant exactly as it absorbs a Gain.
- Every signal in this library is a real matrix, so there is no stored integer to shift
and no word length to shift past. That is why the block needs no word-length parameter
where Bitwise Operator does: a shift of a real value is a scaling, and it is exact
for any exponent. Simulink's own block behaves the same way when its input is a
double. - On the three HDL targets the scale must itself be representable in Q16.16, which holds for e between −16 and 15. Outside that window the exported fixed-point core carries a scale of zero or a saturated one; the software targets are unaffected.
- To scale by something that is not a power of two, use Gain.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Logic_And_Bit_Operations/Shift_Arithmetic |
| family | Control_Systems/Logic_And_Bit_Operations |
| solver environment class | ICoreBlock_0_Control_Systems_1_Logic_And_Bit_Operations_2_Shift_Arithmetic |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Logic_And_Bit_Operations/Shift_Arithmetic/ICoreBlock_0_Control_Systems_1_Logic_And_Bit_Operations_2_Shift_Arithmetic.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Logic_And_Bit_Operations/Shift_Arithmetic/ICoreBlock_0_Control_Systems_1_Logic_And_Bit_Operations_2_Shift_Arithmetic.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 |
|---|---|---|
Bit Shift Number | 8 | BitShiftNumber |
Binary Point Shift Number | 0 | BinPtShiftNumber |
Bit Shift Direction | Left (y = u * 2^(binary point + bits))%~%Right (y = u * 2… | BitShiftDirection |
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/Logic and Bit Operations/Shift Arithmetic |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| always set | BitShiftNumberSource = Dialog, CheckOORBitShift = off, DiagnosticForOORShift = None |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Bit Shift Number | BitShiftNumber | passes through |
Binary Point Shift Number | BinPtShiftNumber | passes through |
Bit Shift Direction | BitShiftDirection | Left (y = u * 2^(binary point + bits)) → Left, Right (y = u * 2^(binary point - bits)) → Right, Bidirectional (Right, and the bit shift may be negative) → Bidirectional |
Caveat (shown to the user): the three directions map 1:1 onto Simulink's BitShiftDirection values, so the choice is lossless in both directions; a shift count arriving on a PORT (BitShiftNumberSource = Input port) is not supported and is reported on import; the Simulink block has NO SampleTime parameter, so "Sampling Time (s)" does not cross
Catalog contract: src/ICoreBlocks/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).
Shift Arithmetic block -- a bit shift and a binary-point shift, on a REAL signal y = u * 2^e, applied entry by entry, with
e = binaryPointShift + d * bitShift, d = +1 for Left, -1 for Right
and Bidirectional behaving exactly as Right, which is what lets its shift number be NEGATIVE. The output keeps the input's size.
⚠ THE TWO KNOBS DO NOT BEHAVE THE SAME WAY, AND THE NAMES SUGGEST THEY DO. The BINARY POINT shift contributes +binPt whichever direction is selected; only the BIT shift follows the direction. Measured in R2026a against the real block driven with a
doubleinput of [5 12 217 128 3 255 64 1 0 7], six runs that pin the rule down between them:bit=2 binPt=0 Right -> u/4 e = -2 = 0 - 2 bit=0 binPt=2 Right -> u*4 e = +2 = 2 - 0 <- the binary point went the OTHER way to the bit shift bit=3 binPt=1 Right -> u/4 e = -2 = 1 - 3 bit=2 binPt=0 Left -> u*4 e = +2 = 0 + 2 bit=0 binPt=2 Left -> u*4 e = +2 = 2 + 0 <- and the SAME way here bit=3 binPt=1 Left -> u*16 e = +4 = 1 + 3
A reading that gave the binary point the direction as well would agree with all three Left rows and disagree with two of the three Right ones, which is why the table is written out rather than summarised.
⚠ AND SIMULINK'S BLOCK REALLY DOES TAKE A DOUBLE. Its three neighbours in this family -- Bitwise Operator, Bit Set, Bit Clear -- refuse one and need an integer type, so the natural assumption is that this one does too and that an ICore version would have to invent a word model. It does not: driven with a double the block answers the exact scaling above, with NO truncation anywhere (measured u = -5, bit=2, Right -> -1.25, not -2). So this block needs no word length, no signedness and no conditioning helper in its rig, and its parity testbench drives Simulink through a plain double path.
Code export: the exponent is resolved at export time and the scale 2^e is inlined as a literal, exactly as Sum inlines its signs -- it is structural, not something a user retunes on a deployed core. All ten targets.
HDL: fully synthesizable. 2^e is exactly representable in Q16.16 for e in [-16, 15], and the multiply is the same resize/shift idiom Gain uses. Outside that window the scale itself is not representable and the block says so -- see the description.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 |
|---|---|---|
| 0 | -2 | -0.007812 |
| 0.4 | 0.5 | 0.001953 |
| 0.8 | -2 | -0.007812 |
| 1.2 | 0.5 | 0.001953 |
| 1.6 | -2 | -0.007812 |
| 2 | 0.5 | 0.001953 |
| 2.4 | -2 | -0.007812 |
| 2.8 | 0.5 | 0.001953 |
| 3.2 | -2 | -0.007812 |
| 3.6 | 0.5 | 0.001953 |
| 4 | -2 | -0.007812 |
| 4.4 | 0.5 | 0.001953 |
| 4.8 | -2 | -0.007812 |
| 5.2 | 0.5 | 0.001953 |
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.003906 |
ramp | Ramp: slope 1 from t = 0 | 0 … 0.02305 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -0.003906 … 0.003905 |
step | Step: 0 -> 1 at t = 1 s | 0 … 0.003906 |
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 3c100aff6f27235305db4ad4d572f32e342718ad · produced by docsSample --out <folder> --blocks Shift_Arithmetic Bit_Set Bit_Clear Bitwise_Operator --steps 60 · data docs/generated/samples/Control_Systems__Logic_And_Bit_Operations__Shift_Arithmetic.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).