Functional Coverage and Randomization

Proposal Information

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

Requirement Summary & Rationale

Add Functional Coverage and Randomization. Essential features if we intend to have a verification focus.

Note, I lumped these together since they are both database operations with overlapping information about the stimulus that we either need to generate or need to observe.

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

For the short term, implementing these features in the same fashion as SystemVerilog, 'e' will result in two separate features that will be complex and expensive to implement. Since industry is already moving beyond constrained random stimulus, so the success of this approach would be suspect - unless it offered solutions to problems not currently offered by SystemVerilog and/or 'e'.

One something different we can offer is the integration of functional coverage and randomization. These are both database operations that have overlapping information about the stimulus. By merging them we can focus on generating the stimulus that is missing. If we did constrained random generation without integrating functional coverage, the run times were reported to be O(n * log n). On the other hand, by including coverage, the run times can be O(n). Where n is the number of coverage bins.

Due to timeliness, we probably need a multi-phased approach. Below are some thoughts.

Short Term Actions, Quick Response Approach

Since functional coverage requires a database, there is much that can be done using protected types (from VHDL-2002) and packages. The randomization packages use protected types mainly to work around issues with VHDL functions (no access types and no inout parameters).

Currently I have released a set of open source packages for both functional coverage and randomization. At this point, they are evolving and are under continual update so check back from time to time. They are available here. To allow these packages to remain under a flexibile update process, it may be best to keep them as open-source (as is done with SystemVerilog libraries).

I note that in current verification languges, creating a high-fidelity cross coverage model is challenging. This is an opportunity. It is important that all the information is captured in a single database so that the information can be correlated.

Medium Term Actions

With the current language definition, there are some things that the package based approach cannot do or would be clumbsey to do. There are a number of enhnacements that we can make to protected types, subprogram interfaces, and subprograms that would expand the capabilities of the package based approach. Most/all of these are inspired by features that are already in ADA.

How do we better leverage PSL - particularly for transition based constraints.

Can we leverage an existing solver? What language enhancements would we need to be able to pass constraints to a solver? How do we blend this in with the randomization across coverage holes?

Long Term Actions

Consider what actions can be done better or easier using language based syntax and add specific enhancements to accomplish this.

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.

Related Issues & Sub-issues

Competing Issues: None at this time

Requirement details

Use Models

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

General Comments


Add your signature here to indicate your support for the proposal

Topic revision: r2 - 2020-02-17 - 15:34:28 - JimLewis
Copyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback