Uniform Random Number — Control Systems/Sources
Control_Systems/Sources/Uniform_Random_Number · 0 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.
Uniform Random Number
Control Systems / Sources
A source drawing a fresh value from a uniform distribution every sample:
y = min + (max − min)·u, where u is uniform on [0, 1)
Every value in the range is equally likely, which is what distinguishes this from Band-Limited White Noise – that block draws from a normal distribution and holds each draw across a noise period, while this one is flat across its band and redraws every time it runs.
Ports
- Output – the drawn value, always a scalar. It has no inputs; the sequence comes from the block's own generator and seed.
Parameters
- Minimum – the lower end of the range, and the smallest value the block can produce.
- Maximum – the upper end. It is approached but never quite reached, because u is drawn on [0, 1) rather than [0, 1]; the gap is one part in 232 of the range. Must be greater than Minimum.
- Seed – the generator's starting state. The same seed always produces the same sequence, so a run is reproducible and two blocks with different seeds are independent. Any whole number.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period. It is also how often a new value is drawn, so a slower rate is a slower sequence rather than a held one.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text, and every one of them produces the identical sequence – the generator is a 32-bit linear congruential generator, which uses only integer arithmetic and so needs no agreement between platform maths libraries. Minimum and Maximum are exposed as tunable parameters; the seed is baked in at export time, being structural. The three HDL targets are simulation-only: they carry the generator in real arithmetic, because the 32-bit generator state does not fit in the Q16.16 datapath at all.
Simulink bridge
Neither direction. Simulink has a counterpart –
simulink/Sources/Uniform Random Number, whose Minimum,
Maximum, Seed and SampleTime line up one
for one with the parameters above – but its sequence comes from
Simulink's own random number generator and cannot be reproduced by generated
code. An exported model would therefore be statistically identical and
sample-wise different, which no parity test could confirm and no user could rely
on. Rather than assert a mapping that nothing verifies, the bridge reports this
block and skips it. To cross a model containing one, place the Simulink block by
hand and copy the values across: the meanings match exactly, and only the stream
will differ.
Notes
- Stateful: the generator state, reset at the start of every run, so a re-run reproduces the sequence exactly, as does a freshly exported core.
- Discrete by nature, so it always takes its period from its own "Sampling Time (s)". Without that, a continuous solver would draw several times per step – once per Runge-Kutta stage – and the sequence would depend on the solver rather than on the block.
- Two blocks in one model with the same Seed produce the same sequence and are therefore perfectly correlated. Give them different seeds.
- Scalar only. Use several blocks, or a Mux, for a vector of independent draws.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Sources/Uniform_Random_Number |
| family | Control_Systems/Sources |
| solver environment class | ICoreBlock_0_Control_Systems_1_Sources_2_Uniform_Random_Number |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Sources/Uniform_Random_Number/ICoreBlock_0_Control_Systems_1_Sources_2_Uniform_Random_Number.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Sources/Uniform_Random_Number/ICoreBlock_0_Control_Systems_1_Sources_2_Uniform_Random_Number.h |
| default size on canvas | 80 × 70 px |
| ports at insert | 0 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 | 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 |
|---|---|---|
Minimum | -1 | — |
Maximum | 1 | — |
Seed | 0 | — |
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::None |
| Simulink path | — |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
Caveat (shown to the user): Simulink's Uniform Random Number matches this block parameter for parameter (Minimum, Maximum, Seed, SampleTime) but not SAMPLE for sample: its sequence comes from Simulink's own random number generator, which generated code cannot reproduce. An exchanged model would be statistically identical and numerically different, and no parity test could confirm it - so the mapping is reported here rather than asserted. Place the Simulink block by hand and copy the values across if you need it
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).
Uniform Random Number block — a fresh uniform draw on [min, max] every sample y[k] = min + (max - min) * u[k], u[k] uniform on 0, 1)
WHY THE GENERATOR IS WRITTEN BY HAND. Code-export verification compares each of the ten generated cores against this C++ one SAMPLE BY SAMPLE, so a random source has to produce the identical stream in ten languages or fail its whole row. That rules out every language's own RNG. What is left is a 32-bit LCG -- integer arithmetic only -- which is bit-identical everywhere including the five backends that have no unsigned integer type at all: every intermediate is a whole number below 2^53, so a double carries it exactly.
This is the same generator Band-Limited White Noise uses, and deliberately so. That block sums twelve of these uniforms to reach a normal; this one IS the uniform, which is the only difference between them at the arithmetic level.
WHY THERE IS NO SIMULINK BRIDGE. The parameters correspond one for one (Minimum, Maximum, Seed, SampleTime), but the STREAM cannot: Simulink's block draws from its own random number generator, so an exported model would be statistically identical and sample-wise different, and no parity testbench could ever pass. Registering the block as exportable would assert a mapping that nothing checks, so it registers Support::None with that reason and the bridge reports it rather than emitting something that quietly disagrees. Verified in R2026a: the block's dialog is Minimum / Maximum / Seed / SampleTime, and at min=-1, max=1, seed=0 it produces -0.5620816273, -0.9059107676, ... which is MATLAB's own stream and not reconstructible from the three parameters.
Code export: all ten targets. The three HDL ones are SIMULATION-ONLY -- they carry the generator in real arithmetic, because a Q16.16 datapath cannot hold the 32-bit LCG state at all, let alone advance it.
Sample results#
Plotted: free — No input: the block run alone
Category source · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60 · data [docs/generated/samples/Control_Systems__Sources__Uniform_Random_Number.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).