Hi Desperado,
(Are you the same Desperado as on the Verification Guild?)
Sorry for the delay in responding. Our normal notification system failed.
SV certainly has the *required* features to allow verification to
succeed. It's just not good at encouraging good programming practices
and has lots of "sharp corners" in its language definition.
By far, the primary wart on the SV language is the difficulty in
separation of interface versus implementation. This is a staple of
good languages since the 1970s. You can separate *most* symbols (data,
methods, classes), but it requires significant work on the coders
part. There are tons of glitches in this process like the poor
definition of a forwarded class type, how prototypes can vary between
declaration and definition, and the initialization of statics.
A second major flaw is that SV is derived from Verilog. This brings a
host of issues and encumbrances, but the main one is that Verilog is
designed to build real physical entities. The ways that that warps a
language design are numerous. Just look at compilation versus
elaboration and what are the scope resolution rules for a.b . Now C++
is weaker in some regards, such as threading, 4/8 state computations
and connection to the DUT, but these can be overcome with relative
ease (i.e. Teal).
A third major flaw is that it does not integrate well with c and
c++. These are the two primary languages of software. Yes, I know
about DPI and PLI, they are quite weak for real model integration.
Here's a partial list of lesser flaws. I am just rattling them off in
no particular order.
C++ has the std namespace and the template library. This alone is a
major piece of good work and provides a good base for both novice and
expert programmers. Many books have been written on the Template
Library and much though has gone into those templates/algorithms. I
know and have used all of SVs container classes, but they are a weak
shadow of the template library.
Packages versus namespaces: There are two major faults. The first is
that when you end a package, all the methods and classes must be fully
defined. This breaks the separation of interface and implementation.
Add to that the fact that the parser and language definition are weak
and you end up with files like teal_vout_pre and teal_vout_post.
Another fault is that the package cannot be added to in another file.
This may seem silly, but I do not want everything associated with a
specific functional area to be in one file. How would users add they
own derivations and have them look like there are "inside" the package
?
A small nit is the fact that a function cannot take time. Either that
or methods should be allowed to return a value.
C++ has automatic construction and destruction. This is of great use
for managing entry/exit tasks, such a mutex sentries, scratch RAM
allocation, and resource reservation. It is invaluable in these
situations within a function with many return points. Now I realize
SV has pointer management, but (1) this can be added to C++ easily
using smart pointers, (2) is often not really an issue and (3) causes
great confusion as to when to new and when to copy. The fact that the
language does not support a copy constructor leaves us to write error
prone and clumsy code (with down casts).
C++ is known by millions of programmers and hundreds of books are
available. SV has maybe 20 thousand programmers and a handful of
books.
The inheritance model if SV is very weak. It does not support
protected or private inheritance or multiple inheritance. It's model
of function resolution follows the pointer type which is just wrong.
Parametrization versus templating: There is only a superficial
comparison and SV has not real facility for meta-programming
(templating). Good templating is critical to the design of good
container classes and generic algorithms. We do a lot of similar
things in verification, it's real hard to express this commonality.
Now I realize this is used in perhaps only 1% of your code (with the
major exception of container classes and algorithms)
parameters in SV versus constants in c++: Just looking at the ability
one has to specify constants for reusable code, SV is weak. There is
still discussion as to whether there can be global parameters. The
initialization of parameters is very weak compared to c++. Finally the
type checking in parameters is weak.
bind versus operator overloading: As far as I know, no vendor has
implemented bin for the purpose of overloading mathematical operators.
Sorry this post was so long; I just got going.
To me SV is like playing a concert on a toy piano. Sure you can try,
but your range, sound and general talent is limited to, well playing
like a child.
Member
Key Master
Key Master
Member