Embedded code generationEngineering methods

Model → Rust firmware

Model-based design to deployable code, the Rust-first way — an autopilot designed as block diagrams, code-generated to #![no_std] Rust, proven equivalent to the model, cross-compiled to a Cortex-M target, and attested for provenance.

DjiniousLabModelling & simulation

DjiniousSafeCertifiable code

Three software-in-the-loop plots — altitude, attitude and position — where the code-generated Rust firmware (dashed) tracks the DjiniousLab model (solid) to within a fraction of a percent

autopilot cascade → Rust: 3 loopsautopilot cascade → Rust
firmware-vs-model deviation: < 1.2%firmware-vs-model deviation
embeddable, libm math: #![no_std]embeddable, libm math
verified cross-compile: Cortex-M4Fverified cross-compile
provenance attestation: in-totoprovenance attestation
Rust, not C: memory-safeRust, not C

The model becomes the firmware. In Rust.

Simulating a system is half the job; shipping it is the other half. DjiniousLab code-generates a controller you designed as a block diagram into a self-contained, memory-safe Rust crate — proven equivalent to the model, cross-compiled to a microcontroller, and cryptographically attested. This is what Simulink's Embedded Coder does, except the generated artifact is Rust, not C — the difference that matters when the code is going somewhere safety-critical.

One command from block diagram to crate.

A control loop authored as a .djl block diagram lowers to a flat intermediate representation, and `djinious codegen` turns it into a Cargo crate: a State struct, an initial-condition constructor, and a `pub fn step(state, inputs, t, dt) -> Outputs` that advances the controller one tick. Add `--no-std` and it emits embeddable firmware with libm for math instead of the standard library. The same three Djinborn T4 autopilot loops — altitude, attitude, position — that the quadcopter program flies in simulation generate straight to Rust.

The generated no_std Rust source for the attitude controller: a State struct, an initial() constructor, and a step() function reading state then computing the cascaded control law — Not pseudocode — the actual generated `#![no_std]` attitude controller. Every integrator state is read at the top (as a dependency-free source), the cascaded outer-attitude / inner-rate law computes in between, and the state updates are deferred to the bottom. Readable, deterministic, and free of the standard library.

Closed loops, not just feedforward chains.

A controller is a feedback loop — the integrator output loops back into the error. The codegen used to emit blocks in declaration order, so a fed-back integrator's output could be referenced before it was bound: Rust that doesn't compile. The fix emits output bindings in topological order, treating integrator and delay outputs as dependency-free sources (their output reads stored state), which breaks the cycle; state updates are deferred to the end of the step. A feedback loop with no state element to break it is a genuine algebraic loop and now errors honestly instead of generating broken code. The full codegen suite — 765 unit tests plus 523 compile-and-run round trips — stays green.

Three software-in-the-loop plots where the generated Rust firmware trajectory overlays the model trajectory for the altitude, attitude and position loops — Software-in-the-loop proof: each loop run through the accurate model solver (solid) and through the fixed-step generated firmware (dashed), aligned and differenced. The firmware reproduces every overshoot, settling time and steady state — max deviation 0.09% / 1.18% / 0.24% of span. The codegen is exact; the residual is just fixed-step discretization.

The generated code is the differentiator.

Memory-safe by construction

No buffer overruns, no use-after-free, no undefined behaviour — the classes of bug that safety standards spend their pages trying to exclude from generated C are absent from Rust by the language's own guarantees.

Embeddable, no_std

The crates are `#![no_std]` with libm for transcendental math — no allocator, no operating system. They cross-compile to a bare-metal Cortex-M4F (STM32F4) target as verified here, ready for a board HAL and a timer ISR.

Provenance-attested

`djinious attest` binds the model to the firmware's SHA-256 in an in-toto Statement; `djinious sign` cosign-signs it. The supply-chain link from 'this model' to 'this binary' that certification asks for.

Proven equivalent

A software-in-the-loop harness runs the model and the firmware side by side and differences them — the generated code is gated on matching the reference, not assumed to.

Every claim is a command you can re-run.

The whole pipeline is real artifacts — lower, codegen, compile, run, diff, cross-compile, attest — not a slideware demo.

Step

Loops code-generated & compiled: 3 / 3
SIL deviation (firmware vs model): < 1.2%
Embedded cross-compile: thumbv7em
Provenance: in-toto v1
Codegen test suite: green

Result

Loops code-generated & compiled: altitude · attitude · position
SIL deviation (firmware vs model): of span, all three
Embedded cross-compile: Cortex-M4F rlib
Provenance: model → firmware digest
Codegen test suite: 765 + 523 round-trips

Embedded-grade, signal-flow codegen.

The generated code is fixed-step forward-Euler — the embedded norm — over the catalog signal-block palette (constant, sum, gain, integrator, saturation, scope and friends), which is exactly what a controller is built from. Custom nonlinear DJL components don't code-generate yet; they run in the Julia worker. Flashing onto a specific board needs a HAL crate and a `cortex-m-rt` entry point, and `sign` / `verify` need a local cosign — board integration and CI signing are beyond this program. What it delivers is the spine of model-based design done in Rust: design, simulate, generate, prove equivalent, and trace — end to end, on one tool.