Home > Community > Blogs > Industry Insights > q amp a a closer look at the cadence virtual system platform
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

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: A Closer Look at the Cadence Virtual System Platform

Comments(0)Filed under: Industry Insights, SystemC, TLM, virtual platforms, Incisive, virtual prototype, EDA360, embedded software, system realization, software, Imperas, system level, virtual prototoyping, System Development Suite, Virtual System Platform, Steve Brown, VSP

Cadence took a significant step into a new marketplace with the recent introduction of the Virtual System Platform, a virtual prototyping environment that supports architectural-level, pre-RTL software development and debugging. The Virtual System Platform is part of the tightly integrated System Development Suite, which also includes testbench simulation, RTL acceleration/emulation, and FPGA-based prototyping.

In this interview Steve Brown, product management director at Cadence, talks about the limitations and challenges of virtual prototyping today and discusses some of the capabilities provided by the Virtual System Platform. In a previous interview Michał Siwiński of Cadence discussed the hardware/software integration challenges that are addressed by the System Development Suite.

Q: Steve, how do you define "virtual prototype" and "virtual platform?"

A: A virtual prototype is a software model of a system that may include one or more systems on chip (SoCs). It is created early in the project and used for software development as well as assessing the system architecture. A virtual platform is the EDA tool or solution used to create virtual prototypes, although sometimes this term is used interchangeably with the term "virtual prototype."

Q: How are customers using virtual prototypes today?

A: Customers have been using virtual prototypes for many years. The solutions have mostly been home grown, and the recent generation of commercial solutions has seen limited adoption because of proprietary constraints or business models, or technical usability issues and learning barriers on the part of customers.

Virtual prototypes are used for a wide spectrum of software development, depending on the goals people have. Some virtual prototypes are created exclusively for hardware-dependent software development, such as drivers. Others are created for very large system exploration, like a full-blown airplane. That requires a different approach to creating the models.

Q: What limitations are people running into with commercial virtual platform solutions?

A: We see that customers have tried solutions and have had some mixed success. That makes it clear that there's a benefit, and when it's managed the right way, customers have been able to reduce their software development schedules.

But despite that success, customers are facing hurdles around the difficulty of creating the platform in the first place. The languages and the approaches to modeling have not been universally accepted. Even with the emergence of the SystemC standard, there are ambiguities or unaddressed areas in how to do modeling that the standard itself doesn't clarify.

Q: There's also a disconnect between virtual prototypes and the RTL environment. How does that arise?

A: The disconnect can be viewed in a couple of ways. One is that the software development environment is so different that moving from a virtual model to RTL or silicon is a very painful process. It's almost like two different planets. Another way to look at this disconnect is to observe that the models themselves don't have an exact correlation with what eventually gets built in hardware. We have customers who have used virtual platforms to develop software, but when they got silicon back they discovered mistakes in the models, and all the software behavior had to be re-analyzed.

Q: What unique capabilities does the Virtual System Platform provide?

A: The Virtual System Platform has the flexible debugging that's required for multi-core SoC and software development. It provides a completely unified hardware and software viewing and debugging environment without artificial boundaries between them. You can set breakpoints, single step, and stop at breakpoints within hardware or software domains. The entire system debugging paradigm is fully synchronized while still providing high-performance execution for software development.

A second differentiation that the Virtual System Platform provides is easier creation of models. It provides a way to generate the [IEEE 1666] TLM 2 code for each peripheral IP block from a register description written in a register description language (RDL) or IP-XACT standard format. The code that's generated can be compiled and executed and can be used to build a register-active virtual prototype.

Third, the integration of the Virtual System Platform with Incisive and the [Palladium XP] Verification Computing Platform allows you to mix portions of the system that have been implemented in RTL as they become available. You can focus on performance-sensitive parts of the design and have cycle-accurate RTL models. With the connection to Incisive you have a unified execution engine and a fully unified debug environment.

Q: Who are the primary users of the Virtual System Platform?

A: We see different companies trying it in different ways. Hardware teams often need to provide information about their chips to software developers, so they're looking to add virtual prototypes as a deliverable. Sometimes it's the hardware verification team that's leading the way, and sometimes it's the architects. Occasionally it's the software team that drives the adoption of virtual prototyping.

Q: Where will the models come from?

A: One of the strengths of the Virtual System Platform is that it is open to models from many different sources. It runs SystemC TLM 1 or TLM 2 models, or any kind of C language model. The strategy behind our model generation is to produce a TLM wrapper for each IP block from a register description or IP-XACT specification. This can work for pre-existing C models or for newly developed functionality.

Processor models are available from IP vendors and other third-party providers, and we work with ARM and Imperas today. We've validated their solutions with the Virtual System Platform. We feel the industry needs to open up about how models are created and shared, rather than trying to control models with proprietary formats.

Q: Are third-party software debuggers available?

A: The Virtual System Platform comes with a hardware and software debugger with all the bells and whistles you would expect. But we recognize that people are comfortable and familiar with third-party debuggers, so when a virtual prototype is exported from the Virtual System Platform as a binary model for software development, it is possible to connect a third-party debugger like those from Lauterbach or ARM.

Q: Is there any connection to implementation via high-level synthesis?

A: Aligning virtual prototype models with synthesizable flows is an area of interest for Cadence. However, there's a difference in the models - the goal of a virtual prototype model is to support just enough functionality for software development, whereas a synthesizable model requires all functionality. What's being explored now, in the industry and by Cadence, is how to align these two types of models. We first need to start with the methodology before we decide on any kind of tooling.

Q: How does the Virtual System Platform support multi-core development and debug?

A: Multi-core is really in its infancy in terms of programming models, system models, and functional debugging. What I see now is that customers are simplifying the way they partition their systems to enable success in reasonable project timelines.

What's required is a tool that allows you to visualize software execution for each core, and keep the processor and SoC peripheral execution fully synchronized. Remember that each core has its own memory map and a set of peripherals that are hooked to it. You have to not only debug a single thread in a single core, but also debug how the thread of execution is interacting and accessing shared resources, and look at all those interactions. With the Virtual System Platform we are helping initially by supporting the controllability and visibility of multiple cores and software threads.

Q: Finally, how will the Virtual System Platform fulfill the EDA360 vision of System Realization?

A: The Virtual System Platform is a major step forward into the embedded software world to really address the problems that exist where hardware and software meet. We add unique value by being aware of hardware design challenges and having some experience in the embedded software world. What happens in the future with the broad EDA360 vision remains to be seen. But I think this is the beginning of a great new era for Cadence and for the EDA market.

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.