SV is a fact of life and is here to stay. You can feel happy or sad about it, think that itís a big step to humanity, or a very small step towards standardization, either way, if you want to make money in todayís verification world, you will not be able to avoid it for long (that is, unless you become a manager within the next 6-12 months). Even if you have a website that you once stupidly named www.specman-verification.com, youíll have to understand at some point, that unless you have a decent SV tutorial online, in one or two years youíre passť.
So, this is the first step in a thousand mile way. More parts will be added in the future. When exactly? Thatís up to god and/or my boss.
SV building blocks
Working with SV often feels like a trainer trying to make the most out of a team whose members are suffering from various disabilities: one is missing a leg, another is blind, a third canít talk. Somehow, you must find the right position for each player, one where his gain will compensate for the pain. Obviously, some players, such as the one who has no legs, no hands and a very big nose, will have to warm up the bench.
Youíll often find yourself facing difficult choices: should you let the blind guy with the powerful right leg, or the deaf guy with the weak left leg shoot the decisive ball? In SV, you always have more than one way of doing something, but almost never the right way of doing something. Pest vs. cholera decisions are a daily matter.
Hereís a quick look at the super powers and weaknesses of the first five: a class supports inheritance, can be instantiated and passed around as reference, but canít instantiate any static units such as a module, interface or program. This means it canít be used as a top level container. It also canít hold assertions. An interface, a module and a program do not support inheritance but can be used as top level entities. All of them can contain assertions. An interface can be somewhat clumsily passed around as a reference, which is quite important, and which none of the other static elements can. However, it canít instantiate a module. A module canít be passed around as reference but can be synthesized, so if you have a Verilog design, youíll always have one of those. A program is more or less identical to a module, except that it canít be synthesized and that it samples signals at the end of the delta instead of at the beginning. For me, thatís the one player I like to have right next to me, that is, on the bench. If youíre using VMM, however, youíll probably have it on the field as well. Finally, a package, is a convenient way of sharing user defined classes and types between modules, programs, interfaces and other classes. Unlike the others, it canít be instantiated, and is used only for type resolution at compile time. Like them, however, it has its own annoying limitations. For example, it canít contain interface, program or module definitions. These definitions must always contaminate the global namespace.
As mentioned above, normally I use four players: the class, the module, the interface and the package, and leave the program out. The class is the natural place for most of the data and functionality of my testbench because it can be derived from and extended later on. The module is an almost unique choice for a top level container because it is the only one that can instantiate the DUT modules. Iím saying almost because you can also use an interface or program as top level modules and instantiate your testbench in parallel to the DUT. If you go for this option, then you can probably leave modules out of your testbench as well. The interface is used as a channel of communication between the class base world and static elements such as modules and interfaces. The package is used as storage for all my classes and user defined types.
Confused? Hopefully the following sections, which are dedicated to each of these five building blocks, will make things somewhat clearer.