|
The verification world is roughly divided between SystemVerilog (SV) and e (a.k.a Specman). Both HVLs (Hardware Verification Language) fight for the same market segment as a Coverage-Driven-Constrained-Random programming language for building automatic test benches and there's tons of information out there about each of them. However, there's not much information about the pros and cons for choosing one HVL over the other, and even less has been written on the effort of switching from one language to the other. Here's our take on the subject - a few technical observations and a couple of other thoughts from a wider perspective.
On the technical level, if you ever make the e-to-SV move, sooner or later you''ll find out that SystemVerilog is very much like the beginning of the world in Genesis 1 - without form and void. Very void... none of the classes actually exist unless you manually construct them. In e it''s the other way around - if you don''t say anything, all structs (and arrays) are alive and kicking as soon as you turn the lights on. Following the same approach, in SV class properties don''t get randomized unless they''re preceded with the magic word "rand". In e, once again, it''s the other way around - struct members always get randomized unless you place a bang (!) before them. It''s not a good or bad issue - it''s just different.
Predefined methods are a blessing in e - every struct comes with a handful of really neat methods (print, copy, compare, deep_compare...). These methods are going to be your best buddies if you ever switch from SV to e, and the ones you''re gonna miss the most if you make the opposite move. Don''t say I didn''t warn you..
Is there anything good about SV? of course, it''s a great way to practice Object Oriented Programming. If you get a kick from polymorphic functions then you''re in for a real treat. The e language really makes your life easier in terms of getting what you want quickly, but looking at the big picture - the inherent AOP capabilities in e could be quite a mess, especially when your verification methodology is not tight enough. You see, in e - you can virtually twist and turn your verification environment from anywhere you want to your very specific needs at that very moment. When everybody does that on your team on a regular basis, code integration becomes a real pain. SV on the other hand, tells you "don''t even think about changing one bit in the environment" because you simply can''t.. You just can''t access previously defined classes that easily, which makes code integration easier. If you''re willing to trade flexibility for better code organization and quicker integreation, SV might be good for you.
A great lesson in marketing can be taken from the SystemVerilog case-study. Why do companies choose SV over e when clearly there are very few people who believe that SV is more effective than e and so many who think the opposite? Well, apart from the fact that the people who call the shots when choosing an EDA vendor are not always the people who actually use the tools, there''s another extraordinary reason... I''ve heard this so many times: "SystemVerilog is better because it''s similar to Verilog which is good because designers will be able to take part in Verification". What can I say? Ignorance is a bliss, no doubt about that, but leveraging ignorance to a marketing strategy is genius. The moment of truth guys - As far as verification is concerned SystemVerilog has nothing to do with Verilog. Nothing, nada! it just sounds the same. It does, however, have much in common with C++.
If a complete stranger were to conduct a quick research on the HVL market he would probably notice that both e and SystemVerilog are IEEE standards. He would also notice that all 3 major EDA companies offer SystemVerilog capabilities while only one of them supports e. If you were just starting out, what would you do? go for a seemingly lesser language that''s widely accepted by the industry or a better language that''s supported by one vendor only?
And what if you were not just starting out? what if you had already mastered one language and wanted to switch to the other one? What if you had legacy code in e and wanted to try out SystemVerilog? The plot would thicken, wouldn't it? Well, our complete stranger from the paragraph above might think that switching from SV to e or vice versa is just a matter of learning a new syntax. I guess stakeholders on both sides have and will use this argument quite often. There''s one little problem though - it''s far from being true... I''ve talked to many people who''ve made the move (either direction) and tried to find a good analogy to illustrate the effort. What I came up with was this: Imagine your Windows-based PC and the way you master your daily activities - email, internet, documents, media management, files location, installing & removing programs, other applications that you might have mastered such as Excel, PowerPoint, a bunch of tricks and tweaks that you''ve come familiar with over the years, etc. Now imagine somebody coming in the middle of the night, formatting your system and installing a Unix OS on it... From the next morning and on you''ll have to keep your level of efficiency but this time using a command line interface rather than a GUI while none of the applications seems familiar.
It''s true that eventually you''ll get the work done, but the effort is much bigger than any marketer would ever reveal. The reason is simple - The syntax of SV and e per se is merely the visible representation of a profound set of conceptions which is significantly different between the two languages. And I haven''t even mentioned the methodology libraries and stacks of code that come with them - VMM/AVM/OVM/eRM/IPCM.
The good news, however, is that the industry has recently come to understand that convergence is the new name of the game and sooner or later the gaps between the various verification methodologies and concepts will be closed. Let''s just hope that the remaining parts from each methodology will only be the best ones...
|
