Mike Stellfox, Distinguished Engineer, Cadence
Mike leads the SoC Verification Solutions Architecture Team and has been working to advance the field of functional verification for the past 15+ years. Mike began his career at IBM as an ASIC designer and held leadership and development roles at Verisity.
The SoC Verification Gap
November 15th, 2010 by Mike Stellfox, Distinguished Engineer, Cadence
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.