Open side-bar Menu
 Real Talk

Archive for November, 2010

The SoC Verification Gap

Monday, November 15th, 2010

If you have been talking to anyone at Cadence, or others in the industry these days, I’m sure you have heard about the EDA360 vision.  If you are an engineer, you are probably saying – what is this “marketing fluff” and how does it help me.   Let me tell you what it means from my perspective, as somebody whose job it is to work with customers to understand the latest verification challenges and figure out what Cadence needs to do to address those challenges.  In short, think of EDA360 as a wake-up call, a heads-up that we understand there are big challenges our customers are facing in realizing SoCs/Systems, and this requires something far beyond EDA-business-as-usual.   At this point, those of you who may know me are probably saying to yourself – “Is Mike Stellfox really talking about this EDA360 stuff, has he sold out…?”   The answer is “no” I have not sold out and let me tell you why.

I have been spending a lot of time lately with engineering teams developing really big SoCs, and I’ve realized we have a significant challenge here – there is a HUGE gap in how SoCs are verified today vs. what is needed in order to have a scalable and efficient SoC development process.   The challenge of bringing a new SoC to market is exactly why a colleague of mine coined the phrase “time to integration”.  Today’s SoCs, are all about integration – integrating IP blocks, integrating analog content, and integrating more and more of the software stack.  While it is true that all of this integration work still includes design challenges, the bigger issues around improving time to integration are centered on improving the entire SoC verification process.   I have seen very few well-structured, methodology-based approaches to how customers are verifying their SoCs.  There are many ad-hoc processes and some internal tools and scripts that attempt to improve the situation, but when it comes to complex SoCs a much more structured and automated approach to verification is needed.   This opportunity to bring a more structured, methodology-based approach to integrating and verifying SoCs will likely need to be developed in a different way. I don’t think it will be feasible to simply understand the requirements and go back to Cadence R&D and ask them to develop some sort of silver bullet “SoC Verification Tool”.  It is going to require a different approach, one that requires tight collaboration with customers developing these complex SoCs. 

Within Cadence, we now have an organization known as the SoC and Systems Group, whose charter it is to define and drive solutions for improving SoC and System realization, where a significant focus will be on improving time to integration and verification of complex hardware and software systems.   Here are some of the key challenges I have seen with regard to integrating and verifying SoCs.

  • SoCs rely on several execution platforms in order to verify the integration, develop software, and verify that the application level use cases meet the requirements of the end system.  This includes a TLM-based Virtual Platform, RTL simulation, RTL Acceleration/Emulation, FPGA prototype, and links to the post-silicon environment.  It is a huge effort to develop and maintain the models and verification environments for each of these platforms, and it is not easy to reuse stimulus, checks, and coverage metrics across each platform. 
  • It is like trying to find a needle in a haystack to debug at the SoC level where the bug might be hidden somewhere in the hardware, software, or the verification environment.  SoC level debug is further complicated by the fact that it is often necessary to reproduce the bug on a different execution platform where there is much better debug visibility.
  • Today IP is not optimized for integration within the SoC.  There is a need to develop and deliver the verification content with the design IP in such a way that it is optimized for integration to reduce the time and effort for integration verification. 
  • Given the complexity of the software content for most SoCs, and all the ways the software might interact with the hardware, there is a need for better tools for automating the creation of software driven tests, and for debugging hardware and software together.
  • More and more analog content is being integrated into SoCs so there is a need to more thoroughly verify the integration between the digital and analog blocks by including reasonably accurate analog models in the IP and SoC verification environments.
  • In order to effectively manage a large-scale multi-geography SoC development project, there needs to be clear metrics and milestones for tracking and reporting the progress of all the SoC development activities. 

These are the core challenges that I see that need to be addressed to close the SoC verification gap.  Admittedly today the gap is rather wide, but I am confident with the right focus and a complete understanding of our customer’s needs, we will align with the much of what is behind the EDA360 vision and close this SoC verification gap in the coming years.

Building Relationships Between EDA and Semiconductor Ventures

Monday, November 8th, 2010

Let’s change topics this month from various approaches to solving the verification challenge to ways to support semiconductor startups.  For this, I turn to EVE’s Vice President of Sales Ron Burns.  He has written a compelling article that will appear in the December issue of GSA Forum on the importance of building relationships between EDA companies and semiconductor startups.  He advocates finding new ways to partner with these new ventures because our synergistic industries have a shared destiny.

