Embeddable C++ SDK Ten export targets, every sample verified Free for academic and non-commercial tiers

System design platform.
An engine you embed.
Automated, verified deploy.

examples/Closed_Loop_Speed_Control agent
Step Scope Σ + − Kp Transfer Fcn 1/(s+1) State Space ẋ = Ax + Bu y = Cx + Du Reduce Deploy agent
Solver
Fixed-step
Exported
10 targets
Residual
1e-11 %

ICore Blocks is a lightweight, industry-grade block-diagram simulator and code engine for control, robotics and machine-learning systems. It exports any level of a model to ten languages, then compiles that code, runs it, and compares it against its own simulation, sample by sample. The same engine embeds in your own platform as a C++ SDK.

Download the app Model to hardware Embed the SDK
Available now Windows macOS
Coming Nov 15, 2026 Linux iPad Android tablets Web

generated cores with no run-time allocation · software targets · tolerance 0.1 % · observed agreement ≈1e-11 %

AI agents · built on embeddable infrastructure

Agents take the model to your hardware.
The engine is what lets them.

Claude Code, Codex, Gemini CLI or Cursor can create a model, simulate it, verify the generated code and deploy it to your own embedded hardware. That is not a chat feature bolted onto an editor. It works because ICore Blocks is infrastructure: a simulator, ten code generators and a verifier behind a plain-text model format and a command interface, which an agent drives exactly as a build script would.

Nothing in the loop needs the window. agentServe opens a project headless and serves the same commands on a build machine, and it is the same engine that embeds in your own platform as a C++ SDK. When a person is watching, every command the agent runs appears in their Command Window as it happens.

How agents work The engine as an SDK
$ icore simulate
simulated 0 to 10 s, 101 steps; 1 signal(s):
  Home/Scope:in0  first 0  last 0.999879  min 0  max 0.999879  mean 0.798693
The agent checking its own work: the model run with the project's solver settings, every sink summarised, and any signal that went NaN or infinite flagged.
$ cat scripts/deploy_controller.icore
t = target(C)
t.setConfig(Source, Home/Controller)
t.setConfig(Folder, firmware/controller)
t.setConfig(Verification, Strict - All Signals)
t.fire()
A deploy target written by the agent: the controller as a C core for the board, verified on every signal before it is written. If verification fails, the export stops and says why.
01

Create

The project file is plain recipe text. The agent edits it in place and reloads; every line that did not apply comes back with its reason, so it fixes the line and reloads again.

02

Test

icore simulate runs the model and summarises every sink - first, last, lowest, highest and mean - and lists every error or warning the run logged.

03

Verify

The export builds the generated code with a real toolchain, drives it with a random stimulus and compares it with the simulation, sample by sample, against a tolerance.

04

Deploy

C for your microcontroller board, VHDL or Verilog for an FPGA, Structured Text for a PLC. The core lands in the folder your firmware build reads: fixed-size, with nothing allocated at run time.

Integration · the commercial path

Three ways the engine goes
into your product.

Most of what ICore Blocks is sold for never shows a window. The engine is a C++ library you link, a code generator whose output you ship, and a headless binary a build can drive - and the desktop application is the fourth way, not the only one.

Embed · C++ SDK

Link the engine

The modelling engine as a library inside your own application: the block model, the solver, the 806-block library, the ten code generators and the editor surface. The public headers expose ICore types only, and you own the loop - so the engine steps on your clock, not on ours. Redistribution rights come with the licence.

What the SDK exposes →
Deploy · ten targets

Ship the generated core

Or take no dependency at all. Export a subsystem and ship what it writes: a C core is a plain struct plus functions with no allocator, no hidden state and nothing beyond the standard library, so it drops into a bare-metal build as easily as a desktop one. One call advances the model exactly one sample - a PLC scan, an RTOS tick, a clock edge.

See all ten targets →
Automate · headless

Drive it from a build

