Adiuvo FPGA Development Process

Using an LLM as an Engineering Assistant Using an LLM as an Engineering Assistant Version: 1.0 Author: Adam Taylor

Adiuvo Engineering

1.

Change Log ...................................................................................................................................... 2

1. Purpose and Guiding Principles .......................................................................................................... 3 Two principles that run through every stage...................................................................................... 3 The context package: what you give the LLM..................................................................................... 4 Device and silicon documentation .................................................................................................. 4 Company rules and engineering guides .......................................................................................... 4 Project structure and reuse ............................................................................................................ 4 2. The V-Model Lifecycle ......................................................................................................................... 5 3. Who Owns What: Human vs AI ........................................................................................................... 6 Human-generated (not AI) .................................................................................................................. 6 AI-generated (then verified) ............................................................................................................... 6 4. The Process, Stage by Stage ................................................................................................................ 7 Stage 1 — Concept .............................................................................................................................. 7 Stage 2 — Requirements .................................................................................................................... 7 Stage 3 — Requirements Lint with AI ................................................................................................. 8 Stage 4 — Architecture ....................................................................................................................... 8 Stage 5 — Generate RTL and Test Bench............................................................................................ 8 Stage 6 — Lint: Static RTL Checks (the critical gate) ........................................................................... 9 Stage 7 — Trial Synthesis .................................................................................................................. 10 Stage 8 — Simulate and Review ....................................................................................................... 10 Stage 9 — Modify, Review, and Integrate ........................................................................................ 10 Stage 10 — Delivery .......................................................................................................................... 10 5. RTL Acceptance Checklist .................................................................................................................. 11 6. Engineering Guardrails ...................................................................................................................... 11 Coding standards (selected).............................................................................................................. 11 Design rules (selected) ...................................................................................................................... 11 IP management rules ........................................................................................................................ 12 7. Process at a Glance ........................................................................................................................... 13

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 1 of 14

1. Change Log Version

Notes

1.0

Initial issue

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 2 of 14

1. Purpose and Guiding Principles This document defines an end-to-end process for engineers using a Large Language Model (LLM) as an assistant in FPGA development. It draws together the V-model lifecycle, requirements discipline, coding standards, IP management rules, and the generate-then-lint workflow into a single repeatable process. The central message throughout is simple: AI accelerates the work, but the engineer still owns the result.

Principles that run through every stage Treat the LLM like a junior engineer on the team, not a magic black box. Architect the design yourself, define modules and interfaces before any RTL is written, provide data sheets, IP docs, constraints and coding standards, set the guardrails, and review every output the way you would review a new hire's work. Give it the same support you would give a new hire and you will get the same quality back. The failure mode is “design me an FPGA that does X,” hit enter, walk away — and debug it forever.

Generate with AI, lint with static analysis. LLMs are powerful code generators and unreliable code analysers, the two capabilities do not correlate, and conflating them introduces unacceptable risk.

Use the LLM for the creative, pattern-based work of producing RTL and test benches, then use a deterministic static analysis tool to perform the rigorous structural verification. Neither replaces the other.

Keep the conversation going. At every stage, state your information explicitly and ask the LLM to feed back what is ambiguous, missing, or contradictory before moving on. Vague intent in, vague design out, tight planning is what makes AI assistance reliable.

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 3 of 14

The context package: what you give the LLM Give the LLM the same support you would give a new hire on their first day. A new engineer does not write good RTL from a one-line brief; they are handed the device documentation, the house rules, and the existing code base. Provide the same package up front, the quality of the output is bounded by the quality of the context you supply.

Device and silicon documentation •

• • •

FPGA / SoC data sheets — the target part(s), including logic, memory (BRAM/URAM), DSP, clocking, and I/O resources, and the speed grade. The model must know what it is fitting into before it makes architectural choices.

Errata sheets — known silicon and IP issues and their workarounds. An engineer designs around documented errata; the LLM cannot unless you give it the errata.

Component and peripheral data sheets — for every external device the FPGA talks to (ADCs, DACs, memories, sensors, transceivers), including register maps and timing diagrams.

Interface and protocol specifications — the interface control documents (ICDs) defining the electrical interfaces and the protocols required to communicate with the equipment, plus any standard bus specs in use (AXI, Wishbone, APB, 1553B, SPI, I²C).

Company rules and engineering guides •

•

•

•

Coding standard — the full VHDL coding standard: language version (IEEE-1076-2002 for synthesis, -2008 for test), naming conventions and signal prefixes (i_, o_, s_, v_, g_, c_, t_), formatting, commenting, and header requirements.

Design rules and guidelines — the synthesis and methodology rules: infer registers not latches, register block boundaries, complete sensitivity lists, CDC handling, no delay constants, no top-level glue logic, multiplexed buses over tristate, and so on.