From his perspective and one shared throughout EVE, today’s fabless startups are in search of external partners willing to work with them and help them become successful.  These partners need to have a solid understanding of the challenges facing a startup, from funding, product development and globalized teams to core competencies and time to market.  And, they need to be ready to offer assistance and support, as appropriate.  In fact, with some creativity, an EDA company can be a collaborative partner able to help a startup navigate some of these challenges. 

He writes convincing about the need to understand the process.  What he means is this:  Before engaging, the most pressing consideration is to establish a goal for working with a startup.  Thinking in terms of a shared destiny helps clarify short-term revenue objectives and the lifetime value of the relationship, with regard to both cost of sales and support, and technology adoption. 

EDA business models have always had some elasticity, and discounting software or loaner programs are common.  Another is a flexible payment model based on projects and key milestones, with the understanding that the EDA company will help the startup reach these milestones.  EVE, for example, offers a remote access model or peak-load onsite rentals.

Intellectual property (IP) is becoming more and more of an issue and many larger EDA companies are building portfolios useful for a new venture.  While that makes great strategic sense, the startup may not have the resources to buy it. 

There are other options, including several offered by EVE.  Our scalable emulation system supports a wide range of verification components that include transactors, memory models and speed-rate adapters.  The transactor catalog comprises, among others, PCIe, USB, FireWire, Ethernet, AHB, AXI, TLM 2.0, Video, HDMI, I2C, I2S and JTAG components.  The Memory Model catalog includes virtually all popular types of memories, such as DDR, DDR2, DDR3, GDDR5, mobile and flash parts.  A Speed-rate Adapter catalog offers PCI, USB and a multi-media card with a complete set of video protocols. 

We may license any verification component for the duration of the project and offer a program to startups where they can mix in and out certain pieces for the duration of the project under the same license.

The possibilities for EDA companies to build supportive relationships with startups are endless, especially for creative companies willing to do something different.  The strategy is to align with the company’s goals and the EDA company’s tools, services and IP.

Watch your email in box next month for your link to the GSA Forum article by Ron Burns and be sure to let us know if you agree that the EDA and semiconductor ventures have a shared destiny. 

Thoughts on Assertion Based Verification (ABV)

Monday, November 1st, 2010

Verification approaches or methodologies that increase the probability of designs being correct the first time and can be easily integrated into the existing functional verification flow will find a ready market. If in addition this technology reduces both verification time and cost it will be a major winner.

Assertion Based Verification (ABV) is in that class of technology. However, ABV has not been widely adapted because of the time, cost and difficulty of deployment. The predominate language used today for coding assertions is SystemVerilog Assertion (SVA) language. The difficulty of the SystemVerilog Assertion (SVA) language plus other factors has limited the use of assertions to simple versus more useful and powerful SVAs.

According to Harry Foster (Verification methodologist in Mentor Graphics) in his paper Assertion-Based Verification: Industry Myths to Realities(Invited Tutorial…2008)

“… is a myth that ABV is main stream technology.” ……”what differentiates a successful team from an unsuccessful team is process and adoption of new verification methods. Unsuccessful teams tend to approach development in an ad hoc fashion, while successful teams employ a more mature level of methodology that is systematic”. ……

Implementing ABV is somewhat of a “chicken and egg” situation. The industry accepts that ABV can reduce debug time by 50% and there is no question relative to its “goodness” for increasing first time design success. However, the implementation phase today is so open-ended and difficult that only “baby steps” have been taken. Even these small steps are useful; however, the industry hasn’t come close to attaining the full benefits of ABV.

A good analogy to ABV is exercise. Everyone knows the benefits are major and any level of exercise is good. Most of us have taken “baby steps” towards exercise. However, to attain the full benefits requires, in addition to believing in the benefits, a way to reduce the open ended nature. This can be done by creating an exercise program or approach that works within the user’s life style and becomes part of their weekly routine. This typically requires help in the form of books, trainers, equipment, etc. to get started and maintain the motivation for continuing the program and reap the benefits.

Clearly the opportunity exists to provide help for implementing ABV. The methodologies are already in place. We at Zocalo believe that automation plus metrics that takes away or reduces the open ended nature of the technology and works within the users flow will motivate projects to start and continue using ABV, thereby reaping the full benefits of implementation.

To access a (no registration required and free) Assertions white paper, please visit

A version of this article was previously published earlier this month at

CST Webinar Series

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy