Problem and Motivation
Firmware answers to the silicon it runs on. Here is why a hidden hardware bug costs so much to find, and how that shaped DICEE.
The Problem
Firmware does not run on an abstract machine. It runs on one specific microcontroller, and the manufacturer fixes the details of that part: pin assignments, clock trees, timers, interrupt vectors, DMA channels and peripheral registers. Getting them right means reading the reference manual and datasheet, cross-referencing several documents, and choosing settings that satisfy the design within the chip’s physical limits.
The hardware sets the rules twice.
In the configuration
Every pin, clock, timer, interrupt and DMA channel is a decision with one right answer for the part. The choices depend on each other: what is given to one peripheral narrows what is left for another, so the whole set has to be held in view at once.
In the application logic
The constraints do not end once the chip is configured. The logic has to be written inside them: the speed of the control loop, trigger rates, how long a trigger must be held. A trigger that should register only when a signal stays high for 300 ms, because anything shorter is noise, takes that number from the hardware’s own characteristics, not from the code.
Neither layer fails loudly. A wrong value can appear to work, fail intermittently, or damage the board, and on a physical device the feedback loop is slow.
Where AI Still Falls Short
Even today’s most capable general-purpose AI returns code that compiles as a matter of course. That is exactly the trap: a clean build says nothing about whether the code is right for the hardware. The bugs that matter are small and hidden. They live in how the code drives the chip’s internals, so no compiler error surfaces them, and they pass every build.
Each one is costly to resolve. Nothing points to it. It sits somewhere in a large codebase that builds and mostly works, and the engineer has to read through all of it to find it: a needle in a haystack. Catching these bugs takes a different, more organised way of developing code, one grounded in the hardware’s constraints from the start. That is where DICEE comes in.
Anywhere in one large output.
Inside a single checkpoint, so the search starts small.
The model’s recall of similar chips.
The documentation for the section of the chip that code touches.
Reading through the codebase until it turns up.
Finding the checkpoint where it first appears.
The aim is not only to make a wrong value less likely. It is to make one easy to locate.
Why We Are Solving It
Bringing the speed of automation to embedded development, without giving up the correctness the domain demands, is worth doing for three reasons.
Every project is bound by it
Whatever is being built, the configuration and the logic both answer to the same chip. The cost sits underneath every STM32 project, so it is worth removing once and properly.
Time belongs to the design
Hours go to cross-referencing manuals and hunting for one wrong value, not to the part of the product that is the engineer’s own.
Trust is the barrier, not capability
Teams working on high-stakes code are the most cautious about AI, and the concern they raise is whether the output can be trusted. A faster tool does not answer that. One that is easy to check does.
Why This Architecture
Each choice in DICEE answers one of the problems above. How each one works is documented elsewhere, so this is only the link between the two.
The model never decides them. Solvers resolve them for the exact chip.
Technical ApproachCode is written against the resolved configuration, not from memory.
Technical ApproachThe design is settled and approved before any code exists.
How It WorksDocumentation-matched sections and checkpoints, as described above.
How It WorksWhy Us
DICEE was founded by people who have lived both halves of the problem: the daily difficulty of embedded development, and the systems engineering needed to make an AI agent behave predictably.
Ajay Talachintala
An IIT Kharagpur graduate with a mechanical engineering degree and a specialization in embedded development, Ajay spent three years as a systems developer building Motor Control Units, on top of more than five years working directly in embedded systems. That hands-on experience with how difficult and error-prone embedded development can be is what led to DICEE.
Pradyumna Peddula
Also an IIT Kharagpur graduate, Pradyumna worked as a systems engineer at a major cloud infrastructure provider, where he specialized in hypervisor-level performance engineering, optimizing how virtual machines are scheduled and run efficiently across large, resource-constrained fleets. That depth of experience with complex distributed systems is what makes him the architect behind DICEE’s AI agent infrastructure.
Where This Goes
DICEE is in an early, experimental alpha stage. The principle stays the same as it grows: nothing the hardware decides is left to recall.
Plans for wider hardware support, flashing and debugging, and bringing your own documentation are set out under Planned direction in Technical Approach. They describe intent and are subject to change.