From time to time I hear or read stories about how engineers find ways to apply Specman to verification problems that are outside of normal RTL verification. Often times they are about connecting Specman to a post-silicon environment such as a physical board. There are probably many of them, but a quick search on cadence.com turned up one published by Intel in 2006.
Most of the time these applications of Specman are setup to drive the hardware, but often for the purpose of verifying the entire system, both hardware and software. All of the stimulus and checking is at the hardware boundaries, but there is software running that must correctly react to the hardware stimulus. One of the things that interests me about the current state of using a Virtual Platform for early software development is the area of hardware stimulus generation and checking. Sure, a Virtual Platform can run software, but nobody talks much about the hardware stimulus that goes in and the activity that comes out of the system. I have done things like using a real network to connect a Virtual Platform to the internet or using a real USB stick to verify that the software is working, but the concept of a testbench is rarely (if ever) talked about. Most of the discussion that does occur is about using TCL scripts or some other scripting language to send a hardware event or data to the simulated system in a primitive way. This use of scripting is about like using TCL scripts as an RTL testbench in Incisive. Yes, TCL can drive and read HDL signals, but most of the time a more complex testbench is needed in RTL verification. My conclusion is that the same verification needs exists at the Virtual Platform level, and in the future more complex verification will be used. This definitely fits into the top level of my Verification Hierarchy of Needs pyramid.
At the recent ARM Techcon3 I gave a presentation titled "Design flow for Embedded Software Verification on Android" that covered both of use of Specman for non-RTL simulation and discussed this idea about hardware stimulus for the purpose of verifying a system.
Before I get into the details, one short point on verification language and tools. One of the great things about Specman is that it is a verification tool that only does one thing, verification. It was built for this purpose and nothing else. There will always be debates about verification languages like SystemVerilog and e and about methodologies like OVM and VMM in the hardware verification community, but I alway receive a very positive response when discussing the use of a dedicated verification language for either embedded software verification or system verification (as I will describe in this series on Android). It's very refreshing to sort of "step outside" of EDA and all the biases and talk to engineers about verification. I watch as their faces light up when they see a dedicated programming language with concepts like Aspect Oriented Programming (AOP), sequences, randomization, constraints, and coverage. I think SystemVerilog is just fine also, but it seems a little funny to apply SystemVerilog to situations like this because even its name associates it with Verilog, a Hardware Description language. OK, let's get started with Android.
To demonstrate my thinking about system verification I decided to use an Android mobile device as an example system to verify. Everybody knows that mobile devices can lock up, reboot, and suffer various other unfortunate events that are most likely caused by some corner cases in the hardware and software. Android is open source, easy to get, and easy to understand. You can read all about Android, and get all of the developer goodies at developer.android.com.
One of the most interesting parts of the Android SDK is the emulator. It has the following characteristics:
Instruction accurate software model of the CPU hardware system
Full programmers view of the hardware design
Runs the same system image as a real device
Developers use the same toolchain for the emulator and devices
It runs pretty fast
It's based on a modified version of QEMU
(one of my favorite tools)
The emulator models a fictitious SoC called Goldfish which includes an ARM926EJ-S CPU, memory controller, real-time clock, interrupt controller, timers, keyboard, modem, SIM card, USB gadget, frame buffer, audio, battery, and more.
The first step is to get the Android SDK, create an AVD (Android Virtual Device), and run the emulator. I'm going to use Android 2.0 for this blog series (which is very new). The presentation I did at ARM Techcon3 was based on Android 1.6, but I'll update here to 2.0 to keep it fresh. I will do everything on Linux, today it will be Ubuntu 9.04 (the Jaunty Jackalope). Once we get the emulator installed and running we will continue next time with our system verification discussion.
Go to developer.android.com and the download page to get the Android 2.0 SDK and extract it:% cd
% mkdir android ; cd android
% tar xvfz android-sdk_r3-linux.tgz
Put the tools directory in your PATH, I'm using bash so I added this to my .bashrc
Now start android with no arguments:
Click on Available Packages on the left and install all of the packages that are listed. I found I had to visit the Settings menu and check the box about "Force https://... sources to be fetched as http://..."
The first step is to create an Android Virtual Device (AVD). This can be done using the GUI or command line. I did it using the command line.
% android list targets
will show the possible targets available.
Next create the AVD in an empty directory to use for this project:
% android create avd -n verify -t 4 --path avds
and start the emulator:
% emulator -avd verify
In about a minute you should see the OS boot and see something like the screen shot below. Try out the emulator, it's pretty cool you can access web sites, simulate phone calls, and more.
Now that we have the emulator running we will pick up from here next time to start talking about system verification using the Android emulator.
Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.