Imperas Installation and Getting Started
Imperas Installation and Getting Started
This document explains how to install and get started with the
OVPsim simulator / models and the Imperas professional products
under Linux and Windows.
Author: Imperas
Version: 2.0.0
Filename: Imperas_Installation_and_Getting_Started.doc
Project: Imperas / Open Virtual Platforms Installation and Getting Started
Last Saved: Wednesday, 23 March 2016
Keywords: Installation, Getting Started, Linux, Windows, Licensing
Copyright Notice
Copyright 2016 Imperas Software Limited All rights reserved. This software and
documentation contain information that is the property of Imperas Software Limited. The
software and documentation are furnished under a license agreement and may be used or
copied only in accordance with the terms of the license agreement. No part of the
software and documentation may be reproduced, transmitted, or translated, in any form or
by any means, electronic, mechanical, manual, optical, or otherwise, without prior written
permission of Imperas Software Limited, or as expressly provided by the license
agreement.
Disclaimer
IMPERAS SOFTWARE LIMITED AND ITS LICENSORS MAKE NO WARRANTY
OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1 Preface......................................................................................................................... 7
2 Introduction................................................................................................................. 7
3 Hardware and Software Requirements ....................................................................... 8
3.1 Operating System................................................................................................ 8
3.2 Hardware............................................................................................................. 8
3.3 Host Compiler Versions...................................................................................... 8
4 Installation................................................................................................................... 9
4.1 Installation Packages........................................................................................... 9
4.1.1 OVPsim....................................................................................................... 9
4.1.2 Imperas Developer ...................................................................................... 9
4.1.3 Imperas Advanced Multicore Software Development Kit........................ 10
4.2 Download the Installation files ......................................................................... 10
4.2.1 Login ......................................................................................................... 10
4.2.2 Download the appropriate package........................................................... 10
4.3 Installing Under Linux...................................................................................... 11
4.3.1 Installing ................................................................................................... 11
4.3.2 Setting up the Linux Environment............................................................ 12
4.3.2.1 Setup Script........................................................................................... 12
4.3.2.1.1 32-bit Product on 64-bit Host ......................................................... 13
4.3.2.1.2 32-bit Compatibility libraries on 64-bit Host.................................. 13
4.3.2.2 Environment.......................................................................................... 13
4.3.2.3 Internet Access Via a Proxy Server ...................................................... 15
4.4 Installing Under Windows ................................................................................ 15
4.4.1 Installing ................................................................................................... 16
4.4.2 Setting up the Windows Environment ...................................................... 17
4.5 Setting up Licensing (Both Windows and Linux) ............................................ 19
4.5.1 Obtaining the computer hostname and Host Id......................................... 20
4.5.2 OVPsim FLEXlm License keys................................................................ 20
4.5.3 Imperas Licenses....................................................................................... 21
4.5.4 Using Floating Licenses............................................................................ 21
4.5.5 Using Node Locked License..................................................................... 22
4.5.6 License Queuing ....................................................................................... 22
5 Windows Development Environment....................................................................... 23
5.1 Introduction....................................................................................................... 23
5.2 MSYS / MinGW Environment ......................................................................... 23
5.2.1 Obtaining Latest MSYS............................................................................ 23
5.2.1.1 First, lets download............................................................................... 23
5.2.1.2 Download and Installation of MSYS.................................................... 24
5.2.2 Installation of MinGW 32-bit and 64-bit Toolchains ............................... 27
5.2.2.1 Adding MinGW to the PATH............................................................... 27
5.2.2.2 MinGW 'make' ...................................................................................... 28
5.2.2.3 Completion and test of MSYS/MinGW installation............................. 28
5.2.3 Checking Imperas tools and OVPsim Installation .................................... 32
1 Preface
This document describes how to install the Imperas Professional products, Advanced
Multicore Software Development Kit (M*SDK) and Virtual Platform Development and
Simulation (C*DEV, S*DEV and M*DEV), and the Open Virtual Platforms OVPsim
simulator on both Windows and Linux computers. The installation includes tools,
models, documents and examples.
This document further introduces how to compile applications using the supplied
example GNU cross compiler toolchains/tool kits and how to use this binary with a
virtual platform.
Please see other documents that explain how to create platforms / harnesses, processor
models, and peripheral / behavioral models.
2 Introduction
This installation guide is for the installation of the OVP or Imperas Professional products
on a Linux or Windows host computer. We will need the installation files of either
OVPsim from www.OVPworld.org or the Imperas products from www.Imperas.com, and
at least one example compiler toolchain, also from www.OVPworld.org.
Imperas products are provided as two installation packages Imperas_SDK for M*SDK
and Imperas_DEV for C*DEV, S*DEV and M*DEV (configured on installation or
post-install with configuration script).
In order to build native host executables and to cross compile applications under
Windows, we suggest the installation of an MSYS/MinGW 1 environment
www.mingw.org. See section 5 for instructions on setting up this environment. This will
make compilation of Applications, Models and Platforms / Simulation harnesses simple.
Part of the installation includes examples files and these will be used to illustrate the
processes and tools used to get your applications running on virtual simulation platforms.
In this document, we will use the openCores openRISC OR1K as the target embedded
processor.
1
It is also possible to use a Cygwin / MinGW environment but care must be taken to ensure that the
MINGW GNU toolset is used.
3.2 Hardware
The product is developed to work on x86 hardware.
2
This is only supported by the Imperas installations, Imperas_SDK and Imperas_DEV.
3
The Imperas 32-bit products are also supported in emulation mode on 64-bit hosts.
4
The disk space indicated is per package install or toolchain install. The actual disk space required is
dependent upon the type and number of packages or toolchains installed.
5
The Windows 32-bit ABI changed at release 4.6 which introduced incompatibilities in the Windows ABI.
The OVP products are compiled with the legacy ABI.
4 Installation
The Imperas professional products and the OVPsim simulator may be installed on a
Linux or Windows platform.
Section 4.1 provides specific information regarding the product packages. The details of
the package installations are the same and are shown for Linux users in section 4.3, and
Windows users in section 4.4.
Different major versions of the software should not be installed on top of each other. The
new installation should either be made into a different directory or the old version
uninstalled before the new version is added. For this reason you should avoid making
changes to files in the installation directories, as those changes will be lost when the
version is un-installed and a subsequent version is installed.
Different minor versions may be installed together; later minor versions typically provide
updates to products.
4.2.1 Login
The OVPworld download page can only be accessed when you are registered and logged
into the sites forums. Please register (can take up to 24 hours to receive authorization
email) and be logged in from the forums page before continuing.
Imperas customers should go to Imperas.com and select user login. This accepts the same
username and password as the OVPworld.org site. This will take you to the Imperas User
Home Page. Click on Imperas Product Downloads Imperas link (or Beta if you require an
updated pre-release version to download) and you will be requested to enter your Imperas
user name and password, which should have been provided to you by Imperas. The
imperas user area also provides 64-bit versions of the OVP packages via the OVP link.
See APPENDIX C Accessing Imperas User Area for additional information
accessing the Imperas User site and downloading packages.
To download the Imperas professional tools or the Imperas development tools after
logging into the Imperas Product Downloads area select the product you wish to
download (Windows or Linux).
The Linux versions are provided as pre-built binaries in a self extracting executable file,
either the
Imperas SDK as Imperas_SDK.<version>.<dot release>.Linux32 6 .exe
Imperas Developer as Imperas_DEV.<version >.<dot release>. Linux 32.exe
OVPsim as OVPsim.<version >.<dot release>. Linux 32.exe or
OVPsim. Linux32.exe (for current version from www.OVPworld.org)
4.3.1 Installing
Execute the self extracting executable file to install. You may need to change the installer
to be executable first:
The self extracting executable will install the files in the current directory or in a selected
directory:
Or
You will be asked to accept a license agreement. It should be read and, if acceptable,
agreed to by typing yes at the prompt. For example:
Software License Agreement for Imperas Proprietary Software
Imperas Limited.
---------------------
You are not allowed to use this software without a specific signed license
agreement.
Imperas_Software_License_Note (v.1.0)
6
This shows the release for a Linux 32-bit host, Linux 64-bit hosts are supported and available from
Imperas.
Once the license agreement has been accepted the Imperas tools or OVPsim you will be
prompted for the directory to install into:
Install into directory <current directory>/Imperas.<release major version>
yes/no >
If you reply yes, the installation will carry on into the current directory. If you reply no,
you will be prompted for a directory to install into:
The Linux binary executables and shared objects are provided in the directory:
<installDir>/Imperas.<major version>/bin/Linux32
A script is provided to install a function to setup the environment in which to run the
Imperas tools. The script is provided in the bin directory below the Imperas installation
directory. This script should be sourced in a bourne shell to provide the function
setupImperas, which is then executed passing the full path to the Imperas directory as the
argument.
One of the environment variables set is IMPERAS_RUNTIME which is used to select the
simulator to be loaded, the normal settings are either CpuManager for the Imperas
Professional simulator or OVPsim for the OVP simulator.
This environment variable may be set prior to running this function. If not set the
setupImperas function will set the environment variable in accordance with the installed
files i.e. if the Imperas simulator, CpuManager, is available it will set the
IMPERAS_RUNTIME to CpuManager; if not found it will default to the OVPsim
simulator, OVPsim.
When running a 32-bit product on a 64-bit host or when using some of the OVP
toolchains, that are only provided as 32-bit executables in the 64-bit package files, you
will need to have 32-bit compatibility libraries on the 64-bit host machine.
To find out information about your specific host operating system and installing
compatibility libraries search the internet for "install 32 bit compatibility libraries linux".
4.3.2.2 Environment
The following environment variables are used by the OVP simulator or Imperas
professional tools:
IMPERAS_PROXY_SERVER Only required for Demo and Web licenses, if the internet is
accessed through a proxy server, this should be set to the value
<hostname>:<port>, e.g. myproxyserver.com:3128
Create an environment variable IMPERAS_HOME pointing to the root of the Imperas tree, for
example:
Create an environment variable IMPERAS_ARCH for the current architecture, for example:
Create an environment variable IMPERAS_SHRSUF for the current architecture, for example:
Create an environment variable IMPERAS_VLNV pointing to the root of the Imperas library,
for example:
If you have a license for OVPsim then this may be left unset (as this is the default value)
or set to:
Add the Imperas executables directory to the search path, for example:
> export PATH=${PATH}:$IMPERAS_HOME/bin/$IMPERAS_ARCH
Add Imperas shared library directories to the variable LD_LIBRARY_PATH, for example 7 :
> export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:$IMPERAS_HOME/bin/$IMPERAS_ARCH:\
$IMPERAS_HOME/lib/$IMPERAS_ARCH/External/lib
These commands should be added to a shell start up script, e.g. ~/.bashrc, or must be
executed some other way before the tools are used.
If you are installing one of the Developer products (C*DEV, S*DEV or M*DEV) from
Imperas you will need to setup the environment variable IMPERAS_PERSONALITY for the
correct type. This can be achieved by directly using the script
IMPERAS_HOME/bin/selectSimulator.sh.
Next, you must also set up licensing for the program. This is described for both Linux
and Windows installations in section 4.5.
7
This is all one command; note the use of the Linux line continuation character \ at the end of the first 2
lines
8
This shows the release for a Windows 32-bit host, other Windows hosts are supported by Imperas.
The installer, when executed, will extract the tools and setup the environment. Remember
to uninstall any existing versions before installing. An uninstall program, uninstall.exe
is provided in the root install directory (i.e. <installDir>\uninstall.exe, e.g.
C:\Imperas\uninstall.exe)
4.4.1 Installing
1. Execute the provided installer 2. Read and click through the license agreement
5. When completed click Finish 6. Finally, read the notes for this release.
IMPERAS_PROXY_SERVER Only required for Demo and Web licenses, this should be set to
the value <hostname>:<port>, e.g. myproxyserver.com:3128
The environment variable IMPERAS_RUNTIME may be set. If the Imperas tools are installed
then it will be set to CpuManager to select the Imperas simulator library to be loaded at
runtime. For OVPsim this variable will be set to OVPsim. It may be left unset and the
default value OVPsim will be used.
If you are installing one of the Developer products (C*DEV, S*DEV or M*DEV) from
Imperas you will be asked during installation which product that you have had licenses
provided for. This will set the environment variable IMPERAS_PERSONALITY for the correct
product personality. This can be also be achieved after installation by directly using the
script IMPERAS_HOME/bin/selectSimulator.bat or using the select product link provided on
the Program Start menu.
You must also set up licensing for the program. This is described for both Linux and
Windows installations in section 4.5. You may wish to install the preferred Windows
development environment, MSYS. This is described in section 5 Windows Development
Environment.
computers host ID. To obtain a license file you must provide the host ID and host name
of one of your computers that will host the license.
NOTE
Running the Imperas license server within a virtual machine is not permitted.
NOTE
If the returned host ID is "000000000000" then this may be because you are using an OS
which uses Consistent Network Device Naming. Please see appendix F.5 for ways in
which this problem can be resolved. A license cannot be generated for a NULL host ID.
The host name of the computer can be obtained with the hostname command. From a
Linux shell or a Windows Command Prompt/MSYS window do the following:
> hostname
Workstation123
>
Floating licenses require that a license server is executed on a machine that will be used
to serve licenses to clients. The license server, lmgrd (lmgrd.exe on Windows) is
provided in the binary directory of an installation. See section
OVPsim and iGen look, by default, for their license file in:
$IMPERAS_HOME/OVPsim.lic
If the license file is installed there then there is no need to do anything else. If it is
installed elsewhere then the IMPERASD_LICENSE_FILE environment variable 9 should be set
to point to it.
OVPsim license key files are to a specific version (release) of OVPsim/iGen, with a
license feature entry similar to that shown below.
You will need to obtain a new license file when you install a new version of the
simulator. Since it is tied to the release, it is OK to place it in the release directory.
License key files that are not tied to a specific release should not be placed in the install
directory, as that directory will be replaced when a new release is installed.
NOTE
When using an OVPsim license the simulator product will also require access to the
internet to allow checking for product updates. Without internet access an error will be
reported.
9
For information on setting the environment variable on Windows please see appendix
The Imperas license daemon (imperasd) must be run on the license server using the
FLEXlm tools. The FLEXlm lmutil tool and the Imperas daemon are provided in the
$IMPERAS_HOME/bin/$IMPERAS_ARCH directory. The daemon can be started using the
following command on the license server:
The license server can also be run on Windows using the LMTOOLS utility. Additional
information for getting a license daemon running on a license server can be found in
APPENDIX E, Additional FLEXlm Licensing Information.
Once you have your license server running, the computer from which the tools are run
needs the IMPERASD_LICENSE_FILE environment variable to be set to an @ followed by
the host name of the license server, for example:
IMPERASD_LICENSE_FILE=@serverhost
where serverhost is the host name of the license server. (See the respective installation
instructions for Windows and Linux for examples of how to set an environment variable.)
In this example we assume that the default port (27000-27009) is being used by the
license server. If the license server was set up to use a different port for some reason it
must be specified before the @, for example:
IMPERASD_LICENSE_FILE=27000@serverhost
Here, 27000 is the port number that the license server is using. Consult your license
administrator or see APPENDIX E, Additional FLEXlm Licensing Information, for more
information.
It is recommended that the latest version of MSYS be obtained from the mingw website
and the MinGW cross compilers taken from the version saved to the OVP World website
resources page.
Click on the link, Download mingw-get-setup.exe (86.5 kB), after the text looking for the
latest version? to start the download of the installer.
This will download a small executable which we will then use to download and install the
MSYS installation.
The installer can install all of the MSYS and MinGW components, we want to install
only the MSYS Base System. Select the "Basic Setup" option and select 'msys-base' for
installation.
This will start the download and installation of the MSYS base system
When the installation has completed you will have a MinGW directory containing the
basic MSYS installation:
The files may be found on the OVPworld.org website under the Resources tab. There are
two zip files containing the 32-bit and 64-bit toolchains respectively.
mingw-w32-bin_i686-mingw_20111031_sezero.zip
mingw-w64-bin_i686-mingw_20111031_sezero.zip
Download the appropriate one for your host (32-bit or 64-bit) and we recommend
extracting into a directory, for example C:\MinGW_Toolchains, separate to the root of
the MSYS/MinGW installation in the previous section, C:\MinGW. This will create
mingw32 and mingw64 directories respectively.
Select the Windows control panel and get to the advanced system setting and the
environment setting within it.
10
These versions of the toolchains are used within Imperas and so are know to work with the provided
build environment.
It is important that the correct version of make is used when using Makefiles in the
Windows build environment.
In the MSYS shell it is possible to invoke make, using one of the shell scripts supplied by
Imperas in the Demo or Example directories or directly but this may not use the correct
version. By default the Cross Compiler toolchains provide 'gmake.exe' and ' mingw32-
make', they do not provide 'make.exe' so this is often either not found or the incorrect
version found.
If not, create your own desktop shortcut by locating the msys.bat file in the installation at
C:\MinGW\msys\1.0\msys.bat and create a shortcut and move to your desktop.
Start the MinGW shell and then type ls and pwd in it to check all is ok and working.
If you already have an OVPsim or Imperas installed try env | grep IMP which should
show that the Imperas environment has been configured.
With any of the OVPsim, Imperas_SDK or Imperas_DEV packages installed and the
or1k.toolchain package installed you can try running the Example
Imperas/Examples/HelloWorld/usingICM that will ensure everything is available and
correctly installed.
In the following screen shot we show the execution of the example using the script
example.sh. Below we further describe each section separately
Build the application, setting CROSS to the Cross Compiler toolchain we are using. In
this case we set CROSS=OR1K to utilize the installed cross compiler toolchain for the
OR1K processor, OR1K.toolchain.
In this next screenshot we attempt to build the platform using the supplied Makefile,
Makefile.platform (provided, with other standard Makefiles in
IMPERAS_HOME/ImperasLib/buildutils).
We specify that we will build locally and not use the VLNV library structure by setting
NOVLNV=1.
make -f ${IMPERAS_HOME}/ImperasLib/buildutils/Makefile.platform \
NOVLNV=1 clean all
As you can see the platform cannot be built because the host GCC (x86_64-mingw32-gcc
as we are running on a 64-Bit Windows 7 host machine) cannot be found. This is because
we have not setup the PATH environment variable.
We can setup the PATH environment variable in the shell. Below we show the addition
of the bin directory for the 64-bit Host GCC to the PATH.
export PATH=$PATH:/c/MinGW_Toolchains/mingw64/bin
We are now able to re-invoke the same make command and build the platform
We can now run the OVP virtual platform. the simulator loads the OVP Fast processor
model (and any other model or semihost libraries required), loads an application into
memory and uses the processor model to execute the binary code.
11
This should provide us with 4 environment variables shown here with their default values
IMPERAS_HOME=C:\Imperas
IMPERAS_UNAME=Windows
IMPERAS_ARCH=Windows32 12
IMPERAS_SHRSUF=dll
IMPERAS_RUNTIME=OVPsim
11
The execution time was extended from the application provided so that statistics would be reported fully.
12
This will be Windows64 if you are installing one of the Windows 64-bit products
IMPERAS_VLNV=C:\Imperas\lib\Windows32\ImperasLib
$ echo $PATH
/c/Imperas/bin/Windows32 13
If you installed, OVPsim or the Imperas tools, in a different directory to the default, then
these variables will be changed accordingly.
These environment variables are used by the Makefiles whilst compiling applications,
models and platforms / simulation harnesses for the OVP and Imperas tools.
IMPORTANT
We have observed that when other packages are installed in the MSYS environment the
msys.bat file used to start up the shell may be modified such that the PATH variable is
restricted to the MINGW and MSYS paths. If you find that the PATH environment
variable does not contain your full PATH, find the bat file executed from the msys link
and if MSYSTEM is set to MINGW32 please remove.
13
This will be Windows64 if you are installing one of the Windows 64-bit products
Using the Cygwin GNU toolset generates executables and DLLs that will reference and
be reliant on the Cygwin DLLs. This will create executables and DLLs that are not
portable and therefore not compatible in other environments. There are compatibility
issues even between different versions of Cygwin.
We should modify the path so that the MINGW GNU tools appear before the Cygwin
tools.
We can see now that the GNU tools are being found from the MINGW installation before
the Cygwin.
Note that this installation of MINGW has been made under an MSYS installation.
Note that when creating Makefiles or scripts to build executables and DLLs it is often
useful to use MINGW specific names of the GNU tool executables. These appear in the
mingw/bin directory as, for example, mingw-gcc.exe. By doing this you will guarantee
that you do not inadvertently pick up the Cygwin tools. There are mingw-* named copies
of all the GNU tools.
There is a utility cygpath that will convert a Cygwin path into a native windows path.
This may be used to give the correct path for the MINGW GNU tools.
cygpath w $(pwd)
Unfortunately this cannot be used in conjunction with the Makefile system provided with
the OVPsim examples because the Windows native path contains a : which is a special
character when used in Makefiles!
The OVPsim examples are all verified for use in the MSYS environment.
> cp r $IMPERAS_HOME/Examples/PlatformsICM/simple_MSVC_compile .
To compile using MSVC the setup program must be invoked that is provided with MSVC
to start a shell with an appropriate environment. This is typically called a Visual Studio
2008 Command Prompt
A script in the platform directory, compile.msvc.bat, contains the following command
line that is used to build using nmake and the Makefile provided.
Note that for completeness this example can also be built in a Linux shell or in a MinGW
shell on Windows by using the following command in the platform directory:
The result is an ELF format file for the OR1K called asmtest.OR1K.elf.
platform/platform.${IMPERAS_ARCH}.exe application/asmtest.OR1K.elf
This message is printed by the imperasExit semihosting library as the processor executes
the first instruction at exit in the application.
IMPORTANT
The Cross Compiler and Peripheral Simulation Engine toolchains are provided only as
32-bit native executables. This requires that a 64-bit host must provide a 32-bit
compatibility mode in order that they can execute. The packages they are provided in are
labeled as 64-bit packages, for example Linux64 only to indicate that they support a
64-bit Imperas or OVPsim installation.
NOTE
The Cross Compiler toolchains are provided to allow a user to quickly start generating
application binary code that can be executed on OVP processor models.
It is expected that after the initial experiments a cross compiler toolchain will be selected
from a cross compiler supplier.
Some processors and processor variants are not supported by the cross compiler
toolchains available on the OVPWorld website and alternatives are indicated to download
and install.
Also as part of these cross compiler toolchains is a Makefile to provide a default build
environment for an application onto a processor. The Makefiles are found in the directory
IMPERAS_HOME/lib/IMPERAS_ARCH/CrossCompiler in the format
<Processor Type/Variant>.makefile.include, for example MIPS32.Makefile.include.
Each cross compiler toolchain should be installed into the current installation of Imperas
Professional or OVPsim.
14
The Imperas website provides the same installers but also for 64-bit host computers.
This toolchain should be installed into the current installation of Imperas tools or
OVPsim.
7 Getting Started
The following should be carried out in a Linux shell or on Windows an MSYS shell,
some scripts may be executed on Windows by double clicking in the explorer browser.
For example, execute the Fibonacci benchmark on a single core OR1K platform.
Change to the directory (the following assumes a Linux or MSYS shell is used).
> cd $IMPERAS_HOME/Demo/Processors/OPENCORES/or1k/generic/single_core
> Run_Fibonacci.sh
If Windows explorer is used, change to the directory and double-click the corresponding
.bat file.
This should provide an output similar to that shown below, for an OVPsim installation:
Info ---------------------------------------------------
Info CPU 'iss/cpu0' STATISTICS
Info Type : or1k (generic)
Info Nominal MIPS : 100
Info Final program counter : 0x1948
Info Simulated instructions: 1,563,699,833
Info Simulated MIPS : 1373.1
Info ---------------------------------------------------
Info
Info ---------------------------------------------------
Info SIMULATION TIME STATISTICS
Info Simulated time : 15.64 seconds
Info User time : 1.14 seconds
Info System time : 0.00 seconds
Info Elapsed time : 1.15 seconds
Info Real time ratio : 13.55x faster
Info ---------------------------------------------------
NOTE
The Imperas ISS used in this example is provided in two different executable programs,
as iss.exe and issdemo.exe. The demo scripts use the environment variable
IMPERAS_ISS that selects which to run. The environment variable is setup as part of the
installation setup scripts. iss.exe is compiled with licensing that uses the default OVPsim
or Imperas simulator license features. issdemo.exe does not require a license but can only
be executed with access to the internet.
This should start iGen with the help output similar to that shown below:
flag short argument description
diagnostics
--apropos command Show igen commands similar to the given argument
--help -h Print list of flags
--showcommands Show all igen commands
input
--batch -b filename Execute this tcl file
--batchargv argument Argument to --batch file
--checkmodels Load and check models when writing a platform
--modellibrary string Processor VLNV library
--modelname string Processor VLNV name
--modelvendor string Processor VLNV vendor
...
To see more about videos, examples etc. for the OR1K look at the OR1K model variant
page: http://www.ovpworld.org/processor-model-variant-opencores-or1k-generic.
The version of the toolchain available is the same as the version of the Imperas tools or
OVPsim available. When extracted they should be installed into the same directory. For
example, into the directory <installDir>/Imperas.<major version> on Linux.
On Linux, the standard toolchain provided with the Linux installation is used.
For our first compilation/run we will use one of the provided 'hello world' examples.
There are a number of different ways of building a platform and controlling a simulation.
In the example above we used the ISS to run the OR1K Fibonacci example. The ISS uses
the model library and allows a binary cross compiled elf file to be run on a processor
model variant without you defining a platform at all. It is the simplest way to run and
debug software.
If you need to model a platform, then there are several ways to create that platform.
If you look in the Examples/HelloWorld directory there are some simple examples:
> ls $IMPERAS_HOME/Examples/HelloWorld
usingHarnessExe usingHarnessInC usingISS usingSystemC
> cp r $IMPERAS_HOME/Examples/HelloWorld/usingISS .
> cd usingISS
In this directory you should see an application directory with a file application.c, which
can run on this platform, and a Makefile for building the application.
> cd application
> make
If you see the following the toolchain has not been installed or it has not been installed
into the current release that is being executed. (Install the toolchain now.)
Makefile:12: *** "Please install the toolchain to support OR1K ". Stop.
> make
Compiling application.c
Linking application.OR1K.elf
rm application.o
This cross compilation of the application for the OR1K processor, will produce a file
called application.OR1k.elf.
> cd ..
NOTE
The Simulated MIPS figure provides an indication of how many millions of instructions
the simulator was able to run on your host machine per second. You will get the message
run too short for meaningful result if the simulated time is less than a second.
> ./example.sh
...
> cp r $IMPERAS_HOME/Examples/HelloWorld/usingHarnessExe .
> cd usingHarnessExe
In this directory - there is the application - as in the previous example. So compile it up:
> cd application
> make
> cd ..
> cd module
> ls
and we will see there is a module.op.tcl file and a Makefile. The module.op.tcl is the
definition of the platform using iGen input script commands.
> make
# iGen Create OP MODULE module
# Host Depending obj/Windows64/module.d
# Host Compiling Module obj/Windows64/module.o
# Host Linking Module object model.dll
and if you now list the directory, you will see several .c/.h files created by iGen. These
are normal C files that make use of the standard OVP OP API that creates platforms. For
examples of platforms/modules written directly in OP, please refer to:
Writing_Platforms_and_Modules_in_C_User_Guide.pdf
Also, please look at the iGen section in doc/ovp/index.html. iGen is a platform and
model building wizard/productivity tool to make it very easy to create platforms/models.
The running of the Makefile has created the module/model.dll that is a binary
representation of the input .c/.h that was created by iGen from the input .tcl file. This
module/model.dll can be used in other platforms/modules (as part of a system/subsystem
hierarchy), or it can be simulated directly using the provided harness.exe program:
> cd ..
> harness.exe --modulefile module/model.dll
--program application/application.OR1K.elf
...
OVPsim started: Wed Mar 23 12:00:23 2016
You can see what control options are available in the harness.exe by using the help
option:
Again there is a script to compile the application, module and run the harness.exe:
> ./example.sh
The OVP OP API provides many powerful functions to control a simulation. There are
many examples of this in the Examples/SimulationControl directory and there are two
documents which provide many common use cases
Simulation_Control_of_Platforms_and_Modules_User_Guide.pdf
Advanced_Simulation_Control_of_Platforms_and_Modules_User_Guide.pdf
> cp r $IMPERAS_HOME/Examples/HelloWorld/usingHarnessInC .
> cd usingHarnessInC
This has an application directory and module directory as in the previous examples. What
is new is the harness directory:
> cd harness
> ls
harness.c Makefile
The harness.c is a regular C program that uses calls to the OVP OP API to control the
simulation of a module. Please refer to the documents mentioned above for information
on the OP API calls etc.
As in previous examples, for convenience a script it provided to compile and run the
complete example:
> ./example.sh
...
# Compiling application.c
...
# iGen Create OP MODULE module
...
# Host Linking Harness harness.Windows64.exe
...
OVPsim started: Wed Mar 23 12:21:06 2016
A semihost library may replace a function in its entirety to provide that function itself, for
example the function _write, which sends a character from a buffer to a hardware device
output register, may be intercepted and replaced by a semihost function that takes the
character from the buffer and displays it on the host stdout.
performed at the low level function level, as defined in the .intercept table of the semihost
file mips32Newlib.c in the VLNV library.
Example ARM Linaro cross compiler toolchain used armAngel semihost library.
The C library used in the application compilation in this case is specified by a specs file,
aprofile-ve.specs. This controls the C library included. The semihosting is performed at
the instruction level, as defined in the armOSOperation function of the semihost file
armAngel.c in the VLNV library.
The typical simulation statistics is shown below. Most entries are self explanatory but are
described in the following sections
Info ---------------------------------------------------
Info CPU 'platform/cpu0' STATISTICS
Info Type : arm (Cortex-A9UP)
Info Nominal MIPS : 100
Info Final program counter : 0x4b8
Info Simulated instructions: 22,400,008,761
Info Simulated MIPS : 5720.7
Info ---------------------------------------------------
Info
Info ---------------------------------------------------
Info SIMULATION TIME STATISTICS
The model type and, if selected, the configuration variant are displayed. The nominal
MIPS for the processor model, by default, is 100 MIPS. This has an effect when running
with 'wallclock' enabled or when in a multi-processor system. With 'wallclock' enabled it
is used to control the maximum execution performance i.e. only 100 million instructions
will be executed in a real time 1 second. In a multi-processor system (without wallclock
enabled) it provides an execution ration between processors e.g. a 200 MIPS processor
will execute twice the instructions as a 100 MIPS processor in a simulation unit of time.
The 'Simulated instructions' will vary depending upon the application being executed, this
count indicates the number of simulated processor instructions for the processors in the
platform. The final program counter can be useful as an easy way of showing the
application program executes in a deterministic way over a number of simulation runs.
Simulated MIPS
The 'Simulated MIPS' will be a measure of the number of 'Simulated instructions' over
the host elapsed time and is an indication of the performance of the simulator.
The simulated time is the time it would have taken to run the application based upon the
MIPS configuration of the processor and the number of instructions the application took
to complete.
The time fields are real time information from the native Host machine relating to the
simulator execution.
The "real time ratio" is an indication of how much quicker the simulator was able to
execute the processor instructions than the real silicon based upon the OVP Fast
processor model MIPS rate configuration and the time the simulator took to execute the
instructions on the native host machine.
1. Morphing cross compiled target instructions (for example ARM Cortex-A9, MIPS
1074Kc, V850) to a sequence of native host instructions
2. Executing the sequence of native host instructions to provide the behavior
expected of the target
In 1 we are executing in 'morph time' using the translations specified by the OVP
processor model. During the translation process, each instruction is read from the virtual
platform memory using a debug (artifact) transaction. This access must have no effect on
the system and must be implemented as a 'back door' access that bypasses any behavior
of the system; including timing or delays that may be in a SystemC TLM2 virtual
platform implementation.
The code morpher will continue reading instructions and morphing code until it has
constructed an entire 'code block'. This may be a few or many instructions.
Once a code block is created, the block is executed. We are now in 2, in 'run time', for
each target instruction behavior, a) the instruction is reread from memory - but this time
as a 'real' transaction that will have an effect on the system that the fetch would normally
have and b) the native code is executed to create the behavior.
There is also generic OVP processor interface code that is provided in the installed
component source library.
The component VLNV source library is found at IMPERAS_HOME/ImperasLib/source,
with the V/L/N/V of the TLM2.0 support models
ovpworld.org/modelSupport/tlmProcessor/1.0 containing the interface file
tlm2.0/tlmProcessor.cpp
In this file you will find the function icmCpuMasterPort::readUpCall that will perform a
TLM2.0 read (fetch) transaction by calling either socket->b_transport() for a 'real' access
or socket->transport_dbg() for a 'debug' (simulation artifact) access.
IMPORTANT NOTE
The SystemC virtual platform must provide both debug and real interface connections.
In addition to the product installation packages above are a number of installers providing
specific demonstrations and example toolchains to be used in compilation of peripheral
models and cross compilation of processor application code.
These include
1. Verification, Analysis and Profiling (VAP) tools
2. Multicore debugger for debugging of applications running on processor
models and peripheral models in a unified environment
3. M*SIM professional simulator
4. Imperas Generator Wizard (iGen) for generating virtual platforms and model
(processor and peripheral) templates
5. Model Library
6. Examples and Demonstrations
These include
1. M*SIM professional simulator
2. Imperas Generator Wizard (iGen) for generating virtual platforms and model
templates
3. Model Library
4. Examples and Demonstrations
16
The Standard Developer simulator configuration provides similar capabilities to the OVPsim simulator.
These include
1. OVPsim reference simulator
2. Imperas Generator Wizard (iGen) for generating virtual platforms and model
templates
3. Model Library
4. Examples and Demonstrations
Name
e-mail address of the person responsible for the Imperas/OVP Tools
Phone number
Company Address
Host id 17
Host Name of the machine running the license server
Type (Linux, Windows)
17
This is the FlexLM information obtained using the lmutil(.exe) that is installed with all packages. See
section 4.5 Setting up Licensing (Both Windows and Linux)
After installing the OVPsim or Imperas packages the license server, lmgrd, and the
Imperas license daemon, imperasd, can be found in the binary installation directory.
$IMPERAS_HOME/bin/$IMPERAS_ARCH/lmgrd.exe
$IMPERAS_HOME/bin/$IMPERAS_ARCH/lmgrd
In the case of a node-locked license, you will send Imperas/OVPworld the host name and
host ID of the computer that you will run the tools on. In the case of a floating license
you will need to choose one computer to be the license server and send the host name and
host ID of that computer to Imperas/OVPworld to obtain your license. Note the license
server may be the same computer you run the tools on.
In addition a license may be uncounted, which means that any number of copies of the
program may run simultaneously, or it may be counted which means that only a specified
number of instances of the program may be active at one time.
You can tell if a license feature is uncounted by looking for the word uncounted
following the expiration date of the feature.
If a license contains only node-locked, uncounted features then you only need to set the
environment variable IMPERASD_LICENSE_FILE to point at it, e.g.:
IMPERASD_LICENSE_FILE=~/Imperas/license.lic
See the respective installation instructions for Windows and Linux for examples of how
to set an environment variable.
Here we see SERVER, VENDOR and USE_SERVER lines in addition to the FEATURE
lines we saw in an uncounted node-locked license. Also, after the expiration date on the
FEATURE lines we see 5 instead of uncounted indicating this is a counted license.
When either of these is true a license server will be required.
<host name> should be the host name of the license server. This can be edited if it is not
correct.
<host ID> is the host id of the license server. This cannot be changed without
invalidating the license file. The license server must be the computer with this host ID.
{<port>} is an optional integer value which specifies the port the server communicates
through. It should usually be left blank, in which case a port in the default range of 27000
2016 Imperas Software Limited www.imperas.com/www.OVPworld.org Page 64 of 92
.
Imperas Installation and Getting Started Guide
to 27009 will be used. If it is specified in the license file then the same value must be
specified on the IMPERASD_LICENSE_FILE environment variable on the computer running
the target program.
Where license.lic is the name of the license file which must be able to be read from the
license server and license.log is the name of a file where the license manager will write
informational and debug messages.
The license server may also be started in a foreground mode by adding the -z switch
If the license server is a different computer than you installed the tools on, you may want
to copy the license manager tools and the daemon file from
$IMPERAS_HOME/bin/$IMPERAS_ARCH to the license server. The license tools all start with
lm and the daemon file is named either imperasd or imperasd.exe.
The lmgrd command will need to be re-run every time the license server is rebooted.
On Windows it can be started as a service each time the computer is rebooted. The
command lmtools will start a GUI program where you can configure the windows lmgrd
service from the Config Services tab.
where serverhost is the hostname of the license server. The command hostname may be
used on both Windows and Linux to find out the host name of a particular computer. This
example assumes that the default port (27000-27009) is being used by the license server.
If the license server was set up to use a different port it must be specified before the @,
for example:
IMPERASD_LICENSE_FILE=9999@serverhost
Here, 9999 is the port number that the license server is using.
See the respective installation instructions for Windows and Linux for examples of how
to set an environment variable.
Also, FLEXlm supports many different options to control how licenses are managed than
are discussed her. If you need to use any of those additional capabilities please consult
the FLEXlm End Users Manual.
Searching the internet for FlexLM End Users Manual should locate a copy of this
manual.
To make FLEXlm use an options file, either specify the full path to the file in the license
file or name the file 'imperasd.opt' and place it in the same directory as the license file.
Each line of the options file controls one option. The most commonly used options are:
where featurename is the name of the feature as specified in the license file, type
is normally USER, HOST or GROUP, and name is the name of the user or group
to exclude.
INCLUDE feature[:keyword=value] type {name | group_name}
This option is the same as EXCLUDE but allows a user to use a license feature,
but note, if any INCLUDE lines are used then one must be provided for each user
who will use the license.
where num_lic is the number of licenses to be reserved, and the other variables are
the same as for EXCLUDE.
For a list of other options please consult the FLEXlm End Users Manual.
Searching the internet for FlexLM End Users Manual should locate a copy of this
manual.
lmutil lmremove - most commonly used to remove licenses that are still checked out after
a node crashes.
lmremove will remove all instances of the specified feature by the given user on
host.
lmutil lmreread - make the license daemon reread the given license file.
This will start any new daemons that have been added and cause currently running
daemons to read their license files again.
2. Click the Configuration using Services button, and then click the Config Services
tab.
3. In the Service Name, type the name of the service that you want to define, for
example, Imperas License Manager. If you leave this field blank, the service will be
given a default name.
4. In the Path to the lmgrd.exe file field, enter or browse to lmgrd.exe for this license
server.
5. In the Path to the license file field, enter or browse to the license file for this license
server.
6. In the Path to the debug log file, enter or browse to the debug log file that this license
server writes.
4
5
6
This will have occurred in the call to icmInitplatform() when the licensing is initialized.
The latest version of the FlexLM licensing code utilized by the OVP and Imperas
products contains a feature that causes a segmentation fault when attempting to run under
a debugger.
This has no effect on the execution of the OVP virtual platform and it is possible to
continue the simulation and debugging the platform beyond this point. Simply continue
the simulation.
The following is the contents of an example .gdbinint script that may be used to ignore
this issue
The OVP and Imperas simulators also may use of the floating point exceptions during
simulation, these may be ignored when debugging by adding the following
Imperas including a test case 18 that can be used to reproduce the problem at the Imperas
site.
However, often these problems are caused when the simulator is being used incorrectly.
If this procedure is not followed the asynchronous calls can cause the simulator to be
interrupted during a system state update and hence the state can become corrupted.
When this occurs it is typical to see the following assertions reported by the simulator and
for the simulation to terminate.
/c/Imperas/Examples/Models/Peripherals/creatingDMAC/1.registers
$ mingw32-make NOVLNV=1
C:/Imperas/ImperasLib/buildutils/Makefile.pse:39: *** missing `endif'. Stop.
/c/Imperas/Examples/Models/Peripherals/creatingDMAC/1.registers
$
You can check the version of mingw32-make that you have installed with the command
mingw32-make --version
18
A test case should include the virtual platform source code, the application code being executed and clear
instructions of how to reproduce the problem. All these files should be sent as a zip or tar file. It is useful to
extract the files and check in a clean directory that the instructions sent can re-produce the problem.
$ mingw32-make --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
F.4 Licensing
You have not got the correct license FEATURE available in your license file.
In the above output you can see that the simulator first attempts to obtain the license
feature IMP_OVPSIM and then attempts to obtain the license feature
IMP_OVPSIM_20130630.
The feature IMP_OVPSIM may be obtained by contacting Imperas, this is a license that
can be used with any version of the OVPsim simulator.
The feature IMP_OVPSIM_20130630 is contained in licenses generated from the OVP
World license page automatically. It is generated for the current product version and can
only be used with that product version.
2. The incorrect license file is being used or the license file has been corrupted
a. Check the IMPERASD_LICENSE_FILE variable is pointing to the
correct license file or license server for floating licenses
b. Check the license file has not been corrupted. Use a hex editor to ensure
only valid ASCII characters and <CR>, <LF> are present
3. The incorrect simulator is being used
a. The incorrect IMPERAS_RUNTIME has been set.
If your license(s) are supplied by Imperas for the Imperas tools, the
IMPERAS_RUNTIME should be set to CpuManager so that the correct
Imperas licenses are used.
4. The simulator personality is not set correctly
a. The correct runtime and IMPERAS_PERSONALITY has been set.
The CpuManager simulator can be set to support different feature sets
using the IMPERAS_PERSONALITY environment variable. This also
means that different license features are required. See section
For version locked licenses the simulator will access a date server. This error will occur if
the simulator is not able to connect to the internet.
You may get this if you are using an internet proxy server. In this case you need to inform
the Imperas products of the proxy server using the IMPERAS_PROXY_SERVER
environment variable. This is set to an <address>:<port> pair for the proxy server access.
For example
export IMPERAS_PROXY_SERVER=192.168.2.1:1234
Invalid host.
The hostid of this system does not match the hostid
specified in the license file.
Feature: IMP_OVPSIM_20100528.0
Hostid: 112233445566
License path: /home/Imperas.20130630/OVPsim.lic
FLEXnet Licensing error:-9,57. System Error: 19 "(null)"
For further information, refer to the FLEXnet Licensing End User Guide,
available at "www.macrovision.com".
The problem is caused by the FlexLM licensing used obtaining the MAC address, against
which the product is licensed, from the eth0 network interface.
If the network interface is enabled on a different device, e.g. eth1 the FlexLM software
does not read a valid MAC address and a NULL host Id is reported. This may be caused
because on modern operating systems Consistent Network Device Naming may be used,
see the following link for further information
http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
The solution is to enable the network interface on eth0 or to rename the network interface
to be eth0.
There are a number of ways this can be achieved, the following was taken from
http://www.science.uva.nl/research/air/wiki/LogicalInterfaceNames
http://unix.stackexchange.com/questions/81834/how-can-i-change-the-default-ens33-
network-device-to-old-eth0-on-fedora-19
The minimum set of stages that were required when performed are:
1. Edit /etc/default/grub. Note you need root privileges to edit this file.
2. At the end of GRUB_CMDLINE_LINUX line append "net.ifnames=0 biosdevname=0"
3. Save the file
4. type the command "grub2-mkconfig -o /boot/grub2/grub.cfg"
5. type the command reboot
One of the problems of Linux is that the order of the network interfaces is unpredictable.
Between reboots it usually stays the same, but often after an upgrade to a new kernel or
the addition or replacement of a network card (NIC) the order of all network interfaces
changes. For example, what used to be eth0 now becomes eth1 or eth2 or visa versa.
Obviously there is some logic to which network interface gets which name, but Linux
documentation states that this may change and no user or program should ever assume
anything about this. This is annoying, in particular if your management interface is at
eth1 at one node in a cluster and at eth2 in another node of the same cluster (which we
have experienced). I personally like to have my (primary) management interface always
to be eth0.
Thankfully, there are ways to achieve this. They can be divided in four methods:
1. Order the network interfaces based on physical properties of the NIC. (e.g. the physical
location in the machine)
2. Order the network interfaces based on the MAC address of the NIC.
3. Order the network interfaces based on the driver of the NIC.
4. Order the network interfaces based on the physical location of the NIC in the computer
So you have to pick a method that suits you. I recommend either to use ifrename (based
on physical properties, especially useful if you often change network cards in your hosts)
or writing a udev rule (based on the MAC address). However, I listed the other methods
as well. Be aware that the last two methods mentioned in this article are only for the
masochistic (you will scream and shoot to get those to work).
Note: Linux kernels up to 2.4 did only probe for the first Ethernet card, ignoring other
NICs. We assume you use a 2.6 or higher kernel or already fixed this, for example by
specifying ether=0,0,eth1 as kernel parameter.
Perhaps the most elegant way to name the Ethernet NIC is to do so based on their
physical properties, like link speed and port type.
It is possible to check the NIC properties using the ethtool program, and to change the
name using the ip program (thanks to Jollynn Schmidt for this tip):
The disadvantage of ethtool is that it can only be run by root, even when you're only
using it to query for information. Though this is a minor annoyance of ethtool, it does not
matter in this case, since you want to set a device name and thus need to be root anyway.
Secondly, it is also possible to name the network interface based on the MAC address of
each NIC. The advantage is that it is possible to use this method if you have two NICs
which use the same driver (unlike the next method: based on driver).
First, you must determine the MAC address of your interfaces. You can do this locally on
a machine running
ifconfig -a
The MAC address is listed as "hwaddr" (hardware address). Alternatively, you can even
determine MAC addresses remotely using ping and /sbin/arp.
There are three ways to map the MAC address to the logical interface name. Either by
using the udev rules, with the get-mac-address.sh script, or by using the nameif program.
The udev method should work on all recent Linux distributions, and is recommended.
The get-mac-address.sh script and the nameif program are know to work with Debian,
while on Red Hat, you can change the interface configuration file.
Now that you have udev, it is rather simple. You only need to create a udev rule mapping
the MAC address to the interface name. Store this in a file inside
the/etc/udev/rules.d/ directory:
KERNEL=="eth?", SYSFS{address}=="00:37:e9:17:64:af",
NAME="eth0" # MAC of first NIC in lowercase
KERNEL=="eth?", SYSFS{address}=="00:21:e9:17:64:b5",
NAME="eth1" # MAC of second NIC in lowercase
Most distributions already come with an example config file for you.
E.g. /etc/udev/rules.d/network-devices.rules or /etc/udev/rules.d/010_netinterfaces.rules.
More information can be found
at http://www.reactivated.net/writing_udev_rules.html or http://www.debianhelp.co.uk/
udev.htm. (Thanks to Casey Scott and Ron Hermsen for the pointers.)
SUBSYSTEM=="net", DRIVERS=="?*",
ATTRS{address}=="00:16:3e:00:02:00", NAME="eth0"
SUBSYSTEM=="net", DRIVERS=="?*",
ATTRS{address}=="00:16:3e:00:02:01", NAME="eth1"
I'm not sure about the difference between these rules. Information is welcome (please
leave a comment below)
DEVICE=eth0
HWADDR=00:37:e9:17:64:af
You can give it any DEVICE name you want, like DEVICE=ethmgmt, as long as you
remember to rename the config file:
/etc/sysconfig/network-scripts/ifcfg-ethmgmt
2016 Imperas Software Limited www.imperas.com/www.OVPworld.org Page 78 of 92
.
Imperas Installation and Getting Started Guide
Source: http://forums.serverwatch.com/showthread.php?t=18476
Source: https://www.gelato.unsw.edu.au/archives/gelato-technical/2004-
February/000334.html
The disadvantage of this method is that defines a mapping, rather then changing the
actual logical interface name.
The advantage of nameif is that you can specify the interface names in
the /etc/mactab file:
ethmgnt 00:37:E9:17:64:AF
ethwireless 00:21:E9:17:64:B5
and eth1 by using a temporary name (e.g. first rename eth1 to ethfoo, then eth0 to eth1
and finally ethfoo to eth0). Note that this method may lead to problems if you use
common names such as eth0 and eth1. If you upgrade a kernel, the names may be
different than you expected, and you may rename a NIC to eth0 while eth0 still exists,
leading to name collisions. Therefore, it is recommended to use other names like
"ethmgmnt", "ethwired", "ethwireless" and "eth10ge", as shown in the example above.
Warning: This only works if the driver is available as a loadable module. Not if it is built
into the kernel.
This is a relative easy method, since it does not rely on external scripts. The idea is to just
load the kernel module for your eth0 interface before the modules for other network
cards.
First of all, you must determine which driver is used for each network card. Thankfully
Linux does have a system to load the appropriate driver automatically, based on the PCI
ID of the network card. Unfortunately, there is no single command to simply get the
driver (and other information like the link speed) based on just the interface name in
Linux. Your best bet is to look for kernel messages:
This should give you a good estimate of the driver name. You can verify if the name
indeed does exist and is loaded:
lsmod
Note:
lsmod gave:
e1000 84868 0
tg3 70816 0
However, the 0 indicates that these drivers are not controlling any device! That is strange,
since modprobe -r tg3 and modprobe -r e1000 do disable the network cards. Apparently,
this is a flaw in lsmod.
Note that running modprobe tg3 en then modprobe e1000 does bring them up in the
correct order, with the correct interface names. This is a good check if this approach
(using the driver to decide the interface name) can work.
F.5.5.1 Debian
On a Debian system, /etc/modules.conf is generated automatically and should not be
edited directly. Instead, create a file in the subdirectory /etc/modules/ (do not
use /etc/modprobe.d/, that seems out-of-date). For example, create the
file /etc/modutils/interfaces and add the appropriate modules. For example:
update-modules
Alternative method: I have encountered scenarios where the kernel did already load the
modules for the drivers, even before /etc/modules.conf was read. The result was that in
effect, the specification in /etc/modules.conf was ignored, and this method did not work.
As an alternative, it is possible to also list the drivers, in the appropriate order,
in /etc/modules (thus not /etc/modules.conf):
tg3
e1000
The result will be that the tg3 driver is loaded before the e1000 kernel.
Since /etc/modules only exists for Debian, this trick will most likely not work for other
distributions.
Note: It is relatively hard to get this to work, and we encountered problems with it. The
other methods are recommended.
It is possible to name the network interfaces based on the interrupt (IRQ) and memory
address. This should work if you have network cards in PCI busses, and it involves
appending the proper parameters to the "ether=" or "netdev=" kernel parameters.
First of all, you can detect the PCI slot of the devices using
lspci -v
This is reported to fail sometimes for certain cards. Now, write down the IRQ and IO
(memory) address of each network card, and use this information to specify the interface
name in your LILO or GRUB configuration file.
For LILO, you need to add an add line to the appropriate boot configuration. For
example:
append="netdev=irq=21,io=0x2040,name=eth0
netdev=irq=20,io=0x3000,name=eth1
netdev=irq18,io=0x2000,name=eth2"
/etc/udev/rules.d/70-persistent-net.rules
If you would like control which interface receives a particular logical name, find the line
matching the interfaces physical MAC address and modify the value of NAME=ethX to
the desired logical name. Reboot the system to commit your changes.
Written by Freek Dijkstra. Licensed under public domain. (That is, feel free to modify,
redistribute, cripple, or even sell it as your own work, and there is no need to mention the
source, even though you are of course welcome to do so.)
This line will modify a Windows long filename format, to the short filename format, so
that in the Makefile, the default value of IMPERAS_HOME is modified from
IMPERAS_HOME = C:\Program Files\Imperas
to
IMPERAS_HOME = C:/PROGRA~1/Imperas
Thus removing the space separator, which would cause a problem for the make
program.
NOTE
It is recommended to install in a location that does not contain a space, for example the
default installation for Windows is C:\Imperas
include $(IMPERAS_HOME)/bin/Makefile.include
IMPERAS_LIB
This variable will point to the Imperas installation lib directory
IMPERAS_BIN
This variable will point to the Imperas installation bin directory
IMPERAS_VMISTUBS
This variable will point to a link library, required whilst producing a shared library
for a processor/semihosting library model.
IMPERAS_VMIINC
This variable will point to the ICM header files.
SIM_CFLAGS
This variable will contain a set of useful flags for compiling host specific code,
including setting paths for the VMI include files
SIM_LDFLAGS
This variable will contain a set of useful flags for linking host specific code,
including setting paths to runtime libraries (e.g., libOVPsim)
G.2.2
$(IMPERAS_HOME)/ImperasLib/buildutils/Makefile.common
This is included in standard Makefiles that are provided to pre-define variables to obtain
the source and dependency files and the VLNV library information for the source input
and target library output when building components:
include $(IMPERAS_HOME)/ImperasLib/buildutils/Makefile.common
This included Makefile, will check that the user has specified one of the following to
define the location for the output binary generation
NOVLNV=1 this will write files to the current directory
SYSTEMVLNV=1 this will overwrite, back to the system library
VLNVROOT=<path> this will write to a new VLNV, rooted at <path>
This included makefile, will provide the following variables to be used by other
Makefiles
OBJ
This variable will contain a list of all the object files found from all the *.c, *.cpp
and *.S files found in the source directory
DEP
This variable will contain a list of all the dependency files to be generated for the
*.c, *.cpp and *.S files found in the source directory
It is recommended to run this from the VLNVSRC directory, this can be achieved using
the following
NOTE
The build system requires that the output library, VLNVROOT, directory exists.
If you are building into your own library directory it may be required to create this
directory before invoking the Makefile.
This is also used to build your own library components in the following way
This allows all components within this library to be found and used in platforms.
However, when you are creating custom components, they may be created using separate
source and binary libraries which are built using the Makefile described in the previous
section.
CROSS?=OR1K
-include $(IMPERAS_LIB)/CrossCompiler/$(CROSS).makefile.include
As the Imperas/OVP simulators load shared objects for processor models, peripheral
models and intercept (including semihost) libraries it is possible that a segmentation fault
or abort can be caused in the loaded code.
This may appear to be a fault of the simulator but this is unlikely. It is more likely to be a
fault in one of the models or platforms that are loaded by the simulator. The following
can be used to help you find the problem in the software that you have created.
An abort will be reported in the following manner. For an example, an abort has been
caused in the virtual platform when run using the command line
OVPsim_single_arm_Cortex-A_tlm2.0.Linux32.exe dhrystone.ARM_CORTEX_A15.elf
<snip>
This could be due to an error in your native code (for example the platform,
semihost library etc.) or an error in the simulator.
Use the following approaches to try to find the source of the error:
1. Rerun the simulation under a debugger.
2. Set environment variable IMPERAS_BACKTRACE=1 to generate a backtrace (Linux
only).
3. Set environment variable IMPERAS_LOOP_ON_EXCEPTION=1 to cause the simulator
to enter a wait loop on exception, so that a debugger can be attached.
If you believe the error originates within the simulator, please contact Imperas
support (support@imperas.com)
Info Exiting
To aid in tracking down the cause of the abort there are two features, explained in the
abort output
IMPERAS_BACKTRACE=1 OVPsim_single_arm_Cortex-A_tlm2.0.Linux32.exe
dhrystone.ARM_CORTEX_A15.elf
Info Exiting
The following shows the same platform run with the environment variable
IMPERAS_LOOP_ON_EXCEPTION=1 set on the command line, i.e.
IMPERAS_LOOP_ON_EXCEPTION=1 OVPsim_single_arm_Cortex-A_tlm2.0.Linux32.exe
dhrystone.ARM_CORTEX_A15.elf
This simulation will not finish. In a separate shell you can now start a suitable host
debugger and examine the running processes on the host for the one running your
platform executable, for example OVPsim_single_arm_Cortex-A_tlm2.0.Linux32.exe in
this case.
##