ItInsightsWorld AI Applications Guide: How Agentic Layers Are Landing in Embedded Toolchains

Anyone deciding where the next slice of AI budget should go will find the embedded toolchain an unusually honest reference point. Nothing in this category is a chat window bolted onto a website: an agent is expected to configure a device, generate code for a specific microcontroller, drive a debugger, or produce an interface that must live inside a fixed memory envelope. A wrong pin mapping or an omitted clock setting is discovered by a board that refuses to boot, which is exactly why the implementations now reaching market share one design rule — the agent is handed context plus guardrails, and a named engineer keeps sign-off.

Read as application case studies rather than model news, they answer the recurring questions of this column: which task is actually automated, what still has to be verified by a human, and what the toolchain owner must supply before a pilot behaves.

AMD Ross: a harness sitting between engineers and every tool

Kirk Saban, AMD's vice president for Product, Software and Solutions, framed the shift for eeNews Europe as "Natural language as the new abstraction layer for embedded in both the hardware and software domains," and added that "The fundamental game changer has been the advent of large language models (LLMs) with the ability to describe the problem in natural language."

The pain he names is procedural rather than theoretical: "One of the key things we see in embedded is that we deal with all different types of domains, form factors, use cases, and that requires a lot of different disciplines and architectural trade-offs," followed by "There’s often many manual handoffs and there are lots of different tools out there and as the chips have become more complicated so have the tools."

Ross is the answer AMD built for that handoff problem: an interface harness that lets its toolchain communicate across multiple tools. The product name follows Anthropic’s Claude AI convention and honours Ross Freeman, inventor of the Field-Programmable Gate Array (FPGA), former director of engineering at Zilog, and a co-founder of Xilinx alongside Bernie Vonderschmidt and James Burnett. "AMD Ross spans the entire paradigm of our development stack, running alongside and plugging into all the different tools," Saban said, with reach covering Vivado FPGA design tools, the Vitis unified IDE development environment, Ryzen embedded processor AI tools and the ChipScope integrated logic analyzer.

For evaluation scorecards, the model-neutrality statement is the load-bearing one: "We are not in the business of creating LLMs – Ross will plug into any of the public model providers, but we also support open weight models. It’s a harness across our entire development stack. We are giving a harness for you to adapt to your design environment," Saban said. "It is the same with IDE tools, we work with all the major players in the industry."

Case read-out: the 300-megapixel sensor benchmark

Saban cited one measurable comparison: in a 300-megapixel sensor development using an FPGA for image processing, handwritten C++ code for the HLS algorithm takes two days and uses 1801 lookup tables (LUTs), while Ross completes the work in two hours and uses 1177 LUTs. Designers have had early access since June, with over 800 customers using it for FPGA development in Vivado, and monthly updates are planned.

Skills, MCP access and the air-gap requirement

"You can use LLMs such as Claude today to run tools such as Vivado and we will be working on all the point tools to make them more agentic friendly with output files that are more friendly to agentic tools," Saban said. "We use MCP which is Anthropic’s database interface to LLMs. Through MCP servers we will give access to our entire knowledge base with access to all the documentation."

"The other piece is making skills available, such as design rules for board layout, best practices for timing closure in an FPGA, published through the agent skills repository. We also see that customers will want to use the knowledge in their own way and they can plug that into their own workflows."

Deployment boundary conditions are stated explicitly, which is what a regulated buyer needs first: "We understand the importance of the airgap for safety and security. Ross can run inside the firewall so you are not putting anything into the public domain. The customer gets to decide the level of access to models and data. We use Claude in AMD sandboxed and firewalled with an LLM gateway."

Saban described Ross as building a skills ecosystem around AMD devices. "We can provide specific skills, for example pipelining, timing closure, partitioning but customers can deploy their own skills internally or to publish, and partners can develop skills. We have design and tool agents, a specification agent and a code creation agent. We will publish 20 skills with the initial release but this will expand rapidly," he said — and on governance of the community itself: "We know the embedded development community very well, they need to be in control, we are very conscious of that and Ross is working alongside the engineers."

The repository will expose all the skills, even though industry-level challenges remain; the skills start as plain text markdown files and that format will evolve. "We are actively evaluating this. Initially it will be in a repo as a plug in with the skills and MCP server and through the MCP server you get access to the AMD database so it gets you to an answer more efficiently with less tokens," said Saban. Asked whether Ross could support a digital twin, he replied: "To do that there are several things that need to happen. Some of the IP models need a software-centric model and some of that IP is ours, some is from third parties, we don’t have a firm plan today but I can see the industry moving to that over time and the whole ecosystem needs to evolve,".

AdaCore: agents boxed in by formal properties

