On Standards and Open-Sourcing. Verification Talks

At Veriest we host VERIFICATION MEETUPS periodically to share verification wisdom. In our virtual meetings we’ve had hundreds of attendants from the US, Europe, Israel, India, and China. Most recently we were able to host a live event in Israel – I want to share feedback from that meeting.

We started with two presentations: Elihai Maicas from NVIDIA discussed “Improved Solutions for Register Solutions”, and Avidan Efody from Intel, outlined a vision for “Post-UVM”, with a double meaning of something that could replace part of UVM functionality, based on Python-based post-processing of the verification database. A lively panel discussion followed. Avidan moderated, with Elihai, Efrat Shneydor (Product Engineer at Cadence), Guy (Verification Manager at a major system house) and an enthusiastic audience.

What are the advantages of UVM?

Avidan asked the panel if they could imagine a world without UVM.  What would be the upsides and downsides? Elihai summarized the obvious upsides nicely: the common layer, base classes, etc; without these we’d be reinventing that wheel. Ramp time reduces for each engineer. “Sometimes”, he said, “I find 15-year-old code developed for internal methodologies where the authors left long ago. What am I supposed to do with that?” A base UVM layer at least gives a common starting point above raw Verilog.

Guy added that UVM also gives us a common base for sharing know-how. “I have no sentiments for SV/UVM, but it’s what most of the industry has agreed on and it facilitates problem solving. Without that, how could we or the EDA industry invest in developing solutions to next level common problems?”

Avidan asked Efrat whether vendors really develop tools to solve UVM issues. “Sure”, she answered, “for example RAL was developed by vendors and is actively used today!” She added “I remember the days before UVM. There was always one recurring problem – no design for re-use. Maybe it’s still not ideal but we’re moved forward. People avoid basic mistakes. Stimulus generation is greatly improved, for example through sequences.”

Elihai added another benefit of a common methodology is the availability of VIPs, the fact we can take a USB VIP off-the-shelf, and it works! (This prompted a separate discussion about how hard is to integrate a VIP these days. That will be another blog.)

What are the disadvantages of UVM?

Shimon Cohen, an experienced verification team leader with Microchip jumped up: “SV/UVM is way too complex! Young electrical engineers starting here are in shock! It’s so overwhelming! I prefer to recruit people with C++ and JAVA knowledge rather than hardware background. I don ‘t care if they don’t know what a flip-flop is. SV and UVM are much more like software.”

Avidan remarked on the challenge with standards: Many people must sign-off on any change. Is this stalling innovation in the field? Guy agreed: “The software world”, he compared, “experienced many revolutions, one after the other, constantly innovating, AI, new tools and methodologies, constantly sharing knowledge. If you look at SV/UVM, or more broadly at verification methodology, you see little change – basically the same methodology that was used 10 years ago. Some cosmetic improvements only. It seems the industry has aligned itself to the lowest common denominator.”

Comparisons with the software world

Guy returned to his initial comparison to the software world. They could obsess about C++ and assembler improvements, but instead keep inventing new things! Why can’t we follow the same path in verification?

Guy remembered that “when SV started 10 years ago, there was a sense of innovation, there was excitement. That resulted in the benefits we talked about – ease to switch between projects/companies, VIP development, etc. In recent years, I don’t feel a similar spirit of innovation. On the software side, I see a lot of new ideas and conferences. If you attend an UVM conference 10 years ago and today – I don’t think you’ll find it that much different.”

This is a favorite topic of mine.  At the last DVCon Europe conference, I gave a keynote comparing  the verification world to the software world. Here, I asked if they thought the deadlock derives from SV/UVM standardization or tools on those standards coming only from the EDA vendors? What is holding us back – standardization or commercialization? Does it matter in the end?

Efrat said that one of the key problems is that verification people don’t share so the only source for advances is the EDA vendors. Someone in the audience suggested that people working in very large companies, are not allowed to share. This is not exactly true. Google – as an example – contributes a lot of open-source software, and even hardware code. Then again, Guy added he worked most of his career in startups, but they were in no hurry to share, either! However, there were at least two speakers at this meetup from large companies who openly contribute their ideas, if not code.

What about open source?

Elihai suggested that maybe the risk in open source is too high. “If a VIP has a bug, it could kill your Tapeout!” However, Shimon said/claimed? That bugs in open source tend to disappear quickly. “I am constantly downloading python applications from the internet, and I never had a problem.” Itai, an engineer who joined Veriest from a SW background added: “In the software world, every question I had, I googled it and in a second, I had an answer. On the hardware side, I may spend two hours searching the net for an answer, and I either find nothing or something that is not related at all, and I need to develop it myself.”

Why is this acceptable in the software world and not in the hardware world? Not sure we got to the bottom of this question.

In general, we believe that standard methodologies in Chip Design have brought and still bring many blessings to our industry. To thrive we need to have full understanding and command of the different features and possibilities. On the other hand, Veriest as a services company is involved in so many different advanced projects and must be open to out-of-the-box thinking to make ourselves more effective and efficient!

We’d like to hear your views on this important topic. Please leave your comments below.

To learn more about Veriest services, click HERE.

To attend/speak at future Veriest meetups, please WRITE US.

Also Read:

Agile and DevOps for Hardware. Keynotes at DVCon Europe

Israel and Automotive Safety. More Active Than You May Think.

Veriest Meetup Provides Insights on Safety, Deadlocks