Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
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.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
Get email delivery of the Cadence blog featured here
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:
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:
Put the tools directory in your PATH, I'm using bash so I added this to my .bashrc
export ANDROID_SDK=/home/jasona/android/android-sdk-linuxexport PATH=$PATH:$ANDROID_SDK/tools
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.
Looking forward to seeing how you use the android emulator on linux with a verification environment.