[sv-ec] Why Classes ?

From: Symons, Tom H <tom.h.symons_at_.....>
Date: Wed Mar 29 2006 - 10:39:05 PST
So why does SystemVerilog add the new type 'class', rather than just
extending modules to have the same capabilities?

 

Seems to me the biggest limitation with both modules and classes
currently (from the perspective of verification) is that they don't have
all the capabilities of the other.

 

I see the following three key benefits to merging classes and modules:

 

1.	Easy migration path for legacy code - i.e. extend it, don't
re-write it. 
2.	Politically much more palatable to people with mostly hardware
experience.  In the real world, this is of huge significance. 
3.	Cleaner, more readable code.  Without these capabilities, people
will dance around the language to get them.  For example, consider the
recent thread on fork-join_none inside functions.  For startup threads,
initial blocks are a well-established, well-used and well-understood
mechanism. 

 

With classes, SystemVerilog is really two separate, distinct languages
bolted together.  But if we simply extend the capabilities of modules,
then SystemVerilog is a much cleaner, more natural language.

 

Wasn't that one of the key concepts behind SystemVerilog - to seamlessly
merge RTL and advanced verification capabilities?  An extended module
would be infinitely more seamless.  No more debates on whether it should
be a module or a class.  No one would have to make the huge leap from
modules to classes.  Legacy code would not have to be ported from a
module to a class.  You could gradually enhance your testbenches and
skill by slowly adding capability to your modules, rather than having to
make the big jump. The beauty of SystemVerilog is that it doesn't have
the step function that other languages require.  But that's really not
true - classes are themselves quite a step function.

 

And it doesn't seem to me that merging the capabilities of the two
should be that difficult.  After all, the capabilities are already
available, just not within both constructs.  In fact, aren't interfaces
really a hybrid of classes and modules?  They are statically
instantiated, like a module, but you can pass around a handle to them,
like a class.  So part of the merging has really already been done, in
some sense.

 

The ironic thing is that modules already are pretty much a class.  They
have member variables and methods.  Seems like we were so close...

 

Just a though.

 

Tom Symons

 

 
Received on Wed Mar 29 10:39:12 2006

This archive was generated by hypermail 2.1.8 : Wed Mar 29 2006 - 10:39:43 PST