Quantcast
Channel: Cadence Functional Verification
Viewing all articles
Browse latest Browse all 652

Rumors of SystemVerilog’s Death Have Been Greatly Exaggerated

$
0
0
Our 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.

 


Viewing all articles
Browse latest Browse all 652

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>