lowRISC / lowRISC/opentitan

[top_earlgrey/dv] Emulated rate of entropy makes tests very slow

Open
#18,284 4 comments 0 reactions 0 assignees View on GitHub
Component:DV Earlgrey-PROD Candidate IP:ast TOP:earlgrey
Dominant language
SystemVerilog
Stars
3.6k
Forks
1.1k
Avg merge
2d 22h
Merged PRs (30d)
141

Description

The random bit generator in the AST (`rng` module) gets emulated for DV purposes by an LFSR that delivers bits at a certain rate to Entropy Source:
https://github.com/lowRISC/opentitan/blob/4abad8254a405c51d13af76dff024ed2fc84eae2/hw/top_earlgrey/ip/ast/rtl/rng.sv?plain=1#L70-L91

For DV simulations and Verilator, `SYNTHESIS` is not defined, so each test run randomly picks a delay (`srate_value`) between 32 and 128 clock cycles. (On the FPGA, `SYNTHESIS` is defined, so `srate_value` is fixed at 120.)

The wall clock time of tests that use a lot of entropy is dominated by slow entropy generation. While it makes sense to have a test configuration that is as close as possible to a real silicon implementation and target environment in order to catch problems that only occur under those circumstances, having a relatively low entropy rate for _most_ tests inflates test run time and thereby reduces other test metrics such as coverage per time and increases associated costs for resources and engineering time.

Some DV tests have `+rng_srate_value_max` and/or `+rng_srate_value_min` or even `+rng_srate_value` set in their `run_opts` to reduce the upper and/or lower bound, respectively, or even set `srate_value` to a fixed value. While this is a way of preventing those tests from timing out, it defeats the purpose of testing under realistic conditions (and its effort scales linearly with the number of tests that rely on it, which isn't desirable either). Additionally, those plusargs are currently not used in Verilator simulations, causing tests to fail on Verilator that pass in DV.

Can we improve entropy emulation, e.g., so that
- all tests get periodically run (e.g., nightly) at worst-case-entropy-rate with significantly extended timeouts -- especially fast emulators such as FPGA or Verilator would be well suited for running worst-case-entropy-rate tests without taking a prohibitively long time --, and
- all tests otherwise use a best-case entropy rate to optimize test throughput and latency in the common case.

Contributor guide

Open the contributing guide

Research direction

Start with hw/top_earlgrey/ip/ast/rtl/rng.sv, especially the emulated srate_value logic around lines 70–91, then inspect DV run_opts and Verilator handling of the rng_srate_value plusargs. Define separate common-case and worst-case entropy-rate paths, ensure the plusargs work in Verilator, and verify that normal tests gain throughput while periodic worst-case runs retain realistic coverage.

Written by the indexing model from the issue text.

Assessment

Domain
embedded-iot, security, testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.