Cross Product — Control Systems/Matrix Operations
Control_Systems/Matrix_Operations/Cross_Product · 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.
Cross Product
Control Systems / Matrix Operations
The 3-D vector cross product y = a × b:
- y₀ = a₁b₂ − a₂b₁
- y₁ = a₂b₀ − a₀b₂
- y₂ = a₀b₁ − a₁b₀
The result is perpendicular to both inputs, with length |a||b|·sinθ. The cross product is defined in three dimensions and nowhere else, so both inputs must carry exactly three elements – a vector of any other length is reported rather than padded, as it is in Simulink.
Ports
- a – the LEFT operand, a 3-element vector: [3,1] or [1,3].
- b – the RIGHT operand, likewise 3 elements. The order matters: b × a is −(a × b), so swapping the two wires negates every output.
- Output – y, three elements, taking a's orientation: a column a gives a [3,1] output and a row gives [1,3]. The two inputs need not agree on orientation – Simulink carries a vector with no orientation at all and accepts any combination – and where they differ, a decides.
Parameters
- 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. Nothing is exposed as a tunable parameter: the six products and their signs are the operation itself, not a setting, and every target emits them written out rather than calling each language's own cross helper – which is what makes the ten agree by construction instead of by each one's argument-orientation rules.
The three HDL targets are fully synthesizable: each output is two Q16.16 multiplies and a subtract, with no division and no function call. Their products are formed at double width and brought back to Q16.16 once per output – the same single rounding the software targets get from IEEE arithmetic – rather than after each multiply, which would round twice.
Simulink bridge
Import and export, mapped to
simulink/Matrix Operations/Cross Product. Nothing crosses but the block
itself: the Simulink block is a masked subsystem that defines no dialog
parameters at all, not even SampleTime, so the entry sets
hasSampleTimeParam = false and "Sampling Time (s)" stays on the
ICore side. Writing that parameter anyway would be a hard set_param
error in MATLAB rather than a warning, aborting the whole generated script.
Notes
- Algebraic, with no state: the output depends only on the current inputs.
- No state space, deliberately – and not for the usual reason. The block is bilinear rather than linear: the output is a product of two SIGNALS, so no D·u represents it at any operating point, and model reduction reports it as unmergeable.
- a × a is the zero vector, and so is any pair of parallel inputs.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Matrix_Operations/Cross_Product |
| family | Control_Systems/Matrix_Operations |
| solver environment class | ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_Cross_Product |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Matrix_Operations/Cross_Product/ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_Cross_Product.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Matrix_Operations/Cross_Product/ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_Cross_Product.h |
| default size on canvas | 70 × 70 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 | a |
| 2 | in | ICoreDouble | b |
| 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/Cross Product |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
Caveat (shown to the user): the rate does not cross: Simulink's Cross Product is a masked subsystem that defines no dialog parameters at all, so "Sampling Time (s)" stays on the ICore side. Simulink carries a vector without orientation and accepts a row or a column on either port; ICore's output takes the first input's orientation.
Catalog contract: src/ICoreSDK/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The checker has a blind spot here — it could not resolve something (a grouped port bullet, a computed config name), which is reported and never counted as a pass. A reader has to settle it:
B0every stimulus in the sample errored — cross-checks skipped
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).
Cross Product block -- y = a x b, the 3-D vector cross product y(0) = a(1)*b(2) - a(2)*b(1) y(1) = a(2)*b(0) - a(0)*b(2) y(2) = a(0)*b(1) - a(1)*b(0)
THREE ELEMENTS, ALWAYS. The cross product is defined in three dimensions and nowhere else, so the size rule is fixed rather than derived: both inputs must carry exactly three elements, and a two-element input is rejected here exactly as Simulink rejects it (which was confirmed against the real block rather than assumed).
A ROW AND A COLUMN ARE THE SAME INPUT. Simulink carries a vector as an orientation-less 1-D signal and accepts either, including one of each -- verified by compiling all four combinations, every one of which reports a 3-wide input and a 3-wide output. An ICore signal is always two-dimensional, so this block accepts [3,1] and [1,3] on both ports and reads them in element order. The OUTPUT takes the FIRST input's orientation, which is the one choice Simulink does not have to make and this block does; the description says so.
NO STATE SPACE, deliberately -- see the header.
Sample results#
No stimulus produced a sampled output in this rig — Invalid input signal at cross product block: ICore Blocks/Home/Cross Product. That is a fact about the single-block rig, not a verdict on the block: an offline batch fit, a block whose output only appears at onSolverFinish, or one that needs a driven environment cannot be exercised alone.
Category unsampled · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60
Sample data: docs/generated/samples/Control_Systems__Matrix_Operations__Cross_Product.json