Home > Community > Blogs > System Design and Verification > virtualization and verification with posedge software
 
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 System Design and Verification 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: *

Virtualization and Verification With Posedge Software

Comments(0)Filed under: System Design and Verification, QEMU, OVP, open virtual platforms, posedge

Posedge Software is a Cadence Verification Alliance Member with skills in two of my favorite areas: virtualization and embedded software verification. Posedge has worked with ISX as far back as 2006. Besides the fact that they are skilled in verification I must also mention that they are from Minnesota, mostly to prove that my home state is not a complete wasteland and other smart people also live here (even though the temperature was 15 degrees Fahrenheit this morning). I sat down with Henry Von Bank of Posedge to find out more about his interests in embedded software verification and his previous work with QEMU and Open Virtual Platforms.

Hi Henry, what does Posedge Software do?

Posedge Software provides consulting services and tools for both hardware and software verification, in particular using Specman Elite and ISX. We have experience with software development, hardware verification, and other skills needed to put together a complete system verification environment

When did you become interested in virtualization?

Like many people, I've used virtualization to run multiple operating systems on one PC (usually for running Windows on top of Linux). I've also found virtualization very useful for software development, particularly for device drivers and other embedded software. Often the only other option is to debug on the real hardware, which is not ideal.

The other thing that fascinates me with virtualization is that you can stop the execution and poke and prod at the internals of the hardware or operating system. There often isn't another way to do this except by adding lots of instrumentation to the software and using debuggers and debugging hardware. I don't think this aspect of virtualization is being exploited as much as it could be, but it has a lot of potential.

I understand you have worked with QEMU in the past and more recently Open Virtual Platforms, what do you find most interesting about them?

The interesting thing about these two virtualization technologies is that they support a variety of target processors, such as ARM and MIPS, while still maintaining good performance. They also allow a variety of peripherals to be used in the virtual target, including real hardware attached to the PC, and emulated hardware. This can be extremely useful for testing and debugging.

While QEMU has more or less a fixed number of platforms it supports, with OVP you create a custom platform that has any number of processors and peripherals. The APIs for creating models in OVP are also much better defined and easier to use.

Can you tell us a little about the performance possible with Virtual Platforms?

The goal for virtualization is generally to get as close to native speeds as possible for the virtual machine. With the clock frequencies and dedicated virtualization instructions in modern processors, the performance is more than adequate. When a smaller, embedded processor is the target, you can potentially run it faster than the real hardware. When doing system verification, anything that can increase performance and shorten test times is valuable.

What type of embedded processors have you been working with?

In the past I've done embedded systems development with platforms ranging from 8-bit micro-controllers to high performance DSPs, and also with systems running embedded Linux. Lately I've been working mostly with MIPS processors.

Did you find anything interesting about how OVP models are created or the interfaces they provide?

One interesting thing with OVP models is the concept of intercepts. An interception library can be created and loaded into the processor model and can catch specific function calls that are made and either replace the behavior of that function, or perform other checking and monitoring. With this you could potentially collect coverage info, and give visibility into your kernel, without modifying any of the software and without affecting the state of the system.

Tell us about your experience with Incisive Software Extensions (ISX)?

I have worked on several projects using ISX, creating the mini-adapters and other work interfacing tools with Specman. While it certainly takes some effort to get the ISX infrastructure in place, once complete you can treat the software similar to any other component in the verification environment. Another thing I like about ISX is that it works independent of the simulator, and really can be used with any type of software execution environments including things like QEMU and OVP.

What kind of problems do you think can be addressed by the combination of Virtual Platforms and ISX?

Software verification has always lagged behind hardware verification, mostly because of the lower cost of making changes and providing updates, even as software complexity has increased greatly. The other issue with performing software verification is that you often do not have precise control over the platform. For example, when writing a device driver it might be tested simply by plugging in the real hardware. This can leave many corner cases untested.

I think hardware verification techniques such as constrained-random testing and coverage-driven verification can help remedy this. Using Specman with ISX provides a foundation on which software verification environments can be built. Virtualization is necessary to handle the complexity of modern software, as it can be too slow, or otherwise too expensive, to use hardware simulators and emulation/acceleration to execute the software.

Another problem that I think ISX and virtualization would be good at is multi-threaded and multi-processor applications. This is a big issue in the software development world and being able to stop execution and inspect the state of each process and processor from the testbench would be very helpful for testing and debugging.

How can readers contact you to get more information about your work?

They can check out the Posedge Software website at or email me.

 

Thanks to Henry for sharing some of his insight into virtualization and verification. I found the most interesting topic Henry mentioned to be the "interception functions" in OVP. I started discussing code instrumentation a bit in a previous post, but there is a lot more to cover here. From what I have seen so far the ability to add code to the simulation that is invoked based on the execution of the target software is really cool. Maybe in a future post I can provide more details on this feature of OVP.

 

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.