Random Stimulus Generation

Proposal Information

• Who Updates: JimLewis, ...
• Date Proposed: 2011-07-16
• Date Last Updated: 2012-11-29
• Priority:
• Complexity:
• Focus: Testbench

Requirement Summary & Rationale

Randomization Stimulus Generation.

Item	Description	Tracking / Proposal	Reviewed On	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.

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.

General Comments

Supporters

Add your signature here to indicate your support for the proposal

Document History

-- JimLewis - 2012-11-30: Split FC from FC+random Old combined FC and Randomization