Fast Models Portfolio 7.1 Release Notes
(version 7.1.45 dated 2012/05/24 12:57:33 GMT)
Detailed documentation can be found in the doc subfolder for Fast Models
Tools and the Docs subfolder for the Fast Models Portfolio.
A significant number of the examples in the Fast Models Portfolio 7.1
make use of images containing third-party IP. These have
been split out into a separate 'Third Party IP' package that can be
Not installing these images will mean that any examples that require
dhrystone.axf, dhrystone_v7m.axf or the Linux images will not be
functional, as well as any example using OSCI System C 2.2 and TLM 2.0.
Enhancements and changes in the Fast Models Portfolio 7.1 release
Fast Models 7.1 includes enhancements/changes in the following since 7.0:
Multiple Instantiation (MI)
Fast Models now adds support for Multiple instantiation to its SystemC export capability.
'simgen' can be invoked with the --enable-mi option. This enables the new MI SystemC export.
When 'simgen --enable-mi' is used, a new class scx::scx_evs_Dhrystone is generated (Dhrystone is just used as a placeholder for the system name here). The header file for this is '#include <scx_evs_Dhrystone.h>'.
See the Fast Models - SystemC Export with Multiple Instantiation document for more information, $PVLIB_HOME/Docs/GENC-010823_mi_ug.pdf.
- multiple SC_THREAD, one per core
- supports true multiple instantiation (multiple of the same and of different EVSes in one system)
- honors the quantums sizes provided by tlm::tlm_global_quantum::compute_local_quantum()
- supported host platforms: Linux and Microsoft Windows (32-bit and 64-bit)
- scx::scx_sync(0.0) (previously called sc_sg_break_quantum())
- default scheduler mapping can be replaced by a custom one (see EVS_CustomScheduler example)
- default simulation controller can be replaced by a custom one (see EVS_CustomScheduler example)
- built-in CADIServer, debugging standalone systems works (the CADIServer is not unhooked, that is, it is not a separate and optional component in this release).
SystemC Export with Single Instance (SI) is deprecated and will be removed in a future release of Fast Models. Please contact ARM for advice on moving to Multiple Instantiation (MI).
The function sg::SchedulerInterfaceForComponents::SchedulerThread::start()
is not required to (and does not for all use cases) behave as
specified in the header and in the documentation. The specification
will change in future versions of Fast Models regarding this behavior:
The start() function returns immediately without running the threadProc() function of the thread. Calling start() during the
elaboration phase adds the thread to the list of threads which will
be made runnable once the simulation starts running. Calling start() while the simulation is already running will add the thread to the list of runnable processes for the current scheduler time. Calling
start() on an already-started thread has no effect. Calling start()
on a thread which already terminated (threadProc() returned) has no
The current SystemC export default scheduler mapping is in
line with this new specification. The current Fast Models standalone
scheduler requires all threadProc()
functions to call wait(0) once
initially to produce this behavior. All threads in Fast Models
components do this already, so this specification change does not
affect any Fast Models component. Future versions of Fast Models
will not require this initial wait(0)
in threadProc(). This issue only affects users who either implement or call start() directly which is usually not necessary (SDDKW-13039).
The following are current known limitations:
- scheduler_mapping::addSynchronisationPoint(t) and scx::scx_sync(t).
These functions support only t=0 at the moment, which is sufficient for cases where the need for immediate synchronization is detected.
Microsoft Visual Studio 2010 support
Support for building models using Microsoft Visual Studio 2010 has
gcc 4.4 support
Support for building models using gcc 4.4.4 has been added.
A model of the ARM Cortex-R7 processor is introduced. This is an
ARM-v7 R profile core.
There are two variants introduced in the Fast Models 7.1 release, each with supporting periperals:
- Cortex-R7_MPx1 - 1-core MPCore processor
- Cortex-R7_MPx2 - 2-core MPCore processor.
MTI Plugin Development Kit
The Model Trace Interface plugin development kit (MTIPDK) is now
shipped as standard with Fast Models Portfolio.
Deprecated in the Fast Models Portfolio 7.1 Release
The following are deprecated in Fast Models Portfolio 7.1:
- CADI 1.1 is deprecated and will be removed in a future release of Fast
Models. Please contact ARM for advice on moving to CADI 2.
- Microsoft Visual Studio 2005 support is deprecated and will be
removed in the next release of Fast Models.
Removed from the Fast Models Portfolio 7.1 Release
GCC 3.4 support has been removed.
Platform requirements for Microsoft Windows
When running Microsoft Windows XP or Microsoft Windows 7 it is recommended to use machines
with at least 2GB RAM, and preferably at least 4GB for best performance. To use
audio a 2GHz, or faster, Intel Core2Duo, or similar-performing, processor is
- Microsoft Windows XP 32-bit SP2 or SP3
- Microsoft Windows 7 32-bit RTM or SP1, Professional or Enterprise editions
- Microsoft Windows 7 64-bit RTM or SP1, Professional or Enterprise editions.
- Microsoft Visual Studio 2005 with Service Pack 1 and the Microsoft Visual Studio 2005 Service Pack 1 ATL Security Update (on Microsoft Windows XP only)
- Microsoft Visual Studio 2008 with Service Pack 1 and the Microsoft Visual Studio 2008 Service Pack 1 ATL Security Update
- Microsoft Visual Studio 2010 with Service Pack 1.
- Fast Models Portfolio does not contain the Microsoft Visual Studio 2005 SP1 or
Microsoft Visual Studio 2008 SP1 or Microsoft Visual Studio 2010 SP1 runtime libraries.
- The Fast Models tools require the Microsoft Visual Studio 2005 SP1 runtime libraries to
be installed. These must be downloaded from Microsoft.
- Models built with Microsoft Visual Studio 2005 SP1 require the Microsoft Visual Studio SP1
Redistributable Package to be installed in order to run.
- Models built with Microsoft Visual Studio 2008 SP1 or Microsoft Visual
Studio 2010 SP1 require both the Microsoft Visual Studio 2005 SP1 and
the Microsoft Visual Studio 2008/2010 SP1 Redistributable Package to
be installed in order to run.
- To build 64-bit host models on Microsoft Windows, a host
platform with a 64-bit CPU and a 64-bit version of Microsoft Windows
is required. Note that Microsoft Windows XP 64 is not
supported. Microsoft Visual Studio 2008 SP1 and the Microsoft Visual
Studio 2008 Service Pack 1 ATL Security Update or Microsoft Visual
Studio 2010 SP1 is required. Microsoft Visual Studio 2005 is not
supported for building 64-bit host platform models.
- Additional project configurations are available for most recently-created System Canvas projects and selected updated example
projects. To build for a Microsoft Windows host, choose 'Win64-Debug-VC2008', 'Win64-Release-VC2008', 'Win64-Debug-VC2010', or 'Win64-Release-VC2010'.
Please email firstname.lastname@example.org with any comments
To view the documentation, Adobe Acrobat reader (Version 8 or higher) must be installed on the system.
Platform requirements for Linux
When running on Linux it is recommended to use machines with at least 2GB
RAM, and preferably at least 4GB for best performance. To use audio a 2GHz,
or faster, Intel Core2Duo, or similar-performing, processor is recommended.
- Red Hat Enterprise Linux 4 (on either 32-bit or 64-bit architecture)
- Red Hat Enterprise Linux 5 (on either 32-bit or 64-bit architecture)
- Red Hat Enterprise Linux 6 (on either 32-bit or 64-bit architecture).
When building models for 32-bit hosts, Fast Models 7.1 for Linux
supports the following compilers:
- gcc 4.1.2 (built against at least binutils 2.17)
- gcc 4.4.4.
When building models for 64-bit hosts, Fast Models 7.1 for Linux
supports the following compilers:
- gcc 4.1.2 (built against at least binutils 2.17)
- gcc 4.4.4.
64-bit host model support:
- To build 64-bit host models on Linux, a host platform with a
64-bit CPU and a 64-bit version of Red Hat Enterprise Linux version 4
or above is required. GCC 4.1.2 or above is required.
Additional project configurations are available for most recently-created System Canvas projects and selected updated example
projects. To build for a Linux 64-bit host, start System Canvas and
change the 'Active Project Configuration' to one of the
'Linux64-Release-GCC' configurations, then rebuild the project.
To view the documentation, Adobe Acrobat reader (Version 8 or higher) must be installed on the system.
Licence management utilities
If you are using floating licenses, you must use FLEXnet license
management utilities version 9.2 or higher. FLEXnet 10.8 license
management utilities are available as an optional installable component in the product installer.
Use the highest version of the license management utilities provided with
any ARM tools you are using. It is recommended to set up the user
environment running applications of the Fast Models product only for one
armlmd license server, because spreading Fast Models license features
over different servers could result in license denials for certain features.
For more instructions on installing licenses please consult the ARM
This section covers installation information for:
Microsoft Windows XP and Microsoft Windows 7
The Fast Models Portfolio installs its examples into the specified
install location, which is normally under C:\Program Files\ARM\ On
Microsoft Windows 7, without Administrative privileges it is not
possible to build and run the examples in situ. It is therefore
necessary to copy the file hierarchy under
to a local directory to which the user has read/write permissions. Once
this is done, it is necessary to load examples into the System Canvas tool
from this new location (TA-588366/SDDKW-3784).
By default, Microsoft Windows 7 does not provide an executable telnet
client. For instructions on how to deal with this, please see Chapter 5 of the Fast
Models Reference Manual.
Once you have installed the Fast Models package, it is
necessary to source the following script (dependent on shell) to
set up up the appropriate environment variables. This should ideally
be included such that it is sourced into the user's environment when they
- For bash/sh: . <install_directory>/FastModelTools_7.1/source_all.sh
- For csh: source <install_directory>/FastModelTools_7.1/source_all.csh
The Third-Party IP package (TPIP) must be installed after the Fast Models package.
Using the MPS platform model
This section provides information for loading and running the platform.
Loading and running the platform
The platform model comes with a pre-built flash image that contains a
slightly modified version of the MPS BootMonitor and the MPS SelfTests.
The platform has a parameter for the name of the file that is loaded
into the flash on startup. To use the flash image this parameter
needs to be set properly.
- with a relative path:
- with an absolute path on Microsoft Windows assuming the default installation directory:
- with an absolute path on Linux assuming the default installation directory:
The BootMonitor can be used to start images from flash:
- To enter the flash menu type flash
- To list the available images type list images
- To run an image, type for example run selftest_mpb_ESL
When running the MPS SelfTests, the following tests are expected to fail on the MPS platform model:
- 1.1 Audio Loopback
- Reason: no loopback simulated.
- 10 USB
- Reason: USB not supported.
Using the ARM Profiler with Fast Models 7.1
Fast Models version 7.1 supports ARM Profiler version 2.1, as shipped in
ARM RealView Development Studio 4.0 SP2, and later. It does not support
the use of ARM Profiler 2.0 or earlier, which was shipped in ARM
RealView Development Studio 4.0 and 4.0 SP1.
If you currently have ARM Profiler 2.0 and wish to use the ARM Profiler
with Fast Models 7.1, it will be necessary to upgrade to ARM RVDS 4.0 SP2.
Please contact ARM Support for further details.
Using TAP/TUN-based Model Networking
Fast Models Version 6.0 added a new model-to-host networking implementation
based on TAP/TUN. This has a number of advantages compared to the previous
- Only requires root/administrator access at install time
- No longer requires nicserver.
Installation instructions for Model Networking can be found in the
Fast Models Reference Manual, Sections 5.4.45, 5.6.3, and 5.6.4.
However, due to the different implementation and configuration methods, you
may encounter some issues during installation:
- Symptom: The model networking worked after the first time setup, then
stopped working after reboot.
- Solution: This is typically caused by /dev/net/tun not having correct access
permissions. To fix this, set the correct permission to the device by
executing chmod 666 /dev/net/tun as root. To preserve the change across
reboots, the udev rules of the tap device need to be modified:
- Open /etc/udev/rules.d/50-udev.rules as root, find the line:
- Check if it has MODE="0666" at the end of the line. If not, append
MODE="0666" to the line:
KERNEL=="tun", NAME="net/%k", MODE="0666"
- Symptom: Model Networking installs correctly, however when a model is
started, the model cannot receive any packets.
- Solution: This is typically caused by the firewall on the host machine.
Disable the firewall, or add tap device to "trusted devices". Please refer
to your vendor's documentation manual for how to do this.
The following known issues and limitations exist in this release:
CT model issues
CT model issues are as follows:
- DMA into TCMs can produce incorrect results in big endian mode
- Connecting to multiple RTSM or Model Library models concurrently using
RealView Debugger can cause instability. This applies to all models which
have been generated using Fast Models (TA-514865/SDDKW-2895).
- Exception breakpoints appear in Model Debugger's breakpoint manager,
however they cannot be configured. This can be worked around by
configuring them using the "Exception Traps" register pane instead (TA-550165/SDDKW-3193).
- The Cortex-R4 fast model treats TCM memory as cacheable. If both TCMs
and caches are configured and the TCM memory is marked cacheable then
the model will respect this and pollute the cache. In the real device
TCM memory is never cacheable even if marked as such (SDDKW-3206).
- The Cortex-A9MP and Cortex-A5MP fast models ignore the SCU invalidate
all register (TA-558715/SDDKW-3385).
- The Cortex-A9MP and Cortex-A5MP fast models ignore the SCU enable
bit. Therefore the SCU is always enabled (TA-558221/SDDKW-3373).
- The Cortex-A9MP and Cortex-A5MP fast models do not implement address
filtering within the SCU. The enable bit for this feature is ignored (TA-558719/SDDKW-3388).
- Functional caches are architectural cache models that do not have
device accurate behavior relating to tag allocation, victim selection
and physical/virtual indexing behavior (TA-732864/SDDKW-8185).
- Broadcast Translation Lookaside Buffer (TLB) or cache operations in the
Cortex-A9MP fast model do not cause other cores in the
cluster which are asleep due to Wait For Interrupt (WFI) to wake up (TA-558220/SDDKW-3372).
- The Cortex-R4 fast model ignores the Cache Size Override register (TA-572916/SDDKW-3584).
- vfp registers are not displayed if ase-present is set. Enabling the
ase-present parameter should force the vfp-present parameter to be
set automatically. This is not currently implemented so it is necessary
to manually set vfp-present when setting ase-present. This will
then enable the display of vfp registers (TA-571230/SDDKW-3554).
- Cortex A8 L2 cache write allocate policy is not configurable. It
defaults to write-allocate. Writes to the configuration register will
succeed but will be ignored, meaning that data can be unexpectedly
stored in the L2 cache (TA-573071/SDDKW-3598).
- Default PVBus bus response for exclusive access has the wrong sense.
EXOK should be mapped to TX_OK, and OK should be mapped to
TX_EXCLUSIVEABORT for exclusive access. TLM2 AMBA-PV behaves
- When taking an exclusive read abort the Cortex-A9 model can return an
fsr with a value of 0, which is not valid (TA-639621/SDDKW-4446).
- PVBus function getMasterID() may be deprecated in a future release (TA-659219/SDDKW-4677).
- Models only support some types of memory breakpoints. Currently the
error message returned if an unsupported type is used may not clearly
indicate that the breakpoint type is unsupported (TA-662969/SDDKW-4722).
- pv::TransactionGenerator does not support exclusive accesses (TA-659218/SDDKW-4676).
- CADI calls not supported by Fast Models. The following methods are not supported by Fast Models.
Virtual Memory API
CADI methods deprecated for use in Fast Models 7.1 (TA-684124/SDDKW-5033):
- The unused legacy CADI configuration parameter 'semihosting-debug'
has been removed from all CoreTile models (SDDKW-14777).
- Attempting to instantiate a system model with more than 200+ CADI
objects may cause the simulation to crash when the CADI client is
- "Goto Main" from Model Debugger is not supported with Cortex-A9MP,
Cortex-A9UP, Cortex-A5MP and Cortex-A5UP fast models (TA-571017/SDDKW-3550).
- The Cortex-A9MP and Cortex-A5MP GIC does not implement the
cfgsdisable behavior to make some registers read-only (TA-549471/SDDKW-3190).
- FlashLoader now has parameters to allow the flash file to be saved
at the end of a simulation, preserving flash contents as would
happen on real hardware. This functionality is Beta quality and
may not work in all cases (TA-721877/SDDKW-6651).
- Cortex A8 does not support a zero-sized L2 cache. All other cache sizes
are supported (TA-725232/SDDKW-7393).
- When attempting to debug an ISIM system, if you launch Model Debugger from
System Canvas and then specify an application to load, this causes an error
in Model Debugger (Error using application...), and the model and
application fail to load.
Workaround: Launch Model Debugger without specifying an application, and
then load the application from within Model Debugger itself using
File -> Load Application Code (SDDKW-10295).
- The GIC-400 model has the following limitations (SDDKW-13075):
- Reads and writes to the
not work as expected unless there is a configured target in
- Some of the interaction of GICD_CTLR.EnableGrpX and level
sensitive interrupts may not work entirely correctly.
- The signals nIRQOUT/nFIQOUT are not modeled.
- All interrupts are modeled with positive logic, rather than the
negative logic used in the hardware. Hence all signal pins have
their 'n' prefix dropped.
- The Cortex A15 and Cortex A7 models claim to have parameters named
CFGNMFI, POWERCTLI, and SMPnAMP. These settings do not correspond to
hardware functionality, and their value will be ignored by the
- The FastModels documentation states that a LISA component that is
going to act as a bus slave must instantiate a PVBusSlave
sub-component. There was a back door where a slave port of type
PVBusProtocol could simply implement a read() and write() method
without requiring a PVBusSlave sub-component. This was not intended
usage, and as of FM7.0 this back-door no longer works. LISA
component designers must now adhere to the instructions given in
DUI0423 (see 5.2.5 PVBusSlave component) and/or copy the structure
of the FastModels example peripherals (SDDKW-13968).
There is a limitation in the ACE cache models in Cortex-A15 and
Cortex-A7, and the ACE support in the CCI-400: these functional
models only handle processing a single transaction at a time. Under
normal use this will not cause any problems, because the simulation
will process each transaction to completion before allowing any
master to generate another transaction.
There are two situations in which this might fail:
- If there is a loop in the bus topology, such that there is a
path of bus connections going out of the master port from a
component back into one of its slave ports. This can potentially
cause problems even if it isn't possible for a single transaction
to go round the loop (for example, if there are bus-decoders that
limit the paths that a transaction can take) (SDDKW-13039).
Contact ARM for further details if these restrictions are likely to
- If a SystemC bus slave calls wait() while it is processing a
transaction, it may allow another master to issue a transaction
that passes through the CCI-400 or the Cortex-A15/Cortex-A7
caches. This could happen if a SystemC bus master running in
another thread is connected to one of the ACE-lite ports on the
- When generating SystemC Export components on Windows, you might see
warning messages such as: "_WIN32_WINT: macro redefinition".
This is issued by an unguarded setting of _WINVER in the OSCI
SystemC headers. Fast Models request a later version of the Win32
API elsewhere in its generated code causing this warning. This
warning can be safely ignored (SDDKW-13781, SDDKW-13523).
- RVD 4.0 cannot be used to step or run an A9 model. In order to do
this, RVD 4.1, DS-5, or ModelDebugger is needed (SDDKW-15171).
- The TelnetTerminal can only manage one active connection at a
time. When there is an incoming connection, this is given priority
and any existing connections are closed by the server. Previously,
TelnetTerminal in versions of Fast Models up to 7.0 had ignored
incoming connections where there was an existing connection (SDDKW-8463).
Model Trace Interface (MTI)
Trace output from the ARM Cortex-M3 fast model has the following known limitations:
- The xPSR register is currently called "CPSR" in the register trace
- Fast Models 6.1 introduced the ability to unregister a MTI callback whilst
within the same callback. This does not work for adding new callbacks or
unregistering any other callback and may result in a crash or unexpected
extra calls to unrelated callbacks (SDDKW-11567).
- The SRS instruction was reporting incorrect store transactions in
TarmacTrace output (SDDKW-18124).
- The source code for the LinuxSyscallTrace plugin, currently supplied
as an MTI Plugin example, is faulty. This is because the code relies
on a particular ordering of components within the model which is not
guaranteed for any given platform model. This means that the plugin
will fail to register properly on some FastModels example platforms (SDDKW-18570).
CLCD has the following known limitations:
- SDL, the library used to provide the visualization component, can only
open one window per process. Models should only ever open one window (TA-455617/SDDKW-2246).
The following parameters of the PL011 UART are being deprecated in the next release of the product (TA-641768/SDDKW-4497):
Model generation issues
There is one known model generation issue:
- If a PARAMETER has no type specified, PARAMETER will default to a uint32_t
and a warning will be generated. It is recommended that type be specified
explicitly as this warning may be promoted to an error in a future version
There are the following known networking limitations:
- The default firewall configuration on Red Hat Enterprise Linux 5
blocks transmission of packets across the bridge device created as
part of the Fast Models TAP networking solution. This will lead to a
loss of host network connectivity if TAP-based networking is
configured on a host with the firewall active. This can be worked
around by disabling the firewall. If the models are to be used in an
environment where it is not possible to disable the firewall then
additional firewall rules will be required to allow
The following iptables commands should configure the
firewall to allow packets across the bridge device (SDDKW-14139):
- iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
- service iptables restart.
- If Dynamic DNS is being used to by the host such that suitable
records are inserted into DNS if the host is managed via DHCP
installing TAP networking may cause failure to register in the
DNS. This happens due to the DHCP client being rerun after the
physical device is attached to the bridge device. At this point the
correct hostname is not passed in the DHCP request. There is no
workaround for this issue at this time (SDDKW-14140).
- Most WiFi adaptors do not implement the required support for TAP
networking to work. There is no workaround for this problem (SDDKW-14142).
- In the technology preview of the User Mode Networking support the
RFC1918 address space used was 172.31.254.0/24 this is the last
subnet in the space and is not recommended it is chosen via an
obvious rule and is more likely to conflict with RFC1918 space used
in a users environment. This has been changed to the arbitrarily
chosen 172.20.51.0/24 (SDDKW-14027).