Hermitian Transpose — Control Systems/Matrix Operations
Control_Systems/Matrix_Operations/Hermitian_Transpose · 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.
Hermitian Transpose
Control Systems / Matrix Operations
The conjugate transpose, MATLAB's ' operator:
y(j,i) = conj(u(i,j)), so an [m,n] signal comes back as an [n,m] one with
its rows and columns exchanged.
An ICore signal is REAL – every entry is a double – so
conj(u) is u and the conjugate transpose here is the plain
transpose y = u.'. That is what the operation means on a real signal
rather than a limitation of this implementation: Simulink's own Hermitian
Transpose handed a real matrix returns the same transpose with no sign changed.
The block keeps its own identity rather than being folded into a plain transpose
so that a Simulink model containing one imports, runs and exports back to the
same block instead of being quietly rewritten into a different one.
Ports
- u – the signal to transpose, of any size [m,n].
- Output – y, the same values at [n,m]: the size is exchanged, which is the one thing this block changes. A square input keeps its size and a [1,n] row becomes an [n,1] column.
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 permutation is structural and is fixed into the generated code at export time, written out entry by entry rather than as a call to each language's own transpose – which is what makes the ten agree by construction instead of by each one's storage convention. The three HDL targets are fully synthesizable: a transpose is a rewiring, so the cores carry plain assignments and no arithmetic at all.
Simulink bridge
Import and export, mapped to
simulink/Matrix Operations/Hermitian Transpose. 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 input.
- No state space, deliberately. A transpose is linear on the vectorized signal but is not a left multiplication y = D·u of the signal matrix – no D turns a column into a row – so model reduction reports the block as unmergeable rather than merging a matrix that does not represent it. Reshape carries none for exactly the same reason.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Matrix_Operations/Hermitian_Transpose |
| family | Control_Systems/Matrix_Operations |
| solver environment class | ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_Hermitian_Transpose |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Matrix_Operations/Hermitian_Transpose/ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_Hermitian_Transpose.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Matrix_Operations/Hermitian_Transpose/ICoreBlock_0_Control_Systems_1_Matrix_Operations_2_Hermitian_Transpose.h |
| default size on canvas | 70 × 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#
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/Hermitian Transpose |
| 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 Hermitian Transpose is a masked subsystem that defines no dialog parameters at all, so "Sampling Time (s)" stays on the ICore side. On ICore's real signals the conjugate transpose is the plain transpose, which is what the Simulink block also computes for a real input.
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).
Hermitian Transpose block -- y = u', the conjugate transpose MATLAB's ' operator: transpose, with every entry conjugated. An [m,n] signal comes back [n,m] with y(j,i) = conj(u(i,j)).
AN ICORE SIGNAL IS REAL. Every ICoreMatrix entry is a double, so conj(u) IS u and the conjugate transpose IS the plain transpose here -- exactly what Simulink's own block computes when it is handed a real signal, which was confirmed against it rather than assumed: a real 2x3 comes back as the 3x2 transpose with no sign changed. That is what the operation MEANS on a real signal, not an unfinished implementation, and the description says so where a user will read it.
SO WHY NOT CALL IT "TRANSPOSE". Because the Simulink library has BOTH, as separate blocks, and the bridge maps a type to exactly one counterpart. A model containing a Hermitian Transpose has to import, run and export back to a Hermitian Transpose; folding it into a Transpose block would silently rewrite the user's model into a different one that happens to agree on real signals.
NO STATE SPACE, deliberately -- see the header.
Sample results#
| t | in ICoreDouble-Out-0 | out ICoreDouble-Out-0 |
|---|---|---|
| 0 | -2 | -2 |
| 0.4 | 0.5 | 0.5 |
| 0.8 | -2 | -2 |
| 1.2 | 0.5 | 0.5 |
| 1.6 | -2 | -2 |
| 2 | 0.5 | 0.5 |
| 2.4 | -2 | -2 |
| 2.8 | 0.5 | 0.5 |
| 3.2 | -2 | -2 |
| 3.6 | 0.5 | 0.5 |
| 4 | -2 | -2 |
| 4.4 | 0.5 | 0.5 |
| 4.8 | -2 | -2 |
| 5.2 | 0.5 | 0.5 |
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 … 5.8 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -1 … 0.9996 |
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 ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Matrix_Operations__Hermitian_Transpose.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).