Posts Tagged ‘DVClub’

We thought that it might make for interesting reading to compile a list of the best processor presentations from past DVClub events.

For those of you unfamiliar with DVClub, membership is free and is open to all non-service provider semiconductor professionals. Most members work in verification, but there are also plenty of entrepreneurs, professors, students, managers, investors, and even design engineers who attend. If you’re interested and would like to learn more, why not join the club?

Chuck Alley, IBM
Using PSL and FoCs for Functional Coverage Verification

Bob Colwell, Intel (Retired)
The Validation Attitude

Raj Dayal, Qualcomm
Managing Deployment of SVAs in Your Project

Ish Kumar Dham, Texas Instruments
Design Verification to Application Validation of a Multiprocessor SoC

Sanjay Gupta, IBM
Cell Verification Metrics

Narasimha Karunakar, AMD
Low-Power Verification Challenges

Mark A Firstenberg, IBM
Experience with Formal Methods, Especially Sequential Equivalence Checking

Jai Kumar, Sun
Leveraging Low-Cost FPGA Prototyping for Validation of Highly Threaded Server-on-Chip

John Ludden, IBM
Mainline Functional Verification of IBM’s POWER7 Processor Core

Milind Padhye, Freescale
Wireless Low Power and Verification Challenges

Somdipta Basu Roy, Texas Instruments
OMAP Verification

Scott Runner, Qualcomm
Verification of Wireless SoCs: No Longer in the Dark Ages

Sakar Jain, Freescale
Verification of the QorIQ Communication Platform’s CoreNet Fabric with SystemVerilog

Shahram Salamian, Intel
Intel Atom Processor Pre-Silicon Verification Experience
CPU Verification Metrics

Jason Stinson, Intel
Pre-Si Verification for Post-Si Validation

Paul Tobin, AMD
Verification in a Global Design Community

Durgam Vahia, Sun
Mapping Server-Class Multi-Threaded OpenSPARC T1 Processor Core on FPGAs

David Williamson, ARM
Verification Metrics

Paul Zehr, Intel
Intel Xeon Pre-Silicon Validation

By Hemendra Talesara

Complexity

In his recent presentation discussing verification of the Power7 processor, John Ludden of IBM opened with a quote from an IBM exec more than a decade ago. “it’s not rocket science”- a perception held by some members of the management and design communities at that time.

However, designs have become a whole lot more complex over time. The Power7 processor at 45nm has 1.2B transistors on a 567 sq. mm die, supporting 8 cores with 4 threads each, an on-chip eDRAM, 3 levels of caches and 2 DDR memory controllers. Yet as verification complexity multiplies in this multi-threaded design, it’s very helpful to have some of the more advanced tools and methodology at your disposal.

Tools and Methodology

Fortunately for Ludden and the Power7 team, IBM has invested in verification technology for years (in spite the quote from the exec). The company continues to develop and rely on in-house tools for many of the advanced verification technologies for processor-specific testing. These include the test-bench, multi-thread test generators, hardware accelerators, formal and semi-formal tools, micro-architecture checkers (API based), cache coherency checkers and coverage tools. Exercisers
originally developed for post-silicon validation were used to exploit the hardware acceleration platform. Forty-five thousand coverage points were organized to assist with big picture and were used to re-direct the test generator and exercisers for accelerators.

To support corner case testing for events that occur rarely, especially in multi-threaded scenarios, software irritator threads were used. These irritators are capable of creating the worst possible contentions. Through their application, twenty-three high quality bugs were revealed hiding in the corners.

A methodical application of these tools and technology clearly captured and advanced the industry best practices.

Designing for Verification

Designing for Verification was an important element in managing the overall risk to verification time line. IBM minimized the risks by maintaining a tight interaction between the specification and verification teams during the design phase and allowing the verification team to maintain architectural changes. “Chicken switches” were placed in silicon that allowed verification team to back-off an area considered risky or possible of otherwise compromising the verification effort. These switches provide workarounds, with some small impact on performance but no functional change, for accessing difficult to verify micro architectural features. Hardware irritators were also used to enable stress testing of corner cases in both pre-silicon and post-silicon testing.

Conclusion

The Power7 draws many architectural features from the Power5 and 6 designs, although it is a much more complex and powerful processor with a much shorter verification cycle. Ludden and the Power7 team accomplished this remarkable feat with a lot of foresight in planning, metrics collection and careful execution. Tight interlocking between metrics collected and verification plan was key part of tracking mechanism and functional closure. This project should serve as an example of how to plan for and manage risks in a complex verification project.

Kudos to John and the IBM team. His full presentation can be downloaded here.

On June 30th, DVClub Austin will be hosting a state of the industry panel discussion. Topics are set to include industry consolidation, downsizing trends, corporate agility, and anything else that the audience can throw at our panelists. As always, DVClub will take place at Cool River Cafe on Parmer Ln.

