Welcome to the Cadence Virtual System Platform

The announcement of the Cadence Virtual System Platform is a momentous event for me. Anybody who has been reading my blog knows I have been interested in virtual platforms for a long time. Since my days as a young engineer trying to debug Pentium CPU boards running SMP Unix in the 1990's, fighting to keep the logic analyzer probes from falling off before the system would hang after hours of operation, I wanted to work on simulation models that would run real software. Through all of the early attempts to run the Internet Operating System (IOS) on Verilog simulations of router ASICs using host-code execution, to mixing Instruction Set Simulation (ISS) models with HDL, to hardware modelers with sockets to plug in CPU chips and connect the pins to HDL via the Verilog PLI, to emulation systems with boards of FPGAs, I always enjoyed the mix of hardware and software and learning how it all fits together to create a functioning system.

At the end of 2005, I had the opportunity to improve the quality of hardware/software systems by working on embedded software verification, first at Verisity and then at Cadence. With ISX (Incisive Software Extensions) we applied the concepts of hardware verification to embedded software. While there have been many success stories described every year at CDNLive! conferences in the United States and Europe, a majority of them were about hardware verification and the use of diagnostic software to better stress the hardware and find bugs in the hardware software combination. From time-to-time there was a story about verification with actual production software or firmware.

It's sometimes a challenge to break out of the land of hardware verification, and it often seemed like most users didn't have the right simulation infrastructure or organizational structure in place to get the most value from ISX as a software and system verification tool. With ISX I was able to experiment with things like qemu, Open Virtual Platforms (OVP), Wind River simics, and the Android emulator. I have written blog articles about some of these. All of this leads up to this week's System Development Suite announcement.

Since 2008, I have been looking forward to the day when Cadence would have a commercial virtual platform product.  Over the last couple of years I have talked to many users about things they would like to improve and the challenges they face. I would like to comment on two of those areas today.

Openness and Flexibility

The first topic is about model creation and assembly. Today, many users are not able to create their own models and connect them with vendor provided models. They struggle with how to deal with small changes needed to vendor models, how to create models using standards that are portable across multiple simulators, and more. Unfortunately, these issues will continue to hold back virtual [latform adoption until they are solved.

I also heard many stories about users paying extra fees to make small changes in virtual platform models, and how it was not possible to change models because the source code was not available. I saw the integration pain of users who thought they were using standards like SystemC and TLM and struggling how to compile a virtual platform using CPU models from CPU vendor A, SystemC models created with EDA Vendor Tool 1, and trying to simulate using EDA Vendor 2's simulator. I tried to help one engineer decide which include file paths should be used when there were three separate (and maybe different) copies of the SystemC header files and a complex combination of object files and libraries compiled with different versions of the GNU g++ compiler.

Integration with Other Parts of the Design Flow

The second topic relates to the connection of virtual platform activities to other design and verification activities. Many engineers told me that they have a tool for virtual platforms, and some said they were quite happy with it, but when it comes time to think about verification or connection to hardware design their company has a completely different environment for RTL simulation and verification. They found it hard to imagine why they had to completely change tools and why there was no way to include legacy RTL or share testbenches across the RTL and virtual platform abstraction levels without a lot of headaches.

I talked to an expert user of ISX (which is derived from Specman technology) who wondered why they had to completely leave the environment they knew well when they wanted to do firmware verification using ISX with a SystemC Virtual Platform. This is because the SystemC virtual platform flow they used was completely different than what they did for RTL simulation. To this expert user, verification should be reusable across any kind of simulation and the migration should be easy.

One particular firmware engineer started his virtual platform journey insisting firmware engineers should run simulation on Windows and it wasn't important to connect to the verification engineers who used Linux. As he saw all of the pieces fall into place during the project, and the teamwork that was happening between firmware, hardware, and architecture engineers when they used a common virtual platform for many different tasks, he was amazed. As he reflected back he was very proud of the teamwork and the benefits to the project. Mysteriously his initial assumption that firmware simulations should be done separately on Windows seemed to melt away and really didn't seem to matter anymore.

These are just of couple of founding principles of the Virtual System Platform. Stay tuned to future articles to find out more.

Virtual System Platform is Built on a Strong Foundation

The Virtual System Platforom is built on a strong foundation of SystemC simulation that goes back to the beginning of SystemC. Our team has many of the industry leaders who have made significant contributions to making SystemC what it is today. Our tools have hundreds of engineering years of development. This strong base, combined with all of the new features that have been added to turn a solid SystemC simulation and debugging tool into a true virtual platform tool, gives us a great start as we step out with our first public announcement of the Virtual System Platform.

Every time I witnessed a new milestone in our virtual platform development, things like booting Linux for the first time, running an RTOS on an ARM microcontroller, running Android and seeing the Facebook app run for the first time, I was pretty sure that when ncsim was first created sometime in the 1990's, the engineers who created it had no idea that someday ncsim would be used like this. It's been an exciting journey and we are glad to share it with you.

As we have created and debugged dozens of virtual platforms we have added many features to make the process easier. We still have a lot more ideas and lot more improvements ahead of us, but if you are interested in virtual platforms don't hesitate to contact Cadence and mention Virtual System Platform.

As Michael McNamara (Mac), the Cadence Vice President and General Manager of System-Level Design, likes to say, at Cadence we are not the first company to do a virtual platform product, but we are the first one to do it right.

Jason Andrews