Everything the window does has a console equivalent, and the console runs without a window: --console executes a command and exits. 66 commands cover loading a model, running it, reading results and deploying code - which is how a model becomes a step in CI rather than something a person remembers to re-export.

Command reference →
Where it ships

Industrial automation and robotics, on the hardware you already chose.

The engine is deliberately light: one static platform library, no runtime services to stand up, and generated code with fixed-size storage and no allocation. That is what lets the same model reach a PLC, a microcontroller, an FPGA fabric and a robotics node without four separate toolchains - and what makes it embeddable in a platform that already has its own idea of how software is built.

  • PLC · DCSIEC 61131-3 Structured Text. The model becomes a FUNCTION_BLOCK called once per scan, carried in LREAL throughout - a full-precision target, not a fixed-point approximation of one.
  • MCU · RTOSThe C core has no allocator, no hidden state and no dependency beyond the standard library. Parameters stay tunable after export, so a gain changes without regenerating.
  • FPGAVHDL, Verilog and SystemVerilog, every signal in Q16.16. One rising clock edge advances one sample, and the residual is set by the number format rather than by the generator.
  • RoboticsC++ and Rust cores drop into a node or a real-time task. 159 robotics and aerospace blocks - equations of motion, axes and coordinate transforms, 3-D orientation, planar kinematics, perception filters, actuators and drivetrain - export through the same path as the controller.
  • Edge ML66 machine-learning blocks, 63 of them exportable to all ten targets, so an estimator, a classifier and the loop that uses them ship as one core instead of three integrations.
  • Your platformIf what you are building is the tool rather than the machine, link the SDK and your users get modelling, simulation and code export inside your product, under your branding.
The SDK · two layers

A C++ library, not an application
you have to shell out to.

The engine is delivered as a C++ SDK in two layers you can adopt separately: a platform foundation that depends on nothing else in the product, and the modelling engine on top of it. Both are C++17, and both keep their dependencies to themselves.

  • Platform SDKICoreEssentials - the foundation: containers, math, geometry, filesystem, networking, concurrency, terminal and UI. One static library, 306 public headers, and it depends on nothing else in the product - it compiles, links and runs outside the application that ships it.
  • Blocks SDKThe modelling engine on top of it - the block model, the solver, the library, the ten code generators and the editor. A findable CMake package: find_package(ICoreBlocks 1.0) and the icore::sdk target, which carries the include root and C++17 and no toolkit target at all.
  • Clean surfaceThe public headers expose ICore types only; text crossing the boundary is UTF-8 std::string. Implementation details stay behind the interface you compile against, so an internal change is not your migration - and your own code never names the UI toolkit.
  • Your loopThe caller owns the clock. run() is exactly while (isRunning()) tick();, and tick() is public - so an engine embedded in your application is stepped by your scheduler and never blocks in a loop it controls.
  • Licensingicore::License is a read-only view of what a copy may do - state(), has(Feature), allowsCodegenTarget(), allowsCommercialUse(). It answers, never acquires, and before anything resolves it says Unlicensed with no features rather than crashing.
  • PlatformsmacOS, Windows and Linux.
$ cat main.cpp
#include <icore/Application.h>
#include <icore/EditorWindow.h>

int main(int argc, char** argv) {
    icore::Application app(argc, argv);
    auto editor = app.createEditorWindow();
    editor->setTitle("ICoreBlocks");
    editor->show();
    return app.run();
}
The public surface of the Blocks SDK, verbatim from its documentation. It compiles with no Qt on the include path at all - the toolkit-free contract is a measured property of the headers, not a promise about them.
$ cat CMakeLists.txt
find_package(ICoreBlocks 1.0 REQUIRED)
target_link_libraries(my_app PRIVATE icore::sdk)
Version-checked under SameMajorVersion: a request for 1.0 is satisfied by any 1.x and refused by 2.x. The public header list is written by hand rather than globbed, so adding to the surface is a deliberate act.

