Coding complex VHDL testbenches

[Marcus Harnisch]

Hi Jim

,----
| class C;
| rand int a, b;
|
| constraint a_less_than_b {
| a < b;
| }
| endclass
`----

[...]

I have read much of the literature and agree that it is important to
have this functionality, however, it is not that impossible to cope
without it:

variable RV : RandomPType ;
variable A, B : integer ;
. . .

A := RV.RandInt(0, 254) ; -- Min, Max, Length
B := RV.RandInt(A+1, 255) ;

The limitation to this case is the distribution of values is not
uniform. The value(A=254, B=255) happens 1 in 255 times where as
the value (A=0, B=255) happens 1 in (255*255) times. As a result,
adjustments would have to be made to some problems (however many
are fine just as they are).

My example was not so much targeting the general problem of getting
the constraint distribution straight. This is often an issue. No
matter which language you use.

In this SV example, it is clearly comprehendible what I am trying to
say -- the RandInt() without a comment explaining the meaning of
arguments is not. Especially since it is not standardized. Everyone
will have his own little mechanism to implement a similar
functionality that will always work best for a particular verification
task.

With all due respect, the code in your other post is very specific to
the problem at hand. It is neither generic nor convenient to type in
the case of, say, a 16 bit vector. And how do you easily set up
implications? I don't blame you -- we can hardly do any better in
current VHDL.

Since the code is not declarative or rule-based, it also doesn't give
me a solution for the case where I really want B to be 42 -- now
generate a corresponding value for A compying to the rules I set up
earlier. To implement every such case an entirely new set of
constraints would have to be passed to these functions that is
entirely unrelated to what I specified earlier. Since I have to way to
express the relations using different equations chances are that
errors will be introduced silently. Now tell me about maintainability
;-)

With class based randomization (Marcus's example), the intent is
that the solver gives a uniform distribution across possible values.
Hence, (254, 255) occurs with the same frequency as (0,255).
While this is nice in theory, actual solver behavior will vary as
demonstrated in Chris Spear's book, SystemVerilog for Verification,
example 6-18 and results in table 6-3 - ironically when I reported
this as eratta, it was explained to me that this is valid behavior
of the solver and the user had a choice of the fast solver or the
slow and accurate solver.

So you are saying both ways are equally broken -- just in different
ways.

I don't think a real-world implementation of a solver has much of a
choice. To be entirely accurate it would have to create a list of all
possible combinations and pick a random one which is not really
feasible. But then I am no mathematician so there may be better ways.

In a rule-based approach I can easily change the generation order,
thus influencing the distribution, without touching the rules
themselves.

Sounds like this is a general problem that also occurs with class based
randomization. You can specify some constraints in the class, then
revise them by extending the class, then revise them in the call to
randomize as well as mix code in with this. So what does the test
actually do? It is specified by the class + extensions + code.
Of course, you do have functional coverage to answer this.
Is the test readable and maintainable and by whom? Better have a
good methodology - I suppose this is a universal truth.

Any badly structured code will spoil readability. The question is
whether a language allows you to express your intent in a concise way.

With VHDL in its current state, I would not try to write declarative
constraints.

How would you anyway?

Have a good weekend,
Marcus

 

[Jonathan Bromley]

but for coverage, i think simulators like modelsim can easily do code
coverage...not quite sure what you mean here.

Presumably you already make heavy use of the superb functional
coverage constructs in 'e'? SystemVerilog offers broadly the
same features, although (of course!) the details are different.
The same stuff in native VHDL might be interesting, no?
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.