All the methods that this structure supported are now pulled
into the __vpiHandle class as virtual methods. This includes
the vpi_free_object_ method, which required some extra trickery.
Instead of C-like data structures where the __vpiHandle base is a
leading member, make the __vpiHandle a derived class. Give the base
class a virtual destructor so that dynamic_cast works reliably, and
now pretty much all of the junk for testing if an object really is
of the derived class goes away. Also, problems with casting up to
a vpiHandle become trivial non-issues.
The standard defines how to calculate the name for an access function
or iterator if one is not given. It is supposed to be vpi followed by
the words in the name with each word capitalized. For the one to many
(iterator) interface from the enumeration typespec to the individual
constants this is vpiEnumConst not vpiMember.
We don't currently have the information needed to correctly provide the
base typespec, but in the next() and prev() methods I need to know if
the enumeration is two or four state. This patch sets the base typespec
for four state enumerations to vpiReg and to vpiBitVar for two state
enumerations. This provide enough information to get next() and prev()
working correctly.
Create the v2009.vpi module to include SystemVerilog core
functions, and start out with some of the enum methods.
Add to vvp support for creating enum types, including some
vpi access methods.
Cary R
Martin Whitaker
Arun Persaud
Stephen Williams