Safety-critical work is where an application team most fears unverified output. AdaCore is applying AI to embedded code for such systems using Ada, SPARK and GNAT Pro. Mark Hermeling, head of technical marketing at AdaCore, is blunt about the cost of the traditional route — "We know that Spark requires an additional level of effort. You can write it without the additional formal methods, but it is harder," — and equally precise about where a model removes toil: "But if you have Ada code and you want to lift that to SPARK Silver [to guarantee the absence of runtime errors], AI can do that in an LLM, every time. This is a tremendous offload for the developer."

The demonstration is a travel-length one rather than a lab benchmark: Hermeling took a standard STMicroelectronics C data-gathering demo, converted it to Ada, and lifted it to SPARK Silver on a laptop during a flight from Los Angeles to Toronto. That work produced six areas for inspecting incoming data and can also set selected functional properties, typically for safety or security, at the next level; SPARK Gold and SPARK Platinum cover the full formally proven design for safety critical code such as automotive, aerospace or encryption. "So whatever AI does it can never violate those requirements, so it’s really easy for developers to elaborate the code while staying completely safe," he said.

Teams wanting to reproduce the pattern find the AI support delivered through a skills repository hosted on Github. "This includes what we have learned over the last six to nine months," he said, describing a move away from protocol-only plumbing: "We started with Model Context Protocol (MCP) but this is not necessary for command line tools, the skills do that. Specifically, the Connect skill codifies SPARK best practices. Grab the skills from the repo and use the Prove skills. This spawns a set of agents in a particular pattern to lift the Ada code to SPARK Silver," he said.

"What GNAT Foundry provides is a workflow for agents to follow the V-model for requirements. There’s an agentic framework with discrete steps and for each step there is an oracle that checks whether the AI is doing the right thing," Hermeling said. The repository has been cloned by 250 people so far and contains an example high integrity traffic light system that can be extended with AI, moving from high level requirements to low level code while maintaining Gold-level properties.

The review economics he describes belong in every business case: "The frontier models are brilliant, but LLMs are intelligent parrots that are trained on poor C code as perfect C code doesn’t exist. One of the challenges with AI is its ability to generate vast amounts of code that you can’t possibly verify," said Hermeling. "With GNAT Foundry you don’t have to. As long as an engineer has reviewed the Gold level properties then it doesn’t even matter if every single line of code has been tested."

He cited automotive ISO 26262 ASIL-D safety critical code where a frontier model found a handful of memory violations and also provided exploits. "Customers can fix those violations but next week’s model will find more. We have to find a different way of doing software engineering," he said. "Writing code becomes less important, software engineering becomes more important – you come up with the design and how to componentise, that’s what the Gnat example shows," he said. "There’s a ton of pressure to write and ship so I would always wrap code with as many oracles as I can – that’s what people have to keep in mind – LLMs like humans can make mistakes."

Infineon Technologies: pushing device context into the editor

Infineon Technologies is broadening its ModusToolbox tools with an AI assistant extension for microcontrollers, and the failure mode it targets is one every embedded program manager recognises: an incorrect pin assignment or an omitted clock configuration can force teams to spend hours debugging physical boards, while generic AI assistants often lack the device-specific context needed to catch such problems early.

The ModusToolbox AI Assistant for Microsoft Visual Studio Code (VS Code) gives AI coding agents hardware-specific context for PSOC Edge and PSOC Control controllers. Lacking that context, generic AI coding assistants can produce code that looks plausible but fails on real hardware — output that might target the wrong device, call deprecated APIs, or skip an initialization step that only becomes visible during board bring-up. Every suggestion is tied by the ModusToolbox AI Assistant to the developer’s actual target device, board, and peripheral configuration. Project context is evaluated locally, and customer project data remains on the developer’s system. Typical uses include connected IoT devices that combine graphics and connectivity functions.

The implementation detail that determines effort is how context is gathered: local workspace analysis of the project structure, board support package, installed middleware, code examples and available tools, which the extension then converts into device-specific instructions and development skills for the agent. Coverage includes peripherals such as GPIO, I2C, SPI, UART and DMA, along with connectivity and RTOS functions; with that targeted context the AI agent can generate more accurate code while consuming fewer tokens.

Two workflow behaviours carry governance value. Prior to code generation, the assistant creates a project plan for developers to review and refine, specifying the target device, board, libraries and project structure. The workflow also supports migrating existing projects to other Infineon devices, and future releases will add support for PSOC 4, PSOC 6 and TRAVEO T2G families.

Tasking: agentic debugging that can survive certification review

Embedded teams — especially those building complex, multicore applications — must deliver increasingly complex, functionally safe software within tighter timelines. Although AI can help write, test, and verify software, requirements traceability still puts full responsibility for all AI activity on developers.