Embedding is scoped work, and it is priced as scoped work

Every Team + SDK licence carries the right to redistribute the SDK inside your own product, fifteen floating seats, plugin loading - and 40 to 200 hours of our engineers working on your integration, in C++ or Python. The SDK downloads from the customer portal with the licence; the hours are how it gets fitted to your toolchain, which is why they are in the licence rather than sold beside it.

Download SDK Talk to sales

Beyond the standard bundle

OEM re-badging, shipping the SDK to your own customers as a development tool, source escrow, air-gapped and offline activation, on-premises licence servers and contractual response SLAs are all quoted individually. Tell us what the deployment needs and we will come back with a quote.

Request a quote
The loop

One model, from a blank canvas
to a program on the target.

Four steps, in order - whether a person walks them in the editor, a script walks them headlessly, or your own application walks them through the SDK. Everything in the window has a console equivalent, and everything the console does the API does too.

01

Draw

Place blocks from the library navigator and join them with signal links. Subsystems nest beneath the top level, so a model stays readable as it grows.

02

Run

Set the start and stop time, the solver and the sampling. Continuous and discrete parts live in the same model - most real ones are mixed.

03

Read

Scopes fill in as the run advances. Results are also variables: read them in the command window, chart them, or keep them for the next run.

04

Deploy

Turn any subsystem - or the whole model - into a stand-alone program with a testbench and a build file, in the language the target needs. Or skip the file entirely and run the engine in-process, inside your own product.

Capabilities

Everything the model needs,
in one environment.

Eleven things it does that you would otherwise assemble from separate tools.

Edit → Reduce

Block reduction

Optimize a model before it deploys. Collapse blocks in series, in parallel or around a feedback loop into one exact state-space realization, so a deployed closed loop is discretized as one loop instead of block by block, with no loop delay between them and fewer signal buffers in RAM. A singular algebraic loop is refused rather than invented.

Read more →
Scripts · agents

AI agents that edit the diagram

The project file is plain recipe text, so Claude Code, Codex or any other coding agent edits it in place and tells the app to reload - the change lands in the window you are working in, and every line that did not apply comes back with its reason. The icore client and its MCP tools let the agent simulate the model and fire its export targets itself, and every command it runs shows in your Command Window.

Read more →
MATLAB bridge

MATLAB and Simulink, both ways

MATLAB and ICore each have their own grammar, and one dictionary translates between them: bring a .m in as a script, or send a script out as a .m that runs on its own. Models cross to Simulink and back, and both bridges are checked against MATLAB before every release.

Read more →
Ten targets

Code export

Any subsystem becomes a stand-alone program: a deployable core advancing one sample per call, a testbench, and a build file. C, C++, Rust, Python, MATLAB, Java, VHDL, Verilog, SystemVerilog and IEC 61131-3 Structured Text.

Read more →
Solver

Global solvers, per-rate subsystems

Continuous or discrete. Fixed-step: Euler (RK1), Improved Euler / Heun (RK2), Kutta (RK3), Runge–Kutta (RK4), and implicit Backward Euler and Trapezoidal for stiff plants. Variable-step: Dormand–Prince (RK45), Bogacki–Shampine (RK23) and implicit TR-BDF2. Subsystems may run at their own sampling rate, reconciled by a multi-rate tolerance you control.

Read more →
Deploy

One model, every rate, every target

A model that runs at several rates ships as several targets: each one names its own source subsystem, its own language and its own verification level, and each is generated at that subtree's rate. Targets are saved beside the project and go out together with Deploy All.

Read more →
User code

Your code in the loop

Drop a C or Python block into the diagram and your own source runs inside the simulation loop, with the ports you declare on it - for the part of a model that was never going to be a block.

Read more →
Console

Python and MATLAB, both

The command window has a Python REPL's feel - a bare variable prints as a Python repr, matrices print as lists - while keeping MATLAB's rules where they matter: a statement ending in ; is silent, and matrices are stored in MATLAB syntax. Type either; it understands both.

