Verification Horizons BLOG

This blog will provide an online forum to provide weekly updates on concepts, values, standards, methodologies and examples to assist with the understanding of what advanced functional verification technologies can do and how to most effectively apply them. We're looking forward to your comments and suggestions on the posts to make this a useful tool.

30 July, 2015

Accellera Handoffs UVM to IEEE

It has been a long path from Mentor’s AVM to IEEE P1800.2.  But the moment has arrived: Accellera has formally announced UVM 1.2 will be submitted as a contribution to the IEEE P1800.2™ working group.

Verification Methodology Beginnings

As the IEEE finalized approval of the initial release of SystemVerilog (IEEE Std. 1800™) in 2005, I floated the idea of the need for a methodology that would be a companion to it.  At the time there was little to no industry desire to explore this opportunity in earnest – apart from interest by Mentor Graphics – so we launched our Advanced Verification Methodology (AVM) and set a new direction for an open functional verification methodology.  We built implementations of AVM based on SystemVerilog and SystemC (IEEE Std. 1666™).  We also pioneered an open-source mechanism based on the Apache 2.0 license which is now the accepted license to foster global and rapid open-source adoption in the EDA industry.  And as others joined with us in this journey, AVM grew to become OVM, then UVM.  Now UVM is set to become an IEEE standard.  The IEEE has assigned it project number 1800.2.

imagePath to IEEE

To say we are pleased to see UVM move to the IEEE is an understatement.  We congratulate the Accellera UVM team on its accomplishment and look forward to participate in this phase of UVM’s standardization. Since our first public announcement on May 8, 2006 when we introduced the world to AVM and announced support for it from 19 of our Questa Vanguard Partners, to our announced collaboration with Cadence Design Systems on the development of the Open Verification Methodology (OVM) on August 16, 2007 and the eventual announcement January 8, 2010 that Accellera adopts OVM as the basis of its Universal Verification Methodology, we have guided its development and supported a path for the Big-3 EDA to voice positive public support.  We are thrilled Accellera has announced its delivery of UVM to the IEEE for ongoing standardization and maintenance.

IEEE Standardization

What comes next?  The IEEE P1800.2 (UVM) project has announced a Call for Participation and kickoff meeting to be held August 6, 2015 from 9am – 11am PDT.  The first meeting will be held via teleconference.  In order to attend, you will need to register for the meeting.  Membership in the IEEE project will be “entity-based” with one company, one vote.  The call for participation has details on membership requirements in order to observe or actively participate.  The 1800.2 project will only focus on the written specification and not the open-source base class library (BCL).  The Accellera UVM TSC will continue to update the BCL.  Accellera has committed to keep the BCL implementation current with changes proposed and approved by the IEEE 1800.2 working group.  This is just like the arrangement Accellera has with the IEEE for SystemC.

Join us at the upcoming meeting and remember to register in order to attend!


, , , , , , , , , ,

29 July, 2015

VA DAC2015 smlIf you were not one of the 100’s of visitors to the Verification Academy booth at DAC 2015 and missed an opportunity to get a printed copy of the DAC 2015 issue of Verification Horizons, don’t worry.  You can also download it as well.

Questa Vanguard Partners Highlighted

Eight of the eleven articles were authored or co-authored by our partners and represent a wide range of topics.  There are two articles on DO-254 (Partners: eInfochips and Verisense).  There is an article on Formal and ABV of MBIST MCPs (Parnter: FishTail Design Automation).  There is an article on how to start formal analysis “right” (Partner: OSKI).  For UVM users, reuse of MATLAB® functions and Simulink® functions is covered (Partner: Mathworks).  Continuing with another article for the UVM users, intelligent testbench automation with UVM and Questa® is explored (Partner: Codasip Ltd.).  For the Agile community, unit testing your way to a reliable testbench is explored (Partner: XtremeEDA & User company: NVIDIA).  Lastly, a noted emulation consultant (Lauro Rizzatti) shares part 2 of his three decades of emulation evolution and a customer paper (Marvell) covers techniques to accelerate RTL simulation.

VH DAC 2015 CoverAll of this is inside the 60-page mega-issue of Verification Horizons in 11 articles.  Direct links to each of the articles is shared below along with the article titles and authors.  The editor introduction by Tom Fitzpatrick gives even more detail and background on this issue.  If you don’t already have some summer or vacation reading, get your electronic copy today!

