Chiplab Wants Your AI Agent to Test Firmware on Virtual Chips. Today It Only Proves "Hello World" Boots.
If you've done embedded work, you know the two-week tax that sits between "the code compiles" and "the code runs on the actual board." You flash it, you watch a UART log, you get silence, you check the linker script, you re-flash, you wait for a JTAG probe to reconnect, you discover the board you ordered is still in customs. None of that friction shows up when an LLM writes firmware for you — the model will happily hand you a clean, plausible-looking driver for an STM32 peripheral that has never once touched real silicon. It has no way to know if it boots.
Chiplab, a new project from German embedded startup Veecle, tries to close exactly that gap. It's not a new simulator aimed at humans — Renode and QEMU already do that — it's a hosted Model Context Protocol (MCP) server that lets a coding agent like Claude Code, Cursor, VS Code, or Codex compile firmware, upload it, run it on a virtual instance of a real chip, and read back what happened — without a human touching a debugger, and without a board on anyone's desk. It launched on Product Hunt as "test firmware on a virtual chip with no hardware needed," and it's free while in beta.
The pitch is narrow and honest in a way most Product Hunt launches aren't: read the GitHub README closely and it tells you, in its own words, that "today it runs Hello world! on STM32 and Nordic boards; a lot more is on the way." That's the whole current scope. Whether that's an interesting bet or a beta note you should discount depends on what you're trying to do with it — this piece is about figuring out which.
What Chiplab actually is
Chiplab is an MCP server sitting at https://chiplab.veecle.ai/mcp. You don't install a simulator locally and drive it yourself; your AI coding agent connects to Veecle's hosted service, authenticates through a browser sign-in on first use, and gets access to a small set of MCP tools for building, uploading, and running firmware against virtual boards.
The contract is deliberately narrow and framework-agnostic: your agent builds an ELF binary with whatever toolchain it wants, uploads that binary to Chiplab, Chiplab runs it on a virtual instance of the target board for a bounded amount of virtual time, and the agent reads back the UART output the firmware produced. That's the entire loop — build, upload, run, read. There's no persistent session, no interactive stepping through breakpoints, no live memory inspection exposed to the agent beyond what comes out over serial.
Today the supported boards are limited to two silicon families: STMicroelectronics' STM32 line (the repo lists F1, F4, F7, H7, L0, and WBA variants, with the STM32F4-Discovery as the flagship example) and Nordic Semiconductor's nRF52. On the software side it supports bare-metal Rust with vendor HALs, Embassy (async Rust), Zephyr RTOS, FreeRTOS, and Eclipse ThreadX — in C and Rust. A full board-by-framework compatibility matrix lives in the repo's supported-boards.md.
The project is MIT-licensed and public on GitHub, though the actual simulation engine — the part that models chip behavior, memory maps, and peripheral timing — runs server-side and isn't part of what's open source. What's open is the client-side glue: example projects per framework, an AGENTS.md file in each that tells the coding agent exactly how to build and run that framework's examples, and the MCP wiring itself.
Getting an agent to actually use it
The setup is deliberately close to zero-friction. You create a free Veecle account, add a small JSON block to your client's MCP config:
{
"mcpServers": {
"chiplab": {
"type": "http",
"url": "https://chiplab.veecle.ai/mcp"
}
}
}
and then, in Claude Code specifically, you don't even need to hand-write that — cloning the repo drops in a pre-configured .mcp.json and the client just prompts you to trust the server. From there the entire remaining interaction is conversational: you tell the agent something like "set up Chiplab and run the stm32f4-discovery example on it," and it reads the relevant AGENTS.md, installs whatever toolchain the example needs, compiles the ELF, calls the MCP tool to upload and execute it against the virtual board, and reports back what came out of the chip's UART. For Codex users the same server is reachable via a TOML block in ~/.codex/config.toml plus a codex mcp login chiplab step; VS Code takes the same JSON shape under a servers key instead of mcpServers.
What's notable here isn't the plumbing — MCP configs all look roughly like this now — it's that the documentation is written in two parallel tracks per framework: a human-readable README and a separate AGENTS.md clearly meant to be consumed by the coding agent itself, with its own conventions for what the agent should and shouldn't infer. That's a small but telling design choice. Most developer tools that predate the agentic-coding wave bolt MCP support onto documentation written for humans; Chiplab was seemingly designed agent-first from the README down, which tracks with Veecle's stated goal of building "the next way to develop chips."
If you haven't touched MCP yet: it's the protocol Anthropic introduced as a standard way for an LLM-driven agent to discover and call external tools — a database, a filesystem, a SaaS API, or in this case a hardware simulator — without every agent vendor and every tool vendor having to hand-build a bespoke integration. Chiplab is a fairly literal application of that idea to a domain, embedded systems, that has historically been the hardest to give an agent any real feedback loop in, precisely because the ground truth lives in a physical chip.
Why an agent-first interface, specifically
This is the part of the pitch worth taking seriously on its own terms, independent of how mature the current implementation is. Hardware simulators for firmware aren't new — Antmicro's Renode has been doing serious ARM Cortex-M and RISC-V emulation for years, with scripting hooks for automated boot flows and CI integration, and it's used seriously enough that Memfault has written explainers on driving it. QEMU emulates a much broader universe of systems but, per multiple embedded-focused comparisons, has thin and inconsistent Cortex-M coverage — historically limited to a couple of Texas Instruments targets. And Wokwi has made browser-based simulation genuinely pleasant for hobbyists and classrooms, but it's tuned for Arduino, ESP32, and RP2040 boards, and explicitly doesn't claim timing-precise peripheral behavior — you're meant to verify on real hardware before shipping.
All three of those are tools a person sits down and operates. Chiplab's bet is that the operator, increasingly, won't be a person — it'll be a coding agent that has already been told to "implement the SPI driver and make sure it boots," and that needs a machine-checkable answer, not a simulator UI. An LLM can write plausible register-level code for a peripheral it has never seen initialize. It cannot tell you, on its own, whether that code actually boots on an STM32H7 or correctly handles an interrupt. Chiplab's actual product is turning "does this boot" into something an agent can query and get a pass/fail answer to, in the same tool-call loop it already used to write the code.
That's a real and current gap. Right now, if you want an agent to validate firmware against real chip constraints, your options are: give it shell access to a local Renode install and hope it can drive the scripting interface correctly, buy it a board (which an agent obviously cannot do, and which — per the founders' own framing — cost them literal weeks of shipping delay before they could start iterating), or trust the LLM's unverified output. Chiplab collapses that to an MCP tool call.
What changed versus the alternatives
The honest framing is that Chiplab isn't better than Renode at simulating chips — it's almost certainly much less capable today, given Renode's years of head start and its support for a far wider range of silicon (it covers ARM Cortex-A and Cortex-M, RISC-V, SPARC/Leon, and more). What Chiplab changes is who's expected to drive the tool and where it runs.
-
Interface: Renode and QEMU are driven by a human (or a carefully scripted CI job) via CLI/REPL and Robot Framework-style test scripts. Chiplab is driven by an agent via MCP tool calls, with per-framework
AGENTS.mdfiles specifically written to be read and acted on by an LLM rather than a person. - Where it runs: Renode, QEMU, and Wokwi's local mode run on your machine or your CI runner. Chiplab is a hosted service — your firmware binary leaves your machine and executes on Veecle's infrastructure. That's a meaningful trade for anyone working on firmware they consider sensitive.
-
Setup cost: a free account, no credit card, and a
git clonegets an agent running the STM32F4-Discovery "Hello world" example in one prompt. Getting Renode scripted correctly for a new board is a real skill investment. - Scope: Wokwi and Renode both simulate a broad and growing set of peripherals — GPIO, timers, I2C, SPI, and more, depending on the platform. Chiplab's current loop is explicitly build → upload → run → read UART. The README doesn't claim broader peripheral access yet, and a Product Hunt discussion of the launch noted peripheral support and CI/CD integration as near-term roadmap items rather than shipped features.
Why developers should actually care
Cost. Getting a physical STM32 or nRF52 dev board on someone's desk means an order, a shipping wait, and a unit cost per contributor — trivial for one engineer, real friction for a team that wants every PR touching firmware to run against every board variant it targets, or for a course that wants every student to have a working board on day one. A virtual chip an agent can reach over HTTP removes that entirely for the "does it boot" tier of validation, and it does so at zero marginal cost during the beta.
Latency of feedback. This is arguably the bigger win. The founders describe losing weeks between deciding they needed to test something and having a board in hand to test it on. Even once hardware is on someone's desk, a human-driven flash-and-observe loop runs at the speed of a person walking to a bench, connecting a probe, and reading a terminal. An agent calling an MCP tool gets an answer in the time it takes the request to round-trip to Veecle's servers and back — the same compression agentic coding already brought to compile-test-fix loops in ordinary software, now reaching a domain where the "test" step used to require physical presence.
Developer experience. The whole point is that nobody has to learn a new tool. You don't study Renode's scripting API or QEMU's machine models; you tell an agent what you want in English and it does the MCP calls. That's a genuinely lower floor than any simulator aimed at humans has managed, at the cost of the ceiling being whatever the agent and the current MCP tool surface can express — which today is "build, run, read UART," nothing more granular.
Lock-in. This is the one the launch materials don't dwell on. Renode and QEMU are things you install and own; nothing stops you from running them offline, forking them, or auditing exactly how they model a chip. Chiplab is a hosted dependency on a single early-stage vendor. If Veecle's service has an outage, changes its terms, or eventually paywalls what's free today, your validation loop goes down with it. There's no self-hosted mode described anywhere in the public materials.
Security. Your firmware binary — which for a commercial product may embody real IP, cryptographic material, or proprietary protocol logic — gets uploaded to a third party's cloud to execute. For open-source examples or teaching material that's a non-issue. For a company's production firmware, "upload your ELF to an early-stage startup's hosted service" is a decision that needs a security review and probably a legal one, not a Product Hunt upvote. Nothing in the reviewed materials describes data retention, encryption at rest, or how long uploaded binaries persist on Veecle's infrastructure.
Maintainability. Because the interface is deliberately thin — three verbs, build/run/read — there's very little surface area to maintain on the consuming side. The flip side is that thinness is also the ceiling: teams that need to assert something more specific than "it booted and printed X" (a peripheral register reached a particular state, an interrupt fired within a timing window) have nothing to hook into yet.
Practical use cases
- Agentic PR validation for firmware repos: wire an agent into your embedded repo so that when it proposes a driver change, it can self-check that the change still boots on the target board before opening the PR, rather than relying purely on code review.
- Onboarding without hardware logistics: new hires or students can have a working "hello world on real chip" experience in minutes through an agent, without waiting on a hardware order — useful for courses, workshops, and remote onboarding.
- Cross-board regression checks: with the board × framework matrix Chiplab publishes, an agent can, in principle, check the same driver logic against multiple STM32 variants (F1 vs H7, for instance) in one pass, something that would otherwise mean owning every variant physically.
- Early triage before real-hardware debugging: catching a firmware change that flat-out fails to boot before it ever reaches a lab bench and a logic analyzer, reserving expensive hardware-in-the-loop time for problems that actually need it.
None of these are CI-grade yet, because Chiplab's stated roadmap explicitly hasn't shipped CI/CD integration — as of the material available, it's a per-session, agent-driven tool, not a pipeline step you can drop into GitHub Actions today.
What the launch page doesn't dwell on
- Board coverage is genuinely narrow. Two silicon families, a specific list of variants within each, versus Renode's multi-architecture support spanning ARM, RISC-V, and SPARC, or Wokwi's Arduino/ESP32/RP2040 breadth. If your target chip isn't STM32 or nRF52, Chiplab has nothing for you today, full stop.
- "Hello world" is not a euphemism — it's the literal current ceiling, by the project's own description. That's an honest disclosure, but it means the interesting failure modes in real firmware — race conditions between interrupts, timing-sensitive peripheral sequencing, power-state transitions — aren't things you can lean on Chiplab to catch yet. Reading back UART output tells you whether the firmware ran and printed something; it doesn't tell you whether a peripheral driver correctly handled a real-world edge case unless that firmware was specifically written to exercise and report on it.
- Execution is synchronous and bounded to fixed virtual time. Fine for boot-and-print smoke tests; not obviously suited to long-running scenarios, power-cycle testing, or anything that needs to run for simulated hours.
- It's a hosted dependency, not a local tool. Renode and QEMU run offline once installed; Chiplab requires network access to Veecle's servers and a Veecle account. If that service has downtime, rate limits, or eventually a paywall past the beta, your firmware validation loop depends on it. Pricing beyond "free during beta" isn't published anywhere in the materials reviewed for this piece.
- The simulation engine itself is a black box. The repo is public, but the part that actually models chip behavior — accuracy of interrupt timing, peripheral register behavior, memory-mapped I/O fidelity — runs server-side and isn't inspectable the way Renode's open-source platform descriptions are. You're trusting Veecle's fidelity claims without being able to audit them the way you could audit an open simulator's model files.
An independent read
Strip away the Product Hunt framing and what's left is a small, credible startup shipping a thin, honestly-scoped MVP against a real problem. The founding story — burning hours flipping through a datasheet for one signal, then losing weeks waiting on a board to ship — is the kind of specific, unglamorous pain that tends to produce useful tools rather than the kind of pain that produces vaporware pitched at a trend. That's a point in its favor independent of how far along the product currently is.
What I'd push back on is the framing of Chiplab as a hardware simulator at all. It isn't competing with Renode on simulation fidelity, board coverage, or peripheral modeling, and by its own README it shouldn't be judged as if it were — not yet, anyway. It's closer to a very narrow, opinionated CI check exposed as an MCP tool: "did this ELF boot and print what we expected." That's a legitimate and underserved niche, but it means the interesting engineering bet isn't the emulator itself (Veecle almost certainly isn't reinventing QEMU-grade full-system emulation from scratch server-side) so much as the packaging: making a virtual-silicon boot check something an agent can reach in one tool call, with per-framework instructions written for a model rather than a person.
The open questions that matter more than today's board list: will Veecle publish anything about the accuracy of its chip models against real silicon, the way Renode's platform descriptions are inspectable because the project is fully open? Will peripheral support and CI/CD integration — both explicitly on the roadmap rather than shipped — arrive quickly enough to matter before a better-funded competitor (Antmicro adding an MCP front end to Renode would be a fairly obvious move) closes the gap? And does Veecle have a real business model here, or is "free during beta" masking a cost structure that won't survive contact with paying customers once they need dozens of board variants and CI minutes at scale? None of those are answerable from the launch materials alone, and that's fine — it's an early-stage bet, not a finished product, and it's refreshing that the project's own documentation doesn't pretend otherwise.
Who should try it, and who should wait
If you're already running agentic coding workflows against an STM32 or nRF52 target, especially in a Rust-with-Embassy or Zephyr/FreeRTOS context, and you're doing greenfield or example-level work where uploading firmware to a third party isn't a concern, Chiplab is worth wiring in this week — the setup cost is close to zero and it directly plugs a real hole in agentic embedded workflows. Educators and workshop organizers teaching embedded basics without a hardware budget for every student are a similarly good fit right now.
If your target silicon isn't in the current STM32/Nordic list, if your firmware is commercially sensitive and can't leave your infrastructure, or if you need CI-grade automated regression testing today, this is a "watch the roadmap" tool rather than an "adopt now" one — Renode remains the more capable and more auditable choice for those cases, agent-driven or not. And if you need peripheral-level simulation fidelity — I2C, SPI, ADC edge cases — none of the sources reviewed here suggest Chiplab does that yet; that's squarely Renode and Wokwi territory for now.
The more interesting question than "is it good today" is whether an agent-native interface to virtual silicon becomes the default way coding agents validate embedded work at all, the way MCP itself became a default way to give agents tool access generally. Chiplab is a young, narrow, honestly-labeled bet on that future. It's worth watching specifically because the problem it names — LLMs that can write firmware but have no way to know if it boots — isn't going away, and nobody else has shipped an agent-first answer to it yet.
What would actually convince you to route real firmware through a hosted simulation service instead of a local one — is it the CI integration landing, third-party security audits of the simulation fidelity, broader silicon coverage, or something else entirely?
Sources:
Top comments (0)