This transcript of a panel discussion that took place at DVCon India is chock-full of interesting information and invaluable advice
Source: EETimes
At DVCon India in September 2016, I moderated a panel titled The Future Verification Flow. Joining me were Ashish Kumar, senior engineering manager at Broadcom India, and Shankar Bhat, verification and validation director at Qualcomm India Pvt. Ltd. What follows is our lively and surprisingly frank discussion on simulation, formal verification, emulation, and everything in-between.
While this is a longer blog post than usual, it is chock-full of interesting information and invaluable advice.
The verification flow
We started with the verification flow as follows:
Rizzatti: Driven by the exponential growth in design complexity, both in hardware and software, the industry has settled on two verification flows: the IP/block level flow and system level plus embedded software flow.
Kumar: It is true. If you to look at today’s designs, their sizes have dramatically increased, and their structures have become horrendously complex, a mix of hardware and software.
Fundamentally, an SoC design has four hierarchical levels, from bottom to top: IP, block, system and system with software. For comprehensive SoC testing, we need to ensure that when you move from bottom to top in the hierarchy, namely, from IP to block, to sub-system, to system, and to the embedded software, all the lower hierarchical components have been thoroughly verified. For instance, when you tackle block-level verification, all IP must be fully verified. Otherwise, block verification won’t pass. The same stands for sub-system, and so forth.
At the system level, you should focus on system-level issues like performance testing and intra-sub-system testing. When it comes down to embedded software verification, we need to ensure that the system hardware has been thoroughly verified so that we can focus only on real software integration issues.
Typically, there are different kinds of designs — designs that are CPU intensive and designs that are host-application intensive. In host-application intensive designs, what actually happens is that you have your system affecting the host and, at that time, the host is driving the actual target inside. And, the CPU is not much of a use case. That is why you need to ensure that the system or SoC level is fully verified before you get your CPU stuff coming in.
Furthermore, the Accellera universal verification methodology (UVM) standard is playing an important role in verifying the system at all the levels. Here’s an example: I have a ONFI flash controller or DDR controller in my design. When I start with UVM at the IP Level and write initialization sequences in UVM, they can be used in sub-system level testbenches and in the SoC testbench without much extra effort.
Bhat: Basically, the question is IP-level verification and SoC-level verification. IP-level verification uses SystemVerilog and UVM. UVM meet its goals. If you look at the challenges we had five years back, design verification was essentially hardware verification, or VLSI verification. Today, design verification is driven by time to market, cost and more and more embedded software. Embedded software validation cycles are shrinking –– you want to have first silicon up and running in less than a month. The challenge you have today is how best to verify your software in the pre-silicon environment. This is the challenge at the SoC level where system scenarios, concurrent scenarios and software scenarios needs to be verified.
When you consider the whole SoC design verification cycle, there are different challenges at different hierarchical levels. In IP verification, challenges are different from those involved in subsystem verification. When you move to SoC verification, the challenges are again different.
The key intention of UVM was to leverage the same methodology across all levels, from IP to subsystem to system. I think it helped us to cope with those challenges.
Now, verification is facing a new level of challenges. Foremost, we need to make sure the SoC is functional on day one with many more multiple and concurrent scenarios. With each SoC including multiple processors, a lot of concurrent scenarios are coming in the picture and lot of software test scenarios need to be verified. Verification strategies at the IP and SoC level have different sets of challenges.