, , , , , , , , , , , , , , , ,

27 July, 2015

ASIC/IC Language and Library Adoption Trends

This blog is a continuation of a series of blogs related to the 2014 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I presented our study findings on various verification technology adoption trends. In this blog, I focus on language and library adoption trends.

As previously noted, the reason some of the results sum to more than 100 percent is that some projects are using multiple languages; thus, individual projects can have multiple answers.

Figure 1 shows the adoption trends for languages used to create RTL designs. Essentially, the adoption rates for all languages used to create RTL designs is projected to be either declining or flat over the next year, with the exception of SystemVerilog.


Figure 1. ASIC/IC Languages Used for RTL Design

Figure 2 shows the adoption trends for languages used to create ASIC/IC testbenches. Essentially, the adoption rates for all languages used to create testbenches are either declining or flat, with the exception of SystemVerilog. Nonetheless, the data suggest that SystemVerilog adoption is starting to saturate or level off at about 75 percent.


Figure 2. ASIC/IC Languages Used for  Verification (Testbenches)

Figure 3 shows the adoption trends for various ASIC/IC testbench methodologies built using class libraries.


Figure 3. ASIC/IC Methodologies and Testbench Base-Class Libraries

Here we see a decline in adoption of all methodologies and class libraries with the exception of Accellera’s UVM3, whose adoption increased by 56 percent between 2012 and 2014. Furthermore, our study revealed that UVM is projected to grow an additional 13 percent within the next year.

Figure 4 shows the ASIC/IC industry adoption trends for various assertion languages, and again, SystemVerilog Assertions seems to have saturated or leveled off.


Figure 4. ASIC/IC Assertion Language Adoption

In my next blog (click here) I plan to present the ASIC/IC design and verification power trends.

Quick links to the 2014 Wilson Research Group Study results

, , , , , , , , , , , , , , , ,

19 July, 2015

ASIC/IC Verification Technology Adoption Trends

This blog is a continuation of a series of blogs related to the 2014 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I focused on the growing ASIC/IC design project resource trends due to rising design complexity. In this blog I examine various verification technology adoption trends.

Dynamic Verification Techniques

Figure 1 shows the ASIC/IC adoption trends for various simulation-based techniques from 2007 through 2014, which include code coverage, assertions, functional coverage, and constrained-random simulation.


Figure 1. ASIC/IC Dynamic Verification Technology Adoption Trends

One observation from these adoption trends is that the electronic design industry is maturing its verification processes. This maturity is likely due to the growing complexity of designs as discussed in the previous section. Another observation is that constrained-random simulation adoption appears to be leveling off. This trend is likely due to the scaling limitations of constrained-random simulation. This technique generally works well at the IP block or subsystem level in simulation, but does not scale to the entire SoC integration level.

ASIC/IC Static Verification Techniques

Figure 2 shows the ASIC/IC adoption trends for formal property checking (e.g., model checking), as well as automatic formal applications (e.g., SoC integration connectivity checking, deadlock detection, X semantic safety checks, coverage reachability analysis, and many other properties that can be automatically extracted and then formally proven). Formal property checking traditionally has been a high-effort process requiring specialized skills and expertise. However, the recent emergence of automatic formal applications provides narrowly focused solutions and does not require specialized skills to adopt. While formal property checking adoption is experiencing incremental growth between 2012 and 2014, the adoption of automatic formal applications increased by 62 percent. In general, formal solutions (i.e., formal property checking combined with automatic formal applications) are one of the fastest growing segments in functional verification.


Figure 2. ASIC/IC Formal Technology Adoption

Emulation and FPGA Prototyping

Historically, the simulation market has depended on processor frequency scaling as one means of continual improvement in simulation performance. However, as processor frequency scaling levels off, simulation-based techniques are unable to keep up with today’s growing complexity. This is particularly true when simulating large designs that include both software and embedded processor core models. Hence, acceleration techniques are now required to extend ASIC/IC verification performance for very large designs. In fact, emulation and FPGA prototyping have become key platforms for SoC integration verification where both hardware and software are integrated into a system for the first time. In addition to SoC verification, emulation and FPGA prototyping are also used today as a platform for software development.

Today, 35 percent of the industry has adopted emulation, while 33 percent of the industry has adopted FPGA prototyping. Figure 3 describes various reasons why projects are using these techniques. You might note that the results do not sum to 100 percent since multiple answers were accepted from each study participant. Also, we are unable to show trend analysis here since previous studies did not examine this aspect of functional verification.


