For FPGA and ASIC teams, AI is particularly useful when a bounded change has a verifiable result. An assistant can describe a counter, explain an unfamiliar process or derive test ideas from an interface description. That does not establish whether the circuit fulfils the agreed requirement. This introduction separates work you can delegate from the evidence that should accompany every change. A register-transfer-level model, or RTL, describes hardware behaviour between registers and clock edges.
Start with behaviour before writing the prompt
The instruction “write a counter” leaves essential decisions open. Which edge increments it? Is reset synchronous? Does reset override enable? Does the counter wrap at its maximum or remain there? A language model has to fill these gaps somehow. A readable proposal may therefore solve a different problem from the one you intended. Begin with a small decision table and identify unresolved points explicitly as questions.
A suitable task might specify four bits, a rising clock edge, synchronous active-high reset with priority, holding when enable is low, and wrapping from 15 to 0. Add the permitted language standard, libraries and existing interfaces. Ask for explanations against these requirements. A reviewer can then assess the change without reconstructing the preceding AI conversation. Keep the requirements, patch and tests together in version control so that later modifications have a clear starting point.
Three different questions about the same code
Language analysis first establishes whether the selected language settings and dependencies allow the code to be analysed. Simulation executes a model with particular inputs. Requirements checking compares observed behaviour with a previously specified expectation. These layers support each other but establish different facts. A successful compiler run cannot discover an incorrect overflow policy if the description is legal in the language.
| Question | Example | What remains open |
|---|---|---|
| Can the description be analysed? | Types, identifiers and libraries resolve correctly. | Reset priority can still be wrong. |
| Does observed behaviour match? | The value increases after an enabled clock edge. | A short run may never reach overflow. |
| Have requirements been checked? | Directed tests check reset, hold and wraparound. | Physical timing and missing requirements remain outside this test. |
Consider a version that remains at 15. It can compile successfully and simulate the sequence 0, 1, 2 correctly. Only the pre-agreed check “15 followed by one enabled clock gives 0” reveals the disagreement. The testbench, which provides the simulation environment around the design under test, needs an assertion: an executable condition with a failure message. The complete counter application note supplies these checks and deliberately introduced faults without inventing a story about an observed AI mistake.
q = 15
rst = 0 · en = 1
↑ clkRequirement R4 expects wraparound.
The assertion detects the mismatch against the requirement.
Schematic comparison for the original counter example, not a captured measurement. Language analysis and comparison with required behaviour answer different questions.
Tasks that are useful to delegate
Ask an assistant to explain files and dependencies, propose a small change or list the consequences of changing a width. Good tasks have a bounded scope and a clear deliverable: an interface description, a patch or specific diagnostic findings. If project context is missing, an explicit question is preferable to an invented port map. Ask the assistant to state assumptions and preserve existing project conventions rather than redesigning unrelated modules.
For verification, AI can propose additional boundary cases and draft repetitive testbench code. However, requirements and expected results should be checked independently of the proposed RTL. If the same misunderstanding drives both implementation and reference model, they can agree with each other while both are wrong. A useful cross-check is a short manually derived cycle sequence that includes reset and the boundary value. Keep that sequence unchanged while the assistant corrects the implementation.
An agent can run the checks itself
An agent connects a language model to tools. It can change a file, execute an authorised local command and read diagnostics before taking the next step. The official Codex CLI documentation describes file work and command execution. This enables an automated checking loop when the required tools are installed and available under appropriate permissions and licences. Source: OpenAI: Codex CLI.
“The agent tested it” is not sufficient acceptance evidence. Require the actual command, tool version, exit code, source revision and an inspectable result file. A missing licence, interrupted process or absent testbench is not a successful result. Even a zero process exit can be insufficient if no tests actually ran. Define an expected completion marker and a time limit. An unfinished run should remain unfinished in the report, even when the assistant can offer a plausible explanation for it.
Combine project analysis and simulation deliberately
Project context includes more than the currently visible file: library mappings, language version, generated sources, package dependencies and the active configuration. Sigasi provides a CLI for project analysis. Establish which deployment variant and licence are appropriate before automating it. The Sigasi agent application note therefore separates project setup, diagnostic interpretation and stop conditions from simulation. Source: Sigasi CLI manual.
Aldec can then provide a simulation and debugging environment, with the suitable edition and configuration determined by your project. Selecting an AI assistant and selecting a simulator are separate decisions. A generated explanation does not replace a recorded simulation, and a convenient editor does not replace a test case. See AI assistants in Aldec for currently documented integrations and their prerequisites. Evaluate their contribution at the step where you actually need assistance.
Consider confidential code and permissions
Before giving an agent access to a project folder, establish which files it needs for the task. An isolated example is often a better starting point than a complete customer project. Examine the whole data path: editor, extension, agent, model provider, logging and any external services. A compiler running locally says nothing about where an assistant sends source code or diagnostics. Concrete assurances depend on the selected configuration and applicable agreements.
Limit working permissions to those needed for the task. An HDL correction, for example, does not require credentials for a production website. Treat external comments and documents as project material, separately from your own working instructions. Start with a local, reproducible technical loop. Introduce broader automation after you have checked stopping behaviour, result recording and rollback. An agent’s ability to run more commands is useful only when the resulting evidence remains easy to inspect.
Keep acceptance manageable
A practical change loop is to record requirements, preserve the starting revision, make a small patch, run project analysis, execute unchanged tests and review the results alongside the diff. When a check fails, investigate its cause instead of casually lowering the acceptance condition. A necessary requirements change is a separate, visible decision with corresponding test changes. Keeping these decisions explicit makes later failures much easier to interpret.
For choosing the environment, use the open-source and commercial tools decision guide. Bring language versions, operating system, existing IP and a representative test to a discussion of suitable development tools. EDA Praxis is a commercial technical portal operated by eVision Systems GmbH. This introduction is documentation-based; actual example test results are stated only in the linked application note, together with the environment in which they were obtained.