Specman Verification
Verification engineer? Verifigen has the right project for you!
Specman Vs. SystemVerilog 
Saturday, January 28, 2006, 01:44 AM
I know, There is hardly a subject in the HVL world, that is more banal than this one...it is probably the parallel of "can you have a true friendship between a men and a women?" in the movie world or a sunset drawing in the art world...it has been chewed to the bone long time ago, but I still would like to add my little drop to this ocean...hope I will get out of it in an honorable way.

The way things look at the moment, most of the “who’s who” in the industry seem to share the opinion that SystemVerilog is the future verification language (see cooley’s poll on the subject here). It might be said that SystemVerilog had won the battle even before it got to the ring, simply because it is standardized (get the standard here), and because it is a "unified design and verification language" (meaning that parts of it, the Verilog parts, can be synthesized), which is sth that most people, for some reason, think of as an advantage...

But in this entry I would like to compare E and SystemVerilog as HVLs...and to break the tension I could tell you immidiately that I (and probably most hands-on verification people) find E far superior to SystemVerilog. In fact, I find SystemVerilog’s defects so hard, that I anticipate that, at least in its standard form, it will soon prove unable to withstand current day verification needs, and will therefore give way to other, better yet non-standard, solutions.

SystemVerilog does have some things that E misses badly...for example it has static variables which allow several instances to share information that is relevant to all of them...SystemVerilog classes have constructors, while e structs have a rather weak initialization method (init()) that can not receive any parameters...SystemVerilog has better control of generation constraints - you can turn constraints on and off, and you can do that at runtime (I guess it is possible to do the same in E but would take more effort). Another nice feature they have is that you could use constraints for checking - if you have some data, you can check that it withstands all the constraints that are currently active for that data type. I guess that if I look hard enough through the LRM I would find other cool features as well...

Still, this is small staff because the disadvantages of SystemVerilog are on a higher level. First of all, it is a huge, obese language. If a small exaggeration is allowed, almost every word in an SystemVerilog editor gets colored because it belongs to some language construct...you might ask: what the #$#* do you care? most programmers will use only 5% of this language anyway...of course this is true, but I'm worried about the amount of variation between programmers, which makes other people's code less readable, because one programmer is not accustomed to the constructs that his colleague uses...If you think this is just an annoying aesthetic pedantry, wait until you have to get into someone elses code.

But the worst part is that SystemVerilog has very limited OO capabilities...Its object oriented support is almost a lip service. I don't expect it to support multiple inheritance like C++ or the Aspect Oriented staff that E supports, just the basics...but it is quite far from that. To begin with, two widely used SystemVerilog elements that are used to group data and functionality (what a class normally does), namely the "module" and the "interface" do not support inheritance at all. In the case of the "module" this is understandable since it is a part of SystemVerilog's verilog heritage, but what about the "interface"? how come this SystemVerilog jewel of the crown does not support inheritance? bit me...

You can try to do without interfaces but you won't get very far since classes can not contain "always" or "initial" blocks. For those unfamiliar with Verilog, "always" and "initial" blocks serve as hooks to the simulator 'run' command (just like the "run()" method in e). This means that in order to execute any "task" or "function" inside a class, you must have an "interface" or a "module" that is charged with calling them when something happens.

And speaking about interfaces, I can't help myself from asking an obvious question - what is their added value for verification anyway? I guess designers would find them quite useful, if and when they come to be supported by synthesis tools, since they allow for a comfortable grouping of signals and for the creation of multiple views of a single bus...but as someone who does verification I really can't see anything that can not be done with ordinary OO techniques for just the same effort. If you ask me, they are just an excellent example of the disadvantages of a unified design and verification language - a language construct that was created primarily for design purposes, "invades" verification and is used to replace OO language constructs.

And I haven’t touched yet on any of these features that make code reuse and maintenance so easy in e, and that are non-existent in SystemVerilog. Turning logical data (classes) into physical data (bits and bytes over the interface) is done seamlessly in e, because of the static % operator that distinguishes logical fields (packet type, packet error kind) from physical fields (da, sa). To do this with SystemVerilog you will have to write a custom task for each class…a task that must know all of the class’s logical and physical fields (and another piece of code you will have to modify when one of the names change). In the same vain, you will have to provide a class specific code for such common tasks as printing, copying or comparing of class instances. E on the other hand provides you with a set of predefined/library methods for all of these common tasks – print, copy(), deep_copy(), deep_comare() and of course deep_compare_physical(), which is highly useful in scoreboards.

How come all of these have been left out of the SystemVerilog standard? Seems to me they had sufficient time to study the competition better.

And finally, at least in its standard form, SystemVerilog does not provide any built in “solutions” for commonly encountered verification problems. For example, it does not support “sequences” or “test scenarios”, at least not in a way that enables to completely decouple them from the rest of the verification environment (that is, change a sequence from a single external file, without touching the rest of the files in the environment). It also does not have a mechanism for test termination, and does not have a sufficient messaging support. The funny thing is that when e started, it faced more or less the same charges, and these features were added to later versions of Specman-E through the eRM (but are now included in the proposed standard).

With these limited abilities I find it hard to believe that SystemVerilog will come to dominate the verification market so fast. Of course, all of these could be added through external vendor-specific libraries, but this would just be the end of the standard, and we will be back to square one, where each EDA vendor, has its own verification language.

If you have found this entry one sided, you can find a more balanced comparison between e and Vera (SystemVerilog’s cousin) at JL Gray’s cool-verification blog.