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
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.
Concept intent, system context
Requirements specification, constraints
Architecture blocks, interfaces, clocks
RTL and test bench generation from requirements
Trial synthesis timing, area, fit (meeting point)
Delivery acceptance, sign-off
Simulation functional, coverage, CDC
Requirements lint with AI trace, coverage, quality
Lint static RTL checks
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
Left arm — design (build down)
Right arm — verification (verify up)
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:
Fix in the block
Fix at system level
A legitimate finding with a legitimate fix inside the IP (e.g. unregistered input ports).
Correctly addressed outside the block (e.g. reset synchronisation handled by a top-level reset controller).
Monitor Less meaningful for the chosen FPGA target or context.
Feed back to the LLM for a seconditeration fix.
Raise a waiver with documented rationale; do not modify the block.
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
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
1. Concept State intent and system context; ask the LLM for gaps and ambiguities.
2. Requirements Write necessary, verifiable, achievable, traceable, unique, single-function requirements (SHALL/WILL/SHOULD); define test cases and test-bench data up front.
Owner
Engineer
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.
5. Generate RTL + test bench LLM generates both from the spec, driven by engineer's test vectors; high-level review of intent.
6. Lint (critical gate)
Static analysis BEFORE simulation; categorise findings (fix in block / fix at system level / monitor); feed back; re-run until clean.
7. Trial synthesis Check timing, area, fit; examine resource utilisation.
8. Simulate and review
Functional, coverage, CDC; eyes on waveforms; review test bench against engineer-owned corner cases.
9. Modify and integrate Iterate with the agent; full acceptance review; integrate only on engineer sign-off.
10. Delivery Acceptance against the verification matrix; full traceability; statement of compliance.
AI accelerates the work. The engineer still owns the result.
Engineer
AI (verified)
Tool + Engineer
Registered Office: 1 Bunting Street, Newhall, Harlow, Essex, CM17 9GN
Company Number: 9350139
13 of 14
Engineer
Engineer
Engineer (+AI)
Engineer
