On 28/04/2011 09:40, john.aynsley@doulos.com wrote:
> 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.
All true, but I'm beginning to wonder how relevant it is. Maybe there is
a case for *not* addressing the wider issue. There are people who use
VHDL for verification, but who don't know, or care, what the
eRM/RVM/VMM/etc-ad-infinitum are, or were. Sometimes (normally?) it's
just about getting your FPGA working, and not about using this year's
flavour of vendor-imposed-methodology (8, by my count, in 9 years).
That's a perfectly valid approach and, for those people, perhaps a CR
stimulus generator actually is a very useful addition to the language.
Coverage probably isn't that relevant.
If that's what the group thinks, then the problem is to define a
generator which is non-trivial, but which is simple enough to be
relatively easily specified and implemented. Hans has given an example,
but I think to be generally useful, you need to produce an entire record
rather than one vector.
Perhaps the minimum useful level of functionality would be something
that can generate a variable-length packet defined in a record, with
pre/post-generate methods, pack/unpack methods, some constraints and,
hopefully, lists of these packets. A good place to start would be to
find an example packet generator in e and SV, and see to what extent
they could be stripped down. Jim? :)
-Evan
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Apr 28 03:20:06 2011
This archive was generated by hypermail 2.1.8 : Thu Apr 28 2011 - 03:20:10 PDT