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.