Cadence Functional Verification Blogs

How Can You Continue Learning About Advanced Verification at Your Desk?

umery — Mon, 03 Jun 2013 21:39:00 GMT

How much time do you spend "playing" and "learning" before you try a new EDA tool, feature, or flow?
Do you really take a training class and sift through the documentation or books about the subject before you start project work? Or are you the type who has the knack of figuring things out on your own by taking a deep dive, head first?

Learning is an iterative and repetitive process. Human beings spend most of their lives learning through a structured learning program in their school years, then an expensive and elective college adventure, leading to years of learning during their professional lives. The big challenge that I have faced with learning is how to find the right learning vehicle that helps me discover what I didn't already know in a short period of time. If you struggle with this aspect, you should look at Cadence Rapid Adoption Kits (or, RAKs).

Rapid Adoption Kits from Cadence help engineers learn foundational aspects of Cadence tools and design and verification methodologies using a "DIY" approach. Don't get me wrong, instructor-led, structured training programs work beautifully if you can invest the time and money. But there is always demand for learning something simply and quickly in some corner of the world.

Today, we have made available eight RAKs focused to help our users learn various aspects of digital IP and SoC functional verification methodologies and tools.

The RAKs provide an introduction to state-of-the-art verification solutions including Universal Verification Methodology (UVM), based on the industry-standard UVM Reference Flow donated by Cadence for digital and mixed-signal verification using Incisive Enterprise Simulator and Metric Driven Verification methodology (MDV). For implementation, the flow uses Incisive Enterprise Manager, as well as SoC verification techniques such as I/O connectivity using Incisive Enterprise Verifier and optimization of simullation performance for large SoCs.

The examples referenced in the Rapid Adoption Kit exercises are based on the Cadence SoC Verification Kit. You can view presentations, app notes, videos and/or download the package that also contains lab exercises, relevant scripts and instructions.

Download your RAK today at http://support.cadence.com/raks.

Happy Learning!

Umer Yousafzai

Introducing UVM Multi-Language Open Architecture

Adam Sherilog — Sat, 01 Jun 2013 02:06:00 GMT

The new UVM Multi-Language (ML) Open Architecture (OA) posted to the new UVMWorld is the result of a collaboration between Cadence and AMD. It uniquely integrates e, SystemVerilog, SystemC, C/C+, and other languages into a cohesive verification hierarchy and runs on multiple simulators. Moreover, the new solution is open for additional collaboration and technology enhancement.

Since Cadence introduced ML verification four years ago, the need for it has never been greater. Complex SoCs are verified with a combination of industry-standard languages and frameworks including IEEE 1647 (e), 1800 (SystemVerilog), 1666 (SystemC), and Accellera UVM, as well as C/C++, VMM, Perl, and others. The previous ML solution enabled the standard connections but had some limitations. Among the limitations included are a focus on “quick-stitch” integration that allowed for data communication but required significant additional coding to synchronize the communication. In addition, the solution was built primarily for the Incisive Enterprise Simulator.

Bryan Sniderman, Verification Architect for AMD, introduces the requirements that drove the development, the limitations in existing solutions, and the features you can expect in this UVM ML OA video. In the video, Bryan describes how the new solution enables hierarchical integration of the frameworks, seamless phasing, seamless configuration, and has the ability to run on multiple simulators.

You can also learn more about the solution in our webinar, “Introducing UVM Multi-Language Open Architecture,” archived on Cadence.com. If you are at DAC, stop by the Cadence Theater on Wednesday at 4:30pm to hear Mike Stellfox present the solution and take part in our Q/A that will follow. Of course, you can also stop by the booth to learn more as well or send an email to support_uvm_ml@cadence.com if you have any questions. Finally, note that you will need to register in the Accellera Forums to download the UVM ML OA and that registration is open to all.

Think of the UVM ML OA as a new beginning. As you read through and watch the background materials, you’ll probably see a mix of exciting new features and opportunities to further improve the solution. We welcome that input. The solution you see here represents a solid foundation, but there is more that we can do and we are happy to expand the collaboration to bring in those new ideas.

=Adam Sherer on behalf of the AMD and Cadence collaboration

New Specman Coverage Engine - Extensions Under Subtypes

