Verification Languages: 3 points to ponder beyond "which one?"

By Ann Germany, Director of Strategic Marketing at Globetech Solutions and Shankar Hemmady, Senior Marketing Manager at Cadence Design

It seems that every decade or so, the EDA industry throws itself into controversial debate about languages. Enormous amounts of energy, resources and mind space are poured into this altercation. Emotions run dangerously out of control, stoking the flames. The stakes are high: EDA giants take position - aim and fire. And the result? A battleground littered with failed projects and a bunch of disgruntled, weary customers suffering from unsupported needs!

We have forgotten that no one language is the panacea. Each language merits its own attention and perhaps serves a specific purpose more successfully than a comparable language and vice versa. Take for instance, the current battle being waged between "e" and SystemVerilog. The stakes are high because everyone is struggling with verification. But is choosing the "right" language alone really going to rein in that 70% of the design cycle spent on verification?

Let us consider some alternative topics to the verification language dialogue. At the end, we can re-visit the language question and decide what is ultimately more important.

1. Do we know what we're getting ourselves into?

An executive at a leading electronic systems company recently remarked how the predictability of his schedule for a successful product launch has plummeted from 90% to 40%. He attributed the drop in confidence to the 13X increase in complexity between the current and prior generations. Can verification be more predictable? How can we be confident that we will be able to launch a successful product within the market window? Can we better identify and isolate the areas that cause this unpredictability to enable us to exercise better judgment and make more informed decisions ahead of time?

2. Is there a way out of this mess?

Deploying thousands of simulations, directing resources across geographically dispersed teams and achieving total coverage across the block, chip, system and project levels are today's verification reality. Exasperating isn't it? With modern SoC's consisting of one or more processors, embedded software, instruction and data caches, large register sets, multiple buses, dedicated hardware accelerator, and a dozen or more interfaces to industry standards, simply keeping track of where we stand and what comes next becomes a problem on its own. How can we capture the verification process and what can be done to automate this process? What if the specification changes in the middle of the project? What if a critical bug is identified a week before tapeout? How can we manage the verification process to gain control over this flood of information?

3. Are we done yet?

It turns out that the devil is always in the details. That is why you made sure you verified that ethernet controller really well and also why you took extra care to check that traffic came in when the FIFOs were full. By now you may have used your verification language of choice to define hundreds of thousands - maybe millions - of coverage points. Maybe you are even keeping track of manufacturing and silicon debug functionality, that 20-30% of your chip gates, that for some reason, are not covered in your uniform verification environment.

But in order to answer multi-million dollar question #3 and to balance risk versus delivering a product, you are realizing that you cannot reach all your measurable targets (i.e. "metrics") in time to ship your product. Instead, you are finding that each metric must be qualified. Should the metric be the same for all parts, or should weights be placed on different parts to reflect their sensitivities? Should the metric be adjusted from project to project or adjusted for different vertical market segments? How do we encapsulate these metrics into the design life cycle? How do we capture these metrics from the various internal stakeholders as well as from our vendors and customers?

So, IS there more to verification than choosing the "right language"? The choice of verification language is important in the context of answering all of these questions because that language will serve as the foundation to providing solutions for these challenges. No matter the verification language chosen, whether one or multiple, verification planning, process management and qualified metrics, are critical to achieving predictability, reducing risk and ultimately delivering your product. So next time you find yourself in a conversation about verification languages, pose some of these questions and encourage your colleagues to not lose sight of the forest for the trees.

Got to EDACafe and participate in the dialog!