Figure 3. Why Was Emulation or FPGA Prototyping Used?

Figure 4 partitions the data for emulation and FPGA prototyping adoption by the design size as follows: less than 5M gates, 5M to 80M gates, and greater than 80M gates. Notice that the adoption of emulation continues to increase as design sizes increase. However, the adoption of FPGA prototyping rapidly drops off as design sizes increase beyond 80M gates. Actually, the drop-off point is more likely around 40M gates or so since this is the average capacity limit of many of today’s FPGAs. This graph illustrates one of the problems with adopting FPGA prototyping of very large designs. That is, there can be an increased engineering effort required to partition designs across multiple FPGAs. However, better FPGA partitioning solutions are now emerging from EDA to address these challenges. In addition, better FPGA debugging solutions are also emerging from EDA to address today’s lab visibility challenges. Hence, I anticipate seeing an increase in adoption of FPGA prototyping for larger gate counts as time goes forward.


Figure 4. Emulation and FPGA Prototyping Adoption by Design Size

In my next blog (click here) I plan to discuss various ASIC/IC language and library adoption trends.

Quick links to the 2014 Wilson Research Group Study results

, , , , , ,

13 July, 2015

ASIC/IC Resource Trends

This blog is a continuation of a series of blogs related to the 2014 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I focused on ASIC/IC design trends and rising complexity. In this blog, I plan to discuss the growing ASIC/IC design project resource trends due to rising design complexity.

Figure 1 shows the percentage of total project time spent in verification. As you would expect, the results are all over the spectrum; whereas, some projects spend less time in verification, other projects spend more. The average total project time spent in verification in 2014 was 57 percent, which did not change significantly from 2012. However, notice the increase in the percentage of projects that spend more than 80 percent of their time in verification.

2014-WRG-BLOG-ASIC-8-1Figure 1. Percentage of ASIC/IC Project Time Spent in Verification

Perhaps one of the biggest challenges in design and verification today is identifying solutions to increase productivity and control engineering headcount. To illustrate the need for productivity improvement, we discuss the trend in terms of increasing engineering headcount. Figure 2 shows the mean peak number of engineers working on a project. Again, this is an industry average since some projects have many engineers while other projects have few. You can see that the mean peak number of verification engineers today is greater than the mean peak number of design engineers. In other words, there are, on average, more verification engineers working on a project than design engineers. This situation has changed significantly since 2007.

2014-WRG-BLOG-ASIC-8-2Figure 2. Mean Number of Peak Engineers per ASIC/IC Project

Another way to comprehend the impact of today’s project headcount trends is to calculate the compounded annual growth rate (CAGR) for both design and verification engineers. Between 2007 and 2014 the industry experienced a 3.7 percent CAGR for design engineers and a 12.8 percent CAGR for verification engineers, as shown in Figure 3. Clearly, the double-digit increase in required verification engineers has become a major project cost management concern, and is one indicator of growing verification effort.

2014-WRG-BLOG-ASIC-8-3aFigure 3. Peak Engineers CAGR per ASIC/IC Project

But verification engineers are not the only project stakeholders involved in the verification process. Design engineers spend a significant amount of their time in verification too, as shown in Figure 4. In 2014, design engineers spent on average 53 percent of their time involved in design activities and 47 percent of their time in verification.

2014-WRG-BLOG-ASIC-8-4Figure 4. Where ASIC/IC Design Engineers Spend Their Time

However, this is a reversal in the trends observed from the 2010 and 2012 studies, which indicated that design engineers spent more time in verification activities than design activities. The data suggest that design effort has risen significantly in the last two years when you take into account that: (a) design engineers are spending more time in design, and (b) there was a nine percent CAGR in required design engineers between 2012 and 2014 (shown in Figure 2), which is a steeper increase than the overall 3.7 CAGR for design engineers spanning 2007 through 2014. We will discuss a few factors that might be contributing to this increased design effort in upcoming blogs.

Figure 5 shows where verification engineers spend their time (on average). We do not show trends here since this aspect of project resources was not studied prior to 2012, and there were no significant changes in the results between 2012 and 2014. Our study found that verification engineers spend more of their time in debugging than any other activity. This needs to be an important research area whose future solutions will be necessary for improving productivity and predictability within a project.