Tasking has introduced certifiable agentic AI for embedded debugging analysis. Developers may choose their own LLM and agentic AI to automate software development, but the setup supports requirements traceability and simplifies certification to functional safety standards. AI agents can connect to Tasking’s unified toolchain through the winIDEA development environment using the tools and files; when agents are reachable inside the development toolchain, developers can automate several workflows, speeding software design and verification while preserving strict requirements traceability for certification.

Within winIDEA software workflows, the tools integrate AI and give generically trained LLMs context on how code or scripts should be generated, improving developer productivity while keeping the traceability needed for certification to industry standards. Guardrails limit what AI may do, and human oversight keeps accountability intact as AI supports the development lifecycle without compromising reliability, functional safety, or security.

"Our approach to AI accelerates complex, multicore embedded development by giving agents structured access to debug and analyse workflows," said Janez Ulcakar, Director of R&D Debugger Solutions at Tasking. "This enables agentic-based automation to work with real-time debug evidence while ensuring engineers remain in full control of AI processes and conclusions. This is essential for systems that need to be certified to functional safety standards."

Integration scope maps neatly to a bill of materials: the winIDEA AI Kit brings together three maintained components. The first is an MCP server providing structured access to design tool capabilities, including debug control, memory, variables, breakpoints, trace, coverage, profiling and timing analysis. AI-ready winIDEA SDK documentation helps agents create accurate automation scripts in supported programming languages, while embedded-development skills provide task-oriented guidance and context for debugging, timing analysis, winIDEA configuration and device-specific workflows. As a result, teams can ask an AI agent to perform tasks rather than build and maintain a large library of custom scripts or tool instructions.

Qt group and IAR: no-code UI that still ships real code

The same shift is changing which languages and environments teams commit to: work moving away from languages such as C++ toward memory-safe Rust with AI support, digital twins with AI models of components, and no-code development environments.

The Qt group, whose portfolio includes the IAR development tools, has built an AI-native, no-code tool for embedded interfaces. Clate is currently in beta testing and seeks to reduce reliance on generic web and mobile design tools. Its AI-native integration supports natural language prompting for actions such as screen generation and design changes, and it uses MCP to connect directly with other design and productivity tools. It outputs production-ready QML code, a declarative programming language designed for building user interfaces.

"For too long, embedded UI/UX designers have had to compromise their work, using web-centric tools that simply don’t account for real-world hardware constraints," said Antti Kujala, Vice President, Design Products at Qt Group. "We created Clate to end that compromise, and to give designers back full control and ownership of the user experience. Designers won’t need in-depth knowledge of code either. Clate runs on Qt, and generates QML production-ready code automatically in the background. And, as an AI-native workspace, Clate connects across a designer’s ecosystem through standard MCP protocols, allowing teams to prompt changes using natural language, without disrupting their natural flow. For the first time, designers can be confident that the UI and UX they create will be exactly what the end-user experiences."

A suite of planned features is set to arrive in early 2027 with AI assistants, integrations, and production-ready QML code output. Embedded hardware optimization features, including frame rate and memory consumption checking, will follow shortly after the initial release.

Language policy inside an Ada house: the Rust question

"If people starring new projects in C++ right now I really question whether that’s the right thing to do, why would you not start in Rust," asks Hermeling at AdaCore. "There’s enough libraries for that and AdaCore is working to get there with Rust. We support Rust to the same level as Ada as we understand that people want to use it unless you have requirements for high levels of high integrity and then Ada does that."

Side-by-side: what each agentic layer automates, and what it still needs from you

Agentic layer	Application task automated	Context the toolchain must supply	Human control point
AMD Ross	FPGA and embedded development flows across Vivado, Vitis, Ryzen AI tooling and ChipScope; HLS code generation	Harness that plugs into public model providers and open weight models; MCP server access to the AMD knowledge base	Runs inside the firewall; customer decides access to models and data; LLM gateway sandboxing
AdaCore skills repo + GNAT Foundry	Lifting Ada to SPARK Silver; requirements-driven V-model workflow	Skills cloned from the Github repository; Prove and Connect skills	Oracle per step; engineer reviews Gold-level properties
Infineon Technologies ModusToolbox AI Assistant	Code generation for PSOC Edge and PSOC Control; project migration	Local workspace analysis: project structure, board support package, middleware, examples, tools; GPIO, I2C, SPI, UART, DMA, connectivity, RTOS	Project plan reviewed and refined before code generation; data stays on the developer’s system
Tasking winIDEA AI Kit	Debug and analysis automation on multicore targets	Three components: MCP server, winIDEA SDK documentation, embedded-development skills	Guardrails, human oversight, requirements traceability for functional safety certification
Clate (Qt group / IAR)	Screen generation and design changes via natural language, output as QML	MCP links into the designer ecosystem; runs on Qt	Beta today; frame rate and memory consumption checks arrive shortly after initial release

Implementation path: six steps from pilot to production

1. Map the handoffs first. Saban's diagnosis is your scoping document: manual handoffs and tool sprawl grow as chips grow more complicated. Instrument the steps that consume board-debug hours before choosing an agent.
2. Supply the context layer. The Infineon pattern shows the work involved: analysis of project structure, board support package, middleware, examples and tools, plus peripheral coverage. An agent without device context produces plausible code that fails on hardware.
3. Force a plan before generation. Require the tool to emit a reviewable project plan naming target device, board, libraries and project structure, and treat that review as a gate, not a formality.
4. Bind every agent step to an oracle. The GNAT Foundry design — discrete steps, each with a check on whether the AI is doing the right thing — is the transferable control, and Hermeling's advice is to wrap code with as many oracles as you can.
5. Fix the data boundary. Decide what may leave the network: air-gap or in-firewall operation, an LLM gateway, local evaluation of project context, and a customer-set level of access to models and data.
6. Assign traceability and sign-off. Certification to functional safety standards still rests on requirements traceability and named human review; automation should speed design and verification, not move accountability.

Selection checklist for application owners

• Does the harness accept any public model provider and open weight models, so you are not locked to one vendor's LLM?
• Is there a skills repository you can clone, audit and extend, and does it ship with worked examples such as a high integrity traffic light system?
• Does the assistant understand your exact target device, board and peripheral configuration, or only generic patterns?
• Are project files analysed locally, and can you prove customer data remains on the developer's system?
• Is token consumption addressed through targeted context, which also improves accuracy?
• Can existing projects migrate to other devices in the family, and is the roadmap for PSOC 4, PSOC 6 and TRAVEO T2G credible?
• Is the product generally available or beta — as with Clate — and which capabilities only arrive in early 2027?
• Do the guardrails, debug evidence and traceability support an eventual functional safety audit?

Common misconceptions to design against

• "We will review generated code line by line." Hermeling's counter is economic: AI can generate vast amounts of code that you cannot possibly verify; the practical unit of review is the formal property, not the statement.
• "The next model release will finish the job." Violations fixed today will be joined by new ones found by next week's model; the change required is in software engineering method, not model version.
• "A good prompt replaces device knowledge." Generic assistants can target the wrong device, call deprecated APIs, or skip initialization that only appears during board bring-up.
• "No-code means no engineering." Clate still emits production-ready QML code in the background, and hardware constraint checks such as frame rate and memory consumption arrive as separate capabilities.
• "Agents take the accountability." Requirements traceability keeps full responsibility for all AI activity with developers, with human oversight preserved by design.

FAQ

Does Ross force a specific large language model on the team?

No. Saban states AMD is not creating LLMs; Ross plugs into any of the public model providers and also supports open weight models, and the same openness applies to IDE tooling partners.

Can AI be trusted with safety-critical formal methods?

Within limits that AdaCore defines for you: lifting Ada to SPARK Silver is described as something an LLM can do every time, while SPARK Gold and SPARK Platinum remain the territory of full formally proven design for automotive, aerospace or encryption work, gated by human review of Gold-level properties.

What does the Infineon extension change during board bring-up?

It ties each suggestion to the actual target device, board and peripheral configuration, so the class of plausible-but-wrong output that surfaces only in hardware testing is reduced before generation begins.

Is agentic debugging allowed in a certification path?

Tasking's position is that it is, provided the agent has structured access through the winIDEA AI Kit, guardrails limit its actions, and real-time debug evidence plus requirements traceability are retained for functional safety standards.

Should a new embedded project start in C++?

Hermeling openly questions that choice and points to Rust, with Ada reserved for the highest integrity requirements — a policy decision your architecture board should make deliberately.

Action recommendations

1. Run one narrow pilot on a flow that today consumes board-debug hours, and instrument it against a baseline such as handwritten C++ for HLS work.
2. Adopt the plan-before-code gate and the per-step oracle pattern in your definition of done, regardless of which vendor wins the toolchain.
3. Write the access policy for models, data and network boundaries before the first agent touches a repository.
4. Treat skills and documentation as assets you own: evaluate what your team can publish internally, and what partners should be allowed to contribute.
5. Keep certification artefacts — traceability, evidence, reviewer names — outside the agent's control.

The pattern worth taking from these toolchains is not that agents write code, but that successful deployments surround generation with structure: device context, a reviewable plan, machine-checked steps and an explicit boundary on what leaves the network. If your organisation is weighing where AI should touch product engineering next, start where a wrong answer is caught by hardware rather than by users — and measure the harness, not the model.