User Tools

Site Tools





This website is sponsored by


This wiki uses icons from licensed under CC BY-ND 3.0.


Random Stimulus Generation

Requirement Summary & Rationale

Randomization Stimulus Generation.

Item Description Tracking / Proposal Supporters Priority
TBV Proposals
TBV 14 Random Value Generation with optional and dynamic Weighting TBV Proposals
TBV 15 Random Object Initialization TBV Proposals
TBV 16 Random 2 state value resolution in place of X generation TBV Proposals
TBV 17 Random choice selection with optional and dynamic weighting TBV Proposals
SAB 3 Random Sequences of Stimulus Accellera VHDL-2008 List - excel
SAB 4 Random Selection of Scenario Accellera VHDL-2008 List - excel

Stable randomization requires separate seeds.

Arguments AGAINST

  • Complexity
  • Timeliness since SystemVerilog, 'e', … already have solutions
  • Constrained random stimulus has coverage closure issues
  • Industry is already moving past language based constrained random solutions

Approach Overview

Randomized stimulus is an important feature that requires an immediate solution. The Open Source VHDL Verification Methodology (OSVVM) project has implemented a package, RandomPkg, that provides some basic randomization capability. When combined with code, this capability can provide a reasonable quality randomization.

The OSVVM package does not have a constraint solver, so there are some limitiations when multiple separate constraints need to be solved together. As a result, it is prudent to consider what should be done to improve the quality of the randomization. Options include: provide a solution with a constraint solver or pursue and supplement OSVVM's “Intelligent Coverage”. See Functional Coverage.

While creating a solution with a constraint solver will give VHDL parity with SystemVerilog and 'e', it will leave us with the same problems. Best case though, a constrained random approach will require O( N * Log N) iterations to randomly generate N test cases. This would be a costly approach alternative in terms of implementation costs.

Industry leaders have suggested that Intelligent Testbenches are the future. OSVVM's “Intelligent Coverage” methodology provides an Intelligent testbench solution. We need to investigate if this is sufficient, if language changes will make it sufficient, or if we need a constraint solver to handle some cases.

The OSVVM packages are available here.
Latest packages:

Is Intelligent Coverage Enough?

Intelligent coverage methodology handles mapping input coverage to input stimulus real well. The question is will it handle mapping internal or output coverage to input stimulus?

Package based Constraint Solver?

For expediency, can we leverage an existing solver and supplement the package based approach? How do we pass constraints to a solver? Are language enhancements needed to facilitate this? How do we blend this in with Intelligent Coverage?

Language based randomization

For some ideas, this is the old randomization document written during the VHDL-2008 effort. It is old and out of date with respect to the current randomization packages. Old Coverage and Randomization doc

Use Models

For now, see the documentation that accompanies the open-source packages.

Competing Issues:

  • None at this time

General Comments

  • None at this time


  • Add your signature here
proposals/random/osvvm/start.txt · Last modified: 23.08.2016 17:54 by paebbels