2014-WRG-BLOG-ASIC-8-5Figure 5. Where ASIC/IC Verification Engineers Spend Their Time

In my next blog (click here) I plan to discuss various ASIC/IC verification solutions adoption trends.

Quick links to the 2014 Wilson Research Group Study results

8 July, 2015

ASIC/IC Design Trends

This blog is a continuation of a series of blogs related to the 2014 Wilson Research Group Functional Verification Study (click here).  In my previous set of blogs, I focused on FPGA design and verification trends.  I now will shift the focus of this series of blogs from FPGA trends to ASIC/IC trends.

In this blog, I present trends related to various aspects of design to illustrate growing design complexity. Figure 1 shows the trends from the 2007, 2012, and 2014 studies in terms of active ASIC/IC design project by design sizes (gates of logic and datapath, excluding memories). The 2014 study added more resolution in identifying larger design sizes (up to 500M or more gates), while the 2012 studies’ upper bound was limited to 60M or more gates.

2014-WRG-BLOG-ASIC-7-1Figure 1. ASIC/IC Design Sizes

The key takeaway here is that the electronic industry continues to move to larger designs. In fact, 31 percent of today’s design projects are working on designs over 80M gates, while 17 percent of today’s design projects are working on designs over 500M gates.

But increased design size is only one dimension of the growing complexity challenge. What has changed significantly in design since the original Collett studies is the dramatic movement to SoC class of designs. In 2004, Collett found that 52 percent of designs included one or more embedded processors. Our 2014 study found that the number of designs with embedded processors had increased to 71 percent. Furthermore, 45 percent of all designs today contain two or more embedded processors, while 12 percent of today’s designs include eight or more embedded processors. SoC class designs add a new layer of verification complexity to the verification process that did not exist with traditional non-SoC class designs due to hardware and software interactions, new coherency architectures, and the emergence of complex networkon-a-chip interconnect.

In addition to the increasing number of embedded processors contained within an SoC, it is not uncommon to find in the order of 120 integrated IP blocks within today’s more advanced SoCs. Many of these IP blocks have their own clocking requirements, which often present new verification challenges due to metastability issues involving signals that cross between multiple asynchronous clock domains.

In Figure 2, we see that 93 percent of all ASIC/IC design projects today are working on designs that have two or more asynchronous clock domains.

2014-WRG-BLOG-ASIC-7-2Figure 2. Number of Asynchronous Clock Domains in ASIC/IC Designs

One of the challenges with verifying clock domain crossing issues is that there is a class of metastability bugs that cannot be demonstrated in simulation on an RTL model. To simulate these issues requires a gate-level model with timing, which is often not available until later stages in the design flow. However, emerging static clock-domain crossing (CDC) verification tools can identify clock domain issues directly on an RTL model at earlier stages in the design flow.

In my next blog (click here) I plan to discuss the growing ASIC/IC design project resource trends due to rising design complexity.

Quick links to the 2014 Wilson Research Group Study results

1 July, 2015

Continuing on our journey on what is needed to get to productive verification with VIP, the first step is to make the connections between the DUT and the testbench.  This includes connecting the signals, the clock and reset and setting any parameters. This is what we covered in part 1 of the series.

Let us look at other steps need to get productive, taking PCIe VIP as an example.


Protocol Specific agents enables easy instantiation of agents in your testbench with fewer lines of configuration in the testbench. This is the customization of the generic agent. The PCIe agent will perform link training automatically, without us needing to start a sequence.


Next we move onto configuring the VIP.  Here we are able to take advantage of a configuration policy that has already been defined for the specific design IP we are using and available alongside the VIP.

It is again important for the VIP to be intuitive, and here you can see that we have used a collection of structs to define the configuration.  These are then declared as variables in a configuration class for the agent, which is used in the testbench to set the configuration.


The user code which sets the configuration for a test is then intuitive and easy to read as shown below.  In this particular example, we have set our agent to be a GEN2 root complex, connected at the serial interface and using an internally generated clock and reset.  We have disabled the build in scoreboard and coverage, but enabled transaction logging.


Once done with configuration, move on to PCIe link training and enumeration, which the VIP can take care of. As I mentioned earlier the agent will perform link training automatically, without needing to start a sequence.  The VIP also provides a sequence to complete enumeration, which will block until link training is complete.

This means that in the test, you just need to create and start this sequence, the “bring up sequence” in the code below.