Read more →
My Blocks

Block Wizard - your own library

Make your own blocks and keep them. The wizard writes a .iblock file - identity, ports, icon, description, and a body that is either recipe text or Python - and it appears under My Blocks in the navigator, ready to import, export or hand to someone else. A definition stamps into ordinary blocks when placed, so a project that uses your library stays self-contained.

Read more →
C++ SDK

Eigen, wrapped

The linear algebra is Eigen underneath - Dense, plus Polynomials, Matrix Functions, Splines, FFT, Numerical Differentiation and Levenberg–Marquardt - reached through ICoreMatrix and its neighbours. You get the performance without binding your own code to the dependency.

Read more →
ICoreMath

The maths in one place

Matrices, polynomials, splines, time series and complex variables. Calculus, geometry, optimisation, signal processing and control-systems tooling - discretization, root locus, state-space and transfer-function conversion, time response - and the expression evaluator the console itself runs on.

Read more →
Code export · ten targets

The same diagram, in the language the hardware speaks.

Every export has the same shape: a deployable core that advances the model by exactly one sample per call, a testbench that drives it across the simulation window, and - where the language has one - a build file so the folder compiles as it is. Storage is fixed-size and nothing is allocated at run time, so this is the artifact that ends up on the PLC, the microcontroller or the FPGA.

  • 749 / 806library blocks export to all ten targets. The rest are software-only by nature - string handling, buses and messages, incremental learning, the ephemeris and CubeSat models, and the user-code and Python-model blocks, which export to their own language - plus the subsystem block, whose contents export rather than itself, and the Hit Scheduler, which steers a variable-step solver that exported code does not have.
  • Paramsstay tunable after export - change a gain without regenerating.
  • Solverfixed-step or discrete. A variable-step model is refused rather than silently approximated.
  • Each rowopens that language's page - what it writes, what it needs, and how it is checked.
TargetDeploy writesOne call advances one sample
C<name>_deployableCore.h/.c, testbench, CMakeLists.txtDeployableCore_init(&core), then execute_blocks(&core)
C++<name>_deployableCore.hpp, testbench, CMakeLists.txtstruct DeployableCore · execute_blocks()
Rust<name>_deployableCore.rs, testbench, Cargo.tomlexecute_blocks(&mut self)
Python<name>_deployableCore.py, testbenchexecute_blocks() · needs numpy
MATLAB<name>_deployableCore.m, testbenchclassdef … < handle · core.execute_blocks()
Java<name>_deployableCore.java, testbenchexecuteBlocks()
VHDLicore_pkg.vhd, entity, testbench, Makefile (GHDL)one rising clk edge
Verilogicore_defs.vh, module, testbench, Makefile (Icarus)one clk edge
SystemVerilogicore_defs.svh, module, testbench, Makefile (Icarus)one clk edge
PLC · ST<name>_deployableCore.st, testbenchFUNCTION_BLOCK FB_<name> - one scan
Verification

Generated code you can check, not code you have to trust.

Most code generators ask for faith. This one exports the model, builds it with a real toolchain, runs it over the simulation window, and compares every sample against the solver - then reports the residual as a percentage. Choose how strict to be: output gates only, gates and sinks, or strict across all signals.

  • 0.1 %the tolerance for software targets, where the exported code runs the same arithmetic as the solver. Anything above noise is a real defect.
  • ≈1e-11 %what passing runs actually measure.
  • ≈5e-13how closely the ten languages agree with one another on the same model.
  • ≈1e-14a discrete state-space against an exact zero-order-hold reference.
