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
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
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
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.