Home > Community > Blogs > Functional Verification > rumors of systemverilog s death have been greatly exaggerated
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Rumors of SystemVerilog’s Death Have Been Greatly Exaggerated

Comments(6)Filed under: SystemVerilog, accellera, uvm, uvm world, universal verification methodology, UCIS, JL GrayOur friend and fellow blogger JL Gray recently published a post with the provocative title "UVM and the Death of SystemVerilog." That sure raised some eyebrows here at Cadence and elsewhere, leading to a flurry of tweets debating several of JL's contentions. I was tempted to join in the fray, but as I re-read his post and thought more about it, I realized that I had enough to say to write a blog post myself. JL made a number of statements that got me thinking, and while I don't intend to write a point-by-point response I do have some contentions of my own.

JL's main argument is that the virtues of a standard methodology (UVM = Universal Verification Methodology) built in a standard language (SystemVerilog) are being compromised because both are hard to learn. I can't really argue but I think it's worth separating two aspects of that difficulty. SystemVerilog is, in truth, a bit of a "Frankensteinian" language. Its many new constructs on top of Verilog came from several different sources. Further, it is a dual-purpose language meant to both describe designs and verify them. It lacks some of the elegance of certain other languages but it does the job, as evidenced by its wide usage and overall success. It is most surely not dying.

The second difficulty in learning the UVM and SystemVerilog is the leap in thinking required to embrace object-oriented programming (OOP) and other advanced concepts. This same challenge exists for just about every "modern" language as well as alternative verification and modeling languages such as e and SystemC. JL calls out for the industry to start looking at "other languages and development frameworks." I frankly find it hard to imagine that any other approach would not entail the use of OOP and therefore require a solid understanding of this programming discipline.

JL concludes by contending that EDA vendors will not, or perhaps cannot, produce the level of innovative thinking to define such a new language. His implication seems to be that both SystemVerilog and the UVM were foisted on the industry by EDA vendors and that's the best we can do. In fact, both of these were produced by standards bodies comprising a mix of EDA vendors, consulting companies, semiconductor suppliers, and systems houses. All can claim credit for the wide success of the UVM and SystemVerilog, while sharing a bit of blame for the less elegant aspects of the language.

I believe that UVM does represent innovation on the part of the industry as a whole, with EDA vendors playing a key role. The UVM has done more than any other single technology to move countless thousands of users to advanced verification. The upcoming Unified Coverage Interoperability Standard (UCIS) is another innovative industry-wide effort likely to have great benefit for users. There are many additional examples of ongoing EDA innovation in functional verification: low-power flows, much faster mixed-signal simulation, multi-core support, unique blends of simulation and formal techniques, and more.

But innovation does not imply that we need to rush off and define yet another language. Sure, someday there will a better verification language than SystemVerilog and a better methodology than the UVM. However, the reality is that every new language and methodology requires a huge investment. It takes EDA vendors three or four years to implement a new standard and by that time there's probably a new version ready to be implemented. Users invest billions of dollars in training and building reusable verification components. Let's leverage this investment; there's a lot of headroom for improved verification productivity and quality with what we have in hand today: SystemVerilog, e, SystemC models, and multi-language UVM. Let's run with it!

Tom A.

The truth is out there...sometimes it's in a blog.



By horace on September 15, 2011
We don't need a new verification language, there is Specman e
We only need need the other two EDA companies admit they also support IEEE1647.

By tomacadence on September 16, 2011
Many engineers consider e a more elegant and focused language than SystemVerilog for verification. I agree that public statements of support from other vendors would be beneficial to e's large and growing user community. We can't make that happen ourselves but perhaps the users can if they keep pushing!
Tom A.

By Tom Fitzpatrick on September 19, 2011
Looks like "rumors of SystemVerilog's death" aren't the only thing being greatly exaggerated. If you look at blogs.mentor.com/.../part-8-the-2010-wilson-research-group-functional-verification-study you'll see the results of a blind study by Wilson Research Group showing that usage of 'e' is actually shrinking (Figure 4), as is usage of eRM (Figure 5).

By tomacadence on September 19, 2011

I did see that blog post; kudos to Mentor for commissioning the survey and to Harry for offering some very interesting analysis. Specific to Specman/e, your survey reports a slight dip in usage from 2007 to 2010. I just ran the numbers from our internal sales system, and have the hard data that the number of Specman licenses in active use by our customers grew significantly over this same period. No matter how carefully a survey is done, it is after all only a sample.

Your survey also suggests a drop-off in Specman/e usage over the next 12 months. I've commissioned and analyzed surveys too, and one very common result is that respondents over-estimate how quickly their environment will change. I'm sure that some Specman/e users feel that they will be forced to switch to SystemVerilog but I predict that far fewer will actually do so. Further, we've seen several projects try SystemVerilog and then switch back to e because they lost 30-40% efficiency:

* www.cadence.com/.../user-view-where-e-outshines-systemverilog-for-functional-verification.aspx

* www.cadence.com/.../user-view-is-e-or-systemverilog-best-for-constrained-random-verification.aspx

On the other hand, I do believe that usage of eRM and URM is declining. UVM is the standard, and with Cadence's contributed e and SystemC extensions paving the way it's natural for users of all older methodologies to switch to multi-language UVM regardless of their language or mix of languages. UVM is the way forward; surely we agree on that!

Tom A.

By Gaurav Jalan on September 26, 2011
IMO, multi-language support in UVM probably would be more interesting & useful. I believe it is the language that makes UVM look tedious. Maybe if it was tried on 'e' first and then extended to SV, the blog post title would have eliminated "UVM" probably.


By tomacadence on September 27, 2011

I agree 100% that multi-language UVM is interesting and useful. As you know, Cadence has contributed e and SystemC UVM libraries to UVM World, and we are encouraging Accellera to extend the standard to include full multi-language support.

Tom A.

Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.