Ramp — Control Systems/Sources
Control_Systems/Sources/Ramp · 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.
Ramp
Control Systems / Sources
A source that holds a constant, then climbs at a constant rate from a time of your choosing:
y(t) = y₀ while t < start, and y(t) = y₀ + slope·(t − start) from then on
The two branches meet at the start time: the ramp term is exactly zero there, so the block still emits y₀ at t = start and begins climbing on the sample after it.
Ports
- Output – the generated signal, always a scalar. It has no inputs; the value comes from the simulation clock and the three parameters below.
Parameters
- Slope – the rate of climb in output units per second, as a single value. Negative ramps down; zero makes the block a constant at y₀.
- Start Time (s) – when the climb begins, as a single value. Before it the output sits at the initial output; at it the output is still the initial output.
- Initial Output – y₀, the value held before the start time and the value the ramp climbs away from. A single value.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period. On this block it only decides how finely the ramp is sampled, not what it computes.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. Each uses a per-block local sample clock rather than a global one, and all three parameters are exposed as tunable parameters on the generated core – a ramp retuned after export is still a ramp, so none of them is structural. The three HDL targets carry the block in simulation-only form: the time comparison and the multiply are done in real arithmetic and quantized on the way out to the fixed-point signal ports.
The HDL caveat beyond that is range. A signal is carried in Q16.16 there, which reaches 32767, and a ramp climbs without bound – so slope·(run length) has to stay inside that for a model intended for the HDL backends. The software targets carry the full double either way.
Simulink bridge
Import and export, mapped to simulink/Sources/Ramp. "Slope" to
slope, "Start Time (s)" to start, "Initial Output" to
InitialOutput – the same three values with the same meanings, so
nothing is left behind. The rate does not cross: Simulink's Ramp is a masked
subsystem and defines no SampleTime parameter at all (verified against
the R2026a block dialog), so "Sampling Time (s)" stays on the ICore side and the
Simulink block inherits the model's step. A block configured with an explicit
positive rate reports that the rate did not cross.
Notes
- Time-driven and stateless: the output depends only on the current time, so a re-run reproduces the ramp exactly and there is no initial state to seed.
- Not discrete by nature, unlike the counters and the noise sources – nothing here is counted, so a continuous solver evaluating the block at its intermediate stages gets the right value at each one.
- See Step for the same shape of block with a jump instead of a climb, and Repeating Sequence for a ramp that resets.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Sources/Ramp |
| family | Control_Systems/Sources |
| solver environment class | ICoreBlock_0_Control_Systems_1_Sources_2_Ramp |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Sources/Ramp/ICoreBlock_0_Control_Systems_1_Sources_2_Ramp.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Sources/Ramp/ICoreBlock_0_Control_Systems_1_Sources_2_Ramp.h |
| default size on canvas | 70 × 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 |
|---|---|---|
Slope | 1 | slope |
Start Time (s) | 0 | start |
Initial Output | 0 | InitialOutput |
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/Sources/Ramp |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
| ICore config | Simulink parameter | Value translation |
|---|---|---|
Slope | slope | passes through |
Start Time (s) | start | passes through |
Initial Output | InitialOutput | passes through |
Caveat (shown to the user): the rate does not cross - Simulink's Ramp is a masked subsystem and defines no 'SampleTime' parameter, so it inherits the model's step and any explicit 'Sampling Time (s)' stays on the ICore side
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).
Ramp block — a signal that holds, then climbs at a constant rate y(t) = y0 t < start y(t) = y0 + slope * (t - start) t >= start
Verified against simulink/Sources/Ramp: with slope 1.7, start 0.12 and initial output -0.35 that block holds -0.35 through t = 0.12 INCLUSIVE and emits -0.333 at t = 0.13, which is what this one does. The inclusive boundary is the one thing to get right and it falls out of the >= above -- at t = start the ramp term is exactly zero, so the two branches meet.
Time-driven and stateless: the output depends only on the current time, so there is no state to seed and a re-run reproduces the ramp exactly. It is NOT declared discrete-only -- nothing is counted, so a continuous solver evaluating it at intermediate stages gets the right answer at each one.
Code export: all ten targets. The three HDL ones are SIMULATION-ONLY -- they read the testbench's sim_time in real arithmetic and quantize only at the port, exactly as Sine Wave does, because a Q-format datapath has no clock to derive t from. The HDL caveat beyond that is RANGE: a signal is Q16.16 there and a ramp climbs without bound, so slope * run length must stay under 32767. See the description.
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__Ramp.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).