teamspecman — Tue, 28 May 2013 13:31:00 GMT

This is first in a series of three blog posts that are going to present some powerful enhancements that were added to Specman 12.2 in order to ease the modeling of a multi-instance coverage environment. In this blog we're going to focus on the first enhancement, while the other two enhancements will be described in the following coverage blogs.

Starting with Specman 12.2, one can define the coverage options per subtype. Using per-instance, Specman checks the subtypes of each instance, and applies only the relevant subtype options. We will demonstrate the power of this in both "per unit instance" and "per subtype instance."

I. Utilizing when extensions for modeling per subtype instances

One intuitive use of extensions of covergroups under "when" subtypes relates to covergroups which are collected per subtype using the per_instance item option:

type packet_size_t: [SMALL, LARGE];

struct packet{

size: packet_size_t;

length: uint(bits:4);

event sent;

cover sent is{

item size using per_instance;

item length;

};

The results of the above covergroup are collected per each value of the size item, so in practice this covergroup is collected separately per each "size" subtype.

Let's assume that small packets can only have length < 8, and big packets can only have length >= 8. The following code was needed in pre 12.2 releases for refining the irrelevant values of each subtype:

extend packet{

cover sent(size==SMALL) is also{

item length using also ignore=(length >= 8);

};

cover sent(size==BIG) is also{

item length using also ignore=(length < 8);

};

This code can now be replaced with a native "when" subtype extension:

extend packet{

when SMALL packet{

cover sent is also{

item length using also ignore=(length >= 8);

};

when BIG packet{

cover sent is also{

item length using also ignore=(length < 8);

};

II. Utilizing when extensions for modeling per unit instances

Extension of covergroups under "when" subtypes can also be used to model the different instances of a covergroup that are collected per-unit instance, according to the exact subtype of the containing instance.

Let's see a code example that illustrates the power of this capability. In this code we model a packet generator unit that generates packets of different sizes. The packet generator unit has a field which describes the maximal size of a packet that a packet_generator instance can generate:

type packet_size_t: [SMALL, MEDIUM,LARGE,HUGE];

struct packet{

size: packet_size_t;

};

unit packet_generator{

max_packet_size: packet_size_t;

event packet_generated;

cur_packet: packet;

generate_packet() is{

gen cur_packet keeping {it.size.as_a(int) <= max_packet_size.as_a(int)};

emit packet_generated;

};

extend sys{

packet_gen1: packet_generator is instance;

keep packet_gen1.max_packet_size == LARGE;

packet_gen2: packet_generator is instance;

keep packet_gen2.max_packet_size == MEDIUM;

packet_gen3: packet_generator is instance;

keep packet_gen3.max_packet_size == HUGE;

};

Oh, right, there's that coverage thing we need to define in order to check that each valid packet size was generated in each instance of the packet_generator :

extend packet_generator{

cover packet_generated using per_unit_instance is{

item p_size: packet_size_t = cur_packet.size;

};

OK, so the above code enables the coverage collection of p_size separately for each instance of packet_generator. Let's generate 100 packets in each packet generator instance. Surely we'll get 100% coverage?

Well, we won't. When launching Incisive Metric Center (IMC), three of the coverage instances are not fully covered. For example the grade of the instance under sys.packet_gen1 is only 75%:

The reason for that is the constraint that prevents the generation of HUGE size packets in instance sys.packet_gen1, so no matter how many packets are generated in that instance, the ‘HUGE' bucket (bin) will never be covered.

We need to refine the valid buckets according to the generatable packet size in each instance. We can use the instance specific covergroups extensions for that:

extend packet_generator{

cover packet_generated(e_path==sys.packet_gen1) is also{

item p_size using also ignore = p_size.as_a(int) >

packet_size_t'LARGE.as_a(int);

};

cover packet_generated(e_path==sys.packet_gen2) is also{

item p_size using also ignore = p_size.as_a(int) >

packet_size_t'MEDIUM.as_a(int);

};

cover packet_generated(e_path==sys.packet_gen3) is also{

item p_size using also ignore = p_size.as_a(int) >

packet_size_t'HUGE.as_a(int);

};

Now we can achieve 100% grade for each instance:

But in 12.2 we can use the following subtype extensions instead:

extend packet_generator{

when SMALL'max_packet_size packet_generator{

cover packet_generated is also{

item p_size using also ignore = p_size.as_a(int) >

packet_size_t'SMALL.as_a(int);

};

when MEDIUM'max_packet_size packet_generator{

cover packet_generated is also{

item p_size using also ignore = p_size.as_a(int) >

packet_size_t'MEDIUM.as_a(int);

};

when LARGE'max_packet_size packet_generator{

cover packet_generated is also{

item p_size using also ignore = p_size.as_a(int) >

packet_size_t'LARGE.as_a(int);

};

when HUGE'max_packet_size packet_generator{

cover packet_generated is also{// for extend packet_type_t: [GIGANTIC]; ...

item p_size using also ignore = p_size.as_a(int) >

packet_size_t'HUGE.as_a(int);

};

At first look, the later solution doesn't look more efficient than the former one. It includes 4 extensions of the covergroup instead of 3 extensions that were needed before. But what would have happened if instead of only 3 packet_generator instances we would have 100 instances? If we extend each instance by itself, as we've done in the first solution, we will need to extend each one of the 100 covergroup instances.

While using the "when subtype extension" solution, the 4 extensions above satisfy the requirement for any number of instances.

Even more important, the solution which uses "when subtype extension" is reusable, since it doesn't use the full path of the covergroup instances. So it is much more suitable for verification IPs and for module verification environments which are later integrated into system level verification.

But before you run and start extending your covergroups under subtypes, I'd like to mention that there is another newly supported option in the e language which is even a better suited for that exact scenario which is described above - -it is called the "instance_ignore" item option.

What is this "instance_ignore" option?
Why it is better suited for the above scenario?
For which scenarios is the ‘extension under when subtypes' better suited?

Answers for all of the above questions (and more) will be found in the next Specman coverage blog -- "Using Instance Based Coverage Options for Coverage Parameterization"

Team Specman

Mode Support for SimVision “Stop Simulation” Button

teamspecman — Wed, 08 May 2013 13:32:00 GMT

Prior to Incisive Enterprise Simulator (IES) 12.1, clicking the SimVision "Stop Simulation" button would stop the simulation both in an HDL context and in a Specman context if Specman was present in the simulation. To provide better flexibility in the exact place where you want to pause, the "Stop in Specman only" functionality has been introduced.

As of IES 12.1,whenever Specman is present in the simulation, the SimVision "Stop Simulation" button provides a drop-down menu that lets you choose between two switchable modes: "Stop Simulation" (wherever the simulation is now), and "Stop in Specman" (see the following figure).

SimVision will immediately perform the "Stop" operation in the mode you select, and keep that mode persistent. It will also indicate the selected mode in the button icon and tooltip (see the following figure).

Note the "e" over the button. The "e" indicates that you selected "Stop Specman" mode. (Had you chosen Stop Simulation, no indicator would appear over the button.)

When you click the "Stop" button while SimVision operates in "Stop Specman" mode, the simulation will stop only when it is in Specman, not before.

To toggle between the Stop Simulation modes, just make your new choice in the dropdown menu.

Note that if you run the simulation without Specman, or invoke standalone Specman, the drop-down menu is absent and the "Stop" button works in "Stop Simulation" mode (see the following figure).

Alex Chudnovsky

Develop For Debugability – Part II

teamspecman — Tue, 23 Apr 2013 13:00:00 GMT

Looking at Coding Styles for Debug

In this blog post we are going to discuss 3 different cases where coding style can help you debug easier:

1. Declarative vs. Sequential Coding

2. Method Call Depth

3. Calculating if-else Conditions

Declarative vs. Sequential Coding

When modeling your testbench you will need to write code that describes time-consuming or complex steps of some intended behavior. This will be considered sequential code.

You will also most likely need code that keeps the current state of your object accessible to other objects, as well as tracking these object states over time. This will be considered declarative code.

While developing your testbench you will find yourself asking quite often: "Should I make this declarative or sequential?" As a general guideline, reducing the number of sequential lines of code and keeping as much information as possible in the declarative code will help you to debug a lot quicker.

Specman has a superb data-browser and step-debugger and it is important to keep this in mind. When debugging code you usually want to see where the testbench and the RTL go out of sync. The common approach would be to fire up your failing simulation and set the breakpoints:

Specman> break on error

Specman> break on gen err

This will make your simulation stop on an error and open up the debugger, highlighting the precise line where the error occurred. In an ideal case, you can already tell from your error description what went wrong. This however is rather rare and you should get acquainted with the current state of your testbench and gather all declarative information you can get through Specman's data browser. This will give you an understanding of where the simulation has headed, and chances that you will understand the error are pretty good if you tracked enough information in your declarative code. If you are fortunate enough you can already resolve the error or at least have a conversation with the person that might have to fix this scenario.

However, there are still quite a few cases where you need to rerun the simulation. Here you will have to dive into the remaining sequential code and do a step-by-step debugging session. Step-debugging is very tedious and will get more cumbersome the more sequential code you have to examine. It gets even more cumbersome if you are relying on a lot of temporary variables inside your methods.

Method Call Depth

While developing sequential code you will be defining and implement a bunch of methods. Crafting methods is usually a straightforward process. In verification you need to think aboiut whether you need a time-consuming method (TCM) or a timeless method. As a general rule, if you are modeling event-based models or checks, then you need a TCM -- otherwise try to stick with a regular, timeless method.

Mostly you will be developing methods for:

Interface and Virtual Sequences
Interface Monitors (not block-level monitors)
Bus-Functional Models (BFMs)
Reference Models
Scoreboards

Due to this separation of functionality, given by the UVM-e, there is already a given blueprint for how to integrate these methods with each other.

One issue that may come from developing methods is that one may feel tempted to create methods for reusability and hence encapsulate even trivial steps in a method and have that method called, instead of typing out these steps. The problem with debugging code that relies heavily on method calls is that you always step into a new method and lose the scope of your method's callee.

The opposite problem of creating too many methods implements mega-monolithic methods. These kinds of methods are hard to debug and understand as well, since they usually not only carry the context of one specific modeled aspect.

Pre-Calculating if-else Conditions

The essence of code execution is handling conditional branching constructs. Generally there is nothing wrong about simply writing a condition into your if-else actions. However, complex Boolean expressions should be evaluated before entering the expression query. By creating a temporary variable and assigning a Boolean evaluation to it, you will gain two advantages:

Create a meaningful variable name
Break on the if-execution with the condition already evaluated

To read part 1 of this blog series, click here.

Daniel Bayer

Develop for Debugability – Part 1

teamspecman — Mon, 08 Apr 2013 14:00:00 GMT

Debugging is the most time-critical activity of any verification engineer. Finding a bug is very often a combination of having a good hunch, experience, and the quality of testbench code that you need to analyze. Since having a good hunch and experience is something everyone needs to acquire for themselves, I am going to focus on potential code optimizations that help reduce debug time.

Encapsulate your Aspects

As in any other object-oriented language, modeling should be a planned rather than an ad-hoc process. However, as a verification engineer you are heavily reliant on others to help you in the planning process to develop your testbench. As such, you will quite often be forced to do ad-hoc programming to model a new requirement, or rewrite already existing code to meet a slight change in an already existing requirement. The UVM-e guidelines already provide a very solid basis; however even within those guidelines, your scoreboard can be very prone to becoming a dumpster for anything that you have to do on an ad-hoc basis.

You might be fine with just using your scoreboard for modeling all the RTL-to-testbench output checking. However, your testbench might have to handle more complex input-to-output transformations to provide the testbench output. This is where using the scoreboard as a dumpster for anything you can think of is a bad idea, and you should think about using a dedicated reference model to provide a well encapsulated input-to-output transformation or even an input predictor, based on the output you received.

As an e user you are in luck, because it is very easy to perform ad-hoc programming in e and avoid "the dumpster." In a series of steps, I am going to guide you through how to integrate your reference model into your block-level monitor unit.

Declare your scoreboard

<’

// This is just a place-holder for your scoreboard

unit my_scbd_u like uvm_base_unit {

// Place-holder method for input-to-output transformation

transform_received_to_expected( src_tr: src_prot_tr_s ): target_prot_tr_s is empty;

};

‘>

2. Instantiate your scoreboard in the Block-Level Monitor

<’

unit my_block_monitor_u like uvm_base_unit {

// the scoreboard instance

scbd: my_scbd_u is instance;

};

extend my_scbd_u {

// reference, do not generate

!p_block_mon: my_block_monitor_u;

connect_pointers() is also {

p_block_mon = get_enclosing_unit( my_block_monitor_u );

};

‘>

3. Create your reference model aspect feature and instantiate it in the monitor

<’

unit my_model_aspect_a_u like uvm_base_unit {

// reference to your monitor unit

!p_block_mon: my_block_monitor_u;

// All your fields, events, methods etc go in here

// ...

my_transformation_algorithm( src_tr: src_prot_tr_s ): target_prot_tr_s is {

// algorithm that models the transformation from input to output

};

connect_pointers() is also {

p_block_mon = get_enclosing_unit( my_block_monitor_u );

};

// Add a name for your model

short_name(): string is also {

result = ”ASPECT_A”;

};

extend my_block_monitor_u {

model_aspect_a: my_model_aspect_a_u is instance;

};

‘>

4. Integrate the first model aspect into the scoreboard

<’

extend my_scbd_u {

// Reference the aspect

!p_model_aspect_a: my_model_aspect_a_u;

// Add the transformation hook

transform_received_to_expected( src_tr: src_prot_tr ): target_prot_tr is {

result = p_model_aspect_a.my_transformation_algorithm( src_tr );

};

connect_pointers() is also {

p_model_aspect_a = p_block_mon.model_aspect_a;

};

‘>

5. Adding more aspects to the verification environment.

<’

extend my_scbd_u {

// Reference another aspect

!p_model_aspect_b: my_model_aspect_b_u;

// Add the transformation hook for another model aspect

transform_received_to_expected( src_tr: src_prot_tr ): target_prot_tr is also {

// This could be an example of a filter that alters or removes transactions

result = p_model_aspect_b.apply_filters( );

};

connect_pointers() is also {

p_model_aspect_b = p_block_mon.model_aspect_b;

};

‘>

In this flow, steps 1 through 4 have to be done once, and step 5 is simply just extending your transformation hook method with any additional algorithms you need to add to your scoreboard.

By following these steps as a guideline, you can quickly change reference model aspects to your scoreboard without creating a dumpster and this will help you debug any issues tremendously. Don’t forget to extend the short_name() method in your units for your messaging!

Daniel Bayer

Incisive Debug Analyzer is a Finalist for EETimes and EDN ACE Software Product of the Year

Karnane — Mon, 25 Mar 2013 17:17:00 GMT

Great news.... Incisive Debug Analyzer (IDA) is one of five finalists for the EETimes/EDN Annual Creativity in Electronics (ACE) Awards in the Software Product of the Year category. In addition to IDA, Lip-Bu Tan and Cadence are also finalists for ACE Executive of the Year and Company of the Year, respectively.

Check out the Press Release.

The awards program honors the people and companies behind the technologies and products that are changing the world of electronics. Winners will be announced April 23 during Design West in San Jose.

Companies today spend more than 50% of their verification effort in debug because bugs are hard to find at both the HDL level or at the testbench level. This has created a critical market need for sophisticated debug solutions that can find bugs quickly, thereby lowering design costs and speeding time to market.

In 2012, Cadence met this market need with the introduction of the Incisive Debug Analyzer (IDA) - a new and unique multi-language, "interactive" post-process debug solution that can help customers find bugs in minutes instead of hours. As the only debug tool in the market to deliver comprehensive and innovative debug functionality in a single, integrated, and synchronized debug environment, the new IDA can cut customer debug time by 40-50% and by more than 2X on really complex bugs.

About IDA

IDA provides sophisticated debug solutions to address RTL, testbench and SoC verification debug needs. Additionally, IDA provides an interactive debug flow in a post-process debug environment. This means that customers have all the functionality of an interactive debug flow while debugging in a post-process mode. Since users have access to all the data files, they only need to run the simulation once -- a significant time saver in debug.

IDA has several unique debug capabilities which are all very tightly integrated and synchronized into a single-multi-pane debug window. Here are just a few:

Playback Debugger: Unique functionality which allows customers to either step or jump through time to any source code line or variable change, both forward and backward in time.
Cause Analysis: Intuitive, flow-oriented debug environment which presents suggestions about where to look, in order to debug.
SmartLog: Integrated message window that shows logfile messages from HDL, testbench, C/C++/SystemC/Assertions, etc.

Learn more about Incisive Debug Analyzer.

Cadence is taking the lead in debug, and there are loads of new features, improved ease of use, and better performance planned for Incisive debug solutions in 2013 and beyond. Contact your Cadence representative for more information, in-depth demos/presentations, or hands-on technical workshops.

Happy Debugging!

Kishore Karnane

Specman: Getting Source Information on Macros

teamspecman — Tue, 12 Mar 2013 23:31:00 GMT

When you write a define-as or define-as-computed e macro, you sometimes need the replacement code to contain or to depend on the source information regarding the specific macro call, including the source module and the source line number.

For example, a macro may need to print source information, or it may need to create different code when used in one module than it needs to create when used in other modules.

You can achieve this as follows.

Define-as macro

In a define-as macro, you can use the following two special kinds of replacement terms inside the replacement block:

<current_line_num>	This is replaced with the decimal numeric representation of the source line number in which the macro is called.
<current_module_name>	This is replaced with the name of the module in which the macro is called.

For example, the following macro modifies the given left hand side expression (such as a field or a variable) to the given value, and prints an informational message reporting this change.

define <my'action> "modify_and_print <field'exp> <value'exp>" as {

<field'exp> = <value'exp>;

out("*** The value of <field'exp> was changed to ", <value'exp>,

" at line <current_line_num> in @<current_module_name>");

};

‘>

Assume the following code is then written in a module called my_module.e:

extend sys {

!x: int;

run() is also {

modify_and_print x 10;

};

‘>

This code will assign the value 10 to the field x, and will print the following output:

*** The value of x was changed to 10 at line 5 in @my_module

Define-as-computed macro

In a define-as-computed macro, the following two pre-defined routines can be used to query the current source line number and the current module.

get_current_line_num(): int	This routine returns the source line number in which the macro is called.
get_current_module(): rf_module	This routine returns the reflection representation of the module in which the macro is called.

To get the module name string, similarly to <current_module_name> in define-as macros, use the get_name() method of rf_module.

For example, the following macro adds a new field of type int to the struct in the context of which it is called. The field name is constructed from the current module name and line number. However, if the module name has the "_xxx" suffix, no field is added.

define <my_field'struct_member> "special_field" as computed {

var m_name: string = get_current_module().get_name();

if m_name !~ "/_xxx$/" then {

result = append("f_", m_name, "_",

get_current_line_num(), ": int");

};

‘>

The following code, if written in a module called some_module.e, adds two integer fields to sys: f_some_module_3 and f_some_module_4:

extend sys {

special_field;

};

‘>

Note however that if the same code is written in a module called some_module_xxx.e, nothing is done.

Yuri Tsoglin

e Language team, Specman R&D

Launch Time – Udacity CS348 Functional Hardware Verification Hits the Web Today, March 12, 2013

Axel Scherer — Tue, 12 Mar 2013 14:00:00 GMT

Coinciding with the first day of CDNLive! Silicon Valley, our Udacity MOOCs course on Functional Hardware Verification will go live today! Developing this course has been a very rewarding experience and we are happy this day has finally come.

Last week we gave you a sneak preview of the interactivity featured in the course. However, as you all know there is nothing like trying something by yourself to really get it.

So now it is your turn. Go ahead - enroll and check it out.

To give you more motivation to enroll, we are providing you another glimpse of the course. This time the clip is from unit 2, where we model packets for a data router.

Let's verify!

Axel Scherer
Incisive Product Expert Team
Twitter, @axelscherer

DVCon 2013: Functional Verification Is EDA’s “Killer App”

jvh3 — Mon, 11 Mar 2013 06:28:00 GMT

With another year of record attendance, DVCon has again proven that a functional verification-focused mix of trade show and technical conference is what customers need to get their jobs done. Here are some of the some of the highlights I took away from this informative event:

DVCon 2013 was a one stop shop for panels, papers, posters,
live demos, and tutorials on functional verification

* Great panels on Verification Planning and Drastically Improving D&V

Two panels at the conference provided valuable food for thought in their own ways. First, in regard to the Cadence lunch panel on "Best Practices in Verification Planning", EDA industry observer Peggy Aycinena wrote:

Sometimes magic happens at panel discussions at technical conferences, and that was the case mid-day on Wednesday at DVCon in San Jose this week, where the conversation was lively, entertaining and informative on the pedestrian, albeit foundational, topic of "Best Practices in Verification Planning." Ironically, the hour-long conversation did not appear to be planned at all, but to be organic and spontaneous ...

Granted I'm biased - but I have to agree whole heartedly. The panelists were generous in sharing their experiences with the mixture of art and science required by verification project planning, and I urge you to review either of Peggy's account of the panel or Industry Insights' Richard's Goering's in depth report.

Later that day "panel magic" happened again at the Industry Leaders panel on "The Road to 1M Design Starts". To everyone's delight, the panelists embraced the spirit of brainstorming how design and verification can be made significantly (think 20x, even 100x) more efficient. Sound impossible? One panelist gamely recalled that not many years ago there was a "software crisis" where the best software managers could expect was a net of 10 tested lines of code per day per engineer. Fast forward to the present, and teenagers with a lot of imagination but limited programming experience are creating money-making apps on incredibly complex mobile platforms thanks to very well thought out development tools and libraries. The panel challenged the audience to consider the lessons of such anecdotes in increasing abstraction and automation for EDA tool providers and their customers alike.

Richard Goering covers this panel in depth here in his Industry Insights blog.

* Apps as the new EDA paradigm

At last year's DVCon one of my product teams ("Team Verify") introduced the idea formal apps in our tutorial. (In a nutshell, a formal app enables usage of powerful formal engines "under-the-hood" by an engineer who has never used formal before, to solve specific problems.) At the time we were the only ones promoting this concept and offering the underlying product support. What a difference a year makes -- not only have our immediate competitors adapted this approach, but the "app" term was being applied to both formal, multi-engine, and pure dynamic simulation offerings and every thing in between. Of course, it's hard to be surprised by this given the EDA-related appeal is obvious: because apps are focused on specific, painful problems -- i.e. they are customer-centric by definition and in practice -- they are a clear win for both end users and vendors.

* The e/Specman Surge

After years of having waves of Specman-related abstracts be rejected seemingly out of hand, this year the assembly finally got to see what Specmaniacs have been eager to share with this verification community. One look at the posters by Meirav Nitzan of Xilinx (1P.21, Taming the Beast: A Smart Generation of Design Attributes (Parameters) for Verification Closure using Specman) and Horace Chan of PMC Sierra (1P.25 Maximize Vertical Reuse, Building Module to System Verification Environments with UVM e) and it's obvious that ‘e' and Specman usage are both thriving and they remain at the forefront of verification innovation.

Until next DVCon, may your power consumption be low and your throughput be high.

Joe Hupcey III

On Twitter: @jhupcey, http://twitter.com/jhupcey

Reference Links

DVCon 2013 Proceedings, http://dvcon.org/

DVCon 2013 YouTube playlist of speaker and panelist video interviews:
http://www.youtube.com/playlist?list=PLYdInKVfi0Kantj1U3H8pk9NkxFykT0rG

Richard Goering Industry Insights report: DVCon 2013 Expert Panel: How to Succeed with Verification Planning
http://www.cadence.com/Community/blogs/ii/archive/2013/03/05/dvcon-2013-expert-panel-how-to-succeed-with-verification-planning.aspx

Richard Goering Industry Insights report: DVCon 2013 Panel: 1 Million IC Design Starts - How Can We Get There?
http://www.cadence.com/Community/blogs/ii/archive/2013/03/01/dvcon-2013-panel-1-million-ic-design-starts-how-can-we-get-there.aspx

Peggy Aycinena, EDA Café: DVCon 2013: Best Practices in Verification Planning
http://www10.edacafe.com/blogs/whatwouldjoedo/2013/02/28/dvcon-2013-best-practices-in-verification-planning/