| |
|
|
 |
| |
 | |  | | | | | Interview: New SoC Functional Verification Kit Kicks it up a Notch
An interview with Amjad Qureshi, Digital Kits Architect
Cadence Design Systems | |
| |  | |  |
Amjad Qureshi, SoC Functional Verification Kit architect for Cadence, talked to cdnusers about the new Kit that was introduced in August. The Kit provides example verification plans; transaction-level and cycle-accurate models; design and verification IP design from Cadence and third parties; scripts; and libraries. Why the need for a new Kit, and what does it mean to the design community? That’s what we asked Amjad.
cdnusers: There seems to be a new level of discussion in the industry about the importance of verification in SoC design.
Amjad: Yes there is, because there is a lot to be gained in terms of time savings for designers and verification engineers who solve the problems of complex SoC design, especially for companies involved with wireless and consumer chip designs. Consider that verification can account for over two-thirds of the overall design schedule and, even after all the time spent, designers and verification engineers are struggling for closure and finding bugs after silicon tape out. New solutions are needed.
cdnusers: Can you be more specific about the problems?
Amjad: Most verification environments focus on directed testing with some pseudo-random coverage. In my view, the key focus should be on formal verification—that is, comprehensive verification meaning functional verification, formal verification, and assertion–based verification.
Also, I believe verification environments need more automation and should rely more heavily on re-use. Today, re-use is often neglected—which is an opportunity. How do we use verification components and verification IP? How do we integrate them at the design engineer level? How do we take them to the system engineer and the verification engineer level? How do we do it without reinventing or recreating the wheel?
cdnusers: What’s the answer?
Amjad: We have to do something different. We have to start working earlier in the design process, in a more integrated way. To understand this, let’s look at the five abstraction levels in SoC design.
The highest level is the algorithmic level. Then, comes the programmer’s level. Next, the programmer’s level plus timing for timed protocols. Then, the cycle-callable level for cycle accuracy. Finally, there is the register level, which is the RTL or Verilog/VHDL level.
Unfortunately, I think that more than 50 percent of the design and verification teams in the industry focus only on register-level verification—the slowest and lowest level of abstraction. They do not go to the higher levels of abstractions. To be more effective, we have to focus on the entire process from the architectural level to the register level.
cdnusers: How does the new functional verification kit you have been working on address this problem?
Amjad: Rather than looking at one piece of the process, we look at the complete verification process from end to end—including re-use.
cdnusers: What’s different about the Kit?
Amjad: The Kit is architected into three major flows that address the five design levels I just mentioned. Designers can use all three levels as an integrated flow or select flows individually, depending on what they need.
The architectural-level flow allows for early software/hardware co-verification. We use what we call software extensions to run actual applications at this level of abstraction.
The RTL block- to chip-level flow covers low power verification, which is very important in SoC design today.
The system-level flow includes what we call in-circuit emulation or transaction-based acceleration. This means that, once you map portions of the design (or the entire design) onto Palladium or Xtreme, you can dramatically improve simulation speed—from 10X to almost 1000X in emulation.
It’s important to note here that, at the architectural level flow we debug and create early software on the hardware. At the system-level flow, in emulation and acceleration, we can actually re-use portions of the verification components that we used in simulation and architectural-level verification in the emulation and acceleration process—and achieve close to 1000X improvement in simulation speed.
cdnusers: You are talking about a flow that spans several design teams: the system design team, the SoC design team and the verification team. In what way does the flow you have described affect their relationship?
Amjad: The whole idea is to bring design and verification teams closer together. Today, these teams do not communicate as well as they should. Not only do the Kit’s three flows ensure proper use, re-use, and verification closure at all levels of the design, they allow design and verification teams to better integrate and communicate.
Through this process, designers write block-level verification plans before verification teams enhance these plans. Then, verification engineers take the verification plans and create chip-level plans, also integrated. At that point, the system engineers basically take the chip-level plan and re-use it at the system level.
It is vital that design engineers work very closely with the verification engineers so they don’t waste time creating throw-away testbenches—which are often written in very low level language, like Verilog or VHDL, and without any notion of closure.
cdnusers: “Interactive methodology” is one of the things Cadence is promoting about the Kit. What does that mean?
Amjad:The Kit includes a Kit Navigator, a GUI-based guide that takes you through all the flows. It can take you through a complete flow for System Verilog, or a specman e-based flow or a low power flow or a software flow, and show you actual verification plans. It can invoke and run that module, so actual tools are linked into the navigator. Then, you can use Enterprise Verification Manager to understand all the results and report on them.
Customers who have used the Kit are really pleased with this feature. It can be used as a demo, as a reference or for training—and it can be customized.
cdnusers: You have obviously put a lot of work into the new Kit, what do you want designers and engineers to know about it?
Amjad: The big take-away is not to underestimate verification. Chip re-spins are very costly in terms of time and, of course, dollars. The new kit can help by enabling re-use, achieving functional closure, and providing automation.
cdnusers: Is training available?
Amjad: Absolutely. Five-day applicability consulting is included and lets users get hands-on experience with the Kit so they can relate it to their own design environment.
| 
About the author
Amjad Qureshi is a Director and digital Kits architect in Cadence Verification Division. Mr. Qureshi has been with Cadence since early 2006 and has over 19 years of experience in chip design and verification. Prior to joining Cadence Mr. Qureshi was the Engineering Director at Cradle Technology, a multi-core DSP processor startup where he successfully managed 4 complex tape-outs. Mr. Qureshi held several management positions with IBM, Samsung and Phoenix Technologies. He has 14 US patents and has written several papers. Mr. Qureshi holds a Bachelor of Science and Masters of Computer Engineering from Case Western Reserve University.
|
| |
This content has not yet been rated by other users |
|
|
|
|
|
|
|
|
|
|
| |
|
|
|