Home > Community > Blogs > System Design and Verification > welcome to quot understanding the virtual platform quot series
 
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 Cadence 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: *

Welcome to the "Exploring the Virtual Platform" Series

Comments(1)Filed under: System Design and Verification, virtual protoype, virtual platform

Today I'm starting a series of articles related to what is commonly called the Virtual Platform or Virtual Prototype. There are probably many definitions of what it means, but I'm going to discuss the Virtual Platform as an abstract software model of a hardware system or subsystem created for the primary purpose of running embedded software and verifying the hardware/software interaction. A secondary purpose of the Virtual Platform is architectural analysis of the hardware/software interactions. Here are some general characteristics to help clarify what the Virtual Platform is:

  • Runs unmodified target code
  • Uses instruction accurate models of processors 
  • Provides a full programmers view
  • Runs very fast (may be faster than real time)
  • Has excellent visibility and control (compared to physical hardware)
  • Is easy to distribute to many users

Virtual Platforms have been around for a long time, ever since somebody got the bright idea to make a software model of the hardware so they didn't need to wait for boards and sit in a lab all of the time. There is a wealth of information available about Virtual Platforms from companies that have been creating and selling them for 10+ years, but instead of another press release or success story about Virtual Platform usage I will provide hands-on information about the Virtual Platform and especially the embedded software part of it. I suspect that many software engineers already understand the details about how to select operating systems, write device drivers, create and populate file systems, cross compile software, program flash memory, etc., but sometimes software engineers are not familiar with it since somebody else sets up all the infrastructure and they just "add code" in the right place. I'm also pretty sure that much of this information is now becoming critical to verification engineers and people who are in companies that have worked primarily with RTL simulation in the past and are making the transition to the next level of abstraction and see the Virtual Platform as playing a key role in system verification and delivery of high quality software sooner in the process. Refer to my first post on cadence.com

The hardware system I will use is the ARM Integrator CP board. It's is an older board that was supplied by ARM and according to the ARM website is no longer promoted because newer hardware platforms have been developed. Not being a state of the art board that means there is a lot of public information available as well as software available. One of the benefits of the Virtual Platform becomes apparent immediately. First, Cadence is a software company and probably wouldn't understand why I need to buy a board to develop embedded software. Next, if a physical board was needed I doubt any readers would buy the board to learn about how embedded software development and verification works.Since we have Virtual Platform technology nobody needs to buy any hardware and everybody can contribute. All that is needed is a Linux machine (sorry, I don't do Windows).

Instead of actually reading the User Guide, we can start with a quick overview of the Integrator board and its memory map:

ARM926EJ-S CPU

Peripherals                                        Base Address

Primary Interrupt Controller                    0x14000000
Secondary Interrupt Controller                0xca000000
Counter / Timer                                     0x13000000
Real time Clock                                    0x15000000
UART 0                                                0x16000000
UART 1                                                0x17000000
Control Registers                                  0xcb000000
Keyboard Controller                               0x18000000
Mouse Controller                                   0x19000000
Multimedia Card                                    0x1c000000
Ethernet Controller                                0xc8000000
LCD Controller                                      0xc0000000

There are many uses for the Virtual Platform. A common one we can start with is to boot the operating system and run applications. Another one is to write device drivers and debug them. To make life easy I'm going to use Linux as the operating system. Again, there is a wealth of information available and Linux is becoming popular as an embedded operating system. Let's get started.

To start with let's download QEMU to use a Virtual Platform for the Integrator board and boot Linux. 

First, get QEMU, an open source processor emulator. It might be on your Linux machine already or can be installed using your package manager. I'm currently typing on an openSuse 10.3 machine and it found qemu 0.9.0 (0.9.1 is the latest) in the YaST2 package manager. If you compile qemu from source there is one gotcha, it cannot be compiled with gcc4 so you need a version of gcc such as gcc 3.3 or 3.4. Even if your machine has a version of gcc 4 you can also install gcc 3. I installed gcc 3.4.6 to compile qemu. After installation, it can be invoked using gcc346 instead of the normal gcc command. The configure script for qemu looks for common names for gcc3, refer to the variable gcc3_list and add your invocation of gcc3 there and then run configure.

Now that you have qemu installed it's time to get a Linux kernel and file system and boot it. As an easy starting point download the ARM Linux 2.6 kernel and ram disk file system image from the qemu website. Extract this file and go to the arm-test directory.

As the README shows you can boot doing:

% qemu-system-arm -kernel zImage.integrator -initrd arm_root.img

If all goes well you will see a new window:

 

Photobucket

 

You can login as root with no password and you have a Linux system running on the ARM Integrator CP Board with the ARM926EJ-S processor. You can use Ctrl-Alt-2 to get to the qemu command prompt, type help to see the commands or type quit to exit. Ctrl-Alt-1 will get back to the console (this is actually the LCD controller). Ctrl-Alt-3 will get to UART 0 and allows another login window. Ctrl-Alt is the key to release the keyboard and mouse.

Now try some networking:

% wget http://www.google.com

This will download index.html This is a ramdisk so next time you boot the file will be gone.

To browse the web use the lynx browser:

% lynx google.com

 

Other than being pretty cool, this exercise raises many questions:

  • How is the Integrator Board modeled?
  • How does qemu know I want to run the Integrator board?  There was no configuration or arguments.
  • What's in the file zImage.integrator?
  • What's in the file arm_root.img
  • How is the Ethernet controller on the Integrator board able to access the Internet?
  • Can I debug code running on the Integrator board?
  • This is a minimalist system, how can I compile and add more programs to it?

Stay tuned to future posts and find out all these answers and more.

Thanks for reading.

 

Comments(1)

By Greentime on February 18, 2009
   * How is the Integrator Board modeled?
Ans: It needs to model every devices that you need and map those physical address of each device by cpu_register_physical_memory(base,offset,type); and write all these information in the integrator virtual board c file qemu/hw/integrator.c
   * How does qemu know I want to run the Integrator board?  There was no configuration or arguments.
Ans:In vl.c you can see function register_machines(); which function will register all the machines that are supported in its architecture. The first default machine is integrator for ARM architecture. I think that's why it doesn't need configuration or arguments.
   * What's in the file zImage.integrator?
Ans: It's the Linux kernel image of integrator and the .config is in it too.
   * What's in the file arm_root.img
Ans: It is the root file system.
   * How is the Ethernet controller on the Integrator board able to access the Internet?
Ans: Qemu uses slirp to accomplish the network ability. It is NAT that you used in this case. It provides real network connection too by tun/tap which need host Linux support
   * Can I debug code running on the Integrator board?
Ans: Yes, you can. If you want to debug kernel, you can type "-s -S -p port_number" in the Qemu execution commandline then you can use a target remote gdb to debug the kernel. If you want to debug programs running in target Linux kernel, you can use gdbserver to debug it.
   * This is a minimalist system, how can I compile and add more programs to it?
Ans:Yes, you can.

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.