Confirmed Panelists include:

Ty Garibay

• Ty Garibay is the Program Manager for ARM Processor development in Texas Instruments’ Wireless Terminals Business Unit and site manager for TI’s Austin office. Currently, he and his team are focused on the completion of the industry’s first 45nm implementation of ARM’s Cortex-A8 super-scalar processor core.
• Over the previous 20+ years, Ty has designed microprocessors at ARM, Alchemy Semiconductor, SGI/MIPS, Cyrix and Motorola, participating in all phases of design from circuits and layout through architecture and product definition.
• He holds over 30 patents in the areas of integrated circuit design, computer architecture and design methodology.

Brian Wong

• Mr. Wong was President and CEO of D2Audio Corporation since 2005, a leading audio semiconductor and software company. D2Audio was recently acquired by Intersil Corporation in August, 2008. He is currently running the D2Audio-Intersil business as Director of D2Audio.
• Previously, Mr. Wong was CEO at Primarion Inc, a company focused on data communications and Power Management ICs, which was acquired by Infineon.
• Prior to that, he was a senior manager at TRW and managed the Mixed Signal IC business, which included data converter, Clock/Data Recovery, PLL, optical datacom, and high speed digital ICs.
• Mr. Wong holds a BSEE from University of California, Los Angeles, a MSEE from University of Southern California, and has taken graduate management classes at UCLA Anderson School of Management. He has co-authored textbooks and papers on semiconductor technology and data converters. He is the Chairman of The Austin Technology Council, serves on the Advisory Board for the UC Davis ECE Department, and on the board of Integral Wave Technologies, a power management company.

Jim Reinhart

• Jim Reinhart is President and CEO of Luminary Micro and one of the company’s three cofounders. Jim has more than 25 years of experience in the creation and commercialization of computing technologies. A sixth-generation Texan with degrees from Rice and St. Edwards Universities, Jim will give a talk on the changes that are driving a massive shift in the semiconductor industry.
• This event will be hosted by Eric Hennenhoefer of Obsidian Software and moderated by Steven Schulz of Silicon Integration Initiative.

Registration

DVClub membership is free and is open to all non-service provider semiconductor professionals. Most members work in verification, but there are also plenty of entrepreneurs, professors, students, managers, investors, and even design engineers who attend. Participation by service providers (solicitors) is limited to event sponsors, who supply the funds for DVClub events.

Help us plan for a proper setup and RSVP here.

By Grant Martin

This blog post originally appeared at:

http://www.chipdesignmag.com/martins/2009/03/19/bailey-on-verification-at-the-club/

— March 19, 2009 @ 11:14 pm

Today I attended the latest meeting of the Silicon Valley branch of the DVClub. For those not familiar with the DVClub (DV = Design Verification), it was started by Eric Hennenhoefer in Austin a few years ago. It now has branches in Austin, Bangalore, Boston, Bristol, Dallas, RTP, San Diego and Silicon Valley. In Silicon Valley it meets about once a quarter for a talk on some aspect of verification. I first heard of this about 1.5 years ago when we were invited from Tensilica to give a talk about verifying our video subsystem. The club has all the right ingredients to attract a crowd of engineers:

1. a free lunch
2. interesting speakers
3. did I mention a free lunch?
4. a chance to meet new colleagues and old friends
5. and of course, a free lunch

(Sponsors such as Cadence, Doulos, Denali, Silicon Elite and Obsidian pick up the tab for the venue and lunch (updated after original post, on Friday 20 March 2009, to correct list of sponsors)).

Today’s speaker was Brian Bailey, a friend and co-author of mine, speaking on “Is it time to declare a verification war?” The place was packed out with about 130 people, filling the room to capacity (Eric said this was the largest Silicon Valley DVClub crowd to date).

Brian Bailey

Brian spoke about his philosophy of verification, drew some analogies to Sun-Tzu’s Art of War, and also spoke about three technologies that he felt had potential to change verification significantly:

1. Functional Qualification – as exemplified by Certess (now SpringSoft) Certitude
2. Raising abstraction – as exemplified by Calypto’s sequential equivalence checking
3. “Intelligent testbenches” – as exemplified by Jasper’s Behavioural Indexing

Brian’s slides are available here.

IF you live or work anywhere any of these branches of the DVClub, and have an interest in verification, I recommend that you check them out. Sign up for their newsletter and get notified of meetings in advance.

By Joseph Hupcey III of Cadence
November 13, 2008
Persistent link to this article here.

Last week I had the pleasure of attending a DV Club lunch presentation from Dr. Henry Chang of Designers’ Guide Consulting on “What the Digital Verification Engineer Needs to Know about Analog Verification”.

