Get email delivery of the Cadence blog featured here
Two main languages, both IEEE standards, are in use today for constrained-random verification - SystemVerilog and the e language. Which is best, under what circumstances? Geoffrey Faurie, a member of the Functional Verification Group at STMicroelectronics, has some definite opinions about that question.
Faurie's team is responsible for evaluating and recommending new verification methodologies. He's a long-time user of e and Specman, and has more recently used SystemVerilog with the Open Verification Methodology (OVM) and its successor, the Universal Verification Methodology (UVM). Today at STMicroelectronics, he noted, about 85 percent of IP verification engineers use e and the remaining 15 percent use SystemVerilog for constrained-random verification.
Faurie says he's noticed an approximate productivity drop of 30% when teams switch from e to SystemVerilog. On the other hand, he acknowledges the value of UVM in providing a standard for verification IP. "We have different advice" for the STMicroelectronics verification teams, he said. "If there is a strong interoperability requirement for design or verification IP to work natively on all EDA vendor simulators, we advise to go with SystemVerilog. If not, we advise engineers to stay with e."
A Screwdriver Versus a Knife
Faurie said that "comparing e and SystemVerilog is like comparing a screwdriver to a knife. The first object has been designed to drive screws, whereas the second one was initially designed to cut food. It can also be used to drive screws but with less efficiency."
Faurie noted that it is important to understand the difference between a language such as e that was developed for verification, and language such as SystemVerilog that was initially developed for IC design and extended for verification. The e language was optimized to fill verification needs such as randomization, productivity, and reuse. He also noted that aspect-oriented programming in e makes it easy to customize and enhance existing code for reuse.
"As driving screws with a knife will take you more time than using a screwdriver, I have experienced a productivity drop switching from e to SystemVerilog," Faurie said. He noted that SystemVerilog environments require significantly more code to perform the same functions, making it "easy to understand the origin of the productivity gap."
"Despite this assessment, we cannot push SystemVerilog aside. Indeed, why are we continuing to drive screws using knives?" Faurie said. "Because knives are more common than screwdrivers. I think this will become the case with SystemVerilog, especially with the arrival of UVM. Indeed, UVM sounds like it will provide full interoperability and many community contributions such as verification IP and tools. That is synonymous with productivity enhancement," noted Faurie.
The Advantages of e
One big plus for e at STMicroelectronics, Faurie noted, is 9 years of production proven use. "A lot of people at ST are using e," he said. "People are trained, and there is a strong legacy of internal VIP, and a lot of verification environments are based on e."
When he started working with SystemVerilog, Faurie said, he noticed that the transition from the aspect-oriented programming (AOP) features of e to the object-oriented programming (OOP) features of SystemVerilog imposed some restrictions. "To reuse the same components or to customize code, AOP is really well adapted. I don't find the same level of coding capability in SystemVerilog. For me aspect-oriented programming is the basis of the added value of e language as it is a powerful feature to address the reuse challenge," he added.
Specifically, he noted, "OOP is the main cause of penalties in term of reusability. Moreover, features developed in OVM to "emulate" AOP lead to over-coding. We can do the same things [in SystemVerilog], but to do the same thing we have to write more lines of code, and for sure this has an impact on productivity." He said that there is typically "an override of 30 percent" in terms of the extra lines of code required in SystemVerilog versus e. For example, fields within the UVM Factory require twice the coding, he noted.
Another advantage of e is its ability to easily replace verification components in existing verification environments. "You have only to customize the interface of the [e] verification component to replace it," Faurie said. "With SystemVerilog, it requires a lot of modification to the original verification environment."
Finally, Faurie said, "As e has been in place for many years, the associated debug tools are more mature and cannot be compared to debugging capabilities offered for OVM/UVM, which are quite new, comparatively. But I expect that fast progress will be motivated and pushed by the standardization of UVM."
The Advantages of SystemVerilog
One advantage of SystemVerilog, Faurie said, is that it's an extension of the Verilog language. Thus it takes less time for the design and verification engineer to learn the basics. Another advantage is UVM, which is gaining support from all major verification providers.
"UVM is a new methodology, and it's the first one that has complete interoperability," Faurie said. "This will motivate EDA vendors and VIP developers to develop VIP using UVM." Over time, the availability of more and more UVM VIP may help compensate for the productivity loss of switching to SystemVerilog, he said.
Faurie would like to see interoperability between UVM and e. "It would make sense to have UVM to interoperate with e verification components as part of the standard effort." he said. (Cadence is a strong advocate of extending UVM to e and SystemC, as noted in this recent Q&A interview.)
It's Your Choice
If you're considering which language to use for constrained-random verification, the takeaway is that there are two solid choices today - e and SystemVerilog. Both are IEEE standards and both are fully supported by Cadence. The e language has a productivity advantage, and over time, SystemVerilog/UVM promises an interoperability advantage. Cadence today already has an implementation of UVM e supporting the interoperability between the two languages. When UVM e is standardized, users will have a wider choice of multi-vendor VIP interoperability, and the entire verification community will benefit.
Poor analogy with the screw driver & knife. I have found myself similarly use a screw driver to cut things - admittedly not food (yet) - and yes with less efficiency if only I could have found that darn knife.
Ask yourself instead, which is the more powerful tool in general, the screwdriver or the knife ? Or am I throwing a wrench now ?
There is a kind of a quiet assumption that OVM/UVM provides verification reusability for free which seems to be an important factor on decisions made by relatively inexperienced verification managers. Then comes a huge surprise that the test bench derived from OVM classes cannot be used on the next project (sometimes event on the project derivative). Well, if there is no high level architecture over the OVM then the methodology itself will not guarantee anything especially will not provide reusability and efficiency. For example the Scoreboard might be perfectly un-reusable even though it is an ancestor of the ovm_scoreboard. One can end up with equally un-reusable environment but written in SV/OVM this time. So now we come to the kind of a conclusion that the language is actually of second importance following the verification environment architecture which should always be #1. Anyway I have always found implementation of such architecture much easier and quicker in e than in SV. Simply because e is a verification language designed from scratch to address specific verification needs and equipped with tools which verification engineer needs most on daily basis. As a result we were able to create a new block level self checking and fully functional test bench from scratch around a new RTL in just one day. ONE DAY! 8 MAN HOURS! How? Just by reusing eVCs (config, transforms, scoreboard, bfms, sequences, etc.) previously architected and already proved in many (different!) projects and by extending hook methods. In this case I really don’t mind that SV test bench might be actually quicker in simulation time...
Thanks Richard for this article and Geoffrey for your comments.
On a similar question, I once compared this with the differences between Linux and Windows. Nowadays, I would talk more about developping for iOS or for Android. I like the screwdriver and knife though ;-)
They are somehow both nice for what they are good at. Both having pros and cons depending on what you want to do with them.
On the technical points, I more than agree that AOP brings productivity and ease some complex code architecture.
IMHO, this comes with two main drawbacks.
1/ One is mentioned here is about the learning curve. All engineers have been taught the OOP principles so you can train someone to SystemVerilog without introducing new concepts. Having done the exercise several times, I now expect something like half the time to train someone and get him/her efficient in SystemVerilog as opposed to e. But as Geoffrey said, it also depends on the personal background, so this is not a very strong statement.
2/ The second point I want to expose about the AOP is its ability to give more freedom to code writers (as said by Geoffrey with less code and in a more productive way) to add new features to existing objects.
The drawback of this is that you can easily write unmaintainable code.
Verification IP are in general well written and don’t fall in this category.
This is however quite common for big verification environments under the project time to market pressure and where more than 3 or 4 verification engineers are involved in the same verification environment.
It’s so easy to add a new feature right in the middle of the file that is already in your emacs buffer (eclipse for younger people or vi for others ;-) rather than thinking about the best place to do so, that resulted code can be very hard to debug, to document and to maintain.
If you’re not careful, you get the productivity gain only up to the point that you reach real issues or up to the beginning of the next project. Then you need to dig into all the different AOP features that are spread in the different files to understand which ones are really needed for the next project.
On my side, I’m always tempted to lose a bit of short term productivity each time I can think of longer term productivity for reuse. But time pressure is also on me, and the good compromise is never easy to find.
If you compare this to OOP with SystemVerilog, since you have to clearly declare a new inherited class and use virtual methods, the short term productivity is less than with AOP. But for long term project reuse and maintenance of big environments, I’m not so convinced.
Now, an less technical points, a choice between e or SV should also consider deals with different EDA vendors, local expertise in one or the other language, or availability of the different Verification IPs in one or the other language.
Even though it is possible to drive SystemVerilog OVM components from e sequences (or vice versa), I would not recommend maintaining an environment using both languages unless you have real expertise in both in your team.
In fact, I can easily imagine debugging an verification environment in e with SystemC reference models, VIP in e and in SV (eVC and uVC ?), interfaced with a design in Verilog and VHDL, including a CPU running some C firmware and the overall thing encapsulated with thousands lines of Perl to run a single test.
If you can just keep thing simple, try to do so. The next person working on the project will thank you.
I do agree with all points mentioned by Mr. Richard. I have worked on both 'e' and 'SV' and I strongly support 'e' from productivity , manageability and re-usability point of view.
Not sure about the comments comparing the easy of replacing e verification components versus SV ones. Either case is straightfoward if the interfaces are compatible. I've been involved in many projects that aimed to replace e by SV - most of the problems and "lack of productivity" were due to the naive insistence in replicating the configurabilty provided by AOP in SV. Many times it would have been better to use pure OOP techniques. As for other productivity issues, it's really because the tools we have are not very powerful as tools, as well as significant oversights in the SV LRM. Take introspection. The reason there's so much extra code required for OVM/UVM compared to e is because the language does not provide the introspection that e does. It's a ridiculous oversight as the tools already have the capability (they have to have otherwise they couldn't operate at all) - yet verifiers have to jump through hoops defining the obvious simply because there's no introspection.
SV is definitely not the answer to problem of verification, but neither is e - they're both just a means to an end. The hard part of verification is not in the coding, it's in writing good verification plans and meaningful coverage goals in the first place. The language and low-level frameworks to connect it all up are the easy part.
Great analogy with the screw driver & knife. I liked the part where this analogy justifies why SV is more common despite being off.
Having worked on 'e' formany years and moving to other HVLs I strongly support 'e' as a better option for verification engineer, be it productivity, managing code, maintaining code, debugging it & reusing it.
If there is a movement of one language to another - a drop in productivity is expected and applies vice-versa to & from any language.
Existence of 'e' has long history, but has it was long guarded by it's proprietary terms and we should give the same amount of time for SV to grow & mature.
Agreeing with Daniel, I also want to add SV may be difficult to learn & adopt for e-users but as easy for Verilog users which has long history as a design & verification language. Also,at our concern, designers feel more comfortable with SV as a verification language.
Thanks for clarifying this Geoffrey!
I actually had to learn e coming from a Verilog design background. I have to say that I went through a lot of eye-opening realizations while ramping up on e and then planing, coding and applying the eRM methodology.
When I had to learn SV, I at first thought that it is not so bad but not as powerful as e. Now that I have been using SV I am really disappointed with that language. First of all, it does not naturally embrace verification methodology. What I mean with that is, comparing e and SV OVM and UVM, I see the eRM everywhere in UVM, however the UVM seems to not have added much to the eRM methodology but rather "patch" the shortcomings of SystemVerilog to make this language usable.
So, I have to say that I completely agree with the rest of the article and also I favor e over SV any time.
I'd be happy to read/hear some more user eperiences with respect to the eRM to OVM/UVM.
Thanks again for this great article!
Excellent summary of differences between the languages. I'd pick e over SV any day - unfortunately they made e too expensive and thus lost much of the market share. I'd be very happy to see e take back the market from SV, but doubt that will happen now since so many have gone through the 'pain' of learning SV.
I think SV could be further simplified and structured for verification though - the multitude of files and folders can be very confusing to navigate; a methodology for keeping things organized (needs to improve on OVM, VMM) might help simplify SV a bit. Having too many ways of doing things ends up confusing the user.
The best product doesn't always win, so we're left with using a knife for putting in eyeglass screws.. ;-)
Excellent article. I agree with many of the points. I've been working with SV for several years and keep reminiscing about my days using 'e'. Everything *seemed* so much easier, but I could never quantify it like M. Faurie has at STM.
What I'm also curious about (but this may not be the best forum to discuss) is the "maturity" of the implementation of the languages. I have to believe that e continues to be aligned with the spec as the current (single source) implementation has been around for a while and is still being actively used; while the various vendors' SV implementations don't quite hit ALL the various language constructs. I expect that state to continue for a *while* yet -- especially as language continues to evolve. My point being, that this implementation maturity also has an impact on productivity. Albeit smaller than the underlying concept that e is designed specifically to make verification easier.
Thanks again for a great article and sharing your views.
I am agree with you Daniel but from my experience I mean teaching first e and now SV to designer engineer, I have noticed that SV ramp up for verification is shorter than e one for this engineer profile (one explanation is that designers are more receptive to OOP than to
But anyway design and verification way of thinking are sufficiently different to justify that jumping from one domain to the other is always tricky.
This is a great article, however I disagree with the assessment of the SystemVerilog advantages. I think SystemVerilog for design can be picked up very quickly by a design engineer since this really is a real extension there.
On the other hand a design engineer wanting to use SV for verification needs to learn a completely different language. Think of SV for verification is like learning the Java language. As stated in the article SV for functional verification is object-oriented and that domain is way different than the RTL design domain.