Re: [vhdl-200x] Requirements to do verification

Hans, Jim, All,

Yes, but... adding randomization and constraints as isolated features only
addresses part of the wider issue, which is verification IP reuse. CRV in
SV, e, and Vera also include the ability to extend or customize existing
verification components without touching the source code, which is one of
the reasons why OOP extensions to VHDL have been a subject of discussion
in this group. Again, not wishing to labor the point, the verification IP
market (speaking qualitatively, not quantitatively) is centered on the
specialist verification languages (e.g. IEEE 1647 and IEEE 1800), not on
VHDL.

Having said that, there is room for pluralism. I really respect all you
guys who are suggesting new features to be added to VHDL. VHDL has helped
feed my children for many years now. I am not opposed to adding new
features to VHDL as such, but given that I do not see EDA companies
queuing up to implement extensions to VHDL, nor do I see pull from the
community of verification specialists for VHDL extensions, I suggest that
this group might have other priorities.

Just my opinion, for what it's worth (and opinions can change 8=)

Cheers,

John A

From:
"hans@ht-lab" <hans64@ht-lab.com>
To:
<vhdl-200x@eda.org>
Cc:
<owner-vhdl-200x@eda.org>, <vhdl-200x@eda.org>
Date:
27/04/2011 17:31
Subject:
Re: [vhdl-200x] Requirements to do verification
Sent by:
owner-vhdl-200x@eda.org

Hi John,
 
I disagree, in my opinion CR is one of the great missing pieces of VHDL
(DPI is another one). We have all the power of PSL to do functional
verification (bins, etc can be added with some code) but what is missing
is support for a proper constraint solver. We are very close, we just need
to tie up some loose ends.
 
I do know that constraint solvers are complex pieces of technology and
hence we must adopt whatever is currently supported by SV/SC. The
question I have is do we really need OO to get CR support (ala SystemC?
smartpointers) or can we use existing VHDL language constructs like
attributes?
 
What I was thinking about is doing something like:
 
signal mux_s : std_logic_vector(7 downto 0);
attribute RANDOM : normal; ? set distribution
attribute RANDOM of mux_s : std_logic_vector is true;
 
mux_s?KEEP_OUT(X?55?); -- avoid using illegal value 55
mux_s?KEEP_RANGE(X?33?,X?CC?); -- keep all values from 33 to CC
randomise; -- like a procedure call
mux_s?NEXT; -- get next random value
etc.
 
We do need to add some keywords to call the constraint solver, in this
case we should probably VHDL? existing SV construct:
 
constraint c1 begin mux_s > X?33? AND mux_s <=X?CC? AND mux_s/=X?55? end;
 
Another idea, which we discussed a few month ago, is to have better
(easier?) support for data introspection. In this case you can bolt on
your own constraint solver (perhaps SCV or Minion). We might need some
additional simulator hooks like start_of_simulation() and
end_of_elaboration() but these are already supported by SV/SC so might not
be to complex/expensive to implement.
 
What I suspect will not work is pages and pages of complex VHPI code, we
need something as simple as a DPI call to an external library perhaps
called from a user define attribute (e.g. mux_s?myfunc() calls myfunc DPI
function with a pointer to mux_s).
 
Just some thoughts,
 
Regards,
Hans.
 
 
From: john.aynsley@doulos.com
Sent: Wednesday, April 27, 2011 10:41 AM
To: vhdl-200x@eda.org
Cc: owner-vhdl-200x@eda.org ; vhdl-200x@eda.org
Subject: RE: [vhdl-200x] Requirements to do verification
Hans, JK,

I love VHDL too. The question I am trying to answer is how we can best
serve the interests of the VHDL community going forward and keep VHDL
relevant. When all the dust has settled on the "marketing statistics"
thing, the point will still stand that VHDL is not the centre of gravity
for constrained random verification at this point in time (just an
opinion). I assert that adding major new features to VHDL for CRV , which
in my humble personal opinion are unlikely to get implemented in a timely
fashion, is not the best use of our effort right now. In my opinion, we
should focus on interoperability with SV and UVM.

Cheers,

John A

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.