The talk was very engaging, where Dr. Chang’s comments on the relatively primitive state of analog verification confirmed my observations in talking with customers and Trailblazer partners. Specifically:

1 – In the eyes of digital verification people, analog verification looks like digital verification circa 1990. This isn’t meant as a criticism of analog developers — Dr. Chang reviewed the many reasons why this gap exists, and why they will likely persist for years into the future. For example, in order to effectively support the hierarchical circuit construction methodologies commonly used in the digital world, depending on the type circuit you are simulating analog simulators would have to become literally 1,000,000 times faster than they are today.

2 – Dr. Chang noted that very trivial, functional A-D interface errors are depressingly common in mixed signal designs. Even worse: such bugs are typically catastrophic (i.e. the chip is dead-on-arrival from the fab)

3 – The level of automation vs. the digital world is very low. Despite the growing complexity of pure analog blocks, most design entry is still done with schematic capture and not high-level design languages (although this is slowly changing). Debug? It’s all about eyeballing golden waveforms.

There was much more to the talk, but these three highlights stood out in my mind because myself and my fellow Trailblazers have also seen 1, 2, and 3 in our customer base. As such, I was “relieved” (in an ironic, negative sense) to hear that an expert like Dr. Chang is seeing the same things too. Do you out there in the blogsphere see all this too? Have you seen any analog users overcome 1, 2, or 3?

In a vaguely related note:
Driving back to my office from the talk, I was also struck by an analogy to the hardware/software co-verification space, where verification in this mixed domain is also relatively primitive compared to pure digital RTL verification. My colleague Jason Andrews captures this issue nicely in his recent post “Is anybody out there a Software Verification Engineer?”

In conclusion, I’d argue that at the 50,000ft level, issues 1 and 2 are factors in both the AMS and HW/SW domains (and for issue 3, you have to admit there is a lot of “bad” automation in the HW/SW domain; but that’s the subject of another blog post). The silver lining in these clouds is that the hunger for automated, metric-driven solutions in the AMS space is growing, and thus the EDA business has some future opportunities here whatever doldrums the economy might be in today.

P.S. If you haven’t been to one of these “DV Club” events, you are really missing out. The format is typically an in depth talk on some design or verification topic given over lunch, and the speakers have always been very informative. These events also draw a good sized audience (I’ve never seen less than 50 people at the Silicon Valley area events I go to), so the networking is great. Note that in addition to Silicon Valley, they hold these “lunch & learns” in Austin, Bangalore, Boston, Bristol UK, Dallas, RTP, and San Diego. Here is the DV Club events calendar for more info:
http://www.dvclub.org

Background

On a sunny afternoon, DVClub Boston was visited by John Ludden from IBM Vermont who delivered his presentation on POWER architecture verification to a full house with over 70 verification engineers in attendance. John is an undeniable expert in this field and has over 18 years of DV experience with the last 15 years focused on the POWER architecture.

John M. Ludden – IBM Systems and Technology Group

Simultaneous Multi-Threading Verification of the POWER5 and POWER6 High-Performance Processors -

A Daunting Challenge

Like most stories, it starts on a relatively high note. After completing the highly complex MP/SMT out-of-order POWER5 design, the initial specification for an in-order POWER6 looked like a reasonable verification project. Unfortunately this was wrong, and as John soon discovered, the POWER6 was to be the most challenging verification project of his career.

What’s so hard about “In-Order”? Isn’t that so last century?

POWER6 – What’s Difficult?

1. Requires highly complex stimuli

• In an OOO MT/MP processor, many of the complex internal conditions can be hit with a single thread; the hardware is nice enough to shuffle the instructions and gum up the gears by default.
• In an IO MT/MP processor, a single thread cannot hit complex cases. Instead, tests require multiple threads with very specific ordering to maximize internal conditions. Consequentially, this requires significantly more complexity in the stimulus generation.

2. High frequency design – this drove the complexity scheme from a centralized control model to one of distributed control, thereby spreading out the logic and making interactions more complex.

3. Mainframe Reliably / Bullet Proof Computing

• The POWER6 hardware is designed to support graceful hardware failure. External errors are retried and internal CPU fails require any running programs to be migrated seamlessly.

John sums this all up by describing the microarchitecture as an “infinite state machine”.

Verification Solution Highlights

Software simulation

• Hundreds of machines 24×7
• Hardware assisted simulations
• 5X cycles over POWER5

Semi-formal

• Extensively used.
• Key to tackling complex SMT issues
• Bring up Lab
• Including a support to recreate post-SI fails in simulation
• Formal tools very useful for closing post-Si MT fail conditions

Aggressive unit level testing

• Increased complexity in testbenches (1M + lines of C++)

Mainframe Reliability (RAS)

• Just really really hard and messy
• Typical issues are at the system level which prevents a unit centric DV approach