Release History

The latest Fast Models release version is reported at the top right of this page.

Details on What's New, and links to the Release Notes are provided below.

 

Fast Models

Version 11.0

Released: June 06, 2017

What's new in 11.0

New features and enhancements

  • Fast Models internal scheduler is deprecated in favour of SystemC:
    • All of the ISIM executables produced by simgen are based on SystemC.
    • The TARGET_ISIM build target is dropped and several new build targets are introduced.
  • New CTModels for Cortex-A55 and Cortex-A75 with several new example FVP_Base platforms.
  • Introduction of DynamIQ(FCM) FVP_Base Platforms consisting of clusters of Cortex-A55 and Cortex-A75 CTModels, in various configurations.
  • Updates to Cortex-R52 parameters and registers.
  • New IDAU model and updates to names of parameters in FVPs to refer to it.
  • New CMN-600 model.
  • New GIC-600 model.
  • New SMMUv3AEM architectural model which implements the SMMUv3.0 and SMMUv3.1 architectures.
  • Mali-V550 and Mali-V61 model parameters have been changed to better reflect RTL configurability.
  • New Mali-G71 GPU model which can work with or without GGA, to help graphics software stack verification.
  • New FVP_Base_AEMv8A-AEMv8A-CMN600 platform.
  • Rate-limiter has been turned to OFF by default on FVP platforms.
  • New P-Channel power management protocol.
  • New AEMv8A core personalities feature allows you to configure AEM instances in a platform for a specific implementation at model startup.
  • New Fastline plug-in enables you to use Streamline Performance Analyzer to analyze software running on Fast Models.
  • use_instr_cnt_as_timestamp command-line parameter has been added to TarmacTrace and TarmacTraceV8 to alow you to use the instruction count instead of the simulation time as the timestamp in the trace.

Deprecated and removed features

  • TarmacTraceAEM plug-in has been removed.
  • Support for Linux compiler GCC-4.7 has been removed.

Release Note for Release History 11.0

Detailed documentation can be found in the 'doc' subfolder for Fast Models Tools and the 'Docs' subfolder for Fast Models Portfolio.

A significant number of the examples in Fast Models Portfolio 11.0 make use of images containing third party IP. These have been split out into a separate 'Third Party IP' package that can be downloaded from:

Not installing these images will mean that examples that require Dhrystone or the Linux images will not be functional, as well as examples using Accellera SystemC 2.3.1.

