Home > Community > Blogs > Industry Insights > q amp a how system design and verification can go mainstream
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Q&A: How System Design And Verification Can Go “Mainstream”

Comments(0)Filed under: Industry Insights, DVCon, FPGA, TLM, RTL Compiler, System Design an Verification, OVM, System C, C-to-Silicon, Incisive, IEX

System design and verification are part of the RTL flow today, but a higher level of abstraction is now poised to enter the IC design mainstream, according to Ran Avinun, marketing group director for system design and verification at Cadence. In this interview he discusses trends in hardware/software integration, prototyping, and transaction-level modeling (TLM), and offers a perspective on the recent merger activity in the virtual platform market. He also provides a preview of Cadence involvement in next week's DVCon 2010 conference.

Q: Ran, how do you define "system" design and verification?

A: There are two definitions for "system" in the electronic industry. One has to do with a higher level of abstraction beyond RTL. The second definition points to system-on-chip [SoC] and system-above-chip integration, including hardware and software.

Q: Why is it so important to bring software into the design and verification process?

A: Just recently there was a Toyota Prius problem where the antilock braking system [ABS] gives drivers an "inconsistent feel" when braking over rough or bumpy surfaces. The core problem is the electronic interface (hardware and software) between the ABS and the regenerative braking system, according to reports. This is just one example. In general our devices are getting more complex, and each one of them has at least one processor, or perhaps other programmable components. Each one of those processors comes with embedded software. If you ignore software, you basically just do half of the job.

In the past, many devices or boards were designed only by hardware engineers, and the software was not part of the hardware design. Integration was done after tapeout when the SoC or board was shipped to the system integrator. This worked well when you had 2-3 years in your design cycle and the design was relatively simple. But when designs became complex, and design cycles shortened to 6-9 months, it didn't work well.

One of the paradigm shifts we see is that more and more semiconductor and IP companies are delivering the hardware together with the software to the system integrator. An IP company needs to think about all the different configurations in which the software will interact with the hardware and create regression tests to test those scenarios. It creates a new set of challenges.

Q: In the hardware design world, we have a metric-driven verification methodology along with formal verification techniques. Can this type of formalized methodology be applied to software verification?

A: Most software verification techniques today are very primitive, and are based on pure code coverage or on methods used in hardware design 15 or 20 years ago. I think there is a place for advanced verification techniques, but they probably will not evolve directly in the pure software world. Instead, they will be created and executed by the hardware developer who is integrating the embedded software.

I think there is room for growth in tools that address the creation of scenarios or use cases to improve up-front verification for hardware and software. Our Incisive Software Extensions product lets users take advanced verification and power shut-off techniques that were applied to hardware only, and start to apply them to both hardware and software.

Q: What do you see as the respective roles for virtual platforms, FPGA-based prototypes, and emulation, and why is there a need for all three?

A: While different products have different software stacks, the lower levels of the stack normally have a higher hardware dependency. Acceleration and emulation do a good job of handling the lower layers of the stack where you have this dependency.

 

 

With FPGA prototyping, you start to address higher layers of the software stack. Virtual platforms enable you to run higher-level applications.

From the hardware side there are three tradeoffs customers need to make - speed, accuracy, and bring-up time. In many cases, bring-up time will be a function of turnaround time. Acceleration and emulation address accuracy and bring-up time very well, since they are based on existing RTL models and provide very good automation and compile time.

FPGA-based prototyping provides better performance, but still has issues with bring-up time, which is unpredictable. To some extent, FPGA prototyping is inaccurate - in many cases it requires you to make changes to your design as you map it to the hardware. Turnaround time and debug are also poor with FPGA-based prototyping systems.

Virtual prototyping provides high speed but not accuracy. Bring-up time is not good for new designs, but for derivative designs where you already have the models, it can be faster. The main issue with virtual prototyping is that you never know if what you build represents your real design and implementation. This is an issue that the industry and  EDA vendors will need to address in the future. While today most customers are using one or two of these platforms, I expect all three will be used by customers in the future.

Q: There's been some recent merger activity in the virtual platform market. Synopsys bought Vast and CoWare, and Intel bought Virtutech. What's your perspective about this activity?

A: These acquisitions confirm that hardware/software integration is a significant issue facing our customers. These acquisitions, however, only focus on one small piece of the total solution. The hardware/software integration challenge will not be solved by amassing a segregated collection of point tools.

