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.
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:
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:
Peripherals Base Address
Primary Interrupt Controller 0x14000000Secondary Interrupt Controller 0xca000000Counter / Timer 0x13000000Real time Clock 0x15000000UART 0 0x16000000UART 1 0x17000000 Control Registers 0xcb000000Keyboard Controller 0x18000000Mouse Controller 0x19000000Multimedia Card 0x1c000000Ethernet Controller 0xc8000000LCD 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:
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:
Stay tuned to future posts and find out all these answers and more.
Thanks for reading.
* 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.