Enhancements and Changes in Fast Models Portfolio 11.0

  • Deprecation of Fast Models internal scheduler in favour of SystemC. The legacy Fast Models scheduler is deprecated in 11.0 release. All of the ISIM executables produced by simgen are based on SystemC. Thus, TARGET_ISIM of sgproj files is dropped.

    The following new targets are introduced in Fast Models 11.0:

    • TARGET_ISIM_DEPRECATED will continue to behave as the current TARGET_ISIM until the feature is finally dropped in May 2018.

    • TARGET_SYSTEMC_ISIM is the new target which produces SystemC ISIM executables.

    • TARGET_SYSTEMC_AUTO produces a single EVS component by applying the new auto-bridging mechanism to LISA components. This feature will eventually replace completely the current TARGET_SYSTEMC.

    As a result of the change of scheduler the following effects could be observed:

    • Simulations are not reproducible in terms of scheduling of threads and events between 11.0 and previous releases.

    • CADI reset is not supported any more and returns eslapi::CADI_STATUS_CmdNotSupported.

    • Default quantum is now 10000 and could be set on the command line through -Q.

    • Min sync latency could also be set at the command line through -M. Default is 100.

  • This package adds support for the Cortex-A55 CTModel with the following LISA definitions:

    • CortexA55x1

    • CortexA55x2

    • CortexA55x3

    • CortexA55x4

    • CortexA55x8

    This package supports the following example FVP_Base platforms:

    • FVP_Base_Cortex-A55x1

    • FVP_Base_Cortex-A55x2

    • FVP_Base_Cortex-A55x4

    • FVP_Base_Cortex-A55 (with NUM_CORES configurable)

    The following features are supported by the model:

    • DynamIQ(FCM) system registers are implemented.

    • Per-Core L2Cache is supported.

    • PChannel for cluster and each core is implemented.

    • Optional peripheral port is supported.

    • L3Cache partition is supported.

    • Per-core clock is implemented.

    The following features are not supported by the model:

    • BROADCASTCACHEMAINTPOU pin is not implemented.

    • COREINSTRRET,COREINSTRRUN,nCLUSTERPMUIRQ,nPMBIRQ signals are not implemented.

    • 256-bit wide output transactions are not supported.

    • Dual ACE masters are not supported.

    • Error correction/detection features are not supported.

    • Self-test features (MBIST) are not supported.

    • Latency configuration is not supported.

    • Snoop filtering is not supported.

    • Cache stashing capability is not supported.

  • This package adds support for the Cortex-A75 CTModel with the following LISA definitions:

    • CortexA75x1

    • CortexA75x2

    • CortexA75x3

    • CortexA75x4

    The package supports the following example FVP_Base platforms:

    • FVP_Base_Cortex-A75x1

    • FVP_Base_Cortex-A75x2

    • FVP_Base_Cortex-A75x4

    • FVP_Base_Cortex-A75 (with NUM_CORES configureable)

    The following features are supported by the model:

    • DynamIQ(FCM) system registers are implemented.

    • Per-Core L2Cache is supported.

    • PChannel for cluster and each core is implemented.

    • Optional peripheral port is supported.

    • L3Cache partition is supported.

    • Per-core clock is implemented.

    The following features are not supported by the model:

    • BROADCASTCACHEMAINTPOU pin is not implemented.

    • COREINSTRRET,COREINSTRRUN,nCLUSTERPMUIRQ,nPMBIRQ signals are not implemented.

    • 256-bit wide output transactions are not supported.

    • Dual ACE masters are not supported.

    • Error correction/detection features are not supported.

    • Self-test features (MBIST) are not supported.

    • Latency configuration is not supported.

    • Snoop filtering is not supported.

    • Cache stashing capability is not supported.

  • DynamIQ(FCM) FVP_Base Platforms are added in 11.0 release.

    This release adds the DynamIQ(FCM) cluster of Cortex-A55 and Cortex-A75 put together to form a FVP_Base platform. New fixed-configuration FVP_Base DynamIQ platforms including Cortex-A55x1+Cortex-A75x1, Cortex-A55x2+Cortex-A75x2, Cortex-A55x2+Cortex-A75x4, and Cortex-A55x4+Cortex-A75x4 are added.

    A new flexible Cortex-A55+Cortex-A75 FVP_Base DynamIQ platform is also added in this release. The flexible Cortex-A55+Cortex-A75 platform provides the configurability to use the subclusterX.NUM_CORES parameters to configure at runtime the number of Cortex-A55 and Cortex-A75 instances within the cluster. Each subcluster within the DynamIQ cluster can be configured independently by using the parameters exposed with the subclusterX.param_name prefix, where X=0 or 1.

    The following features are supported by DynamIQ(FCM) clusters:

    • DynamIQ(FCM) cluster system registers are implemented.

    • Timing annotation for L3 cache is implemented.

    • Partitioning of L3 cache is implemented.

    • L2cache parameters are changed to be per-core basis instead of cluster basis in this release.

    • For Cortex-A55+Cortex-A75 FVP_Base platform, the subcluster level NUM_CORES parameter is supported to instantiate flexible combinations of Cortex-A55 and Cortex-A75 core instances within the cluster.

    Limitations of the DynamIQ(FCM) clusters:

    • Partial powerdown of L3 Cache is not implemented yet.

    • For flexible Cortex-A55+Cortex-A75 clusters, there is a known issue related to presentation of parameters and CADI targetNames to CADI clients when cpu instances in 1st subcluster are configured to be less than 4. CADI targetNames and parameters for cpu[0-3] are always shown from Cortex-A55 subcluster, when viewed by CADI clients.

  • This package contains the following updates to Cortex-R52:

    • A new parameter num_protection_regions_s1 is provided to configure number of stage1 MPU regions.

    • ID values in registers have changed according to revision r1p0.

    • EDECCR register is updated as per revision r1p0.

  • IDAU parameter changes in the 11.0 release:

    The IDAU has been moved from v8-M cores, and duplicates in other components, into a dedicated component. As a result, the names of parameters in FVPs have changed to refer to this component instead of the CPUs and other devices. See comments at the top of IDAU.lisa and the MPS2 example for information on how to use the IDAU component.

  • CMN-600:

    The CMN-600 model supports the following:

    • rnf, rni/rnd , hni, snf/sbsx interface ports. The mapping between port number and NodeId is based on the NodeId index. For example, RNF2 (index is specified in node_info register as logical_id) controls pvbus_s_rnf[2]. Similar behavior can be expected for HNI.

      If both RND and RNI nodes are present then all starting rni ports are mapped to RND nodes and then the RNI nodes. For example, for CMN-600 with 2 RND nodes, 1 RNI node and given each RNI/RND node controls 3 interface ports, pvbus_s_rni[0-2] maps to RND0, pvbus_s_rni[3-5] maps to RND1 and pvbus_s_rni[6-8] maps to RNI0. Similarly, SNF and SBSX nodes are mapped to pvbus_m_snf[] ports where starting ports are mapped to SNF and then SBSX nodes.

    • A parameter to define the mesh placement of the CHI nodes. The parameter mesh_config_file can be used in the following ways:

      • Set it to the name of the yml configuration file emitted by Socrates.

      • Set it to a json file with the following format (file extension should be .json):

        {
            "mesh_row_size":4,
            "mesh_column_size":3,
            "mesh_placement" : {
            "0.0" : "RND:HND",  "1.0" : "RND:RNF",  "2.0" : "RND:RNF",
            "0.1" : "HNF:HNF",  "1.1" : "HNF:HNF",  "2.1" : "HNF:HNF",
            "0.2" : "HNF:HNF",  "1.2" : "HNF:HNF",  "2.2" : "HNF:HNF",
            "0.3" : "RND:HNF",  "1.3" : "HNF:HNF",  "2.3" : "HNF:SNF"
        }
    • The Discovery feature to determine system address of CHI Nodes.

    • Hashed and non-hashed memory regions as well as sys_cache_group for hashed memory regions.

    • DVM filtering using VMF registers.

    • Entry/exit of RNs from snoop and DVM domain using both SYSCOREQ/SYSCOACK signals and via software using MXP syscoreq registers.

    • Reading the content of cache via HNF l3_cache_access* registers provided cache_state_modelled is true.

    • HNF SAM feature to allocate a range of addresses to a specific SNF.

    • HNF Cache way lock and OCM.

    Limitations:

    • PMU counters are not supported (counter registers are implemented as RAZ).

    • All RNI and RND nodes control 3 interface ports. The other variants which control 2 or 1 ports are not supported.

    • QoS is not supported and all related registers are RAZ/WI.

    • Error injection and Error generation is not supported. All error registers are RAZ/WI.

    • Power/Clock/Interrupt signals are not supported.

    • RN SAM and HN-F SAM memory partition size of 128MB is not supported.

    Outstanding issues:

    • The power related registers in HNF are implemented but may not have the required functional behavior.

    Changes:

    • Fast Models 11.0 fixes the num_hnf field size from 5 to 6 bits in sys_cache_group_hn_count register to match spec.

  • GIC-600

    Fast Models 11.0 introduces an ARM GIC-600 Generic Interrupt Controller model suited for single chip systems.

    This model provides a simple configuration interface that allows designers to introduce GIC-600 like functionality to their systems, while only implementing the architectural behaviors as defined by the GICv3 architecture.

    All implementation-specific registers and functionality are unimplemented except for GICR_PWRR for which an effectless but stateful implementation is present. This allows the correct value to be observed by a power-aware software implementation.

    As with the other GIC componenents, there are two variants of the component with slightly different memory interfaces. Both the GIC600 and the GIC600_Filter have a pvbus_s port for register access and a pvbus_m port for the LPI related traffic from redistributors and the ITS.

    In addition, the GIC600_Filter variant has a pvbus_filtermiss_m port, to which any transaction coming on the pvbus_s port and not directed to a 4k page used by the GIC is forwarded unmodified. Such transactions are terminated in the component when using the GIC600 variant. It is recommended to use the GIC600 variant in most cases.

  • SMMUv3AEM

    This is an architectural model implementing the SMMUv3.0 and SMMUv3.1 architectures which are for I/O virtualization of devices.

    Limitations:

    • RAS

    • No P- or Q-channels for power control.

    • AMBA 'stash' operations and 'destructive read' operations are not supported on PVBus and also not by the device.

    • The PMU has limited functionality, only a subset of the architecturally mandatory events are supported (as indicated by the SMMU_PMCG_CEID0 fields). The PMU is only intended for demonstration purposes and for driver development.

    • Cache maintenance operations from upstream client devices are not supported.

  • Mali-V550

    Model parameters have been changed to better reflect RTL configurability. They have been grouped into fuse-disable-* and supports-* to distinguish between fuse input ports and RTL configuration.

    New parameters:

    • fuse-disable-VP8

    Changed parameters:

    • supports-AFBC renamed to fuse-disable-AFBC; no longer affects CONFIG register

    • supports-Real renamed to fuse-disable-Real; no longer affects CONFIG register

    • supports-VP8 no longer affects FUSE register (use fuse-disable-VP8 for that)

    Changed parameter defaults:

    • AXI-data-width: default changed from 3 (64 bits) to 4 (128 bits). The original value is only supported for "ncores" parameter values of 1 and 2. The new value is supported for all supported "ncores" values.

    Removed parameters:

    • ID-bits: can be computed directly from the value of "ncores"

    New features in this release:

    • Preview support for VP8 encode. Can accept three-plane progressive-scan YUV420p input frames and an FPS setting.

    The following limitations are present in this release:

    • No support for HEVC & RealVideo decoders

    • No support for 10-bit video output

    • No profiling support

    • No QoS support

    • Power/Test modes are modelled only as register state changes

    Known issues:

    • To build example platforms containing V550, either the Fast Models Third-Party IP package needs to be installed, or the dependency on FFmpeg and libvpx needs to be removed from the platform's sgproj file by removing the line containing "V5xx.sgrepo".

    The model requires an external OpenMAX (OMX) IL implementation for codec functionality. By default, V550 looks for ffomaxil.dll on Windows or libffomaxil.so on Linux in the model binary's directory or in the Fast Models installation. The default library path can be overridden using the parameter omx-library-path.

    FFomaxIL is an OMX IL implementation provided by ARM in the TPIP package for convenience. Refer to the TPIP package for more details on FFomaxIL.

    When querying the OMX core, V550 searches for the following roles in the list of OpenMAX components:

    • H.264 decode: "video_decoder.avc"
    • JPEG decode: "video_decoder.mjpeg"
    • MPEG2 decode: "video_decoder.mpeg2"
    • MPEG4 decode: "video_decoder.mpeg4"
    • VC1 decode: "video_decoder.vc1"
    • VP8 decode: "video_decoder.vp8"
    • VP8 encode: "video_encoder.vp8"
  • Mali-V61

    Model parameters have been changed to better reflect RTL configurability. They have been grouped into fuse-disable-* and supports-* to distinguish between fuse input ports and RTL configuration.

    Changed parameters:

    • supports-AFBC renamed to fuse-disable-AFBC; no longer affects CONFIG register

    • supports-Real renamed to fuse-disable-Real; no longer affects CONFIG register

    • supports-VPX renamed to fuse-disable-VPX; no longer affects CONFIG register

    Changed parameter defaults:

    • AXI-data-width: default changed from 3 (64 bits) to 4 (128 bits). The original value is only supported for "ncores" parameter values of 1 and 2. The new value is supported for all supported "ncores" values.

    Removed parameters:

    • ID-bits.

    New features in this release:

    • Preview support for VP8 encode. Can accept three-plane progressive-scan YUV420p input frames and an FPS setting.

    The following limitations are present in this release:

    • No support for HEVC, VP9, or RealVideo decoders

    • No support for 10-bit video output

    • No support for RGB or AFBC input for encoding

    • No profiling support

    • No QoS support

    • Power/Test modes are modelled only as register state changes

    • No support for AFBC 1.2

    • Models r0p0 hardware revision

    Known issues:

    • To build example platforms containing V61, either the Fast Models Third-Party IP package needs to be installed, or the dependency on FFmpeg and libvpx needs to be removed from the platform's sgproj file by removing the line containing "V5xx.sgrepo".

    The model requires an external OpenMAX (OMX) IL implementation for codec functionality. By default, V61 will look for ffomaxil.dll on Windows or libffomaxil.so on Linux in the model binary's directory or in the Fast Models installation. The default library path can be overridden using the parameter omx-library-path.

    FFomaxIL is an OMX IL implementation provided by ARM in the TPIP package for convenience. Please refer to the TPIP package for more details on FFomaxIL.

    When querying the OMX core, V61 will search for the following roles in the list of OpenMAX components:

    • H.264 decode: "video_decoder.avc"
    • JPEG decode: "video_decoder.mjpeg"
    • MPEG2 decode: "video_decoder.mpeg2"
    • MPEG4 decode: "video_decoder.mpeg4"
    • VC1 decode: "video_decoder.vc1"
    • VP8 decode: "video_decoder.vp8"
    • VP8 encode: "video_encoder.vp8"
  • GGA and GRM

    GGA (Generic Graphics Accelerator) and GRM (Graphics Register Model) can work together to help graphics software stack verification in Fast Model 11.0. The GRM implements ARM Mali graphics hardware without shader support and it can work with or without GGA. With GGA support, the end-user can view the rendering result in the Fast Models visulization window, and can use the error code checking feature to verify app correctness.

    Open GLES APIs supported:

    • v2.0
    • v3.0
    • v3.1

    New features in Fast Models 11.0:

    • Support for error code checking to compare error codes between host and target.

    • Support for GPU trace dumping to expose all register access details inside graphics processor.

    Preferred host GPU hardware and driver:

    • The preferred graphics card model is nVidia GT730 and the corresponding driver versions are:

      • Ubuntu: 367.57 and above

      • Windows: 368.39 and above

    • Graphics cards supported for other vendors cover:

      • AMD. The typical model is R7 240 and the driver versions are:

        • Ubuntu: 15.30 and above released by AMD officially

        • Windows: 15.12 and above

      • Intel HD Graphics. The typical model is HD Graphics 530 and driver versions are:

        • Ubuntu : Not supported due to unqualified native driver

        • Windows : 10.18.15.4279

    Target GPU supported by GRM:

    • Mali-G71

    Target OSes supported:

    • Android 4.4.2
    • Android 6.0.1
    • Android 7.0.0

    Outstanding issues:

    • The following issues depend on Mali OpenGL ES Emulator:

      • Doesn't support GLES v3.1 AEP and v3.2.

      • OpenGL ES extension API shadow2DEXT can't be correctly supported in GLES Shading Language.

      • OpenGL ES APIs glTexSubImage and glCopyTexSubImage2D have errors for some special formats like GL_ALPHA.

      • Android applications using GPU resources in multi-threaded manner are not well supported and might lead to unpredictable behavior.

    • Some corner cases may fail on AMD and Intel HD Graphics cards due to native graphics driver issues.

    • For Intel HD Graphics card, a driver version above 10.18.15.4279 may bring unexpected failures for some corner cases.

    Limitations:

    • For applications that only do single frame rendering, the rendering result is invisible in Fast Model visualization window.

    • The MMU inside GPU can't be verified using GRM.

    Benchmark list verified:

    • GLMark2
    • GFX Bench v2.7.5 and v3.0.11
    • AnTuTu 3D Rating
    • GPU Benchmark 3D v1.2.3
    • Unity Benchmark v1.1.1
    • Mali SDK Samples
  • Platform examples

    FVP_Base_AEMv8A-AEMv8A-CMN600 is introduced in Fast Models 11.0.

    Rate-limiter has been turned to OFF by default on FVP platforms. Linux running on platform FVP_Base_AEMv8A-AEMv8A has been observed to become unresponsive after several hours. A work-around is to turn rate-limiter to ON (-C bp.vis.rate_limit-enable=1 )

  • Usage notes for the P-Channel power management protocol:

    • Master interface: void pactive (uint32_t power_state)
    • Slave interface: prespt_t prequest (uint32_t)
    • enum presp_t { ACCEPT, DENY }

    ARMv8A cores support the following enumeration for power_state:

    enum { OFF = 0, OFF_EMU, MEM_RET, MEM_RET_EMU, LOGIC_RET, FULL_RET, MEM_OFF, FUNC_RET,
        ON, WARM_RST, DBVG_RECOV }

    Components using P-Channel:

    • A Power-Controller implements void pactive (uint32_t power_state). power_state is kept as uint32_t because it is up to the "System" using P-Channels to decide the enumeration of power states it wants to support. A device calls this API to give a hint to the Power-Controller that it can go to a particular power state. A Power-Controller can take action based on its design. It will usually communicate to the device by calling device.prequest(new_power_state).

    • A device such as a CPU implements prespt_t prequest (uint32_t power_state). A Power-Controller would typically call prequest(new_power_state) on the device and look for a response, which can either be ACCEPT or DENY. A device implements this API and provides an appropriate response based on its logic.

    Usage changes between the old way of using stdbywfi/stdbywfe and P-Channels

    • Previously:

      • CPU: Drive stdbywfi = HIGH
      • Power-Controller: Perform some logic X
    • Now:

      • CPU: Call pactive(OFF)
      • Power-Controller: Call prequest(OFF) if it indeed wants CPU to go to OFF and then perform logic X

      When the controller wants to wake-up the CPU, it should send prequest(ON)

    For access to the following additional documentation, contact ARM:

    • ARM® Power Control System Architecture Specification, Version 1.0 (ARM DEN 0050)
    • ARM® Power Control System Architecture Supplement for ARM® Cortex™-A v8.2 Profile Processors (ARM DEN 0059)
    • AMBA® Low Power Interface Specification, ARM® Q-Channel and P-Channel Interfaces (ARM IHI 0068C ID091216)
  • AEMv8A core personalities

    The AEM core personalities feature allows you to configure AEM instances in a platform to use the IMPLEMENTATION DEFINED registers and UNPREDICTABLE behavior for a specific implementation of your choice at model startup.

    Configuring an AEM with a core personality requires a license for both the AEM and the selected implementation.

    Setting the personality can be done using either an environment variable or a parameter. The parameter allows you to configure different instances in the same platform with different personalities, including subclusters in a heterogeneous AEM. The environment variable takes precedence over the parameter and will affect all instances of the AEM in the platform. Other than this, the two function identically:

    • Environment variable FASTSIM_AEMV8_PROFILE.
    • Cluster or subcluster-level parameter impdef_regs_and_unpred_from_implementation.

    To see the available values for the environment variable or parameter, set either of them to the special value list. The model will print the list of available values and exit. An example value is: ARM_Cortex-A57. Then set the parameter or environment variable to the required value.

    Configuring a core personality only affects IMPLEMENTATION DEFINED registers and UNPREDICTABLE behaviour. In other respects, the cluster or subcluster will still behave like the AEM. For example, all parameters will default to the AEM default values. Therefore, parameters have to be manually configured to valid values for the configured personality, as many of the defaults will be incompatible with any given implementation.

    To assist with this, the AEM will print warnings for any parameter with an invalid value for the configured personality, listing the parameter name and the valid value or range of values it should be set to for the selected personality.

    Running the model with invalid parameter configurations for the selected personality may lead to unexpected behaviour.

  • Plugins:

    • TarmacTraceAEM has been removed.

    • Fastline has been introduced in Fast Models 11.0.

    • 'use_instr_cnt_as_timestamp', a new command line parameter has been added to TarmacTrace and TarmacTraceV8. When use_instr_cnt_as_timestamp is set to 1, it uses the instruction count instead of the simulation time as the timestamp in the trace. The default value is 0.

  • Support for Linux compiler GCC-4.7 has been removed from Fast Models 11.0.

Advanced Notice

  • Fast Models will deprecate TarmacTraceV8, resulting in a single TarmacTrace plugin.

  • The folder structure in FastModelsPortfolio will be refactored in a future release.

  • VFS will be removed in a future release. ARM recommends using Virtio P9 instead.

Notice

  • The BaseR platform swaps the upper 2GB address space with the lower 2GB in its memory map with respect to Base platform. This means that any peripherals in the memory range [0x0 - 0x7FFFFFFF] (in Base) will be available at the same offset in the memory range [0x80000000 - 0xFFFFFFFF] (in BaseR), and vice-versa.

    The DRAM in the Base platform memory map starts at address 0x80000000, which in BaseR would prevent any code from running from DRAM after reset since in the V8R architecture, the upper 2GB of memory (i.e. [0x80000000 - 0xFFFFFFFF]) do not have execution permissions by default (i.e. after reset).

  • C++11 was enabled in 10.1 and is in use from 10.2. For full compatibility, it is highly recommended that all code that links against the Fast Models should also be compiled with C++11 support enabled. While there are no known issues when linking non-C++11 code with the Fast Models, the compiler does not guarantee that the ABI is the same for both types of code, and compiling models with C++11 support disabled may cause data corruption or other issues when using them.

  • AMBAPV has been amended to bridge the ExtendedID and TranslatedAccess attributes of PVBus transactions

  • Fast Models 10.2 introduced API version checking for SystemC components. If you are using SystemC eXported components, you will need to ensure those components have been exported from the same version of Fast Models. Different versions in the same executable or library are not supported.

  • Format of traces generated by TarmacTrace has been modified to match the format generated by TarmacTraceV8.

  • Excessive license checkouts may appear in client license diagnostics (FLEXLM_DIAGNOSTICS=3). However, the correct number of licenses are actually checked out.

FLEXnet license management utilities

FLEXnet server binaries are no longer shipped with the product; if you need them, download them from https://developer.arm.com/products/software-development-tools/license-management/downloads.

Release 11.0 of Fast Models requires a newer version of the FLEXnet license management utilities. If you are using floating licenses, you need to upgrade to version 11.14.1.0 (or later) of the FLEXnet license management utilities. Prior versions are not compatible.

License queueing support

When using floating licenses, if all available licenses are in use, models and tools can be configured to queue until a license is available. This is enabled by setting the environment variable FM_LICENSE_QUEUE_TIMEOUT to a timeout value in seconds. The default value of 0 disables this feature.

Note that enabling this feature may cause model initialisation to take a long time, as models will wait for a license to become available until the timeout period expires, rather than failing immediately.

Linaro images and command lines tested in this release

All A-profile platforms available in this release have been validated against the following Linaro images: Android 16.12 for v8-A platforms and Android 15.03 for v7-A platforms.

The command lines tested are:

  • v8-A:

    FVP_Base_AEMv8A-AEMv8A \
    -C pctl.startup=0.0.0.0 -C bp.secure_memory=0 -C cache_state_modelled=0 -C bp.pl011_uart0.untimed_fifos=1 \
    -C bp.secureflashloader.fname=bl1.bin -C bp.flashloader0.fname=fip.bin \
    -C bp.ve_sysregs.mmbSiteDefault=0 -C bp.virtioblockdevice.image_path=fvp.img \
    --data cluster0.cpu0=Image@0x80080000 \
    --data cluster0.cpu0=fdt.dtb@0x82000000 \
    --data cluster0.cpu0=ramdisk.img@0x84000000
    EVS_Base_AEMv8A-AEMv8A.x \
    -C Base.pctl.startup=0.0.0.0 -C Base.bp.secure_memory=0 -C Base.cache_state_modelled=0 -C Base.bp.pl011_uart0.untimed_fifos=1 \
    -C Base.bp.secureflashloader.fname=bl1.bin -C Base.bp.flashloader0.fname=fip.bin \
    -C Base.bp.ve_sysregs.mmbSiteDefault=0 -C Base.bp.virtioblockdevice.image_path=fvp.img \
    --data Image@0x80080000 \
    --data fdt.dtb@0x82000000 \
    --data ramdisk.img@0x84000000
    (This command line is also valid for SVPs)
  • v7-A:

    FVP_VE_Cortex-A15x1-A7x1 \
    -C motherboard.flashloader0.fname=boot/rtsm/uefi_rtsm_ve-ca15.bin -C motherboard.flashloader1.fname=uefi-vars.fd \
    -C motherboard.flashloader1.fnameWrite=uefi-vars.fd -C motherboard.mmc.p_mmc_file=linaro.img \
    -C motherboard.pl011_uart0.unbuffered_output=true -C motherboard.smsc_91c111.enabled=1 \
    -C motherboard.hostbridge.userNetworking=1
    EVS_LinuxBoot_Cortex-A15x2 \
    -C Base.motherboard.flashloader0.fname=boot/rtsm/uefi_rtsm_ve-ca15.bin -C Base.motherboard.flashloader1.fname=uefi-vars.fd \
    -C Base.motherboard.flashloader1.fnameWrite=uefi-vars.fd -C Base.motherboard.mmc.p_mmc_file=linaro.img \
    -C Base.motherboard.pl011_uart0.unbuffered_output=true -C Base.motherboard.smsc_91c111.enabled=1 \
    -C Base.motherboard.hostbridge.userNetworking=1
    (This command line is also valid for SVPs)

Outstanding CT model issues

  • 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.

  • The following CADI methods are not supported by Fast Models:

    • CADI:
      • Parameter API
        • CADIGetParameters()
        • CADIGetParameterInfo()
        • CADIGetParameterValues()
        • CADISetParameters()
      • Register API
        • CADIGetCommitedPCs()
      • Memory API
        • CADIMemGetOverlays()
      • Virtual Memory API
        • PhysicalToVirtual()
      • Cache API
        • CADIGetCacheInfo()
        • CADICacheRead()
        • CADICacheWrite()
      • Execution API
        • CADIExecLoadApplication()
        • CADIExecUnloadApplication()
        • CADIExecGetLoadedApplications()
        • CADIExecAssertException()
        • CADIExecGetPipeStages()
        • CADIExecGetPipeStageFields()
        • CADIGetCycleCount()
    • CADIDisassembler:
      • GetSourceReferenceForAddress()
      • GetAddressForSourceReference()
      • GetInstructionType()
    • CADIDisassemblerCB:
      • ReceiveSourceReference()
  • CADI methods deprecated for use in Fast Models 11.0:

    • CADICallbackObj
      • appliOpen()
      • appliClose()
      • cycleTick()
      • killInterface()
  • 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.

  • A15 bus transactions are not bus accurate.

  • CADI and MTI names for CP15 registers are different.

  • Cache state modelling configuration is now verified at simulation start and the simulation will exit with an error message if an incorrect configuration is detected in the platform. For example:

    Error: MyPlatform: Incompatible Cache Configuration 
    Cache state modelling is on in my_platform.cci 
    Cache state modelling is off in my_platform.core.l2_cache
  • PVBus Fan out is not supported and a bus decoder is required in order to do this.

  • When semi-hosting is enabled on SystemC model and a read from stdin is done within the target software, the semi-hosting call from CADI does not originate from the SystemC thread. Consequently the complete simulation becomes blocked if the semi-hosting call cannot complete due to no user input.

  • Cache models may output debug messages on stderr even with --quiet.

  • The Watchpoint mask does not have the expected effect.

  • In some cases the Tarmac Trace reports an invalid physical address for some instructions. (In particular PA:0x000000000000).

  • When writing to MDSCR_EL1.SS on AEMv8A, it does not change status until an ERET is executed. This should be consistently managed by the has_delayed_sysreg parameter.

  • In some circumstances, the model will boot more slowly when an operating system filesystem image is used in read-only mode. The workaround is to make sure that the image is writeable.

  • The shareable override functionality of CCI400 does not work. The slave interface shareable override register exists and may be read and written but has no functionality.

  • The value of cpu.register_reset_data and cpu.scramble_unknowns_at_reset should be reflected in the bits of CNTHCTL_EL2 which reset value is UNKNOWN.

  • When EL3 == AArch32 and executing in AArch32 Secure EL1 (SVC_s), an update of the CNTP_CTL_S causes the tarmac log to print an update of CNTPS_CTL_EL1.

  • Breakpoints must be set after loading the image to be run, otherwise these will not be hit during execution even if the addresses are accessed.

  • Elf object loader ignores SHT_REL/SHT_RELA sections.

  • MAIR_ELx appear twice in the trace source SYSREG_UPDATE64.

  • Cortex-A53, A35 and A32 lack the Advanced SIMD Engine-present parameter.

  • A17 BROADCAST parameters should be at cluster level, not cpu level.

  • Visual Studio configuration files default to Win32 for MTI examples.

  • Trace plugin parameters cannot be set from a model parameter configuration file for any FVP. To workaround, set these parameters directly on the command line.

Outstanding tools issues

  • ModelDebugger does not display the correct values for wTasKMaskId.

  • The Cortex-M0 model exposes a VTOR register via CADI, but this register in not present in hardware.

Feedback on this product

If you have any comments or suggestions about this product, contact support-esl@arm.com and give:

  • The product name.

  • The product revision or version.

  • An explanation with as much information as you can provide. Include symptoms and diagnostic procedures if appropriate.