Get email delivery of the Cadence blog featured here
Don't expect Michael Blech, a verification manager at PMC-Sierra's Fiber to the Home (FTTH) division, to switch from the Specman e verification language any time soon. A 10-year user of e, he has some strong views about the advantages of e over SystemVerilog, including language features that he says are often overlooked.
First, he'd like to make a clarification - SystemVerilog is not just an extended version of Verilog. While the naming was successful, it's actually a new object-oriented language. "More than two-thirds of the [SystemVerilog] language is actually something new," he said. "Designers have to learn what object-oriented is all about."
While e is a language specifically developed for verification, the role of SystemVerilog is "not defined yet," Michael said. When it comes to verification, his view is that SystemVerilog is "about where e was 7 or 8 years ago in terms of maturity and functionality."
AOP - A Different "Aspect" to Verification
One key difference between e and SystemVerilog is that e is aspect-oriented, whereas SystemVerilog is object-oriented. What does this mean in a verification context? Aspect-oriented programming (AOP), said Michael, "gives you the flexibility to change things as you go, without the need to rewrite a lot of your environment or your test data base."
A case in point: several years ago he was verifying a network processor when engineers suddenly discovered that the processor could not support full wire speeds and calculate a cyclic redundancy check (CRC) on Ethernet packets on some of its interfaces. By default, packets have CRC. AOP allowed an easy fix - creating a new "aspect" of a packet that does not have CRC. It wasn't necessary to modify tests or change the verification environment.
"Without AOP, you would need to create a new class or subclass that does not have CRC as a member," Michael said. "You would need to change your environment and modify all relevant tests." Moreover, it would probably be necessary to maintain two environments, one for packets with CRC and one for packets without it, potentially doubling the number of lines of code.
Random Stability, Coverage, and Debug
An often-overlooked advantage of e, Michael believes, is random stability. Long part of the e language, random stability ensures that tests will maintain the same pseudo-random values over multiple runs with a given seed, even if the test environment changes. Without random stability, he noted, it is possible to miss bugs when designs are modified or scenarios are changed. An engineer might think he's fixed a bug when all he's done is changed the scenario.
SystemVerilog has random stability up to a thread resolution (but is missing stability within a thread). Michael said the e language is more mature in this respect because "e is completely stable. If you find in e a scenario for the same thing, and you get different results, that means there's a bug that should be fixed, as stability is assured within a major version."
SystemVerilog has coverage, but Michael believes e language coverage is more mature. What's missing in SystemVerilog, he said, is scalability. The e language, he said, "allows you to have true coverage metrics for real life, and not just for several hundred simple items. In the last ASIC we verified, just on the top level, we covered more than 10,000 items and cross items, and lower level verification environments (cluster or unit) sometimes can hold a magnitude more than that."
When it comes to debug, one advantage of the e language is its ability to run in both interpreted and compiled modes. When it runs as an interpreter, Michael noted, e will not cause segmentation faults, but rather the simulation will stop, indicating that some coding violation or memory access violation has occurred. Also, when e is interpreted, you can easily make changes. "When you're debugging your code, and you want to try a new method, no problem - just execute it from the command line. There is no way to do that in SystemVerilog."
SystemVerilog runs only as a compiled language. "That means every time I fix something, I need to elaborate again. On large designs that is costly," he said.
Michael has not done direct comparisons of the language by applying both to the same verification problem. However, he's done evaluations of SystemVerilog and worked with many contractors that use both languages. He estimates that switching from e to SystemVerilog (assuming one is a proficient user of e) will cause a 30-40% productivity loss. (A similar conclusion was reached by an STMicroelectronics engineer featured in a previous Industry Insights blog interview).
SystemVerilog does have a few advantages. One is that, thanks to its name, "designers are less afraid of it and are willing to try it." Also, it is easier to accomplish zero time accesses to DUT structures for simulation performance (for example: read-modify-write to behavioral RTL memory models).
His advice to verification teams considering a language choice: "It depends on what you need to verify. If it's simple and you don't need to do a lot of generation, and you feel SystemVerilog is more natural for some reason, you can go for SystemVerilog. On the other hand, if the environment is heavy on generation, and complex in the way it manipulates information, you should go to e."
As for Michael himself, will he be switching away from e today? "Why would we take a step backwards in verification capabilities when we are faced with challenges of verifying even more complex chips?"
Cadence verification tools fully support both e and SystemVerilog, and both are IEEE standards. From a Cadence perspective, either language can be a good choice. The important takeaway is that there is a choice. With thousands of loyal users such as Michael, a great deal of legacy code, an ongoing IEEE standards effort, and a much longer history than SystemVerilog, you can count on e to be around for a very long time.