English
''Enterprise'' System Level (ESL) Verification -- PART II
By Ran Avinun, Cadence Design Systems, Inc.
December 04, 2006 -- edadesignline.com
In the first part of this two part series we spent a significant portion of the article addressing the anticipation, or as some would say "state of confusion" in ESL as it stands today. We also hinted about how a much broader definition based on proven enterprise-wide, system-level verification processes will bring new life to the underachieving industry. In fact, these mature verification process automation techniques have been steadily gaining momentum because verification complexity continues to grow exponentially. Hardware and embedded software development at the system-level will only require more verification cycles and proven methodologies to adhere to the specification to expose system-level errors and manage overall project risk.
To illustrate this point I'd like to share a recent discussion I had with a project manager responsible for IP verification at a large semiconductor company. This manager told me that one of the major challenges of IP and SoC verification is the ability to test all hardware/software interactions within the overall system. He said that many of his projects have an IP that includes multiple processors requiring full system-level testing. In other words, a single SoC becomes a combination of multiple systems and the inability to verify these systems thoroughly and efficiently may bring on a verification crisis, project delays or even cause his team to "kill" the project. This example simply illustrates the need for ESL with an "enterprise-wide" scope that leverages system-level verification planning, management and metric tracking, advanced automation, and high-performance engines working within a structured process. In this article, we will explore these system-level needs and share some of the newer technologies and methodologies helping to illustrate how "enterprise" demands are driving ESL growth.
In order to plan, design, and verify embedded software closer in-line with the way we currently design and verify hardware, we need access to a full line up of automation-based solutions and engines working together to achieve one goal " full system-level closure. We need to apply proven techniques from advanced hardware verification (introduced and deployed by the design and verification community in the last 10 years for block-level verification) and expand them to embedded software to bridge the gap between the two areas of specialization. We also have to offer up new ways to manage the process based on an initial plan that uses checkpoints or metrics towards full system-level closure. And due to these complexities, the large number of interfaces, and the need to run long software use cases, we'll have to rely heavily on hardware-based engines that combine the ease and familiarity of simulation with performance levels that are sufficient for software developers.
All of these functions need to be delivered in a way that can be incrementally adopted by the majority of existing users and specialists, and based on existing models and tools to avoid major disruptions in the workflow or environment. The best way accomplish this is to incorporate a methodology that has multiple entry points including high-levels of abstraction (SystemC, C, C++), RTL simulation, acceleration or emulation and even silicon. This methodology needs to work with multiple levels of abstraction, support multiple design languages and be independent of the way the processor is modeled and/or the software is executed.
December 04, 2006 -- edadesignline.com
In the first part of this two part series we spent a significant portion of the article addressing the anticipation, or as some would say "state of confusion" in ESL as it stands today. We also hinted about how a much broader definition based on proven enterprise-wide, system-level verification processes will bring new life to the underachieving industry. In fact, these mature verification process automation techniques have been steadily gaining momentum because verification complexity continues to grow exponentially. Hardware and embedded software development at the system-level will only require more verification cycles and proven methodologies to adhere to the specification to expose system-level errors and manage overall project risk.
To illustrate this point I'd like to share a recent discussion I had with a project manager responsible for IP verification at a large semiconductor company. This manager told me that one of the major challenges of IP and SoC verification is the ability to test all hardware/software interactions within the overall system. He said that many of his projects have an IP that includes multiple processors requiring full system-level testing. In other words, a single SoC becomes a combination of multiple systems and the inability to verify these systems thoroughly and efficiently may bring on a verification crisis, project delays or even cause his team to "kill" the project. This example simply illustrates the need for ESL with an "enterprise-wide" scope that leverages system-level verification planning, management and metric tracking, advanced automation, and high-performance engines working within a structured process. In this article, we will explore these system-level needs and share some of the newer technologies and methodologies helping to illustrate how "enterprise" demands are driving ESL growth.
In order to plan, design, and verify embedded software closer in-line with the way we currently design and verify hardware, we need access to a full line up of automation-based solutions and engines working together to achieve one goal " full system-level closure. We need to apply proven techniques from advanced hardware verification (introduced and deployed by the design and verification community in the last 10 years for block-level verification) and expand them to embedded software to bridge the gap between the two areas of specialization. We also have to offer up new ways to manage the process based on an initial plan that uses checkpoints or metrics towards full system-level closure. And due to these complexities, the large number of interfaces, and the need to run long software use cases, we'll have to rely heavily on hardware-based engines that combine the ease and familiarity of simulation with performance levels that are sufficient for software developers.
All of these functions need to be delivered in a way that can be incrementally adopted by the majority of existing users and specialists, and based on existing models and tools to avoid major disruptions in the workflow or environment. The best way accomplish this is to incorporate a methodology that has multiple entry points including high-levels of abstraction (SystemC, C, C++), RTL simulation, acceleration or emulation and even silicon. This methodology needs to work with multiple levels of abstraction, support multiple design languages and be independent of the way the processor is modeled and/or the software is executed.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
|
||||||
