MicroZed Chronicles: AI Development Process
- 4 hours ago
- 5 min read
FPGA Horizons London- October 6th and 7th 2026 - get Tickets here.
The $99 Artix UltraScale+ Explorer Board - learn more here
A few weeks ago, I had the privilege of giving the keynote at the CERN FPGA Developers Conference. It was a fantastic event, bringing together engineers from across industry and research. For my keynote, I wanted to be informative, inspirational, and perhaps a little challenging.
Long-term readers will know that I am a strong advocate for systems engineering and its application to FPGA and SoC development. We begin by defining requirements, developing verification plans, establishing the architecture, and only then move on to implementation and verification.
It is in this disciplined engineering process that I believe AI and Large Language Models (LLMs) can make us significantly more effective and efficient. To use these tools successfully, however, we must have a deep understanding of both the technology and the solution we are developing.

We are certainly not "vibe coding" our FPGA designs.
As a child of the 1990s, I cannot help but think of the engineers in Star Trek. They understood the science and engineering behind every problem they faced. They used advanced tools, but they never delegated responsibility or understanding to those tools.
In my view, this is exactly how we should be working with LLMs for RTL and FPGA development. The engineer remains the system architect, defines the interfaces, understands the implementation, and validates the result. The LLM accelerates the work, but it does not replace engineering judgement.
I view AI as another tool in the FPGA engineer's toolbox. Whether it is the appropriate tool for a particular task remains a decision for the engineer. In many ways, AI represents the next level of abstraction in FPGA development. Over the years we have progressed from logic equations, to schematic capture, to hardware description languages, high-level synthesis, and model-based design. AI is simply the next step in that evolution. As with every previous abstraction, successful engineers must understand both the abstraction itself and what lies beneath it.
So what does an AI-enabled development process actually look like?

I thought I would share the approach we have been developing here at Adiuvo. It has enabled us to reduce development time while maintaining engineering discipline and delivering high-quality solutions.
The approach works equally well with cloud-based AI services such as Codex, Claude, and Gemini, or with locally hosted models such as Gemma and the Qwen Coder family.
This flexibility is important because many commercial and defence projects cannot risk exposing confidential designs or intellectual property to external services.
Before we start, there are several guiding principles that underpin the process.
A successful AI development process combines systems engineering, the V-model, requirements management, verification planning, coding standards, and IP management into a single, coherent workflow.
Ownership is critical. AI may accelerate development, but the engineer owns every design decision and every line of delivered code.
Treat the LLM as you would a junior engineer, not as a magical black box. The engineer should define the architecture, partition the design into modules, specify interfaces, provide datasheets, constraints, coding standards, and implementation guidance. A useful rule of thumb is simple. If a new graduate joining the team would need the information, then so will the AI.
Use linting and static analysis tools to ensure generated RTL complies with coding standards and recognised best practices.
Keep the conversation going. At every stage, provide context explicitly and ask the AI to identify anything that is ambiguous, incomplete, or contradictory.
Most importantly, AI-generated RTL must pass exactly the same verification process as engineer-written RTL. Simulation, formal verification, CDC analysis, timing closure, and hardware validation remain unchanged. AI accelerates development, not sign-off.
The information we provide to the AI is equally important. Typically, this includes:
FPGA and SoC datasheets.
Device errata.
Component datasheets.
Interface and protocol specifications.
Company coding standards and design rules.
Vendor best practice guides.
Relevant industry standards.
Existing IP libraries and reuse guidelines.
Folder structures, naming conventions, file headers, version tagging, and project organisation.
The guiding principle throughout is simple. The process remains the process. We do not take shortcuts simply because AI is involved. Systems engineering, verification, and engineering judgement remain central throughout the development lifecycle.
The complete process we use is considerably more detailed than I have described here, but I have made it available for anyone who is interested. Like AI itself, this process continues to evolve as new capabilities emerge.
One thing, however, seems increasingly clear. Engineers who learn how to integrate AI into disciplined engineering processes will have a significant advantage over those who choose to ignore it.

The future of FPGA development is not about replacing engineers. It is about enabling engineers to deliver better solutions, more quickly, while maintaining the engineering rigour that our industry depends upon.
FPGA Conference
FPGA Horizons London- October 6th and 7th 2026 - get Tickets here.
FPGA Journal
Read about cutting edge FPGA developments, in the FPGA Horizons Journal or contribute an article.
Workshops and Webinars:
If you enjoyed the blog why not take a look at the free webinars, workshops and training courses we have created over the years. Highlights include:
Upcoming Webinars Timing, RTL Creation, FPGA Math and Mixed Signal
Professional PYNQ Learn how to use PYNQ in your developments
Introduction to Vivado learn how to use AMD Vivado
Ultra96, MiniZed & ZU1 three day course looking at HW, SW and PetaLinux
Arty Z7-20 Class looking at HW, SW and PetaLinux
Mastering MicroBlaze learn how to create MicroBlaze solutions
HLS Hero Workshop learn how to create High Level Synthesis based solutions
Perfecting Petalinux learn how to create and work with PetaLinux OS
Boards
Get an Adiuvo development board:
Adiuvo Embedded System Development board - Embedded System Development Board
Adiuvo Embedded System Tile - Low Risk way to add a FPGA to your design.
SpaceWire CODEC - SpaceWire CODEC, digital download, AXIS Interfaces
SpaceWire RMAP Initiator - SpaceWire RMAP Initiator, digital download, AXIS & AXI4 Interfaces
SpaceWire RMAP Target - SpaceWire Target, digital download, AXI4 and AXIS Interfaces
Embedded System Book
Do you want to know more about designing embedded systems from scratch? Check out our book on creating embedded systems. This book will walk you through all the stages of requirements, architecture, component selection, schematics, layout, and FPGA / software design. We designed and manufactured the board at the heart of the book! The schematics and layout are available in Altium here. Learn more about the board (see previous blogs on Bring up, DDR validation, USB, Sensors) and view the schematics here.
All words in this blog were written by a human.

