A simulator is rarely used by only one person for a single design. It must fit existing libraries, test environments, operating systems and working practices. A good evaluation therefore represents everyday use. This checklist can serve as a work plan: gather requirements, check mandatory capabilities, investigate typical failures and assess operation under realistic conditions. A product name alone is not yet a verifiable configuration.
1. Define the scope of the decision
Start with the next concrete project and add foreseeable requirements. Record the languages, language versions, target devices, external IP and test frameworks used. Distinguish definitely required features from possible future additions. This avoids both an underspecified choice and buying capabilities in advance without a demonstrable need. A short prioritised list is usually more useful than a long unstructured questionnaire.
Also identify who uses the simulator: RTL developers, verification specialists, integrators or an automated runner. A graphical interface and an overnight batch run have different operational requirements. Record which activities happen concurrently and which results are handed between people. Only then can an appropriate licence and workstation configuration be requested.
2. Demonstrate language and library compatibility
- Analyse representative RTL sources using the intended language version.
- Check the actual testbench constructs, including assertions or classes.
- Include vendor libraries and encrypted IP in approved versions.
- Test mixed-language boundaries for widths, parameters and reset values.
- Repeat a complete build in a new output directory.
For every discrepancy, record a small reproducing example. “SystemVerilog does not work” is too broad to help find a solution. A specific file containing a particular construct, the actual command and the diagnostic is actionable. The same applies to library problems, which often arise from a path, mapping or version issue.
3. Evaluate debugging against a real failure
A clean demonstration design rarely exposes the difficult parts of everyday work. Choose a known defect or deliberately generate an incorrect data sequence. Follow the path from the failed assertion to the logic that caused it. Can relevant signals and instances be found quickly? Can a late failure be investigated without uncontrolled waveform-file growth? Are the source revision and result unambiguously associated?
Ask two people to perform the same diagnosis and record obstacles. What matters is not whether an expert knows the right keyboard shortcut, but whether the team has a repeatable diagnostic process. Transaction-based testbenches should also expose the relationship between transactions and signal behaviour. A waveform-only view may not provide enough context.
4. Test automation, including failure cases
A batch run needs an unambiguous status. Test a successful case, a deliberately failing check, a compiler error and a test that does not terminate. The parent runner must distinguish these situations correctly and retain relevant logs. A message in the terminal is insufficient evidence if the surrounding system still treats the process as successful.
Then test selection, concurrent processes and separate output directories. A shared writable working directory can cause results to overwrite one another. With limited licences, establish how waiting processes are handled and when a time limit takes effect. These conditions belong in operational planning, rather than being discovered while debugging an unreliable overnight regression.
5. Compare results and measurements meaningfully
Runtime comparisons need the same source revision, test, host, optimisation and recording settings. Where possible, measure compilation, elaboration and simulation separately. Memory use and generated file sizes may also matter in practice. One very small test cannot support a general claim about performance on large designs. State the scope of every measurement.
Coverage and result export also need a practical trial. Check whether reports from several tests merge correctly and how exclusions are documented. Manually inspect at least one known gap. A number without traceable provenance provides little help to a reviewer. The article on code coverage: benefits and limitations explains the boundaries of this metric.
6. Check the quotation against operational needs
Clarify required editions, usage rights, concurrent processes, operating systems and maintenance against the specific quotation. The official Active-HDL and Riviera-PRO pages explain the products; they do not automatically establish binding terms or your exact configuration. Also ask how to submit reproducible defect reports and which installation versions are available.
7. Record a traceable decision
The final record contains mandatory criteria, test results, remaining limitations and the chosen configuration. Clearly mark untested points. A limitation can be acceptable if a workable approach has been agreed; it must not disappear behind an overall score. Identify changes that require renewed evaluation, such as a new operating system, a different IP version or a more demanding test methodology.
With this record, a simulator-selection consultation can start directly from the requirements. For an initial comparison, Active-HDL and Riviera-PRO explains typical situations. This article is an original evaluation guide and contains no invented benchmark results or blanket recommendations of a winner.
Sources and date
Research checked on 19 October 2026. Aldec Active-HDL, Aldec Riviera-PRO.