Once that sequence ends, link up and enumeration are complete and you can start a user defined sequence that would typically perform reads and writes to do some application specific verification.

VIP’s include various sequence API for rapid test creation like memory, configure and I/O reads and writes, as well as various scenario and error injection sequences. Finally we are able to use the transaction layer sequences to begin some application specific verification by performing reads and writes across the bus.

Using the automation provided by the VIP it is possible to complete the entire testbench and link up process in hours rather than days, allowing users to become productive much earlier.

I would really like to hear how you use various VIPs so please comment below. In part 3 of the series, we will talk about various debug features of a VIP.

, , , ,

25 June, 2015

There are intrinsic limitations in the current approach for estimating dynamic power consumption. Briefly, the approach consists of a file-based flow that evolves through two steps. First, a simulator or emulator tracks the switching activity either cumulatively for the entire run in a switching activity interchange format (SAIF) file, or on a cycle-by-cycle basis for each signal in a signal database file such as FSDB or VCD. Then, a power estimation tool fed by as SAIF file calculates the average power consumption of a whole circuit, or an FSDB file computes the peak power in time and space of the design.


Figure 1: Conventional power analysis is grounded in the two-step, file-based approach.

The method may be acceptable when the design-under-test (DUT) is relatively small, in a ball-park of a few million gates or less, and the analysis is performed within a limited time window of up to a million or so clock cycles. Such time windows are typical when the DUT is tested with adaptive functional testbenches.

When applied to modern, large SoC designs of tens of hundreds or millions of gates executing embedded software, such as booting an operating system and running application programs that require billions of cycles, three problems defeat the conventional approach:

  1. The sizes of SAIF and, even more so, FSDB/VCD files become massive and unmanageable
  2. The file generation process slows to a crawl that extends to hours, possibly exceeding a day
  3. File loading into a power estimation tool extends to several days or more than a week

New software for the Veloce emulation platform eliminates the core problems affecting the conventional approach to estimate power consumption. It eliminates the two-step, file-based flow by tightly integrating the emulator to the power analysis tool.

In this new approach, an Activity Plot maps in one simple chart the global design switching activity over time as it is occurring, booting an OS and running live applications.Image 2

Chart 1: The Activity Plot identifies focus areas over long runs.

It identifies time frames of high switching activities that may pose power threats to the design team. While this chart is not unique, its creation is an order of magnitude faster than the generation time of file-based power charts. As a data-point, Veloce takes 15 minutes to generate an Activity Plot of a 100-million gate design for 75-million design clock cycles. Power analysis tools could consume more than a week to generate similar information. Moreover, they may not be able to handle such a large volume of data.

Of course, the next questions are, “where” are those peaks happening in the DUT and “what” is causing them? This is addressed by replacing the file based approach with a Dynamic Read Waveform API for the signal data.

Dynamic Read Waveform API Flow

Once high-switching activity time frames are identified at the top level of the design, the design team can zoom into those frames. Users can dig deep into the hierarchy of the design and the embedded software to uncover the main source of such high-switching activity.

The Dynamic Read Waveform API replaces the cumbersome SAIF/FSDB/VCD file generation process by live streaming switching data from the emulator into the power analysis tool. All operations run concurrently, from emulating the SoC, design capturing switching data, reading switching data by the power analysis tool and generating power numbers. The net effect is a jump in overall performance from booting an OS and running real applications.

As a side benefit, the Dynamic Read Waveform API also delivers improved accuracy compared to SAIF-based average flows because conditional controls are incorporated automatically for switching.

The bottom line is that the Activity Plot and the Dynamic Read Waveform API enable power analysis and power exploration at the system level that is not possible with a file-based flow.


8 June, 2015

Do you have a really tough verification problem – one that takes seemingly forever for a testbench simulation to solve – and are left wondering whether an automated formal application would be better suited for the task?

Are you curious about formal or clock-domain crossing verification, but are overwhelmed by all the results you get from a Google search?

Are you worried that adding in low power circuitry with a UPF file will completely mess up your CDC analysis?

Good news: inspired by the success of the UVM courses on the Verification Academy website, the Questa Formal and CDC team has created all new courses on a whole variety of formal and CDC-related subjects that address these questions and more.  New topics that are covered include:

* What’s a formal app, and what are the benefits of the approach?

* Reviews of automated formal apps for bug hunting, exhaustive connectivity checking and register verification, X-state analysis, and more