Our approach is to address the problem by connecting the hardware and software worlds to the design, verification and implementation methodologies and flows. We provide a comprehensive TLM [transaction level modeling] driven design and verification solution, including high-level synthesis and full system integration using acceleration and emulation. Our flows and methodologies are based on standards. As part of this flow, we provide customers with a single verification environment, verification IP and a metric-driven verification methodology for TLM, RTL simulation, acceleration, emulation, and hardware/software integration.

Q: Some people may be hesitant to invest in acceleration/emulation. Why is it so important for system design and verification?

A:  Although many new IP blocks are created in TLM, when it comes to SoC integration, most designers are still relying on their RTL. If you want to bring up your system including hardware and software at RTL pre-silicon, there is only one way to do that - hardware-assisted verification.  If you need accuracy for hardware, and you need to bring up new complex designs in a short time frame, emulation will definitely provide the fastest bring-up. If you don't have acceleration/emulation you may miss the target because it takes you 6 or 9 months to bring up the environment.

FPGA-based prototyping is a good hardware/software integration solution for a sub-system but is not scalable. Once you get into larger designs, the time spent mapping and bringing up the design is very long, and also the performance will degrade significantly, maybe even to the point where you're running slower than emulation. Also, debug visibility into the chip is very limited.

Many companies are using a combination of emulation and FPGA prototyping. We see this happening in two ways. "Dual mode" is where they use each platform at different phases of the design. "Hybrid mode" is where they're connecting FPGA prototyping to acceleration/emulation and running them together at the same time.

Q: Cadence is putting a lot of emphasis on a TLM-driven design and verification flow. TLM describes hardware. Does TLM modeling help with software verification?

A: Absolutely. You can use a TLM model as a single source, and apply it to both a virtual platform and to high-level synthesis in order to link to implementation. It might be that as you do this, you generate two models - one will be faster, another will have more details about implementation, but the point is that you start from a single model that you can continue to update as your golden source.

Q: How does transaction-level modeling help with the design and verification challenge?

A: TLM gives you a productivity improvement in both hardware design and verification.

Through the transition to TLM, our goal is to provide our customers with a 3-10X design productivity improvement, 2X shorter verification cycle, and 10X faster exploration and architectural trade-offs. As you write a smaller amount of code and keep a separation between your functionality and design constraints, your initial design and especially IP re-use becomes faster. When it comes to verification, you can simulate your design and debug your problems faster, because you're debugging at the protocol level and there are likely to be fewer bugs because you're writing less code.

Q: What's needed to bring TLM into the design and verification mainstream?

A: We're moving from the early adopter or missionary deployment into the mainstream, and I think right now we're at the inflection point. I think there were two issues that didn't allow this to happen in the past. One is that TLM models were not created to be synthesized and implemented -- they were created only for simulation and modeling and therefore resulted in a discontinuity between TLM and RTL.

In order to change this, TLM needs to have a link to mainstream logic design and implementation. We're doing that with C-to-Silicon Compiler by embedding RTL Compiler into it, and building a TLM to GDSII flow. Now we need IP providers to start delivering IP in TLM. We see that today, but only for modeling and simulation, not for implementation. I think that will start to happen as the methodology becomes part of the mainstream flow.

Another point is that verification engineers were not part of this [TLM] environment. They waited until the architecture was done and an RTL description was ready. We have recently started to see large companies preparing their infrastructure in order to extend their verification environment to TLM. This is a good sign, showing us that we are at the tipping point of the change.

Q: How will Cadence participate in DVCon 2010, Feb. 22-25?

A: First, there is a SystemC day Monday, February 22 and we will participate in multiple ways. Mike McNamara [Cadence] and Mike Meredith of Forte will give a tutorial on the SystemC synthesizable subset. On the same day, Brian Bailey will give a presentation on TLM-driven design and verification based on the Cadence methodology.

An OVM tutorial [Feb. 23] will show, for the first time, our OVM acceleration methodology applied to our Incisive Palladium products. I'm also going to participate in a panel [Feb. 25] that will discuss how to minimize verification time and effort. And Lip-Bu Tan [Cadence CEO] will be the keynote speaker [Feb. 24] for DVCon, and will talk about the new directions will Cadence bring to the industry.

[Note: For further information about Cadence participation in DVCon, click here.]

 

Richard Goering

 

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.