Starting Virtual Platform Simulation with Cadence Software Developer

Last time, I provided an introduction to the Eclipse setup for the Cadence Virtual System Platform. This time I will explain how to run simulation using Software Developer. Cadence Software Developer provides multiple flows to hand off virtual platform simulations to software engineers. The easiest flow can be used when the platform creator and software developer are working at the same company and on the same network. In this flow, I will describe how to simulate a virtual platform in System Creator, then save the platform configuration information. Using the saved configuration information, it is easy to run Software Developer from Eclipse. Finally, I will explain how to set up a debug configuration to begin debugging software running on the virtual platform. This will be performed without copying the design files.

Run the Simulation and Save the Configuration

Start by running the virtual platform in the usual way using Cadence System Creator--typically this is done with irun. If the design is able to successfully build and run, then you should be able to save the platform configuration information for use in Eclipse.

To save the configuration information, use the same irun command you use to run the simulation, but add the following option to it, choosing a name for the configuration:

$ irun [...] -savevpconfig <name>

You can also pass the -savevpconfig option directly to ncsim if you are not using irun.

To illustrate the details let's try it on a simple example that comes with Incisive 13.1. The example is found in the release area under `ncroot`/tools/esl/examples/single_core_symbolic_eswdebug

First, go to a scratch area and copy the example:

A new directory is created in the scratch area named single_core_symbolic_eswdebug/ and a message is printed recommending to go there and check the README file.

The first step is to prepare the software program to run. This is done by the script BUILDME. If you have an ARM cross compiler it will compile the software program, and if not it will use a pre-compiled version. The output is the software program that will be run, example.elf, so make sure that is now in the directory. The key step is to run:

$ ./BUILDME

To make sure the example can compile and simulate in batch mode use the command:

$ ./RUNME_ARM -input example_ARM.tcl

You should see some compilation and then a stream of tlmcpu commands which demonstrate the debugging features from the ncsim> prompt. Assuming your setup is good and you have the required licenses it will run and complete automatically.

Next, generate the virtual platform configuration file. This is a file with a .vpc extension. Just add the -savevpconfig argument with any name and run again to generate the .vpc file.

$ ./RUNME_ARM -input example_ARM.tcl -savevpconfig example

At the end of the simulation there is a new file ./vpconfig/example/example.vpc created, and that's all you need to fire up the simulator with Eclipse.

Launch Eclipse

You can use either method of launching Eclipse that was covered last time. I will assume you are using the RCP version. Start by running

$ vsp_eclipse &

Select the workspace directory and get to the VSP perspective. If this is the first time vsp_eclipse is run, the screen may look like this:

From the Welcome screen click Workbench and use the menu to select Window -> Open Perspective -> VSP

There is also an Open Perspective button near the top right of the window.

Now it's time to create a "Debug Configuration". On the menu select Run -> Debug Configurations

You will see a number of different kinds of configurations down the left side.

Select and Right Click on "C/C++ VSP Application" and select New

When the next dialog comes up choose a Name and then click the "Browse VP Configuration" button and find the example.vpc file generated above.

Now just click Debug and the simulator will start up, connect and wait for you to start running! You can use the VSP File Browser tab to put a breakpoint on main() and then use the run controls on the Debug tab to start running. Here is the program stopped at main().

This particular example demonstrates a lot more detail about how the simulator provides the tlmcpu command to do embedded software debugging directly from the ncsim> prompt. Most people who have used ncsim in the past are pretty surprised to learn that you can put breakpoints in embedded software code, single step through the embedded software, print values, disassemble code, look at the stack and memory all from the ncsim> prompt. It's worth a look at different files with the pattern example_*.tcl to learn how the commands work. If you are not an Eclipse fan, but love to work at the command line in Linux, you will enjoy using the ncsim> command line as a full embedded software debugger. There is even a gdbalias command which provides support for using gdb-compatible commands at the ncsim> prompt.

Jason Andrews