How compile and synthesis is done in our flow
Follow original RTL through isolated Icarus compilation and generic Yosys synthesis—and understand what a passing check does not prove.
HDL Arena compares two AI implementations of the same hardware specification in one selected HDL language. The generated source is the starting point for separate tool checks, not the final answer about correctness. Understanding what those checks do makes their results useful without giving them more authority than they deserve. A successful compile, a generic synthesis report, an AI review, and a human vote answer four different questions.
From the original generation to independent checks
The selected models generate independently and concurrently. As each implementation arrives, the application saves the original output and queues its tool check. A separate AI reviewer reads the requirements and implementations; it does not receive tool results and is instructed not to invent them. Voting waits for completed generation and review, but a slow or unavailable tool check is not a declaration that the RTL is bad.
Before voting, model identities, AI reviews and scores, and tool reports are withheld from the normal battle presentation. After voting, the model identities and available reports are revealed. This separation helps keep a preference vote from becoming a vote for a familiar model name or a reassuring green status. The checks operate on the original generated source; they do not automatically rewrite or repair it.
A bounded, isolated tool environment
Generated code is untrusted input. The checker launches fixed tool commands inside a namespace-isolated environment with no application credentials. It exposes the required immutable toolchain and a temporary working directory rather than the project workspace. CPU, memory, file size, open-file, diagnostic-output, and wall-clock limits bound the work. The queue is also bounded, with limited parallel workers, so a large design cannot demand unlimited service resources.
If tools are missing or isolation cannot start, the checker fails closed and reports unavailability. It does not silently retry outside the isolation boundary. Queue saturation, expiration, and resource limits can prevent a check from finishing. These operational states must not be interpreted as functional failures. Source over the checking size limit or containing invalid bytes is rejected, while policy-limited features can be marked unsupported.
Language support and top-module selection
The checking flow supports Verilog and a subset of SystemVerilog. VHDL generation is available in the product, but this Icarus/Yosys flow does not check VHDL. SystemVerilog accepted by the compiler may still contain constructs unsupported by the synthesis frontend. A language being offered for generation is therefore not a promise of complete tool coverage.
The worker identifies ordinary module declarations after removing comments and looks for a unique root module not instantiated by another module. Duplicate names, multiple roots, or ambiguous hierarchy are unsupported rather than resolved by guessing. Keep one clear design top and include its required submodules in the submitted source. External includes, macros and conditional compilation, file-based memory loading, file I/O, and external calls are outside this checking stage’s policy; timescale and default_nettype directives are exceptions.
What Icarus compilation establishes
The worker invokes Icarus with Verilog-2005 mode for Verilog or the 2012 language mode for SystemVerilog, selects the detected top, and uses the null target. It checks whether that source can be compiled and elaborated by this tool under those settings. It does not execute a generated testbench, apply input vectors, or run functional simulation. A compile pass can catch syntax and some elaboration problems while missing a wrong state transition or arithmetic requirement.
iverilog -g2005 -t null -s <detected_top> candidate.sv
# SystemVerilog uses -g2012 instead of -g2005.What generic Yosys synthesis establishes
Only after compilation passes does the worker ask Yosys to read the source, check hierarchy, synthesize the selected top, flatten the design, check the resulting structure, and report statistics and a longest topological path. The outline below documents the fixed flow; the top name is detected by the worker, not supplied as an arbitrary shell command by the user.
read_verilog -sv candidate.sv; hierarchy -check -top <detected_top>; synth -top <detected_top>; flatten; check -assert; stat; ltpThe report’s cell count is a generic synthesized-cell count. Although the interface may call it an area estimate, it is not physical silicon area, FPGA utilization, power, or a library-characterized implementation cost. Likewise, logic depth is a structural path length, not a delay in nanoseconds or sign-off timing. No target cell library, placement, routing, or static timing sign-off is established by this flow.
A smaller count can even accompany missing functionality. Comparing counts is only meaningful after establishing equivalent requirements and behavior in your own verification flow. DSP or block-RAM inference depends on coding style, target architecture, and technology mapping; generic synthesis does not establish that a particular device resource will be used. Never choose a winner solely because one output reports fewer cells.
How to act on a report
- Read failed diagnostics as tool evidence about this source and tool configuration, not a universal verdict on an HDL language.
- Distinguish unsupported features, rejected inputs, timeouts, execution limits, and unavailable infrastructure from a normal compiler failure.
- After voting, you can manually save and recheck a revision; it remains separate from the original model output and original vote.
- Run your own functional simulation, assertions or formal checks, target synthesis, and timing analysis. HDL Arena does not automatically repair RTL or perform functional verification.