* New topics in CDC verification, such as the need for reconvergence analysis, and power-aware CDC verification

* How to get started with direct property checking including: test planning for formal, SVA coding tricks that get the most out of the formal analysis engines AND ensure reuse with simulation and emulation, how to setup the analysis for rapidly reaching a solution, and how to measure formal coverage and estimate whether you have enough assertions

The best part: all of this content is available NOW at, and it’s all FREE!


Joe Hupcey III,
on behalf of the Questa Formal and CDC team

P.S. If you’re coming to the DAC in San Francisco, be sure to come by the Verification Academy booth (#2408) for live presentations, end-user case studies, and demos on the full range of verification topics – UVM, low power, portable stimulus, formal, CDC, hardware-software co-verification, and more.  Follow this link for all the details & schedule of events (including “Formal & CDC Day” on June 10!):

, , , , , , , , ,

4 June, 2015

Learn more about DDA at DAC

At DAC – Mentor Graphics and Cadence Design Systems are coming together to usher in another level of productivity in verification results data access and portability with a modern design debug data application programming interface standard. We call this emerging standard the Debug Data API, or DDA for short.  We want to share more details with you in person at DAC.  Join us on Tuesday, June 9th, at the Verification Academy Booth (#2408) at 5:00pm for a joint presentation and unveiling.  And to get a bit of background and hint of what’s to come, please read on.

History: It Started with VCD

In the beginning we had VCD as the universal standard format to exchange simulation results as part of the IEEE 1364 (Verilog) standard.   Anyone trying to use VCD today on those large SoC’s or complex FPGA’s knows the size of VCD files has all but excluded this portion of the IEEE standard from use in modern design verification practice. So the question is when will it be replaced?

To ask that question today seems fine.  But I was even skeptical in the mid 1990’s when we at Mentor Graphics created Extended VCD to support the IEEE 1076.4 (VITAL) gate level simulation standard.  At that time the largest designs were around 1 million gates. While Extended VCD never became an official IEEE standard, we shared it with our ASIC Vendor and FPGA partners along with our major competitors to ensure debug data access and portability for VITAL users was on par with Verilog.  But Extended VCD also suffers the same fate of being almost impossible to support modern large designs.

Today: VCD Replaced by a Proprietary World

VCD and Extended VCD have remained static for about 20 years. But commercial simulator, emulator and other verification technology suppliers have not stopped innovating to advance support for larger design sizes with larger result data sets. As we move to 2 billion gate designs and beyond, the dependence on these private and closed technological advances and innovations has never been more important.

But that proprietary dependence comes with a cost. We stand at a crossroads where consumers of verification results information lose the open and unencumbered use offered by VCD or they need a path forward that preserves their current benefits while protecting and encouraging producers of such information to continue to innovate by private means.  The only alternative are fully integrated solutions from a single supplier that rarely get consumer endorsement in a best-of-breed; mix-and-match world.

Near Future: Federating the Proprietary World with DDA

Federating proprietary solutions almost sounds like something that is impossible to do. But Mentor and Cadence will share their emerging work on a standard to federate the different sources of verification results that can come from private sources with unencumbered access for the consumer. The Debug Data API standard will offer consumers the benefits of VCD interoperability, data portability and openness while preserving the benefits of private innovation for tool and solution producers. It will not impose data format translations from one format to another as a means to promote data portability.  It will not require the means by which one supplier or another stores verification results to be exposed.  It will offer the best of both worlds to producers and consumers.  I guess in some cases, you can have your cake and eat it too! There are more details to share, and the best place start is to meet us at DAC.

VA DDA Session AbstractMentor and Cadence Share DDA Details at DAC

  • Location: Verification Academy Booth (#2408)
  • Date: Tuesday, June 9th
  • Time: 5:00pm PT
    More Information >

We will discuss the details of DDA and show a proof of concept demonstration that will highlight each company’s simulator and results viewer in action.  Since there is no other session following this one at the Verification Academy booth, we will also be around to discuss the next steps with all present afterwards.

You can read more about this from my colleague and competitor, Cadence’s Adam Sherer, on his blog at the Cadence site here.  He bring his own perspective to this.

See you at DAC!

, , , , , , , , , , , ,

@dennisbrophy tweets

Follow dennisbrophy

@dave_59 tweets

Follow dave_59

@jhupcey tweets

Follow jhupcey