Three tool roles require different evidence
An assistant inside an HDL editor can explain an interface, propose a code skeleton or summarize an error message. Its answer does not replace project configuration or an executed compilation or simulation run. A useful evaluation starts by establishing which product version provides the feature, which service processes requests and which independent checks will follow generated code. This article separates the current vendor statements and provides a small original evaluation workflow.
Aldec describes HDLCopilot as an OpenAI API-based aid available from Active-HDL 15 and invoked in the HDL editor. The current public download page also names a document about Active-HDL 17; its contents require access and were not read here. The introduction reference to version 15 therefore does not mean that version 15 is the current product release. Aldec: HDLCopilot in Active-HDL; Aldec: What is new in Active-HDL 17 (access page).
For Riviera-PRO, Aldec describes AI Assistant as an addition in 2026.04 and mentions support for several AI service platforms. That public text does not establish which local model endpoints, protocols and models a particular installation supports. ALINT-PRO contributes static RTL and constraint analysis to this workflow; no generative assistant is inferred from that role. Aldec: AI Assistant in Riviera-PRO 2026.04; Aldec ALINT-PRO.
Setup: From the installed version to a controlled first request
Start with your own small project containing no customer source code. Record the product, installed version, operating system and edition. Windows is documented as the Active-HDL product platform. Open the help supplied with the installation and compare its assistant description with the vendor presentation. This research examined publicly visible descriptions but did not practically follow an embedded video demonstration. It therefore supplies no invented dialog names or menu sequences. Aldec Active-HDL; Aldec: HDLCopilot in Active-HDL.
- First establish that the project works in the intended compiler without AI. This separates later integration problems from pre-existing project faults.
- Invoke the assistant from the HDL editor as described for the installed release. If it is unavailable, resolve version and entitlement questions before adding components.
- Configure only an organization-approved provider using the installation’s actual settings. API keys belong in the designated secret storage, not in HDL files, prompts or screenshots.
- Check the service account, possible charges and data terms separately from the EDA licence. Owning a simulator licence does not establish free or unlimited model usage.
- Begin with the non-confidential text task below. Before sending, check which selected material and additional project context will be transmitted.
- Initially treat an answer as an inspectable proposed change. Compare it with the specification, compile it and then run the independent functional tests.
An API or connection error in the interface is not an HDL finding. Record the time, product version and a sanitized error message. Credentials, responses containing confidential sources and complete request traces do not belong in public support posts. Following a failed request, do not evaluate the application as though its assistant had already checked the code.
An original prompt with a checkable result
A short behavioral specification is more useful than asking for “good VHDL code.” This original example defines priority, state changes and output format. It was not used as a measured Aldec assistant response. You can use it to compare approved configurations as long as the specification and test cases remain unchanged.
Create a VHDL-2008 four-bit unsigned counter using numeric_std.
Ports: clk, rst, enable, count(3 downto 0).
On each rising edge: synchronous active-high reset has priority.
Otherwise increment by one when enable is high; otherwise hold.
Overflow wraps modulo 16. Do not add asynchronous behavior.
Return the entity and architecture, then list assumptions.
Do not claim compilation or simulation unless you actually ran tools.
Do not change these requirements to fit your implementation.
Assess the answer against the requirements, rather than its confident language. Are the port types and width correct? Is reset actually synchronous? What happens when reset and enable are asserted together? Does the response introduce nonstandard arithmetic packages? An explanation may sound correct while the associated process implements a different priority. Compare source code and explanation together.
-- Deliberately unsuitable priority for the stated requirements:
if rising_edge(clk) then
if enable = '1' then
value <= value + 1;
elsif rst = '1' then
value <= (others => '0');
end if;
end if;
This intentionally faulty fragment is our own example. It can appear syntactically ordinary while violating the requirement: when enable and reset are both asserted, it increments. It is not a recorded vendor-model response. The corresponding negative check must assert both inputs and determine the expected zero value independently. A testbench derived by an agent from its faulty process could reproduce the same incorrect priority.
| Test case | Independently expected behavior |
|---|---|
| Reset and enable together | Zero after the active clock edge. |
| Enable without reset | Previous value plus one, modulo 16. |
| Neither enable nor reset | Previous value unchanged. |
| Previous value 15, enable asserted | Wrap to zero. |
| Reset changes between edges | No synchronous state change before the next active edge. |
Inspect data flows, particularly for Riviera-PRO
- Project / editor
The permitted selection and any additional context form the request.
- Configured model provider
Process the request and return a text or code proposal.
- Back in the project
Review the proposal as a diff; then run analysis and independent tests.
Which files and diagnostics reach which service? What storage, logging and further sharing are agreed for this configuration?
Conceptual data flow, not a measured vendor transmission. A local compiler does not establish local model processing. Availability of local Riviera model endpoints is not assumed here.
Distinguish at least four stages: local source files, assembled request context, model processing and local verification of the answer. The simulator may run locally while the model request reaches an external service. Conversely, a selectable provider name does not prove support for arbitrary local servers. The public Riviera presentation establishes multiple service platforms but provides insufficient detail for a local-deployment guarantee. Aldec: AI Assistant in Riviera-PRO 2026.04.
If local model processing is a project requirement, obtain specific information about the supported endpoint, authentication, model format and version before production use. Also examine the network connections established by the selected configuration and whether ancillary services are involved. Leave the conclusion open until that evidence exists. No such test was performed for this article; a blanket statement that everything stays local would be unsupported.
For external services, define the permitted context in advance. One selected function can already expose internal signal names, protocol details or comments. Limit the first attempt to the original example. In real projects, do not rely only on the short selection visible in the editor: the integration’s actual transmitted context matters, not the length of the typed prompt.
Compilation, simulation and ALINT-PRO remain separate checks
Active-HDL and Riviera-PRO provide HDL simulation and debugging tools; treat the assistant separately as a source of proposals. Successful compilation does not establish whether reset takes effect on the correct clock edge. A successful simulation applies to the executed cases and the models used. Preserve the source revision, testbench, invocation and result together. Aldec Active-HDL; Aldec Riviera-PRO.
ALINT-PRO can add static rules and structural checks, including clock and reset crossings. Record which rule sets and configurations are actually active for the project. An assistant may explain warnings, but automatically proposed waivers should not be accepted without technical justification. Removing a warning by disabling its rule does not improve the design. Aldec ALINT-PRO.
For an initial evaluation, keep three results separate: did the integration return an answer, does the unaltered proposed change compile, and does it pass the previously specified tests? Only several real tasks with recorded effort can establish whether an assistant saves time in your workflow. This example does not support general productivity percentages or a blanket claim of better HDL quality.
Verification scope and next step
Documentation-based; vendor tool testing remains outstanding. Sources were checked on 19 October 2026. Active-HDL HDLCopilot, Riviera-PRO AI Assistant and ALINT-PRO were not executed for this article; no model request or data-flow test was recorded. Access-controlled release presentations were classified only from their visible entry pages. The prompt and deliberately faulty VHDL fragment are our own teaching examples.
The independent VHDL simulation note covers subsequent functional checks. To select a version, licence and suitable operating model, request Aldec advice. Bring a non-confidential sample task, the required HDL language and your model-deployment constraints.
Sources
Aldec: HDLCopilot in Active-HDL · Aldec Active-HDL · Aldec: What is new in Active-HDL 17 (access page) · Aldec: AI Assistant in Riviera-PRO 2026.04 · Aldec Riviera-PRO · Aldec: Riviera-PRO 2026.04 presentation (access page) · Aldec ALINT-PRO