Vendor best-practice guides — the device-family methodology guides the lint stage will enforce (e.g. Xilinx UltraFast, Intel/Altera Quartus, Microsemi RTG4), so the generated RTL is written to pass them first time.

Applicable standards — project compliance standards such as DO-254, plus any EMC, derating, and electrical standards that constrain the design.

Project structure and reuse •

•

•

•

IP library and reuse pointers — the location of existing IP (the BitBucket IP project) and a pointer to every common-library (cl_) element and full IP (ip_) block available for reuse, so the model reuses proven blocks rather than reinventing them.

Repository and folder structure — the standard IP layout (docs, scripts, src, test, xgui, drivers) so generated files land in the right place, and the minimum IP standard the block must meet.

File headers, version tags, and conventions — the header template, author attribution, change-history format, and source-control conventions (branching model, commit discipline, CI).

Constraints — timing constraints, clock definitions, pin assignments, and the engineering budgets (power, mass, memory) the design must live within.

Rule of thumb: if a new hire would need a document to do the task correctly, the LLM needs it too.

Anything you leave out becomes an assumption the model makes for you — and an assumption you will have to catch downstream.

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 4 of 14

2. The V-Model Lifecycle The process follows a classic V-model. The left arm builds the design down through decreasing levels of abstraction; the right arm verifies it back up. The two arms meet at trial synthesis at the bottom.

Each design level on the left is paired with its corresponding verification level on the right.

Left arm — design (build down)

Right arm — verification (verify up)

Concept — intent, system context

Delivery — acceptance, sign-off

Requirements — specification, constraints

Simulation — functional, coverage, CDC

Architecture — blocks, interfaces, clocks

Requirements lint with AI — trace, coverage, quality

RTL and test bench — generation from requirements

Lint — static RTL checks

Trial synthesis — timing, area, fit (meeting point)

Trial synthesis — timing, area, fit (meeting point)

The process is the process. AI-generated RTL goes through exactly the same gates as humangenerated RTL, linting, coding standards, structural checks, vendor design rules, simulation, waveform review, and design review with human sign-off. The process does not change just because the first draft came from a model instead of a person. If anything, it reinforces the need for discipline.

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 5 of 14

3. Who Owns What: Human vs AI A clear division of ownership underpins the whole process. The engineer owns the specification of intent and of correctness; the LLM generates the implementation against that specification. The AI never decides what the design should do, nor what counts as a pass, it only produces code to satisfy definitions the engineer owns. This is precisely why the lint and acceptance gates exist: they check AI-generated output against human-owned definitions.

Human-generated (not AI) • •

• •

Concept — intent, system context, target part, and constraints. The engineer defines what the device must do and where it sits in the wider system.

Requirements — written before any code: necessary, verifiable, achievable, traceable, unique, single-function; SHALL / WILL / SHOULD language; environment, reliability, SIL, and interface content.

Architecture — blocks, data flow, interfaces, and clocking. Modules and interfaces are defined before any RTL is written.

Test bench data — the test vectors, expected results, and golden data (CSV, tables) that define what “correct” means for the nominal, corner, boundary, and failure cases. Supplied up front, not after the fact.

AI-generated (then verified) • •

RTL — generated from the human-written requirements and architecture.

Test bench (structure and code) — the agent produces the bench, but it is driven against the human-supplied test vectors and expected results. The engineer defines the pass/fail criteria; the AI only writes the harness that exercises them.

In short: the LLM generates the implementation (RTL and test-bench scaffolding), while the specification of correctness — concept, requirements, architecture, and test-bench data — stays with the engineer.

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 6 of 14

4. The Process, Stage by Stage Stage 1 — Concept State the intent and system context to the LLM: what the device must do, where it sits in the wider system, the target part, and the constraints you already know. Then explicitly ask it to feed back what is ambiguous, missing, or contradictory. Resolve those gaps before going further.

Stage 2 — Requirements Requirements define the system you are developing. Get them wrong at this stage and the whole project inherits the problem. Write them before any code. Each requirement should satisfy the six core characteristics: 1. Necessary — success cannot be achieved without it.

2. Verifiable — provable by inspection, test, analysis, or demonstration.

3. Achievable — technically possible within the constraints.

4. Traceable — traces up to higher-level requirements and down to lower-level ones.

5. Unique — no duplication and no contradiction between requirements.

6. Simple and clear — each requirement specifies one function.

Write requirements in a SMART manner and use precise modal language: Keyword

Meaning and example

SHALL

Mandatory requirement. “The equipment SHALL have a 1553B interface.”

WILL

States the purpose of the part or system. “The equipment WILL be used to encrypt the telecommands.”

SHOULD

Non-mandatory requirement. “The equipment SHOULD be able to store 10 encryption keys.”

For mission-critical work, the requirement set must also capture the operating reality of the system: system lifetime; operating environments; temperature (maximum, minimum, rate of change); shock and vibration; radiation; EMC / EMI / ESD; MTBF or, better, probability of success; permissible downtime; and SIL with probability of failure / success. Requirements converge from many viewpoints functionality, performance, environment, electrical and mechanical interfaces, other interfaces such as HMI, capability, and stakeholders.

Define test cases up front at the same time: nominal, corner, and boundary conditions; failure modes and out-of-range inputs; with pass/fail criteria fixed in advance, not after the fact. Hand the requirements to the LLM and ask it to flag any that are untestable, conflicting, ambiguous, or incomplete.

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 7 of 14

Stage 3 — Requirements Lint with AI Use the LLM to review the requirements for traceability, coverage, and quality, confirming each requirement is single-function, testable, correctly worded, and mapped to a planned test, and that environment, reliability, and interface requirements are present. This is the verification partner to the Requirements level on the right arm of the V, performed before any RTL exists.

Stage 4 — Architecture You architect the design, blocks, data flow, interfaces, and clocking. Define modules and interfaces before any RTL is written. Provide the LLM with data sheets, IP documentation, constraints, and the coding standards. Identify which requirements are implemented in the FPGA (sub-system segmentation) and capture how they will be addressed (architectural design description). Check the IP library first: a block that could be useful to future projects should be configured as reusable IP rather than written from scratch.

Stage 5 — Generate RTL and Test Bench This is where the LLM is strongest. Generating RTL from a natural-language specification is a creative, pattern-based task that plays to the model's strengths, and it has proven effective at common design patterns, FIFO buffers, state machines, bus interfaces (AXI, Wishbone, APB), serial controllers (UART, SPI, I²C), clock dividers, debounce circuits, and parameterised arithmetic units.

For experienced engineers this can cut initial coding from hours to minutes.

•

Describe the module: functionality, interfaces, behaviour, and corner cases, written out properly.

• Provide rules and reuse: the coding standards plus pointers to every IP core available for reuse.

• Generate both: let the agent produce the RTL and the test bench — never just the RTL. The test bench is AI-generated, but it is driven against the engineer's own test vectors and expected results (Stage 2); the AI writes the harness, not the definition of correct behaviour.

Review the generated code for architectural intent and functional correctness at a high level before moving on.

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 8 of 14

Stage 6 — Lint: Static RTL Checks (the critical gate) Run the generated RTL through a deterministic static analysis tool (for example Blue Pearl Visual Verification Suite) immediately, before simulation, before synthesis, and before peer review. This is the step the LLM cannot reliably do itself: it predicts what a lint report should look like rather than performing the underlying structural computation, it cannot detect its own errors, and it is nondeterministic, so it is unsuitable for any workflow requiring repeatability and audit trails. Static analysis catches the structural issues an LLM misses, width mismatches, clock-domain crossings, latch inference, combinational loops, reset methodology, and FSM completeness, checked against established industry methodologies (Reuse Methodology Manual, STARC, DO-254, and FPGA-vendor best practice guides).

Then interpret the findings with engineering judgement. Do not naively ask the LLM to fix every finding; categorise them into three buckets: Category

Meaning

Action

Fix in the block

A legitimate finding with a legitimate fix inside the IP (e.g. unregistered input ports).

Feed back to the LLM for a seconditeration fix.

Fix at system level

Correctly addressed outside the block (e.g. reset synchronisation handled by a top-level reset controller).

Raise a waiver with documented rationale; do not modify the block.

Monitor

Less meaningful for the chosen FPGA target or context.

Record and watch; no immediate change.

A waiver is not the same as ignoring a warning. It is formal evidence that the finding was reviewed and dispositioned by someone qualified to understand it, with a documented audit trail. This is exactly where the experienced engineer remains essential: an inexperienced engineer who asks the AI to “fix” a system-level reset finding inside the block clears the check but makes the design subtly worse.

Feed the actionable findings back to the LLM, re-run the lint tool to verify closure, and iterate. The loop is complete when the report is clean.

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 9 of 14

Stage 7 — Trial Synthesis Run trial synthesis to check timing, area, and fit (the meeting point at the bottom of the V). Examine resource utilisation, LUTs, FFs, BRAM, DSP against what experience says the design should cost.

Surprises here usually indicate architectural drift.

Stage 8 — Simulate and Review Proceed to simulation and, where required, formal verification, with confidence that the code has passed deterministic structural checks. Cover functional behaviour, coverage, and clock-domain crossing. Put eyes on the waveforms, do not accept just a pass/fail from the bench. Review the test bench: does it actually hit the corner cases and boundary conditions defined in Stage 2? For complex work, supply test vectors and expected results up front as CSV, tables, or golden data.

