Matrix Multiply — Control Systems/Matrix Operations
Control_Systems/Matrix_Operations/Matrix_Multiply · 2 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.
Matrix Multiply
Control Systems / Matrix Operations
Multiplies two live signals as matrices: y = u1·u2. Entry (i,j) of the output is the inner product of row i of the first input with column j of the second, so [m,n] × [n,p] gives [m,p].
Ports
- u1 – the LEFT operand, of any size [m,n].
- u2 – the RIGHT operand. Its ROW count must equal the left operand's COLUMN count; anything else is reported when the model is built. Matrix multiplication does not commute, so the two ports are not interchangeable.
- Output – [m,p]: the left operand's rows and the right operand's columns. A [1,n] × [n,1] pair therefore collapses to a scalar, and an [n,1] × [1,n] pair expands to the [n,n] outer product.
Parameters
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
There is nothing else to set: the operation and the operand count are both fixed. Product is the block that offers the choice between the matrix and element-wise forms and admits longer chains.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. Nothing is tunable on the generated core: both operands are signals, and the dimensions are resolved at export time.
The three HDL targets are fully synthesizable. Each entry is a sum of
products in the Q16.16 datapath, and the accumulator is not the same width in
all three. Verilog and SystemVerilog sum into a
double-width register (2*ICORE_WIDTH) and shift back to
Q16.16 once per entry. VHDL accumulates in the shared
Fx process variable, which is Q16.16
(sfixed(15 downto -16)), so every product is rounded as it is
added. The three therefore agree to within the low bits rather than
bit-exactly, and the longer the shared dimension n, the further
VHDL drifts.
Simulink bridge
Import and export, mapped to simulink/Matrix Operations/Matrix
Multiply. That Simulink block is a Product underneath, preset to the
matrix form, so the entry always writes Multiplication =
Matrix(*) and Inputs = 2; on import a
model carrying anything else is reported rather than silently accepted.
Sampling Time (s) → SampleTime, as on every block.
This is the one block in the Matrix Operations family whose counterpart defines
that parameter – the others are masked subsystems and S-Functions that do
not.
Notes
- Algebraic, with no state.
- Deliberately carries no state space. The output is bilinear in the two inputs, so no A/B/C/D reproduces it; model reduction is right to report the block as unmergeable. Gain is the linear sibling – a signal times a CONSTANT matrix.
- Product computes the same thing with its Matrix (*) multiplication type. They are separate blocks in Simulink, in two different libraries, and separate here, so a model imports onto the one it was drawn with.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Matrix_Operations/Matrix_Multiply |
| family | Control_Systems/Matrix_Operations |
| solver environment class | ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_Matrix_Multiply |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Matrix_Operations/Matrix_Multiply/ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_Matrix_Multiply.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Matrix_Operations/Matrix_Multiply/ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_Matrix_Multiply.h |
| default size on canvas | 90 × 80 px |
| ports at insert | 2 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 | u1 |
| 2 | in | ICoreDouble | u2 |
| 3 | 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#
No config variable beyond the Sampling Time (s) every block carries.
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/Matrix Operations/Matrix Multiply |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
| always set | Multiplication = Matrix(*), Inputs = 2 |
Caveat (shown to the user): the Simulink counterpart is a Product preset to the matrix form, so this entry always writes Multiplication = Matrix(*) and Inputs = 2; a model carrying a different multiplication or a longer chain is reported on import rather than silently narrowed, and belongs on the Product block
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).
Matrix Multiply -- y = u1 * u2, the matrix product of two live signals [m,n] x [n,p] -> [m,p]. Exactly two inputs, and the operation is fixed: this block IS the matrix form. Verified against Simulink R2026a, where simulink/Matrix Operations/Matrix Multiply has BlockType 'Product', no mask, and comes up preset to Multiplication = 'Matrix(*)' with Inputs = 2 -- which is precisely what this entry pins as fixedParams.
Unlike its neighbours in this family, the Simulink counterpart DOES define a SampleTime parameter (it is a plain Product underneath), so the rate crosses normally.
HDL is SYNTHESIZABLE: a sum of products in the Q16.16 datapath, accumulated at double width and shifted back down once.
Algebraic and stateless. No state space -- see the header for why.
Sample results#
| t | in ICoreDouble-Out-0 | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 |
|---|---|---|---|
| 0 | -2 | -2 | 4 |
| 0.4 | 0.5 | 0.5 | 0.25 |
| 0.8 | -2 | -2 | 4 |
| 1.2 | 0.5 | 0.5 | 0.25 |
| 1.6 | -2 | -2 | 4 |
| 2 | 0.5 | 0.5 | 0.25 |
| 2.4 | -2 | -2 | 4 |
| 2.8 | 0.5 | 0.5 | 0.25 |
| 3.2 | -2 | -2 | 4 |
| 3.6 | 0.5 | 0.5 | 0.25 |
| 4 | -2 | -2 | 4 |
| 4.4 | 0.5 | 0.5 | 0.25 |
| 4.8 | -2 | -2 | 4 |
| 5.2 | 0.5 | 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 … 34.81 |
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 c01902987 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Matrix_Operations__Matrix_Multiply.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).