$ ICoreBlocks --console "G = tf([1],[1 1]); y = step(G, 5, 6); y.values()"
[[0], [0.632121], [0.864665], [0.950213], [0.981684], [0.993262]]
The step response of 1/(s+1) at t = 0…5 - the samples of 1 − e−t, and the curve plotted at the top of this page. The command window is a calculator, a scripting surface and the headless interface, with 66 commands.
$ Code Engine → Code Export Verifier → Verify All
Target classToleranceObserved
Software · 7 languages0.1 %≈1e-11 %
HDL · Q16.161 %≈1e-3 %
The three HDL targets carry every signal in Q16.16 - about ±32768 with a step of 1.5e-5 - so their residual is set by the number format, not by the generator.

Checked against Simulink, block by block

Every block bridged to Simulink is driven with a seeded random stimulus. The identical samples go through the Simulink counterpart and through the block's own generated MATLAB, and the outputs are compared sample-by-sample against a per-block tolerance. It is a pre-release suite: a block that drifts fails the release.

Blocks ship with a measurement

667 of the 806 library blocks carry a sample from a real headless run - a step, impulse, sine or ramp response, or an input-to-output table where that is the point - regenerated with the software, never drawn by hand. The same rule governs this page: every number on it is a measurement.

The library · 806 blocks, 81 families

Four domains, one signal model.

Blocks carry typed matrix signals over port-based links, so a controller, an estimator and a classifier sit in the same diagram and export through the same path. Each block's description - its ports, parameters and what it computes - is one text, shown in the library navigator, in its configuration dialog and on its documentation page. The four domains below hold 789 of them; the other 17 are the subsystem block and the parts that go inside one: its input and output gates, its enable, trigger, reset and action ports, and the iterator, If, Switch Case and function-call blocks that drive it.

Control systems
516
Continuous and discrete dynamics, discontinuities, lookup tables, matrix operations, spectral measurements, curve fitting, optimization, symbolic maths, sources and sinks, model verification.
Machine learning
80
Neural networks, classical models, incremental learning, preprocessing, feature engineering, anomaly detection and post-processing - 63 of them exportable to all ten targets.
Robotics & aerospace
174
Equations of motion, axes and coordinate transforms, 3-D orientation, gravity, atmosphere and wind models, spacecraft and rotorcraft dynamics, kinematics, perception filters, actuators and drivetrain, and flight instruments.
System identification
19
Recursive and offline estimation, excitation signals and validation, including monitors for model fit, excitation richness and residual whiteness.
61 templates

Start from a worked example

Closed-loop control, subsystem building blocks and more ship with the application. Opening one creates a project of its own, so the template is never modified.

66 commands

Scriptable, and headless

Anything done in the window has a console equivalent, and the console runs without one: --console executes a command and exits, which is how models are driven in a build.

MATLAB bridge

Move code and models across

.m files translate in and out of the console, and blocks carry a Simulink mapping. Both are checked against MATLAB before every release.

The application

The same engine, with a window on it.

Everything above is also a desktop application, and it is a real one - it is where models get drawn, run, read and exported before any of it is embedded, and it is how most teams evaluate the engine before they link it. Download it, open one of the 42 templates, and the first export is a few minutes away.

Download the app Read the documentation
  • PlatformsAvailable now on Windows, from the Microsoft Store, and macOS, from the customer portal. Linux, iPad, Android tablets and a web version of the editor and simulator, running in the browser, are coming Nov 15, 2026.
  • Free tiersAcademic and non-commercial licences are free, and every paid tier starts with a 30-day trial.
  • Same engineThe application is the SDK plus the editor. A model drawn in the window and a model built through the API are the same object, exported by the same generators and checked by the same verifier.
  • Everything publishedThe manual, a page for every block, and the full command reference are public, with nothing behind a sign-in.
Release notifications

Hear when it ships.

A short, plain message when a new ICore Blocks release lands - what changed, what it means for the SDK, and the new block responses. No newsletter, no drip sequence, and the list is never shared or sold.

Get started

See it on your own model.
Then inside your own product.

Take the SDK into the platform the engine has to live in, or start with the application: download it and read the documentation - the manual, a page for every block, and the full command reference are public, with nothing behind a sign-in.

Download SDK Download the app Contact us