Stage 9 — Modify, Review, and Integrate Iterate with the agent until the output matches expectations. The output then gets the same scrutiny as any human engineer's, nothing ships unverified. Only once the engineer is satisfied does the work land in the project, with design review and human sign-off at the gate.

Stage 10 — Delivery Acceptance and sign-off against the verification matrix, closing the top of the V. Every requirement traces from specification through to RTL and lab result, with a statement of compliance recording the disposition of each requirement and any deviations or waivers.

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 10 of 14

5. RTL Acceptance Checklist Before any AI-generated RTL is accepted into the project, it passes the same checklist as humanwritten code: 1. Review the RTL yourself — read it line by line. Does it look like what you would have written? Sanity-check structure, naming, style, and intent.

2. Review the test bench — does it hit the corner and boundary cases? Are the tests sensible?

Supply golden test vectors for complex work.

3. Examine resource utilisation — LUTs, FFs, BRAM, DSP. Does it line up with experience?

Surprises mean architectural drift.

4. Run static analysis — lint against the coding standards and the relevant vendor design rules; disposition every finding.

6. Engineering Guardrails These guardrails are provided to the LLM up front and enforced on its output.

Coding standards (selected) • •

•

•

•

Synthesisable models written to IEEE-1076-2002 VHDL; test structures may use IEEE-10762008. English for all identifiers, comments, and filenames.

VHDL reserved words in uppercase; all other identifiers in lowercase. One statement per line for RTL (aids code coverage). Lines ≤ 120 characters (80 recommended). Two-space indents, no tabs.

Signal naming prefixes: i_ inputs, o_ outputs, s_ internal signals, v_ internal variables, g_ generics, c_ constants, t_ types. Signal names ≤ 20 characters; instance names ≤ 10 characters.

Vectors defined (N-1 DOWNTO 0); treat a vector consistently — if any bit is reset or registered, all bits are. Number items from 0. Port and generic maps use named association with all ports explicitly listed (OPEN where needed).

Every source file carries header, design-unit, process, and sub-program comments; no uncommented or temporarily commented-out code may be issued.

Design rules (selected) • •

• •

Infer registers, not latches; do not use latches. Register sub-block outputs and top-level inputs and outputs.

Specify complete sensitivity lists. Avoid asynchronous logic, combinational feedback, and timing exceptions (multi-cycle / false paths). Release reset in a controlled manner, usually registering the external reset input.

For clock-domain crossing use two flip-flop stages for single bits; for multi-bit use gray coding or handshaking, never parallel single-bit synchronisers.

No delay constants in RTL. Prefer signals over variables for synthesisable code. Use multiplexed buses instead of internal tristate buses. No glue logic at the top level.

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 11 of 14

IP management rules • • •

IP is stored and managed in BitBucket within the IP project. Full IP blocks use ip_ repositories; common-library elements use cl_ repositories.

Standard IP folder structure: docs, scripts, src, test, xgui, drivers. All IP uses the same structure.

Minimum IP standard: compiles with no errors; has a compile script (relative paths, runnable from any location); has a self-checking test bench proving its primary features; aligns to the coding standard; has headers and commentary; has a Confluence documentation page from the standard template; and has a nominated owner.

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 12 of 14

7. Process at a Glance Stage

What happens

Owner

1. Concept

State intent and system context; ask the LLM for gaps and ambiguities.

Engineer

2. Requirements

Write necessary, verifiable, achievable, traceable, unique, single-function requirements (SHALL/WILL/SHOULD); define test cases and test-bench data up front.

Engineer

3. Requirements lint with AI

LLM checks requirements for trace, coverage, and quality.

AI (verified)

4. Architecture

Define blocks, interfaces, clocking; provide data sheets, IP docs, constraints, standards; check IP library.

Engineer

5. Generate RTL + test bench

LLM generates both from the spec, driven by engineer's test vectors; high-level review of intent.

AI (verified)

6. Lint (critical gate)

Static analysis BEFORE simulation; categorise findings (fix in block / fix at system level / monitor); feed back; re-run until clean.

Tool + Engineer

7. Trial synthesis

Check timing, area, fit; examine resource utilisation.

Engineer

8. Simulate and review

Functional, coverage, CDC; eyes on waveforms; review test bench against engineer-owned corner cases.

Engineer

9. Modify and integrate

Iterate with the agent; full acceptance review; integrate only on engineer sign-off.

Engineer (+AI)

10. Delivery

Acceptance against the verification matrix; full traceability; statement of compliance.

Engineer

AI accelerates the work. The engineer still owns the result.

Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN Company Number: 9350139 Page 13 of 14