Cloud computing was the subject of much interest and discussion at this year’s DAC.  While I acknowledge that the cloud will play an increasingly important role in our business, its displacement of today’s semiconductor design practices is easily a decade or more away.

The attraction of the cloud is to increase one’s access to raw computing power and software.  If you need more speed, or a specialized program, just grab it and go.  But the hard work and differentiation for our customers is still done in the trenches, not up in the sky.  They are not about to put their proprietary designs on some server, somewhere, or give up their customized and optimized design flows.  What can we in EDA do for them today to help with increased design complexity and the need for higher performance?

For me the answer lies in maximizing throughput by leveraging the advantages of parallel computing.  This is also a subject of great debate within our community, often involving the technical difficulties of parallelizing EDA software (particularly legacy software) and its impact on traditional business models.  These are real challenges, but so are the benefits to our users when we get it right.

There are myriad technical questions to address: What parts of the software to parallelize?  How to avoid dead locks, live locks and race conditions?  Is it possible/feasible to adapt legacy software for parallel applications and at what cost?  How scalable will the parallel software be?  What about resource allocation and tracking?  These are in addition to many other deep technical challenges known from the parallel computing world.  There are also real business implications with dramatic performance improvements such as recognizing appropriate value when tool efficiency goes up dramatically.

I’ll address the business case briefly.  Our job in EDA should not be to limit productivity, but to maximize it.  At Jasper we always sell based on a customer’s ROI, and how much real value we add to their organization.  That shouldn’t be based on volume purchasing, but on the effectiveness of our solutions.
As to the technical issues, it must be said that not all applications easily lend themselves to this approach.  In our case, the parallelization of our flagship formal verification system, JasperGold, has been extremely valuable to our customers for compute-intensive tasks such as block-level verification, proofs of sequentially deep properties, protocol certification and regression testing.  It should be noted that not all legacy code will lend itself to adaptation, but there are many instances of the successful porting of existing software to run on multiple cores throughout the industry.

Another success for us came by moving intelligent task distribution management into the designer’s hands with our ProofGrid and ProofManager products. This has enabled the dynamic allocation of properties, proof engines and licenses over a computer network for parallelism and efficiency to significantly raise formal verification throughput and performance by leveraging the power of local machine, cluster, and computer farms. It also provides seamless and powerful distribution and collaboration management for proof engines running on the network under a unified tracking console. The result is greatly enhanced productivity as users are freed from manually separating and dispatching multiple, single runs and then collecting the results for each.

It’s important to look ahead to the advent of game-changing technologies such as cloud computing, but we should not neglect the opportunity presented to us today to help our customers by speeding the adoption of parallel execution of EDA tools.

First of all, we’d like to invite all the DAC attendees to Accellera’s breakfast and panel about UVM: Charting a New Course on Tuesday, June 15, 7:30 am – 9:00 am, Room 203B in Convention Center.

It is no news when one talks about increasing complexity of designing the SoC devices. It is a foregone conclusion that designing is a relatively bounded problem compared to verification. Just as design reuse through Semiconductor IP (aka design IP) helped bring the designers up the productivity curve, in the last decade Verification IP (VIP) has done the same for the verification engineers. Two leading methodologies, Verification Methodology Manual (VMM) and Open Verification Methodology (OVM), helped accelerate the adoption of structured verification methodologies using SystemVerilog as well as the creation of commercially available verification IP to independently validate integration of design IP in SoCs. Essentially, both methodologies are a collection of SystemVerilog classes with inherent semantics for their behavior in different phases of the simulation. The user creates verification objects from these classes and attaches them to the design components as traffic/data generators, monitors, checkers, etc.

Both verification methodologies are built on SystemVerilog, both have been available under Apache license, and both have been successfully deployed in production environments – with one caveat, as long as the verification IP was built on only one of them and not the other. This is where the problem arises. Many projects acquire Verification IP (VIP) from multiple vendors, and occasionally even multiple groups inside a company may have worked independently using different methodologies. Naturally, there is a conflict for integrating such VIPs into one consistent verification environment.

In 2007-08, this was recognized as an issue, and leading users formed the Verification IP Technical Subcommittee (VIP-TSC) under Accellera. By July 2009, 12 recommended practices were formalized in the form of an API to allow interoperability of VMM and OVM VIPs in a single environment. However, it was only seen as the first step in solving a larger problem – that of having publicly available universal base classes that can be used for creating a wide variety of VIPs. Naturally, if all VIPs are based on the same base class library, one does not need to go through an interoperability API. Thus came to life the second phase of the VIP-TSC efforts, UVM base classes.

The UVM base class is based on SystemVerilog. OVM 2.1.1 was used as the starting point to define UVM. In Accellera’s Early Adopter release of the UVM (UVM-EA), there were some enhancements to Callbacks and End-of-Test features, and a new type of Message Catcher callback was added, along with renaming of objects to UVM_*.The VIP-TSC has a list of items that brings features from OVM, VMM and other home-grown methodologies to add to UVM-EA for release 1.0 and beyond. However, current and planned features of UVM base class can be best described as the reflection of collective knowledge of the verification experts participating in VIP-TSC.

In other words, are we just transferring the knowledge from syntactically and semantically different methodologies into a new one? What is the real value to this exercise? If we fast forward by a year, what would UVM base class release X look like? What features should it have to solve the problems faced a year from now? 3 years from now? Are we looking at adding more of the same or make a quantum leap in our ability to deal with much larger and significantly more complex designs? What specifically are we doing to improve our ability to find bugs in the design and then fix them?

This is the topic of our breakfast discussion at DAC, hosted by Accellera and sponsored by its members Cadence, Mentor and Synopsys. The panelists are verification experts from our user and vendor community. Our moderator is no stranger to challenges and stimulating great dialog across the industry. This is the time for you to find out more and chime in.  See you there.

UVM: Charting the New Territory
When/Where: Tuesday, June 15, 7:30 am – 9:00 am, Room 203B in Convention Center
Host: Shrenik Mehta, Chairman, Accellera
To register visit: www.accellera.org/events
Moderator: Gabe Moretti, www.GabeOnEDA.com
Panelists:
Sharon Rosenberg, Verification Solutions Architect, Cadence
Hillel Miller, Verification Manager, Freescale and VIP-TSC co-chair
Mohamed Elmalaki, Verification Expert, Intel
Tom Fitzpatrick, Verification Technologist, Mentor
Janick Bergeron, Synopsys Fellow, Synopsys
Stacey Secatch, Sr. Staff Verification Engineer, Xilinx