D3.2: User guide of the SAFEPOWER Virtual Platformsafepower-project.eu/wp-content/uploads/2018/03/D3... · V1.0 Document information Contract number 687902 Project website Contractual

D3.2: User guide of the SAFEPOWER Virtual Platform

V1.0

Document information Contract number 687902

Project website www.safepower-project.eu

Contractual deadline 31/08/2017

Dissemination Level PU

Nature Other

Author IMP

Contributors OFF

Reviewer FEN, IKL

Keywords Virtual Platform

Notices:

This project and the research leading to these results has received funding from the European Community’s

H2020 program [H2020-ICT-2015] under grant agreement 687902

2017 SAFEPOWER Consortium Partners. All rights reserved.

Ref. Ares(2017)4245261 - 30/08/2017

Page 2 of 69


Version 1.0

Change log

VERSION DESCRIPTION OF CHANGE

V0.1 Initial

V0.2 Including review notes from IKL

V0.3 Including review from IKL and FEN

V1.0 Submitted version

Page 3 of 69


Version 1.0

Table of contents

1. PREFACE ................................................................................................................ 7

2. INTRODUCTION ...................................................................................................... 8

2.1. VLNV COMPONENT LIBRARY ............................................................................................... 9

2.2. DOCUMENT REFERENCES .................................................................................................... 9

3. INSTALLATION ..................................................................................................... 11

3.1. INSTALLATION PACKAGES ................................................................................................. 11

3.2. SETTING UP ENVIRONMENT .............................................................................................. 12

3.3. SETTING UP LICENSING ..................................................................................................... 12

4. VIRTUAL PLATFORM DESCRIPTION ....................................................................... 13

4.1. EXECUTION HARNESS ........................................................................................................ 13

4.1.1. Introduction .................................................................................................. 13

4.1.2. Command Line.............................................................................................. 14

4.2. BOARD DEFINITION ........................................................................................................... 15

4.3. ZYNQ SOC .......................................................................................................................... 15

4.4. PROCESSING SUB-SYSTEM (PS) ......................................................................................... 15

4.5. INTERCONNECT ................................................................................................................. 17

4.6. PROGRAMMABLE LOGIC (PL) ............................................................................................ 17

4.6.1. Default PL module ........................................................................................ 17

4.6.2. PL module Zynq_PL_SingleMicroblaze ......................................................... 19

4.6.3. PL module Zynq_PL_DualMicroblaze ........................................................... 22

4.6.4. PL module Zynq_PL_NoC ............................................................................. 25

4.6.5. Zynq_PL_NoC_node Module ........................................................................ 28

4.6.6. NoC Peripheral ............................................................................................. 30

4.7. LINUX KERNEL ‘SMARTLOADER’ COMPONENT ................................................................. 31

5. BINARY INTERCEPTION LIBRARY ........................................................................... 33

Page 4 of 69


Version 1.0

5.1. INTERCEPTION LIBRARY TECHNOLOGY ............................................................................. 33

5.2. ADDING AND CONFIGURING AN INTERCEPTION LIBRARY ................................................ 34

5.3. POWER INTERCEPTION LIBRARY ....................................................................................... 35

5.4. FAULT INJECTION LIBRARY ................................................................................................ 37

6. STARTING SIMULATION ........................................................................................ 38

6.1. STANDARD COMMAND LINE ARGUMENTS ....................................................................... 38

6.2. BAREMETAL APPLICATION ON PROCESSING SUB-SYSTEM ............................................... 39

6.3. BAREMETAL APPLICATION ON PROGRAMMABLE LOGIC PROCESSOR ............................. 39

6.4. LINUX KERNEL ON PROCESSING SUB-SYSTEM .................................................................. 40

7. EXAMPLES ........................................................................................................... 42

7.1. BAREMETAL SINGLE MICROBLAZE PL ................................................................................ 42

7.2. BAREMETAL DUAL MICROBLAZE PL WITH SHARED MEMORY COMMUNICATION ........... 45

7.3. BAREMETAL NOC PL NETWORK COMMUNICATION ......................................................... 47

7.4. LINUX KERNEL .................................................................................................................... 48

7.4.1. Running Zynq with Linux Kernel ................................................................... 49

7.4.2. Running Zynq with Linux Kernel and Imperas Tools .................................... 50

7.5. XTRATUM HYPERVISOR EXAMPLES ................................................................................... 53

7.5.1. Running with ‘Hello World’ Example ........................................................... 53

7.5.2. Running with ‘4led_3push’ Example ............................................................ 55

7.6. NOC EXAMPLES ................................................................................................................. 59

7.6.1. Nostrum NoC ................................................................................................ 59

7.6.2. TTEL NoC (SAFEPOWER Implementation) .................................................... 63

7.6.3. Running Zynq with TTEL NoC USI Example (SAFEPOWER Example) ............ 65

8. REFERENCES ......................................................................................................... 69

Page 5 of 69


Version 1.0

Index of Figures

Figure 1: Zynq Block Diagram ..................................................................................................... 8

Figure 2: Virtual Platform Block Diagram ................................................................................. 13

Figure 3: Module External Port Connection ............................................................................. 17

Figure 4: PL Block Diagram for Single Microblaze .................................................................... 20

Figure 5: PL Block Diagram for Dual Microblaze Subsystems .................................................. 23

Figure 6: PL Block Diagram for NoC System ............................................................................. 26

Figure 7: PL Block Diagram for NoC System ............................................................................. 34

Figure 8: Instructions to include a binary interception library ................................................. 34

Figure 9: Overview of the location of the Power Interception Library .................................... 35

Figure 10: Overview of the components of the Power Interception Library ........................... 35

Figure 11: Virtual Platform output [11] .................................................................................... 36

Figure 12: UART output of executed application requesting sensor information through PMBus [11]............................................................................................................................... 37

Figure 13: Overview of the location of the Power Interception Library [11] ........................... 37

Figure 14: PL Defining Microblaze Subsystem ......................................................................... 43

Figure 15: PL Defining Dual Microblaze Subsystem with Shared memory .............................. 46

Figure 16: Block Diagram of NoC System ................................................................................. 47

Figure 17: Executing Linux Kernel with Console Output .......................................................... 49

Figure 18: Visualization of the Xilinx zc706 LEDs and Switches ............................................... 58

Page 6 of 69


Version 1.0

Index of Tables

Table 1: Processing Sub-System Model Status ......................................................................... 15

Table 2: Processing Subsystem Processor Model Components ............................................... 16

Table 3: Accesses performed by the local processor ............................................................... 21

Table 4: External Port (incoming) Access from other masters ................................................. 21

Table 5: External bus master access ......................................................................................... 24

Table 6: Microblaze sub-system access .................................................................................... 24

Table 7: External bus master access ......................................................................................... 27

Table 8: The NoC Peripheral Register Interface ....................................................................... 30

Table 9: Fields defining NI Configuration ................................................................................. 62

Table 10: Example port 0 configuration ................................................................................... 68

Table 11: Example port 1 configuration ................................................................................... 68

Page 7 of 69


Version 1.0

1. PREFACE

This document is intended to provide the information required to work with the SAFEPOWER virtual platform.

Imperas creates Extendable Platform Kits (EPKs) to allow customers to quickly start executing demonstration example software on a virtual platform.

An EPK is a package containing a virtual platform definition, the models used within the platform and also software and applications to execute on the processors within the platform.

The EPK definition can be extended by customers to allow new hardware devices to be added with additional application and driver software. The extensions could be done for:

1) Adding new peripheral devices to the main hardware definition, this is essentially making changes to the Zynq definition which is not possible in hardware.

2) Creating a new Zynq Programmable Logic definition, this can be any combination of devices, memories, interconnects that could be programmed into the Zynq FPGA

3) Adding additional tools for the analysis of the execution of the application on the virtual platform

IMP provide tools in the M*SDK product to aid in the development of software on this platform.

This document, after a short introduction, in chapter 0, presents the installation packages provided by IMP that have been used in the SAFEPOWER project and; in chapter 0, a description of the virtual platform that they provide. Chapter 0 introduces how extension libraries can be added to a virtual platform to provide analysis or other tool features.

The overall control and configuration of the virtual platform is described in chapter 6 with a number of examples described in chapter 0. Finally, chapter 8 introduces how the Timer Triggered system operates in the virtual platform.

Page 8 of 69


Version 1.0

2. INTRODUCTION

The SAFEPOWER virtual platform EPK, which has been developed based on the Zynq platform consists mainly of a Processing Sub-system and Programmable Logic, as shown in the following Xilinx product diagram. However, as mentioned before, this virtual platform could be easily adapted or extended to any platform.

Figure 1: Zynq Block Diagram

The virtual platform apart from the processor also includes the main components of the PCB used during the project; that is to say, the zc702/zc706 evaluation boards and the SAFEPOWER PCB.

Nevertheless, the virtual platform does not include all aspects of the Xilinx zc706/zc702 and SAFEPOWER boards or the Zynq-7000 processor. The virtual platform EPK provides the behavioral features of the platform that allow a software application to execute as it would be on the real hardware platform.

The EPK provides the Processing Sub-system (PS) which is a fixed definition that comprises an ARM Cortex-A9MPx2 processor and other peripheral components (Ethernet, I2C, SPI, UART) and memory (DRAM, QSPI). Some of these components have been modelled as register only models, see reference [1], defining the registers of the component and the read/write capabilities without including any behaviour associated to the access of those registers. On the other hand, Ethernet, UART or DI/DO behave like the real board accessing the peripherals of the host where the platform is executed (DI/DO are mapped to a Web page).

Page 9 of 69


Version 1.0

The memory interface to the Programmable Logic (PL) is provided allowing accesses between the PS to the PL at the defined address ranges.

The PL is defined using standard OVP module design. The module may include any OVP components, processors, peripherals, memory etc. and be connected using any bus architecture. The PL module can communicate with the PS via the defined memory interconnect interface.

There may be many PL modules representing alternative hardware designs that can be loaded into the programmable device. The method of designing a module is described in the OVP document iGen Platform and Module Creation User Guide [3]. Each is defined and stored in the Imperas VLNV library and can be loaded to represent any programmable elements by selecting the module using a Zynq platform command line argument. The VLNV library is explained in the Imperas Installation and Getting Started guide [2].

2.1. VLNV Component Library

OVP and Imperas utilize a VLNV library structure for model source and for the compiled binary output. The VLNV library provides a unique identifier for all components using Vendor, Library, Name and Version specifiers.

A user should create their own VLNV library in which to create new components and modules which can then be specified to be searched for models in addition to the standard library using the –vlnvroot command line argument.

The peripheral models are located in a ‘peripheral’ Library. They are developed by first creating a programmers view template as described in the document iGen Peripheral Generator User Guide [4] and then creating behavior as described in the document OVP Peripheral Modeling Guide [5].

The hardware definition is created as a module and located in a ‘module’ Library. They are developed as described in the document iGen Platform and Module Creation User Guide [3].

A pre-defined VLNV component library is provided with the OVP and Imperas products.

The model source library is located at

IMPERAS_HOME/ImperasLib/source

With corresponding output binary library located by the IMPERAS_VLNV environment variable which is set to

IMPERAS_HOME/lib/IMPERAS_ARCH/ImperasLib

2.2. Document References

The following documents were used in the creation of the EPK and component models.

Page 10 of 69


Version 1.0

ZC706 Evaluation Board for the Zynq-7000 XC7Z045 All Programmable SoC UG945 v1.5 September 10, 2014 (ug954-zc706-eval-board-xc7z045-ap-soc)[6]

ZC702 Board user Guide UG850 (v1.5) September 4,2015 (ug850-zc702-eval-bd.pdf) [7]

Zynq-7000 AP SoC Technical Reference Manual UG585 (v1.10) February 23, 2015 (ug585-Zynq-7000-TRM.pdf)[8]

D3.1 Architecture Design of Virtual Platform[1]

Page 11 of 69


Version 1.0

3. INSTALLATION

This chapter will explain the necessary installation process to put SAFEPOWER virtual platform EPK running. Further explanation can be found in the Imperas Installation and Getting Started Guide [2].

3.1. Installation Packages

The SAFEPOWER virtual platform EPK is provided as two installation packages, a standard product package and a demo/example package.

The standard components used in the PS and PL examples are provided as part of a standard product release, such as M*SDK that is provided as the installation package Imperas_SDK.

The Xilinx Zynq examples are provided as a separate package, Demo_Xilinx_Zynq, which also provides the harness to configure and execute the Xilinx Zynq module.

In addition the package Demo_Xilinx_Zynq_SAFEPOWER provides examples specific to the European SAFEPOWER project for which the SAFEPOWER virtual platform was initially developed.

The self extracting installers are provided for both Linux and Windows, 32-bit and 64-bit host machines in the following URL: www.imperas-user-com. Once the installer is downloaded the following steps can be followed (for a Linux installer), although further details can be found in the Imperas Installation and Getting Started Guide [2], available in the Installation doc directory or from the OVP World website:

Ensure the installer is executable and execute the self extracting installer:

$ chmod +x Imperas_SDK.20161005.0.Linux64.exe

$ ./Imperas_SDK.20161005.0.Linux64.exe

Accept the license agreement. If you want to install in the current directory (that will be displayed) type CR, if not type no and provide the required installation directory.

Take into account that all the packages/toolchains that want to be added should be installed on the same directory.

The Linux installation would be provided as shown below:

$ /home/SAFEPOWER/Imperas.201XYYZZ

Page 12 of 69


Version 1.0

3.2. Setting up environment

The environment required to execute an OVP or Imperas product is described in detail in the Imperas Installation and Getting Started Guide [2], provided as part of a product installation.

On Linux it is required to source the script Imperas/bin/setup.sh in the shell and then invoke the function setupImperas and provide to it the full PATH to the installation root directory1. On Windows the installer will setup the environment for you.

Only one installation is possible on Windows, whereas, on Linux multiple installations may co-exist.

3.3. Setting up Licensing

The licenses are served from a license server executing on the physical machine that has the host MAC address and server name provided to Imperas and included in the license file from Imperas. The license server can serve licenses to any other machine on the same network.

Details of how to start a license server for a Linux and Windows Host machine can be found in the Imperas Installation and Getting Started Guide [2].

1 In order to avoid writing these commands every time a new shell could be opened and the environment

variables copied them into the .bashrc file.

Page 13 of 69


Version 1.0

4. VIRTUAL PLATFORM DESCRIPTION

The virtual platform consists of a Zynq harness that loads a module defining the board (zc706, zc702 or SAFEPOWER PCB). This instances a Zynq module that in turn instances a Processing Sub-System (PS) module and can instance any defined Programmable Logic (PL) module. By default, if no PL is supplied on the command line, a default module is loaded that has no behaviour.

Figure 2: Virtual Platform Block Diagram

4.1. Execution Harness

4.1.1. Introduction

An execution harness creates a ‘root’ module, into which the board module is instanced. Then, it configures the system to be ready for the execution of software.

The harness incorporates a command line argument parser, which includes the standard simulator arguments and also some specific arguments for this system, as described in the following section.

The module instanced is either the zc706 (default), the zc702 module or SAFEPOWER PCB depending upon command line option.

Page 14 of 69


Version 1.0

4.1.2. Command Line

There are standard command line arguments used in this harness that are provided by the simulator.

--override is used to modify the configuration of components in the virtual platform

--program specifies an elf file to be loaded on a specific processor or onto all processors in the virtual platform

--output specifies the log file

--verbose creates a verbose output from the simulator indicating what is being loaded

--help provides a list of all the command line arguments provided by the harness and the simulator

There are specific command line arguments that are defined within the harness to control specific features of this environment.

Board configuration definition

--boardtype is used to define the board definition being used i.e. zc706 (default), zc702 or SAFEPOWER PCB. This provides the routing of board features, for example LED and switches on the GPIO connections

Specification of the PL module to load

--plmodulevendor is used to define the vendor for the Programming Logic module that should be loaded

--plmoduletype is used to define the type for the Programming Logic module that should be loaded

These configurations are used to locate the PL module in the VLNV library tree. The library is fixed as module and the version as 1.0 when selecting the PL to load.

For control of a Linux kernel specification and boot the following arguments will be used to configure PS initialization components

--zimage specifies the zImage of the Linux Kernel to be loaded. The zImage is expected to have the Device Tree appended

Page 15 of 69


Version 1.0

--initrd specifies the initial ramdisk to be loaded

--boot specifies boot code to be executed before the Linux Kernel. This typically puts all but one core into a halted state

--smartloader enables the smartLoader peripheral. This is used to configure the platform into a state ready for the Linux Kernel to be executed. It replaces the operation and requirement of full boot software.

4.2. Board Definition

The board definition module defines the main board which instances the Zynq device and includes the correct user visualization interfaces to the LEDs and switches of the board.

The physical interface, power supply and other components that reside on the real hardware are not modeled as part of a virtual platform.

Note that the memory is instanced as part of the Processing Sub-System rather than the board module.

4.3. Zynq SoC

The Zynq module, as explained previously, instances the Processing Sub-system module and a Programmable Logic module.

4.4. Processing Sub-System (PS)

The Processing Sub-system is a fixed module in the VLNV library, xilinx.ovpworld.org/module/Zynq_PS/1.0, that contains an ARM Cortex-A9MPx2 processor, memory and other peripheral components. This section defines the components of the Zynq PS module and the model status (more detail about the different model status in [1]).

Table 1: Processing Sub-System Model Status

Component Model Status

ARM Cortex-APMPx2 Full complete and verified

uart0/uart1 Supports standard I/O and interrupt generation. Does not model physical aspects of the device e.g. baud rate

Slcr Register reset values, allows reset of CPU cores and controls OCM mapping.

Devcfg Minimal behavior for XADC access

USB/USB1 Register only

I2C0/I2C1 Model Implemented

Page 16 of 69


Version 1.0


SPI0/SPI1 Register only

CAN0/CAN1 Register only

GPIO Model Implemented

ETH0/ETH1 Model Implemented

Quad-SPI Model Implemented – single Flash type provided

Static Memory Controller (SMC) Register only

System-Level Control registers (SLCR) Register only

Triple Timer Counter0 (TTC) Model Implemented

Triple Timer Counter1 (TTC) Model Implemented

DMAC (DMAC S) (DMAC) Register only

System Watchdog Timer (SWDT) Model Implemented

DDR Memory Controller (DDRC) Register only

Device Configuration Interface (DEVCFG) Register only

AXI HP0 (AFI)/ AXI HP1 (AFI)/AXI HP2 (AFI)/AXI HP3 (AFI)

Dummy

eFuse Dummy

SDIO0/SDIO1 Register only

ARM L2 Cache Controller (PL310) Register only

Top level interconnect and Global Programmers View (GPV)

Not modeled

DDR Simulator Memory

On-chip Memory (OCM) Simulator Memory

ARM processor model CBAR, which corresponds to the value on the PERIPHRESET input pins of the ARM processor, is set to 0xf8f00000 to base the CPU Model internal register address mappings correctly for the following components that are implemented as part of the processor model.

Table 2: Processing Subsystem Processor Model Components


SCU Control and Status CPU Core Model

Interrupt Controller CPU CPU Core Model

Global Timer CPU Core Model

Private Timers and Private Watchdog Timers CPU Core Model

Interrupt Controller Distributor CPU Core Model

Page 17 of 69


Version 1.0

4.5. Interconnect

There is a memory connection between the PS and PL that allows the ARM processor of the PS to access any memory regions within the PL and also any processors in the PL to access shared memory regions in the PS.

Each module has a bus port defined, busPort, that can be used to connect modules together in a higher level module by connecting the bus ports to a shared bus.

Within a module the bus port is connected to an internal bus. The bridge component is used to add connections between busses. The bridge creates an uni-directional connection so for accesses both into a module and from a module two bridges are used as shown in the following diagram.

Figure 3: Module External Port Connection

4.6. Programmable Logic (PL)

The Programmable Logic subsystem is a module loaded from the VLNV library that has an interface and can contain any combination of components, memories and interconnects. The default module is xilinx.ovpworld.org/module/Zynq_PL_Default/1.0.

There are a number of example PL module alternatives provided by Imperas in the Xilinx Zynq package that can be loaded into the virtual platform:

4.6.1. Default PL module

All modules have the same initial construction that defines their VLNV, which must be unique.

User-defined modules should be developed in a local VLNV library separately from the standard library provided as part of an OVP or Imperas product installation, so that they will not be overwritten when a new version of the Imperas products are installed.

Page 18 of 69


Version 1.0

set desc "This module implements a default of the Xilinx Zynq Programmable Logic

(PL).

This PL configuration instances no devices or memory."

set limitations "The is baremetal only."

set reference "No Reference"

set license "Open Source Apache 2.0"

# Setup variables for platform info

set vendor xilinx.ovpworld.org

set library module

set name Zynq_PL_Default

set version 1.0

#

# Start new platform creation

#

ihwnew -name $name -vendor $vendor -library $library -version $version -stoponctrlc

-purpose module -releasestatus ovp

iadddocumentation -name Licensing -text $license

iadddocumentation -name Description -text $desc

iadddocumentation -name Limitations -text $limitations

iadddocumentation -name Reference -text $reference

# Include the default interconnect ports and signals for the PL to PS

source

"$env(IMPERAS_HOME)/ImperasLib/source/xilinx.ovpworld.org/module/Zynq_PL_Default/1.

0/module/PS_PL_interconnect.tcl"

The default module includes a common file, PS_PL_interconnect.tcl, that should be included into ALL PL modules to defines all the connections between the PL and PS.

#

# This file defines the common interconnet signals to a PL module

#

#

# Bus connections

#

ihwaddbusport -instancename extPort

ihwaddbus -instancename extPortBus -addresswidth 32

ihwconnect -busport extPort -bus extPortBus

#

# GPIO connections

#

# Common procedure to add GPIO connection

proc addGPIOConnection {bank} {

ihwaddnet -instancename gpio_bank${bank}_out

ihwaddnetport -instancename gpio_bank${bank}_outP

ihwconnect -netport gpio_bank${bank}_outP -net gpio_bank${bank}_out

ihwaddnet -instancename gpio_bank${bank}_oen_out

ihwaddnetport -instancename gpio_bank${bank}_oen_outP

ihwconnect -netport gpio_bank${bank}_oen_outP -net gpio_bank${bank}_oen_out

ihwaddnet -instancename gpio_bank${bank}_in

ihwaddnetport -instancename gpio_bank${bank}_inP

ihwconnect -netport gpio_bank${bank}_inP -net gpio_bank${bank}_in

Page 19 of 69


Version 1.0

}

addGPIOConnection 2

addGPIOConnection 3

#

# Interrupt connections

#

# Interrupt connections PL to PS

proc addIntPL2PS {irq} {

ihwaddnet -instancename irqf2p${irq}

ihwaddnetport -instancename irqf2p${irq}_outP

ihwconnect -netport irqf2p${irq}_outP -net irqf2p${irq}

}

# SPI (0-15)

# IRQ and FIQ interrupts to cpu_CPU0 and cpu_CPU1 (16-19)

for {set irq 0} {$irq <= 19} {incr irq} {

addIntPL2PS ${irq}

}

# Interrupt connections PS to PL

proc addIntPS2PL {irq} {

ihwaddnet -instancename irqp2f${irq}

ihwaddnetport -instancename irqp2f${irq}_inP

ihwconnect -netport irqp2f${irq}_inP -net irqp2f${irq}

}

for {set irq 0} {$irq <= 28} {incr irq} {

addIntPS2PL ${irq}

}

This creates a bus, extPort, to which all other address mapped components can be connected.

It is important to correctly expose the address ranges for slave access (accesses from an external master) and master access (accesses from a master device within this module or sub-modules) onto this bus. This is performed using bridges that define the address ranges between two separate busses. This is shown in further PL module examples.

There are ports for GPIO bank input and output connection ports for GPIO2 and GPIO3 banks. There are also ports for the interrupt lines. As it has been explained before the default module has no behavior.

4.6.2. PL module Zynq_PL_SingleMicroblaze

This module instances a single Microblaze processor with local and shared memory. This subsystem is a module loaded from the VLNV library SAFEPOWER.ovpworld.org/module/Zynq_PL_SingleMicroBlaze/1.0.

The start of the module definition is the same as the default PL module.

set desc "This module implements a configuration for Xilinx Zynq Programmable Logic

(PL).

This PL configuration instances one Xilinx MicroBlaze processor and local memory.

Also included is an area of shared memory that can be accessed by the Microblaze

processor or other external master."

Page 20 of 69


Version 1.0

set limitations "The is baremetal only."




set vendor SAFEPOWER.ovpworld.org

set library module

set name Zynq_PL_SingleMicroblaze

set version 1.0

#


#








source



We can now start adding the additional components into the PL and connect them together to provide the sub-system shown in the following figure.

Figure 4: PL Block Diagram for Single Microblaze

#

# pBus

#

ihwaddbus -instancename pBus -addresswidth 32

#

Page 21 of 69


Version 1.0

# Processor

#

ihwaddprocessor -instancename cpu -type microblaze -vendor SAFEPOWER.ovpworld.org -

version 1.0 \

-defaultsemihost

ihwconnect -instancename cpu -bus pBus -busmasterport INSTRUCTION

ihwconnect -instancename cpu -bus pBus -busmasterport DATA

There is an area of memory on the local processor bus that can only be accessed by the local connected processor.

# Local Processor

# 0x00000000 0x03ffffff RAM

ihwaddmemory -instancename ram -type ram

ihwconnect -instancename ram -bus pBus -busslaveport sp1 \

-loaddress 0x00000000 -hiaddress 0x03ffffff

We also add a ‘shared’ bus with a memory attached. We will add bridges to allow this to be accessed from the local processor and the external port.

#

# sBus (shared resources)

#

ihwaddbus -instancename sBus -addresswidth 32

# 0x00000000 0x03ffffff RAM (shared)

ihwaddmemory -instancename ramS -type ram

ihwconnect -instancename ramS -bus sBus -busslaveport sp1 \


We will use bridges to connect address ranges between the external port bus, the local processor bus and the shared bus. The bridges create the address map shown in the following tables.

Table 3: Accesses performed by the local processor

Low address High address Description

0x54000000 0xffffffff No Access

0x50000000 0x53ffffff External Port (master) Low address maps to external address 0x00000000

0x40000000 0x43ffffff RAM (shared memory)

0x04000000 0x3fffffff No Access

0x00000000 0x03ffffff RAM (local memory)

Table 4: External Port (incoming) Access from other masters


0x00000000 0x03ffffff RAM at local address 0x40000000 (shared)

Page 22 of 69


Version 1.0

The bridges to create the mappings for the local processor are shown below. These are mapping address ranges on the processor local bus, pBus, to the external port bus, extportbus.

# Local Processor (shared memory)

# 0x40000000 0x43ffffff

ihwaddbridge -instancename pBusToMem

ihwconnect -instancename pBusToMem -busslaveport sp1 -bus pBus \


ihwconnect -instancename pBusToMem -busmasterport mp1 -bus sBus \


# Local Processor (Access to External Processor Sub-System)

# 0x50000000 0x53ffffff (maps to 0x00000000 to 0x03ffffff)

ihwaddbridge -instancename pBusToextPort

ihwconnect -instancename pBusToextPort -busslaveport sp1 \

-bus pBus -loaddress 0x50000000 -hiaddress 0x53ffffff

ihwconnect -instancename pBusToextPort -busmasterport mp1 \

-bus extPortBus -loaddress 0x00000000 -hiaddress 0x03ffffff

The bridges to create the mappings for the local processor are shown below. These are mapping address ranges on the processor local bus, pBus, to the external port bus, extportbus.

#

# External devices access

#

# 0x00000000 0x03ffffff RAM (external port access)

ihwaddbridge -instancename extPortToMem

ihwconnect -instancename extPortToMem -busslaveport sp1 -bus extPortBus \


ihwconnect -instancename extPortToMem -busmasterport mp1 -bus sBus \


4.6.3. PL module Zynq_PL_DualMicroblaze

This module instances two Zynq_PL_SingleMicroblaze modules, each of which includes a single Microblaze processor with local and shared memory. This module also instances its own shared memory and creates interconnections allowing its access from either a Microblaze sub-system or from other modules. This subsystem is a module loaded from the VLNV library SAFEPOWER.ovpworld.org/module/Zynq_PL_DualMicroBlaze/1.0.

The start of the module definition is the same as the default PL module.


(PL).

This PL configuration instances two Xilinx MicroBlaze processors sub-systems, each

with a local and shared memory.

Also included is an area of shared memory that can be accessed by the Microblaze

sub-systems or other external master."

set limitations "This is baremetal only."



Page 23 of 69


Version 1.0



set library module

set name Zynq_PL_DualMicroblaze

set version 1.0

#


#








source



The two Zynq_PL_SingleMicroblaze sub-systems are included with a shared memory to create the sub-system shown in the following figure.

Figure 5: PL Block Diagram for Dual Microblaze Subsystems

This instances two microblaze sub-systems and a top level shared memory.

#

# Microblaze sub-module 1

#

ihwaddmodule -instancename mbsub1 \

-vendor SAFEPOWER.ovpworld.org -type Zynq_PL_SingleMicroblaze \

-library module -version 1.0

ihwaddbus -instancename mbsub1_PortBus -addresswidth 32

ihwconnect -instancename mbsub1 -busport extPort -bus mbsub1_PortBus

#

# Microblaze sub-module 2

Page 24 of 69


Version 1.0

#

ihwaddmodule -instancename mbsub2 \

-vendor SAFEPOWER.ovpworld.org -type Zynq_PL_SingleMicroblaze \


ihwaddbus -instancename mbsub2_PortBus -addresswidth 32

ihwconnect -instancename mbsub2 -busport extPort -bus mbsub2_PortBus

#

# Top Level Shared Memory

#

ihwaddbus -instancename shrmem_Bus -addresswidth 32

ihwaddmemory -instancename shrmem -type ram

ihwconnect -instancename shrmem -bus shrmem_Bus -busslaveport sp1 -loaddress

0x00000000 -hiaddress 0x000fffff

The address mapping allows master access from an external bus master using the busPort connection. So, for example, the ARM processor within the Zynq_PS module may access the resources of the Zynq_PL using the following addresses:

Table 5: External bus master access


0x4a000000 0x4affffff Access to Microblaze subsystem 1 shared memory

0x45000000 0x48ffffff Access to Microblaze subsystem 2 shared memory

0x41000000 0x44ffffff Access to shared memory

Table 6: Microblaze sub-system access


0x00100000 0x03ffffff Access Zynq_PS (ARM Processing System)

0x00000000 0x000fffff Access to shared memory

The bridges that provide the access from the module port into the module are generated with the following instances. In the second and third code snippets, the bridges that provide the access from the Microblaze sub-system modules.

# Bridge mbsub1 from input port

# 0x41000000 to 0x44ffffff

ihwaddbridge -instancename msub1_extPort

ihwconnect -instancename msub1_extPort -busslaveport sp1 -bus extPortBus -

loaddress 0x41000000 -hiaddress 0x44ffffff

ihwconnect -instancename msub1_extPort -busmasterport mp1 -bus mbsub1_PortBus -


# Bridge mbsub2 from input port

# 0x45000000 to 0x48ffffff

ihwaddbridge -instancename msub2_extPort

ihwconnect -instancename msub2_extPort -busslaveport sp1 -bus extPortBus -


ihwconnect -instancename msub2_extPort -busmasterport mp1 -bus mbsub2_PortBus -


# Bridge shared memory from input port

# 0x4a000000 to 0x4affffff

ihwaddbridge -instancename shrmem_extPort

ihwconnect -instancename shrmem_extPort -busslaveport sp1 -bus extPortBus -

loaddress 0x4a000000 -hiaddress 0x4a0fffff

Page 25 of 69


Version 1.0

ihwconnect -instancename shrmem_extPort -busmasterport mp1 -bus shrmem_Bus -

loaddress 0x00000000 -hiaddress 0x000fffff

# Bridge mbsub1 to output port

# 0x00100000 to 0x03ffffff

ihwaddbridge -instancename msub1_out_extPort

ihwconnect -instancename msub1_out_extPort -busslaveport sp1 -bus

mbsub1_PortBus -loaddress 0x00100000 -hiaddress 0x03ffffff

ihwconnect -instancename msub1_out_extPort -busmasterport mp1 \


# Bridge mbsub2 to output port

# 0x00100000 to 0x03ffffff

ihwaddbridge -instancename msub2_out_extPort

ihwconnect -instancename msub2_out_extPort -busslaveport sp1 \

-bus mbsub2_PortBus -loaddress 0x00100000 -hiaddress 0x03ffffff

ihwconnect -instancename msub2_out_extPort -busmasterport mp1 \


# Bridge mbsub1 to shared memory

# 0x00000000 to 0x000fffff

ihwaddbridge -instancename msub1_shrmem

ihwconnect -instancename msub1_shrmem -busslaveport sp1 \

-bus mbsub1_PortBus -loaddress 0x00000000 -hiaddress 0x000fffff

ihwconnect -instancename msub1_shrmem -busmasterport mp1 \

-bus shrmem_Bus -loaddress 0x00000000 -hiaddress 0x000fffff

# Bridge mbsub2 to shared memory

# 0x00000000 to 0x000fffff

ihwaddbridge -instancename msub2_shrmem

ihwconnect -instancename msub2_shrmem -busslaveport sp1 \

-bus mbsub2_PortBus -loaddress 0x00000000 -hiaddress 0x000fffff

ihwconnect -instancename msub2_shrmem -busmasterport mp1 \

-bus shrmem_Bus -loaddress 0x00000000 -hiaddress 0x000fffff

4.6.4. PL module Zynq_PL_NoC

This module instances four sub-modules each of which comprises a MicroBlaze processor, memory and a NoC interface peripheral. At the interface to the Zynq_PS, ARM Cortex-A9MPx2 based sub-system, a further NoC interface peripheral is memory mapped for access by the ARM processor cores. This subsystem is a module loaded from the VLNV library SAFEPOWER.ovpworld.org/module/Zynq_PL_Noc/1.0.

The five NoC interface peripherals are connected together, utilizing the Imperas packetnet interface, to allow message transfers between any nodes as a point to point connection. Each node is identified by an ID set using an attribute.

The module definition is the same as the default PL module.


(PL).

This PL configuration instances four Xilinx MicroBlaze processors based NoC sub-

systems, each with a local memory and NoC Peripheral interface.

Also included is NoC peripheral that is accessible from the Zynq_PS ARM

processors."


Page 26 of 69


Version 1.0





set library module

set name Zynq_PL_NoC

set version 1.0

#


#







#

# Top Level NoC connection (memory interface to ARM Sub-System)

#


source



The Zynq_PL_NoC has a local memory and interface to the packetnet and four instances of a Zynq_PL_NoC_node sub-system also connected to the packetnet as shown in the following figure.

Figure 6: PL Block Diagram for NoC System

Page 27 of 69


Version 1.0

This instances the packetnet ‘network’ connection, a top level memory and the NoC Interface peripheral.

#

# network connection

#

ihwaddpacketnet -instancename network

# Bus

ihwaddbus -instancename mBus -addresswidth 32

# Bridge local memory from input port

# 0x41000000 to 0x410fffff

ihwaddbridge -instancename smem_extPort

ihwconnect -instancename smem_extPort -busslaveport sp1 -bus extPortBus \

-loaddress 0x41000000 -hiaddress 0x410fffff

ihwconnect -instancename smem_extPort -busmasterport mp1 -bus mBus \


# Bridge NoC node registers from input port

# 0x41000000 to 0x410fffff

ihwaddbridge -instancename nocif_extPort

ihwconnect -instancename nocif_extPort -busslaveport sp1 -bus extPortBus \

-loaddress 0x44000000 -hiaddress 0x440003ff

ihwconnect -instancename nocif_extPort -busmasterport mp1 -bus mBus \


# NoC node

ihwaddperipheral -instancename node -type node -vendor SAFEPOWER.ovpworld.org

ihwconnect -instancename node -bus mBus -busslaveport hostif \


ihwsetparameter -handle node -name id -type uns32 -value 5

ihwconnect -instancename node -packetnet network -packetnetport network

# Memory

ihwaddmemory -instancename smem -type ram

ihwconnect -instancename smem -bus mBus -busslaveport sp1 \


The address mapping allows a master access from an external bus master using the busPort connection. So, for example, the ARM processor within the Zynq_PS module may access the resources of the Zynq_PL using the following addresses.

Table 7: External bus master access


0x41000000 0x410fffff Access to memory

0x44000000 0x440003ff Access to NoC Peripheral Registers and internal memory

The NoC_node is a separate module that is instanced 4 times in the NoC. The only connection between them is the packetnet ‘network’ interface. Each of the modules NoC peripheral is configured by setting the nocid parameter to a unique number.

Page 28 of 69


Version 1.0

#

# Microblaze NoC 1

#

ihwaddmodule -instancename mbNoC1 \

-vendor SAFEPOWER.ovpworld.org -type Zynq_PL_NoC_node \


ihwsetparameter -handle mbNoC1 -name nocid -type uns32 -value 1

ihwconnect -instancename mbNoC1 -packetnet network -packetnetport networkNodePort

#

# Microblaze NoC 2

#





ihwconnect -instancename mbNoC2 -packetnet network \

-packetnetport networkNodePort

#

# Microblaze NoC 3

#






#

# Microblaze NoC 4

#






4.6.5. Zynq_PL_NoC_node Module

The NoC_node module is a separate module containing a MicroBlaze processor, local memory and a NoC interface peripheral that is used in the Zynq_PL_NoC module. This is a module loaded from the VLNV library SAFEPOWER.ovpworld.org/module/Zynq_PL_NoC_node/1.0.

The start of the module definition is similar to all others.

set desc "This module implements a NoC node used to implement an example NoC in

Xilinx Zynq Programmable Logic (PL).

This PL configuration instances one Xilinx MicroBlaze processor with a local memory

and a NoC interface peripheral."




Page 29 of 69


Version 1.0



set library module

set name Zynq_PL_NoC_node

set version 1.0

#


#







The parameter to set the NoC node ID on the NoC peripheral is defined as a formal parameter to allow it to be passed down from a higher level in the hierarchy.

# the NoC node Id is passed in

ihwaddformalparameter -name nocid -type uns32

The sub-system comprises a bus onto which a MicroBlaze processor, memory and NoC peripheral are connected.

#

# pBus

#

ihwaddbus -instancename pBus -addresswidth 32

#

# Processor

#

ihwaddprocessor -instancename cpu -type microblaze -vendor xilinx.ovpworld.org -

version 1.0 \

-defaultsemihost

ihwconnect -instancename cpu -bus pBus -busmasterport INSTRUCTION

ihwconnect -instancename cpu -bus pBus -busmasterport DATA

#

# Address Map

#

# Local Processor Access

# 0x40000030 0xffffffff No Device

# 0x04000000 0x0400002f NoC peripheral registers


#


ihwaddmemory -instancename ramS -type ram

ihwconnect -instancename ramS -bus pBus -busslaveport sp1 -loaddress 0x00000000

-hiaddress 0x03ffffff

# 0x40000000 0x4000002f NoC peripheral

ihwaddperipheral -instancename node -type node -vendor SAFEPOWER.ovpworld.org

ihwconnect -instancename node -bus pBus -busslaveport hostif -loaddress

0x04000000 -hiaddress 0x040003ff

ihwsetparameter -handle node -name id -type uns32 -value nocid

Page 30 of 69


Version 1.0

The PSE used for OVP peripheral modelling has its data alignment set by the host machines. Typically we are using x86 hosts with little endian data ordering. As the MicroBlaze is big endian we configure the peripheral with a parameter which enables byte swapping on the processor interface.

NOTE: There is no byte swapping currently performed on the data message buffer.

# microblaze is big endian so need to configure peripheral register interface

ihwsetparameter -handle node -name endian -type string -value big

The only connection from this module is for the packetnet interface using a packetnetPort.

#

# External packetnet Port

#

ihwaddpacketnetport -instancename networkNodePort -mustbeconnected

ihwaddpacketnet -instancename networkNode

ihwconnect -packetnet networkNode -packetnetport networkNodePort

# Connect NoC Peripheral

ihwconnect -instancename node -packetnetport network -packetnet networkNode

4.6.6. NoC Peripheral

The NoC peripheral is a simple design allowing a single message to be transferred from this node to any other single node and for a single message to be received. The peripheral model is loaded from the VLNV library SAFEPOWER.ovpworld.org/peripheral/node/1.0.

The node on the network is identified by a fixed ID that is set using a parameter.

The peripheral has a register interface with control and status words and a message transfer buffer containing several control words and the message buffer itself.

Table 8: The NoC Peripheral Register Interface

Offset Register Description

0x000 Control Control

0x004 Status Status

Transmit

0x100 Id The Node Id to which the message is to be sent

0x104 FromId The Id of this node

0x108 Nid Internal

0x10c Length The length, in bytes, of the data (max 256)

0x110 Data The transmit data buffer

Receive

0x210 Id Not used

Page 31 of 69


Version 1.0

Offset Register Description

0x214 FromId The Id from which this message was sent

0x218 Nid Internal

0x21c Length The length, in bytes, of the data (max 256)

0x220 Data The receive data buffer

The packetnet interface works by instantly (in zero simulation time) passing a data structure pointer from the sending node to all other nodes that are connected to the packetnet interface. If the node has registered a receive callback on the packetnet interface it will be called and each node examines the data and determines if it is to be received by itself or ignored. If it is to be received it is copied into the receive buffer and the status word updated.

The data message used by the packetnet interface is defined in the same way as the transmit and receive structures, as shown below:

typedef struct networkDataS {

unsigned int toid;

unsigned int fromid;

unsigned int nid;

unsigned int length;

unsigned int data[0x100/4];

} networkDataT, *networkDataP;

The current implementation of the NoC transfers a message to the destination node when the complete message has been written into the buffer of the source node.

In the future there will be two forms of time triggered execution.

1) By controlling the scheduling of the virtual platform simulation the processors in the system will be executed until the time of the next time triggered event that they are required to perform. The system time will then be moved to the time of this event.

2) The NI will be configured with the time schedule and only send messages on these simulated time events.

Both of these implementations are currently under development.

4.7. Linux Kernel ‘SmartLoader’ Component

The harness, when configured for Linux Kernel operation, instantiates an additional component that is used to setup the environment of the system ready for the Linux Kernel to execute. This essentially provides the features usually provided by a ‘boot loader’ program.

Page 32 of 69


Version 1.0

The SmartLoader loads the Linux Kernel zImage file and an initial ramdisk image into system memory. It sets up a few initial instructions at the reset vector and some Linux Kernel address information which call into some basic smp boot code, ‘smpboot’.

Page 33 of 69


Version 1.0

5. BINARY INTERCEPTION LIBRARY

5.1. Interception Library Technology

An interception library can have full visibility of the simulating system and has the ability to control and modify some aspects of the system during execution; so that; a wide range of functions including modifying or adding processor instructions, performing verification, analysis or other functions on a simulated application - all without the need to modify the application- could be performed.

A binary interception library can cause the simulation engine to call it at certain points in the simulation, including:

At simulation construction and destruction

Before each instruction is morphed

When a specific instruction type is executed

When a specific address is executed

When specific memory address ranges are read or written

When a specific Programmers View event occurs

When a user invokes a command defined by the library

After a specific number of instructions have been executed

Once called, a binary interception library may use the VMI Run Time API to query and control the simulation state, including

Examine the state of the processor including general purpose and system registers

Examine Programmers View objects

Examine the simulation environment

Replace the simulated behavior for an instruction

Access symbolic and debug information for the application program being run

Use GDB to evaluate expressions for the currently running application program

Add or delete simulator callbacks to the library

Communicate with other binary interception libraries

Multiple binary intercept libraries may be used at the same time on a single processor, or multiple processors.

The following figure illustrates the operation mode of a binary Interception Intercept Library which is monitoring the code executed by a processor model.

Page 34 of 69


Version 1.0

Figure 7: PL Block Diagram for NoC System

More detail about this concept and VMI APIs has been included in [1] or [10].

5.2. Adding and Configuring an Interception Library

All interception libraries are added into the virtual platform using the --extlib command line argument. They are applied onto one or more components in the virtual platform. The configuration of a library is carried out using the --override argument on the parameters for the library.

Before executing and calling it the user has to be sure that all the requested libraries have been included in the installation path of OVP.

Figure 8: Instructions to include a binary interception library

Page 35 of 69


Version 1.0

5.3. Power Interception Library

The power interception library was included by OFFIS to enhance the VP so that it is power aware providing power consumption figures and virtualizing the monitoring devices used in SAFEPOWER project. This will help to analyze the state of the low power techniques that can be applied especially for the ARM cores and the voltage rails. In that way the virtual platform itself stays unmodified. Figure 5.3 illustrates the location of the power interception library, while the figure 5.4 shows an overview of its components.

Figure 9: Overview of the location of the Power Interception Library

The PIL is created specifically for one processor type taking into account the instruction set, the technology and other aspects that impact power consumption. For the time this user manual is written, the PIL is only for the ARM; but there will be further releases including other CPU Models or other peripherals like the network on chip.

Figure 10: Overview of the components of the Power Interception Library

Page 36 of 69


Version 1.0

The current PIL, focused in ARM consumption, consists of five main components. Two instances of core models, a platform model and a tracing engine for generating value change dump (VCD) files and a model of the voltage regulators, which implements the communication behavior of the physical PMBus interface. Excluding the virtual voltage regulators, all other components in the framework communicate via Timed Value Streams (TVS) [3]. TVS are particularly suitable for transferring values of extra-functional properties from one component to another. A TVS is a FIFO that saves tuples of the pushed data and the correct simulation time.

The core models deliver the following data for each core: number of accesses to the memory and the AXI bus, accesses to the processor’s frequency register as well as to the memory’s frequency and processor’s power state register. To check the suspend state of the cores, the executed instructions are analyzed for occurrence of wfe or wfi instructions. Finally, the core model defines a timer that executes a function periodically, to calculate the CPU load at a defined interval. If the callback functions detect a change outside this periodic interval, a separate update of the metrics at the current simulation time is made. This ensures that no event is missed by the core models. All core related metrics are processed within the core models, the CPU load, memory and AXI read/write rates, the suspend and power states, and transferred via TVS to the VCD trace engine. All other platform related metrics, all frequency changes and also changes in power states are directly given to the platform model. In the case that not all data is required for the current analysis, the data acquisition can be switched off individually to improve performance of the simulation.

The platform model processes and stores the received data from the core models and also controls access to them as well as to the simulation kernel. E.g., if a frequency is changed by the user application, only one core model detects this change and notifies the platform model, which then notifies all other core models to update their local values for the global state. The local values must be kept up to date for the correct calculations regarding CPU loads or read/write rates values which depend on the frequency. Furthermore, the platform model provides a monotonic global simulation time, which can be used by all components in the framework to push their values acquired data in the TVS with the correct event time.

Figure 11: Virtual Platform output [11]

Closely connected to the platform model, the virtual voltage regulators give the possibility to the power interception library to recognize changes of the platform voltages. Accordingly, the executed applications can use the provided PMBus interface as per the physical ZC702

Page 37 of 69


Version 1.0

board or the SAFEPOWER PCB. The model transfers the voltage values to the platform model since they are platform related. Also the virtual interface supports transmission of the current values in Amperes for each voltage rail. Later in future work, an attached power model can easily fill them.

Figure 12: UART output of executed application requesting sensor information through PMBus [11]

The VCD trace engine is notified at each push of its connected TVS and pulls the data to update the trace output file as a VCD trace. This file can be viewed at run-time or stored for further analysis. Further output formats are easily produced by using the Timed Value Streams. To use the power interception library the only requirement is to configure the simulation kernel to load this specific intercept library dynamically onto the processor models at simulation run-time. Thus it is easy to provide the power interception library to other OVP users as well as to maintain updates of the power interception library without the need to modify the virtual platform description itself.

Figure 13: Overview of the location of the Power Interception Library [11]

5.4. Fault Injection Library

A library can be created to inject faults into an executing system. These faults may include, but are not limited to, the corruption of memory in the platform, the corruption of register values in the processor(s) etc.

One or more fault injection library will be created during this project and the options will be detailed in future releases, as currently they are not fully implemented.

Page 38 of 69


Version 1.0

6. STARTING SIMULATION

This chapter will describe how to configure the virtual platform using the command line options to provide the required resources for the application(s) to execute correctly when starting a simulation.

There is a set of standard simulator command line arguments that are available to all virtual platforms (the command line arguments may be enabled or disabled in a harness).

6.1. Standard Command Line Arguments

This section briefly introduces some of the command line arguments that are used with the Xilinx Zynq harness to control the operation of the virtual platform:

--verbose generates verbose output from the simulator. For example, this will show the models being loaded.

--output specifies a log file to which the simulator will write information.

--program specifies an elf file to be loaded on a specific processor or on all processors in the virtual platform.

--override modifies the value of a parameter on a model or a simulator built in parameter.

Other useful command line arguments that can be used are:

--showoverrides provides a list of all the parameters that are available in the virtual platform that can be modified using the --override command line argument. This argument causes the available overrides to be printed and does not allow the simulation to run

--showbusses provides an output showing all the busses defined in the virtual platform and the memory map for components connected.

--showdomains similar to showbusses, but based upon the actual memory domains that the virtual platform has caused to be generated within the simulator.

--showmodule provides details of the interfaces and contents of modules contained in the platform

The loading and configuration of tool libraries are controlled by the command line arguments:

--enabletools controls the loading of the Imperas VAP tool libraries.

Page 39 of 69


Version 1.0

--extlib allows the loading of a custom extension library that is defined using the Binary Interception Technology, for example power and timing libraries

--override is used to provide configuration parameters to models and tools. The overrides can be found using the --showoverrides argument

6.2. BareMetal Application on Processing Sub-System

The following is an example command line for Zynq to run a baremetal application on the ARM processor in the Processing Sub-system.

harness.${IMPERAS_ARCH}.exe \

\

--program zc706/Zynq/Zynq_PS/cpu=applications/arm/app.ARM_CORTEX_A9.elf \

--override zc706/Zynq/Zynq_PS/cpu/defaultsemihost=1 \

\

--override zc706/Zynq/Zynq_PS/uart0/console=0 \


\

--output imperas.log \

--verbose \

"$@"

The command line argument --program is used to specify the application elf file to load onto the ARM processor. The ARM processor is distinguished by the hierarchical path zc706/Zynq/Zynq_PS/cpu and the application to load is applications/arm/application.ARM_CORTEX_A9.elf.

The ARM applications are compiled with C Newlib library functions that use semihosted output. This means that the program expects a debugger or other system feature to be available to allow output from an application call, for example printf, to be displayed on the host machine stdout. This saves the requirement for UARTs and drivers within the application.

To enable this feature on the processor model we set the parameter defaultsemihost on each of the processors in the virtual platform.

For example --override zc706/Zynq/Zynq_PS/cpu/defaultsemihost=1 enables on the ARM processor and --override zc706/Zynq/Zynq_PL_SingleMicroblaze/cpu/defaultsemihost=1 on the Microblaze processor.

This also means that the UART consoles are not required and these are disabled using --override zc706/Zynq/Zynq_PS/uart0/console=0.

6.3. BareMetal Application on Programmable Logic Processor

The following is an example command line for a Zynq run that uses the zc702 board definition and includes a Programming Logic module defining a microblaze sub-system on which we wish to run a baremetal application, for example ‘Hello World’.

Page 40 of 69


Version 1.0


\

--boardtype zc702 \

\

--program zc702/Zynq/Zynq_PS/cpu=applications/arm/application.ARM_CORTEX_A9.elf \

--override zc702/Zynq/Zynq_PS/cpu/defaultsemihost=1 \

\



\

--plmoduletype Zynq_PL_SingleMicroblaze \

\

--program zc702/Zynq/Zynq_PL/cpu=applications/microblaze/application.MICROBLAZE.elf \

--override zc702/Zynq/Zynq_PL/cpu/defaultsemihost=1 \

\


--verbose \

"$@"

The program from the previous example run is being executed on the ARM within the PS, but now we are loading a Programmable Logic (PL) module that contains a Microblaze processor sub-system that is running a second program.

The command line argument --boardtype indicates the loading of the zc702 board, --plmoduletype indicates the choice of which PL module to load from the library, --plmodulevendor can be used to indicate the vendor.

The argument --program is used to specify the application elf file to load onto the Microblaze processor. The Microblaze processor is distinguished by the hierarchical path zc702/Zynq/ Zynq_PL_SingleMicroblaze/cpu and the application to load is applications/microblaze/application.MICROBLAZE.elf.

The Microblaze applications are compiled with semihosted output, and so to enable this feature on the processor model we set the parameter defaultsemihost on each of the processors in the virtual platform.

For example --override zc702/Zynq/Zynq_PL_SingleMicroblaze/cpu/defaultsemihost=1 will enable the interception of low level functions on the Microblaze processor.

6.4. Linux Kernel on Processing Sub-System

The harness, when configured for Linux Kernel operation, instantiates an additional component that is used to setup the environment ready for the Linux Kernel to execute. This is not a real component and does not appear in the hardware. The ‘smartloader’ component is a simulation artifact that is used to simplify the virtual platform to allow the execution of the Linux kernel without the need for a boot loader program or monitor code applications.

The following is an example command line for a Zynq run that executes a Linux Kernel on the ARM Cortex-A9MPx2 of the PS. There is a small baremetal startup program , smpboot, that is initially loaded and executed. This is executed by both cpu0 and cpu1 of the ARM MPx2. The processor ID is used to detect cpu0 or cpu1 executing, with cpu1 executing a wfe instruction

Page 41 of 69


Version 1.0

and entering a halt state and cpu0 executing code to jump into the kernel start using a register value that has been initialized by the smartLoader.


\

--boardtype zc702 \

\

--zimage zImage \

--initrd fs.img \

--boot smpboot.ARM_CORTEX_A9.elf \

--smartloader \

\


--verbose \

"$@"

Page 42 of 69


Version 1.0

7. EXAMPLES

In this chapter we introduce a number of examples that have been created to illustrate the use of the SAFEPOWER virtual platform. There are applications running solely on the ARM processor of the Processing System, for example Linux and XtratuM hypervisor, that do not use any defined Programmable Logic implementations. There are other examples that show the creation of PL definitions and executing applications on the Microblaze processors that are included within them. A final set of examples show communication between multiple processors in the PS and PL using both shared memory and Network-on-Chip.

The examples require a valid M*SDK installation before installing. This is obtained by installing the Imperas_SDK package and following the instructions in the Installation and Getting Started Guide [2] to setup the environment.

There are two sets of examples available, some general usage examples and some SAFEPOWER specific examples. These are installed from the packages Demo_Xilinx_Zynq and Demo_Xilinx_Zynq_SAFEPOWER respectively.

The examples are found in a directory within the current installation, the root of which is defined by the environment variable IMPERAS_HOME.

This will be of the form <IMPERAS_HOME>/Demo/Platforms/<NAME-OF-EXAMPLE>

To run one of the examples go into the specific directory, for example

Imperas/Demo/Platforms/Xilinx_Zynq_zc702_PL1, and execute one of the available scripts which provide the correct command line arguments.

The script RUN_Zynq.sh can be used to start the simulation (there is an equivalent RUN_Zynq.bat for Windows)

7.1. BareMetal Single Microblaze PL

In this example we have the PS with an ARM Cortex-A9MPx2 processor and we load a PL module into the Zynq that contains a Microblaze processor with local memory, as shown in the following figure. The main memory is shown as part of the Zynq module. In the current implementation this is actually instanced within the PS.

Page 43 of 69


Version 1.0

Figure 14: PL Defining Microblaze Subsystem

Both the ARM processor and the Microblaze processor execute simple ‘Hello World’ applications. Only cpu0 of the ARM processor runs the main application; cpu1 is put into a halt state by issuing a wfe instruction.

The following output should be observed and also recorded to the logfile, imperas.log.

Reporting the flags that the simulator was invoked with.

Info ---------------- FLAGS ----------------

Info --program

zc702/Zynq/Zynq_PS/cpu=applications/arm/application.ARM_CORTEX_A9.elf

Info --override zc702/Zynq/Zynq_PS/cpu/defaultsemihost=1

Info --override zc702/Zynq/Zynq_PS/uart0/console=0

Info --override zc702/Zynq/Zynq_PS/uart1/console=0

Info --plmoduletype Zynq_PL_SingleMicroblaze

Info --program

zc702/Zynq/Zynq_PL/cpu=applications/microblaze/application.MICROBLAZE.elf

Info --override zc702/Zynq/Zynq_PL/cpu/defaultsemihost=1

Info --output imperas.log

Info --verbose

Info ---------------------------------------

Reporting the modules and components that are loaded.

Page 44 of 69


Version 1.0

Info (Zynq) Loaded Module Name ‘Zynq_PS’ :

‘Imperas/lib/Linux32/ImperasLib/xilinx.ovpworld.org/module/Zynq_PS/1.0/model.so’

Info (OP_AL) Found attribute symbol ‘modelAttrs’ in file



‘Imperas/lib/Linux32/ImperasLib/arm.ovpworld.org/processor/arm/1.0/model.so’


‘Imperas/lib/Linux32/ImperasLib/arm.ovpworld.org/semihosting/armNewlib/1.0/model.so

’

Info (Zynq) Programmable Logic Module Vendor ‘SAFEPOWER.ovpworld.org’ Name

‘Zynq_PL’

Info (Zynq) Found Module Vendor ‘SAFEPOWER.ovpworld.org’ Name

‘Zynq_PL_SingleMicroblaze’ :

‘Imperas/lib/Linux32/ImperasLib/SAFEPOWER.ovpworld.org/module/Zynq_PL_SingleMicrobl

aze/1.0/model.so’


‘Imperas/lib/Linux32/ImperasLib/SAFEPOWER.ovpworld.org/module/Zynq_PL_SingleMicrobl

aze/1.0/model.so’


‘Imperas/lib/Linux32/ImperasLib/xilinx.ovpworld.org/processor/microblaze/1.0/model.

so’


‘Imperas/lib/Linux32/ImperasLib/xilinx.ovpworld.org/semihosting/microblazeNewlib/1.

0/model.so’

The status of the modules loaded.

Info (Zynq) Checking Modules Loaded: Zynq_PS ok Zynq_PL ok

The programs being loaded onto the processor(s) in the virtual platform.

Info (OR_OF) Target ‘zc702/Zynq/Zynq_PS/cpu’ has object file read from

‘applications/arm/application.ARM_CORTEX_A9.elf’

Info (OR_PH) Program Headers:

Info (OR_PH) Type Offset VirtAddr PhysAddr FileSiz MemSiz

Flags Align

Info (OR_PD) PROC 0x0000f588 0x0000f588 0x0000f588 0x00000008 0x00000008

R-- 4

Info (OR_PD) LOAD 0x00008000 0x00008000 0x00008000 0x000075cc 0x000075cc

R-E 8000

Info (OR_PD) LOAD 0x0000f5cc 0x000175cc 0x000175cc 0x000008d8 0x00100a34

RW- 8000

Info (OR_OF) Target ‘zc702/Zynq/Zynq_PL/cpu’ has object file read from

‘applications/microblaze/application.MICROBLAZE.elf’



Flags Align

Info (OR_PD) LOAD 0x00000114 0x00000000 0x00000000 0x00000004 0x00000004

R-E 4

...

The application output from the Microblaze and ARM (cpu0).

MICROBLAZE: Hello World

ARM (0): Hello World

Status information from the simulation.

Info

Info ---------------------------------------------------

Info PSE SIMULATION TIME STATISTICS

...

Info

Page 45 of 69


Version 1.0

Info ---------------------------------------------------

Info CPU ‘zc702/Zynq/Zynq_PL/cpu’ STATISTICS

Info Type : microblaze

...

Info ---------------------------------------------------

Info CPU ‘zc702/Zynq/Zynq_PS/cpu_CPU0’ STATISTICS

Info Type : arm (Cortex-A9MPx2)

...


...

Info TOTAL

Info Simulated instructions: 4,564

...

Info SIMULATION TIME STATISTICS

Info Simulated time : 0.00 seconds

Info User time : 0.09 seconds

Info System time : 0.00 seconds

Info Elapsed time : 0.09 seconds

7.2. BareMetal Dual Microblaze PL with Shared Memory Communication

In this example we have the PS with an ARM Cortex-A9MPx2 processor and we load a PL module into the Zynq that contains two sub-systems. Each sub-system has a Microblaze processor with local memory. The PL also instances a memory that is shared between the PS and the Microblaze sub-systems, as shown in the following figure:

Page 46 of 69


Version 1.0

Figure 15: PL Defining Dual Microblaze Subsystem with Shared memory

The ARM processor and the Microblaze processor execute applications that communicate using the shared memory within the PL. The Microblaze processors write data into structures in the shared memory, the ARM processor monitors the shared memory and reads the data when available. Only cpu0 of the ARM processor runs the main application while cpu1 is put into a halt state by issuing a wfe instruction.

The following output should be observed. We are only showing the application output in this example, the simulator output is the same as the previous example.

MICROBLAZE 2: Started

MICROBLAZE 2: Write 0x22220000

MICROBLAZE 1: Started


ARM (0): Started

ARM (0): microblaze 1 Received 0x00001111






































ARM (0): Finished

MICROBLAZE 2: Finished

MICROBLAZE 1: Finished

Page 47 of 69


Version 1.0

7.3. BareMetal NoC PL Network Communication

In this example we have the PS with an ARM Cortex-A9MPx2 processor and we load a PL module into the Zynq that contains a connection to the NoC node peripheral and four NoC sub-systems. Each sub-system has a Microblaze processor with local memory and a NoC node peripheral connecting to the packetnet ‘network’, as shown in the following figure:

Figure 16: Block Diagram of NoC System

The ARM processor and the Microblaze processors execute applications that communicate using the NoC peripherals within the PL. The ARM processor sets up a simple data message and sets up the NoC peripheral to transmit this to node 1. Each subsequent MicroBlaze node receives a message and sends the message on to the next node i.e. incrementing the received from node ID and using this for the transmission to node ID. This continues until the ARM processor has seen the message passed around the system a number of times, at which point it sends a terminate message and all the processor terminate the application and shutdown.

Note: Only cpu0 of the ARM processor runs the main application while cpu1 is put into a halt state by issuing a wfe instruction.

Page 48 of 69


Version 1.0

The following output should be observed. We are only showing the application output, not the simulator output, in this example.

MICROBLAZE: Started

MICROBLAZE: Started

MICROBLAZE: Started

MICROBLAZE: Started

ARM (0): Started

ARM (0): Sending Initial Message

MICROBLAZE : Network (1): from 5 Received 0xaa55aa00 length 1 (1) send to 2




ARM (0): Network (5): from 4 Received 0xaa55aa04 length 1 (1) send to 1






MICROBLAZE : Network (1): from 5 Received 0xaa55aa0a length 1 (3) send to 2

MICROBLAZE : Network (2): from 1 Received 0xaa55aa0b length 1 (3) send to 3

MICROBLAZE : Network (3): from 2 Received 0xaa55aa0c length 1 (3) send to 4

MICROBLAZE : Network (4): from 3 Received 0xaa55aa0d length 1 (3) send to 5

ARM (0): Network (5): from 4 Received 0xaa55aa0e length 1 (3) send to 1

MICROBLAZE : Network (1): from 5 Received 0xaa55aa0f length 1 (4) send to 2

MICROBLAZE: Finished (1)








ARM (0): Finished (5)

7.4. Linux Kernel

The Linux kernel executes purely on the ARM processor of the PS. The PL, therefore, uses the default definition.

Page 49 of 69


Version 1.0

Figure 17: Executing Linux Kernel with Console Output

The UARTs within the PS are used to interact and obtain information regarding the Kernel boot process. The UARTs have the console parameter enabled which means that they automatically start up a console connected on their output.

7.4.1. Running Zynq with Linux Kernel

When the simulation is started a console window will be opened and connected to the UART output, this will show the Linux kernel output. The following output should be observed in the terminal in which the simulator is started, showing simulator messages.

Info Session started: Mon May 16 15:02:07 2016

Info ---------------- FLAGS ----------------

Info --zimage zImage

Info --initrd fs.img

Info --boot smpboot.ARM_CORTEX_A9.elf

Info --smartloader


Info --verbose

...

CpuManagerMulti started: Mon May 16 15:02:07 2016



...

Info (Zynq) Programmable Logic Module Vendor ‘SAFEPOWER.ovpworld.org’ Name ‘not

loaded’

Info (Zynq) Checking Modules Loaded: Zynq_PS ok Zynq_PL not loaded

Info (Zynq) Installing ‘SmartLoaderArmLinux’ to perform configuration for Linux

Kernel

Info (PSE_SER) ‘zc702/Zynq/Zynq_PS/uart0’ Connected to 50526

Page 50 of 69


Version 1.0


Info (OR_OF) Target ‘zc702/Zynq/Zynq_PS/pBus’ has object file read from

‘smpboot.ARM_CORTEX_A9.elf’



Flags Align

Info (OR_PD) LOAD 0x00000000 0x10000000 0x10000000 0x0000107c 0x0000107c

R-E 8000

Warning (ARM_MP_WUMPRI) CPU ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: Write unimplemented

MPCore register at offset 0x1384: ignored





Warning (ARM_MP_RUMPRZ) CPU ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: Read unimplemented

MPCore register at offset 0x30: return 0





The simulation continues until one of the UART consoles is closed, at which point the simulation terminates.

Info (PSE_SER) ‘zc702/Zynq/Zynq_PS/uart1’ Socket disconnected - terminating

simulation

Info (PSE_SER) ‘zc702/Zynq/Zynq_PS/uart1’ Disconnected from port 53195


Info ---------------------------------------------------


...

Info ---------------------------------------------------



...

Info Simulated instructions: 209,827,600

...

Info ---------------------------------------------------



...


...






Info Real time ratio : 194.05x faster

Info ---------------------------------------------------

...

Info Session ended: Mon May 16 15:02:20 2016

7.4.2. Running Zynq with Linux Kernel and Imperas Tools

A second script is provided that starts the same virtual platform simulation but also loads and enables VAP tools.

Page 51 of 69


Version 1.0

The VAP tools are the Imperas Verification, Analysis and Profiling tools that can be loaded into the Imperas Professional Simulator and controlled from the command line or interactively through the Imperas MPD or GUI interactive shells.

The OS Helper tool is specific to the operating system being used, for example, in this case, the Linux Kernel. Other OS Helper tools are provided for FreeRTOS, Nucleus, MQX, uC/OS-II etc. The OS Helper allows visibility of specific activities within the operating system. As examples, the OS Helper can output all of the kernel print messages (printk); it can indicate when tasks are created or when a switch occurs between tasks; it can show when an exception becomes active and the application software starts processing the exception etc.

To start the example with the OS Helper and VAP tools enabled invoke the OSHELPER_Zynq script.

The additional command line arguments added to those of the RUN_Zynq script are the following:

--enabletools \

--override zc702/Zynq/Zynq_PS/cpu/enableSMPTools=1 \

--extlib zc702/Zynq/Zynq_PS/cpu=linuxOsHelper \

--callcommand ‘zc702/Zynq/Zynq_PS/cpu_CPU0/linuxOsHelper_0/ostrace -on -printk’\

--symbolfile vmlinux \

The purpose of these arguments is briefly introduced here, full details may be found in the Imperas VAP Tools User Guide [8]:

--enabletools causes the simulator to load all standard tools found in the library and make them available. Tools are not generally active by default.

--extlib loads a specific extension library onto a specified processor or all processors

--callcommand allows a command from an extension library to be called from the command line. The available commands can be found by running a simulation with --showcommands set on the command line.

--symbolfile loads a file, typically an elf file, containing symbolic information to be used by the simulator and VAP tools.

--enableSMPTools configures the VAP tools for the specified multi-processor, in this case the Cortex-A9MPx2 dual core processor. It configures the VAP tools to treat the dual processors cores as a single SMP cluster.

The ostrace printk tool is enabled, using the callcommand argument on the command line, which shows the kernel print messages, giving visibility to the boot of the Linux kernel before the console is enabled/working.

Page 52 of 69


Version 1.0

./OSHELPER_Zynq.sh

The following output should be observed.

Info Session started: Mon May 16 15:55:24 2016

Info ---------------- FLAGS ----------------

Info --zimage zImage

Info --initrd fs.img

Info --boot smpboot.ARM_CORTEX_A9.elf

Info --smartloader


Info --verbose

Info --enabletools

Info --override zc702/Zynq/Zynq_PS/cpu/enableSMPTools=1

Info --extlib zc702/Zynq/Zynq_PS/cpu=linuxOsHelper

Info --callcommand zc702/Zynq/Zynq_PS/cpu_CPU0/linuxOsHelper_0/ostrace -on -printk

Info --symbolfile vmlinux

Info ---------------------------------------

...

Info (CMD_CC) calling ‘zc702/Zynq/Zynq_PS/cpu_CPU0/linuxOsHelper_0/ostrace’

TRC (LNX_STRT) 146235892: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: start_kernel called. OS

Helper initializing

TRC (PRTK) 146236815: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Booting Linux on

physical CPU 0x0

TRC (PRTK) 146241903: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Linux version 4.4.0-

xilinx-34568-g9c1d910-dirty ([email protected]) (gcc version 4.5.2

(Sourcery G++ Lite 2011.03-41) ) #7 SMP PREEMPT Wed Apr 20 16:24:33 BST 2016

TRC (PRTK) 146247068: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: CPU: ARMv7 Processor

[413fc090] revision 0 (ARMv7), cr=10c5387d

TRC (PRTK) 146250877: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: CPU: PIPT / VIPT

nonaliasing data cache, VIPT aliasing instruction cache

TRC (PRTK) 146268873: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Machine model: Xilinx

Zynq

TRC (PRTK) 146359398: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: cma: Reserved 16 MiB

at 0x07000000

TRC (PRTK) 146361968: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Memory policy: Data

cache writealloc

TRC (PRTK) 146600492: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: On node 0 totalpages:

32768

TRC (PRTK) 146702931: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: free_area_init_node:

node 0, pgdat c07534c0, node_mem_map c6ef0000

TRC (PRTK) 146705546: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Normal zone: 256

pages used for memmap

TRC (PRTK) 146707847: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Normal zone: 0 pages

reserved

TRC (PRTK) 146710555: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Normal zone: 32768

pages, LIFO batch:7

TRC (PRTK) 147831329: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: PERCPU: Embedded 12

pages/cpu @c6ed4000 s19328 r8192 d21632 u49152

TRC (PRTK) 147844271: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: pcpu-alloc: s19328

r8192 d21632 u49152 alloc=12*4096

TRC (PRTK) 147850967: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: pcpu-alloc: [0] 0 [0]

1 d21632 u49152 alloc=12*4096

TRC (PRTK) 147862430: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Built 1 zonelists in

Zone order, mobility grouping on. Total pages: 32512

TRC (PRTK) 147864575: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Kernel command line:

TRC (PRTK) 147870660: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: PID hash table

entries: 512 (order: -1, 2048 bytes)

TRC (PRTK) 147885825: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Dentry cache hash

table entries: 16384 (order: 4, 65536 bytes)

...

Page 53 of 69


Version 1.0

TRC (PRTK) 898106040: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Registering SWP/SWPB

emulation handler

TRC (PRTK) 904032029: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: hctosys: unable to

open rtc device (rtc0)

TRC (PRTK) 904112332: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: ALSA device list:

TRC (PRTK) 904126611: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: No soundcards found.

TRC (PRTK) 904599002: ‘zc702/Zynq/Zynq_PS/cpu_CPU0’: printk: Freeing unused kernel

memory: 256K (c06dc000 - c071c000)

Info (PSE_SER) ‘zc702/Zynq/Zynq_PS/uart1’ Socket disconnected - terminating

simulation



Info

Info ---------------------------------------------------


...

Info ---------------------------------------------------



...


...

Info ---------------------------------------------------



...


...

Info ---------------------------------------------------

Info TOTAL

Info Simulated instructions: 1,103,689,985

...

Info Session ended: Mon May 16 15:57:29 2016

Other tools can be enabled from the command line or controlled from interactive shells. Add the argument --showcommands to the command line to obtain a list of all the potential commands available and/or use ::ihelp in one of the interactive debug shells to get a list of the commands that can be applied during execution.

7.5. XtratuM Hypervisor Examples

The FentISS hypervisor, XtratuM, is used on the ARM Cortex-A9 processor to partition processes. Two example applications are provided that execute on the zc706 board.

The FentISS ‘Hello World’ example executes on both of the ARM CPUs and prints to the UART console.

The ‘4led_3push’ example is provided by Ikerlan and takes input from 3 switches on the zc706 board which changes the output to the 4 user LEDs.

7.5.1. Running with ‘Hello World’ Example

Page 54 of 69


Version 1.0

The script, RUN_Zynq_hello-world-smp.sh is used to start the simulation (there is an equivalent RUN_Zynq_hello-world-smp.bat for Windows).

./RUN_Zynq_hello-world-smp.sh

The following, or similar, output should be observed from the simulator.

Info Session started: Thu Apr 20 09:52:03 2017

…

CpuManagerMulti (32-Bit) veng.20170418.0 Open Virtual Platform simulator from

www.IMPERAS.com.

Copyright (c) 2005-2017 Imperas Software Ltd. Contains Imperas Proprietary

Information.

Licensed Software, All Rights Reserved.

Visit www.IMPERAS.com for multicore debug, verification and analysis solutions.

CpuManagerMulti started: Thu Apr 20 09:52:03 2017

…

Info (Zynq-Harness) Checking Modules Loaded: Zynq Board (xilinx.ovpworld.org/zc706)

ok : Zynq_PS ok : Zynq_PL (xilinx.ovpworld.org/Zynq_PL_Default) ok

Info (PSE_SER) 'zc706/Zynq/Zynq_PS/uart1' Connected to 35409

Info (GPIO_CFG_TST) zc706/Zynq/Zynq_PS/GPIO: ledBase 2, ledNumber 8, ledMask

0xfffffc03 swBase 0, swNumber 2, swMask 0xfffffffc

Info (ZYNQ_7000_GEM) zc706/Zynq/Zynq_PS/eth0: DMA initialization

Info (ZYNQ_7000_GEM) zc706/Zynq/Zynq_PS/eth0: Tx DMA channel reset

Info (ZYNQ_7000_GEM) zc706/Zynq/Zynq_PS/eth0: Rx DMA channel reset




Info (OR_OF) Target 'zc706/Zynq/Zynq_PS/cpu' has object file read from 'hello-

world-smp/resident_sw'



Flags Align


R-E 8

Info (OR_PD) LOAD 0x000026ae 0x00300000 0x00300000 0x0001fb48 0x0001fb48

RW- 1

Info (OR_PD) LOAD 0x000221f8 0x00200000 0x0031fb48 0x0000007c 0x0000f4b4

RW- 8

Info (PSE_SER) 'zc706/Zynq/Zynq_PS/uart1' Socket disconnected - terminating

simulation

Info (PSE_SER) 'zc706/Zynq/Zynq_PS/uart1' Disconnected from port 35409

Info (ZYNQ_7000_GEM) zc706/Zynq/Zynq_PS/eth0: DMA termination


Info

…

Info ---------------------------------------------------

Info CPU 'zc706/Zynq/Zynq_PS/cpu_CPU0' STATISTICS


Info Nominal MIPS : 500

Info Final program counter : 0x2000ae3c


Info Simulated MIPS : 22.7

Info ---------------------------------------------------

Info

Info ---------------------------------------------------



Info Nominal MIPS : 500

Info Final program counter : 0x20002df8

Page 55 of 69


Version 1.0



Info ---------------------------------------------------

Info

Info ---------------------------------------------------

Info TOTAL



Info ---------------------------------------------------

Info

Info ---------------------------------------------------






Info Real time ratio : 1661.33x faster

Info ---------------------------------------------------

CpuManagerMulti finished: Thu Apr 20 09:52:18 2017


www.IMPERAS.com.


Info Session ended: Thu Apr 20 09:52:18 2017

Additionally ‘uart1’ should provide output from the application executing on the ARM Cortex-A9MPx2 processor.

[RSW] Start Resident Software

[RSW] Starting XM at 0x20000000

XM Hypervisor (2.0 r3) Built May 5 2016 10:50:49

Detected 400.0MHz processor.

>> HWClocks [CortexA9 Global Clock (1000Khz)]

>> HwTimer [CortexA9 Private Timer1 (1000Khz)]

2 Partition(s) created

P0 ("Partition0":0) flags: [ SYSTEM ]:

[0x10000000:0x10000000 - 0x1003ffff:0x1003ffff] flags: 0x0

P1 ("Partition1":1) flags: [ SYSTEM ]:


InitSecondaryCpu 1 0x21007134


[vc0:P0] Hello World!






The simulation is terminated by closing the UART terminal.

7.5.2. Running with ‘4led_3push’ Example

The script, RUN_Zynq_4led_3push.sh is used to start the simulation (there is an equivalent RUN_Zynq_4led_3push.bat for Windows).

Page 56 of 69


Version 1.0

./RUN_Zynq_4led_3push.sh


Info Session started: Thu Apr 20 10:27:34 2017

…


www.IMPERAS.com.


Information.



CpuManagerMulti started: Thu Apr 20 10:27:34 2017

…


ok : Zynq_PS ok : Zynq_PL (xilinx.ovpworld.org/Zynq_PL_Default) ok

Info (PSE_SER) 'zc706/Zynq/Zynq_PS/uart1' Connected to 50270









Info (OR_OF) Target 'zc706/Zynq/Zynq_PS/cpu' has object file read from

'4led_3push/resident_sw'



Flags Align


R-E 8

Info (OR_PD) LOAD 0x000026ae 0x00300000 0x00300000 0x00022cd0 0x00022cd0

RW- 1

Info (OR_PD) LOAD 0x00025380 0x00200000 0x00322cd0 0x0000007c 0x0000f4b4

RW- 8

Info (HTTP_PORT) 'zc706' listening on port 8000

Info (zc706_SW) Power Switch pushed - terminating simulation.

Info (PSE_SER) 'zc706/Zynq/Zynq_PS/uart1' Disconnected from port 50270



Info

…

Info ---------------------------------------------------



Info Nominal MIPS : 0.5

Info Final program counter : 0x10001e54



Info ---------------------------------------------------

Info

Info ---------------------------------------------------



Info Nominal MIPS : 0.5

Info Final program counter : 0x20000420

Info Simulated instructions: 6,189


Info ---------------------------------------------------

Info

Info ---------------------------------------------------

Page 57 of 69


Version 1.0

Info TOTAL



Info ---------------------------------------------------

Info

Info ---------------------------------------------------






Info Host utilization : 4.3% (wallclock enabled)

Info ---------------------------------------------------

CpuManagerMulti finished: Thu Apr 20 10:27:51 2017


www.IMPERAS.com.


Info Session ended: Thu Apr 20 10:27:51 2017

7.5.2.1. Visualization and User Interaction

When there are LEDs and switches on a board that can be used by a user to interact with an application or monitor the behavior of a system, they can be visualized using a browser connected to the visualization port of the virtual platform simulation.

When prompted a browser should be connected to the HTTP port that is indicated in the log, by default this is port 8000.

Info (HTTP_PORT) 'zc706' listening on port 8000

The browser should connect to the port and provide the screen shown below, representing the zc706 board user I/O.

Page 58 of 69


Version 1.0

Figure 18: Visualization of the Xilinx zc706 LEDs and Switches

The DIL switches 0 to 2 can be used to control the operation of the software. Additionally ‘uart1’ should provide output from the application executing on the ARM Cortex-A9MPx2 processor.

[RSW] Start Resident Software

[RSW] Starting XM at 0x20000000

XM Hypervisor (2.0 r3) Built May 4 2016 14:56:05

Detected 400.0MHz processor.

>> HWClocks [CortexA9 Global Clock (1000Khz)]


2 Partition(s) created

P0 ("LedCounter":0) flags: [ ]:


[0xe000a000:0xe000a000 - 0xe000afff:0xe000afff] flags: 0x0

P1 ("Wait":1) flags: [ ]:


[P0] ---PARTITION0---

[P0] sw 7 1

[P0] ---Delay---

…[P0] ---Delay---

[P0] sw 7 1

[P0] ---Delay---

…

[P0] ---Delay---

[P0] sw 7 1

…

[P0] ---Delay---

[P0] sw 9 1

[P0] ---Delay---

…

[P0] ---Delay---

Page 59 of 69


Version 1.0

[P0] sw 9 1

[P0] ---Delay---

…

[P0] ---Delay---

[P0] sw 8 1

[P0] ---Delay---

…

[P0] ---Delay---

[P0] sw 7 1

[P0] ---Delay---

…

[P0] ---Delay---

The application calls a delay function multiple times and then checks the setting of the switches in order 0 (sw 7 1) , 1 (sw 9 1) and 2 (sw 8 1). Depending upon the first switch found in the ‘on’ state the LEDs are changed according to:

0 (sw 7 1) : invert the LED values

1 (sw 9 1) : rotate LED values to the right

2 (sw 8 1) : rotate LED values to the left

The simulation can be terminated by pressing the ‘Power’ button in the user visualization browser or by closing the UART terminal.

7.6. NoC Examples

This section introduces two different network implementations, the Nostrum NoC and the TTEL NoC.

It is the TTEL NoC programmers interface that is utilized by the SAFEPOWER architecture.

7.6.1. Nostrum NoC

The Nostrum NoC is an implementation of a NoC that utilizes the processor interface and implementation defined by KTH and generated using their NoC system generator.

An example NoC was provided called NoC2x2_1MHz_ZeroReleaseSiegenDemo_Tage. This system utilizes the ARM processor in the PS and defines a PL containing Microblaze based subsystems, a NoC and a Network Interface (NI) connecting the ARM processor to the NoC. The Microblaze subsystems each contain a Microblaze processor, memory and a NI connecting to the NoC. All NI’s connected to the NoC are given a unique identifier in the network used for controlling message transfers between them which is configured when the system was defined and generated. In the current example, a message was passed between the nodes (3 microblazes and 1 ARM) as a token ring.

7.6.1.1. Running Zynq with Nostrum NoC

The script, RUN_Zynq.sh is used to start the simulation (there is an equivalent RUN_Zynq.bat for Windows).

Page 60 of 69


Version 1.0

./RUN_Zynq.sh


CpuManagerMulti started: Wed Jan 4 15:42:23 2017


‘/home/graham/Imperas/lib/Linux32/ImperasLib/xilinx.ovpworld.org/module/Zynq_PS/1.0

/model.so’


‘/home/graham/Imperas/lib/Linux32/ImperasLib/xilinx.ovpworld.org/module/Zynq_PS/1.0

/model.so’


‘/home/graham/Imperas/lib/Linux32/ImperasLib/arm.ovpworld.org/processor/arm/1.0/mod

el.so’


‘/home/graham/Imperas/lib/Linux32/ImperasLib/arm.ovpworld.org/semihosting/armNewlib

/1.0/model.so’

Info (Zynq) Programmable Logic Module Vendor ‘SAFEPOWER.ovpworld.org’ Name

‘Zynq_PL_NostrumNoC’

Info (Zynq) Found Module Vendor ‘SAFEPOWER.ovpworld.org’ Name ‘Zynq_PL_NostrumNoC’

:

‘/home/graham/Imperas/lib/Linux32/ImperasLib/SAFEPOWER.ovpworld.org/module/Zynq_PL_

NostrumNoC/1.0/model.so’



NostrumNoC/1.0/model.so’



NostrumNoC_node/1.0/model.so’


‘/home/graham/Imperas/lib/Linux32/ImperasLib/xilinx.ovpworld.org/processor/microbla

ze/1.0/model.so’


‘/home/graham/Imperas/lib/Linux32/ImperasLib/xilinx.ovpworld.org/semihosting/microb

lazeNewlib/1.0/model.so’

Info (Zynq) Checking Modules Loaded: Zynq_PS ok Zynq_PL ok


‘A9_0_app/Debug/A9_0_app.elf’



Flags Align

Info (OR_PD) LOAD 0x00008000 0x00100000 0x00100000 0x0001800c 0x000255b0

RWE 8000

Info (OR_OF) Target ‘zc702/Zynq/Zynq_PL/mbNoC_0_1/cpu’ has object file read from

‘cpu_0_1_app/Debug/cpu_0_1_app.elf’



Flags Align


R-E 4

Info (OR_PD) LOAD 0x0000009c 0x00000050 0x00000050 0x00001200 0x00001e38

RWE 4





Flags Align


R-E 4

Info (OR_PD) LOAD 0x000000bc 0x00000050 0x00000050 0x00000f1c 0x00000f20

RWE 4

Page 61 of 69


Version 1.0

Info (OR_PD) LOAD 0x00000fd8 0x00000f70 0x00000f70 0x0000013c 0x00000d78

RW- 4





Flags Align


R-E 4

Info (OR_PD) LOAD 0x0000009c 0x00000050 0x00000050 0x0000138c 0x00001fc0

RWE 4

Info (Zynq_CFG) Configured Board zc702

Info (HTTP_PORT) ‘Zynq’ listening on port 8000


…

Additionally, ‘uart1’ should provide output from the application executing on the ARM Cortex-A9MPx2 processor.

---Entering main---

Running ScuGicSelfTestExample() for ps7_scugic_0...

ScuGicSelfTestExample PASSED

ScuGic Interrupt Setup PASSED

Running GpioOutputExample() for pio_dpr...

7.6.1.2. NoC Configuration

The NoC is generated for a specific number of nodes and behind each node a number of processes. Each design is, therefore, a unique hardware and software definition with hard coded communication channels defined between processes in the system. So that a single Virtual platform can support any definition of message transfers2 in the NoC each NoC node in the virtual platform must be configured so that it is aware of:

a) the processes that are located at each NoC node

b) the channels to be used for each process to process communication

The configuration data is extracted from the software files generated for each processor and found as the header file software_configuration.h in the software definition by extracting the definitions of the channels.

2 The configuration of the NoC itself i.e. the number of subsystems connecting to the NoC, is defined by

creating a new PL module definition.

Page 62 of 69


Version 1.0

A script is provided to extract the required information from the software header file and provide it in a form that can be read by the NI.

To extract the channel information the script, generateConfigFile.sh, should be run in the root directory of the NoC software. The script is found in the VLNV source directory for the NI peripheral model.

Imperas/ImperasLib/source/SAFEPOWER.ovpworld.org/peripheral/NostrumNode/1.0/pse/gen

erateConfigFile.sh

This will generate a file, channel_config.inf, which should be used to configure all of the NoC nodes using a parameter override, as shown below. All nodes must be configured using the same file.

--override zc702/Zynq/Zynq_PL/mbNoC_0_1/node/configfile=channel_config.inf

The file contains a list for each nodes, the processes it contains and the channels associated with data transfers between the nodes for which communication routes are configured.

A line can be a comment, preceded by the ‘#’ character, or contains the following set of fields:

Table 9: Fields defining NI Configuration

Field number Content

1 physical node

2 ‘receive’ or ‘send’

3 software process

4 physical node containing software process 3

5 ‘from’ or ‘to’

6 software process

7 physical node containing software process 6

8 channel number for transfer

The following is an example of a configuration file.

1 recv p1 1 from p12 2 0



1 send p1 1 to p7 1 0

1 send p6 1 to p2 2 4

1 send p6 1 to p1 1 5



2 send p2 2 to p13 2 0


Page 63 of 69


Version 1.0

In the above file,line 1 ‘1 recv p1 1 from p12 2 0’ indicates that physical node 1 has a process p1 that receives messages from process p12 on physical node 2 and receives those messages using local channel 0. Line 4 ‘1 send p1 1 to p7 1 0’ indicates that physical node 1 has a process p1 that sends messages to process p7 on physical node 1 and receives those messages using local channel 0.

7.6.2. TTEL NoC (SAFEPOWER Implementation)

The TTEL NoC is an implementation of a NoC that utilizes the processor interface and implementation defined by the University of Siegen (USI). This NoC is used by the SAFEPOWER architecture.

Two examples are provided that utilize the basic 2x2 network construction. The first example uses example applications created by Imperas based upon the documentation provided by USI. The second one uses example applications provided by USI.

7.6.2.1. Running Zynq with Imperas TTELNoC Example

This example uses the four nodes in the 2x2 NoC to send messages between each node in a round robin fashion.

The ARM NI has index 0 and the Microblaze nodes are IDs 1 to 3. The ARM processor application initiates sending a network message addressed to node 1. The message contains a count field. The count field is incremented by the application receiving the message on each node as then passed on to the next node in the system. When the ARM processor receives a message with a count field greater than a specific value, indicating that the message has been passed multiple times, the simulation is terminated.

The script, RUN_Zynq.sh is used to start the simulation (there is an equivalent RUN_Zynq.bat for Windows).

./RUN_Zynq.sh


Info Session started: Wed Apr 19 17:53:21 2017

…


www.IMPERAS.com.


Information.

…


‘applications/cpu_0_0_app.ARM_CORTEX_A9.elf’



Flags Align

Info (OR_PD) PROC 0x0000fbf0 0x0000fbf0 0x0000fbf0 0x00000008 0x00000008

R-- 4

Page 64 of 69


Version 1.0

Info (OR_PD) LOAD 0x00008000 0x00008000 0x00008000 0x00007c34 0x00007c34

R-E 8000

Info (OR_PD) LOAD 0x0000fc34 0x00017c34 0x00017c34 0x00000940 0x00100bcc

RW- 8000

Info (OR_OF) Target ‘zc702/Zynq/Zynq_PL/NoC_0_1/cpu’ has object file read from

‘applications/cpu_0_1_app.MICROBLAZE.elf’


…



…



…

APP (MICROBLAZE_1_1): Send Message - port 3 - ‘message to node 0_0 from 1_1

(MICROBLAZE_1_1)’

APP (MICROBLAZE_1_1): Check Incoming (0)


(MICROBLAZE_1_0)’



(MICROBLAZE_0_1)’


APP (ARM): Send Message - port 1 - ‘message to node 0_1 from 0_0 (ARM)’



APP (ARM): Check Incoming (0)

APP (ARM) : port(004) : ‘messages’ : status 0x0000040c message length 12

APP (ARM) : Get Message : port 4 : ‘message to node 0_0 from 0_1 (MICROBLAZE_0_1)’

APP (ARM) : port(004) : ‘empty’ : status 0x00100000













APP (MICROBLAZE_1_1) : port(001) : ‘messages’ : status 0x00000409 message length 9

APP (MICROBLAZE_1_1) : Get Message : port 1 : ‘message to node 1_1 from 0_0 (ARM)’

APP (MICROBLAZE_1_1) : port(001) : ‘empty’ : status 0x00100000













APP (ARM): Complete








Page 65 of 69


Version 1.0
















APP (MICROBLAZE_1_1): Complete







Info

…

CpuManagerMulti finished: Wed Apr 19 17:53:22 2017


www.IMPERAS.com.


Info Session ended: Wed Apr 19 17:53:22 2017

7.6.3. Running Zynq with TTEL NoC USI Example (SAFEPOWER Example)

This example uses only three of the four nodes in the 2x2 NoC with the fourth microblaze node put into a sleep state and taking no part in the activity of transferring messages around the system.

The applications running on the Microblaze subsystems periodically send messages into the NoC to the ARM processor. When a message is received the ARM processor generates a message to the UART.

The script, RUN_Zynq_USI_Example.sh is used to start the simulation (there is an equivalent RUN_Zynq_USI_Example.bat for Windows).

./RUN_Zynq_USI_Example.sh


Info Session started: Wed Apr 19 15:32:15 2017

…


www.IMPERAS.com.

Page 66 of 69


Version 1.0


Information.



CpuManagerMulti started: Wed Apr 19 15:32:15 2017

…


ok : Zynq_PS ok : Zynq_PL (SAFEPOWER.ovpworld.org/Zynq_PL_TTELNoC) ok












‘zero_release.sdk/a9_app/Debug/a9_app.elf’

…


‘zero_release.sdk/M2_app/Debug/M2_app.elf’

…


‘zero_release.sdk/cpu_1_1_app.MICROBLAZE.elf’

…

APP (MICROBLAZE_1_1): Started

Info (dummyPort) zc702/Zynq/Zynq_PS/dummyeFuse: 4 byte read at offset 16 (0x10)





Info

…

CpuManagerMulti finished: Wed Apr 19 15:35:56 2017


www.IMPERAS.com.


Info Session ended: Wed Apr 19 15:35:56 2017

Additionally, ‘uart1’ should provide output from the application executing on the ARM Cortex-A9MPx2 processor.

Hello World

Port#3: 00000000 Port#4: 00000000

Port#3: 00000002 Port#4: 00000002

Port#3: 00000004 Port#4: 00000004

Port#3: 00000006 Port#4: 00000006

Port#3: 00000008 Port#4: 00000008

Port#3: 0000000A Port#4: 0000000A

Port#3: 0000000C Port#4: 0000000C

Port#3: 0000000E Port#4: 0000000E

Port#3: 00000010 Port#4: 00000010

Port#3: 00000012 Port#4: 00000012

Port#3: 00000014 Port#4: 00000014

Page 67 of 69


Version 1.0

Port#3: 00000016 Port#4: 00000016

Port#3: 00000018 Port#4: 00000018

Port#3: 0000001A Port#4: 0000001A

Port#3: 0000001C Port#4: 0000001C

Port#3: 0000001E Port#4: 0000001E

…

Port#3: 0000000A Port#4: 0000000A

…

7.6.3.1. TTEL NoC Timing

The current implementation of the TTEL NoC NI provides the immediate transfer from a source node to a destination node using the configured channels. This provides a functionally correct system that allows software applications to execute as though on the real hardware.

Under development is the ability to enhance the NoC so that it makes use of the timing schedule defined for message transfers. In this mode the messages will only be sent according to the timing schedule for each channel.

7.6.3.2. TTEL NoC Configuration

The NoC is generated for a specific number of nodes and within each node there are a number of ports, that are each configured. A port is used to pass messages to a specific port on the same or a different node.

Each design is, therefore, a unique hardware and software definition with defined communication between processes in the system. So that a single Virtual platform can support any definition of the NoC each NoC node in the virtual platform must be configured so that it is aware of the ports to be used for each process to process communication.

A set of configuration files are generated from a master NoC configuration, one for each node. This is used to configure the nodes using a parameter override, as shown below. All nodes must be configured using their specific file.

--override zc702/Zynq/Zynq_PL/NoC_0_1/ni/configfile=config_node_0_1.inf

The file contains a list for each node the configuration of each port. A line can be a comment, preceded by the ‘#’ character, or contains the following set of fields:

Enable is set if the port is initially enabled

TDS is a bit field defining the type, direction and semantic. These are defined by the USI documentation of the reference example.

bufferSize is the number of 32-bit words that can be contained in each buffer

Page 68 of 69


Version 1.0

queueSize is the number of buffers that form the queue contained in the port

destination is the physical node defined by the Cluster, Tile, Node fields (upper 24-bits) and the port within the node (bottom 8-bits) to which data is transferred

mint this field represents timing between the transmission of messages but is unused in the current implementation

The following is an example of a configuration file (all numbers shown are hexadecimal).

# enable | TDS | bufferSize | queueSize | destination | mint

1 4 010 001 00000000 0000000000200000

1 1 010 010 00000101 0000000000000000

Line 0 is a comment

Line 1 indicates configuration for port 0:

Table 10: Example port 0 configuration

Enable Port enabled

TDS Type RC1

Direction Output

Semantic STATE

Buffer Size 16 (32-bit words)

Queue Size 1

Destination node 000000 port 00

Line 2 indicates configuration for port 1:

Table 11: Example port 1 configuration

Enable Port enabled

TDS Type TT

Direction Output

Semantic EVENT

Buffer Size 16 (32-bit words)

Queue Size 16

Destination node 000001 port 01

Page 69 of 69


Version 1.0

8. REFERENCES

[1] Architectural Design of the Virtual Platform, SAFEPOWER deliverable D3.1

[2] Imperas Installation and Getting Started Guide, available in Imperas and OVP releases in the doc directory or available from www.ovpworld.org documentation page. This document explains how to install and configure an OVP or Imperas installation.

[3] iGen Platform and Module Creation User Guide, available in Imperas and OVP releases in the doc directory or available from www.ovpworld.org documentation page. This document describes how to create a module that defines some specific hardware.

[4] iGen Peripheral Generator User Guide, available in Imperas and OVP releases in the doc directory or available from www.ovpworld.org documentation page. This document describes how to create a peripheral model template which defines the programmers view (register interface) of a peripheral hardware device.

[5] OVP Peripheral Modeling Guide, available in Imperas and OVP releases in the doc directory or available from www.ovpworld.org documentation page. This document describes how to create the behavior within a peripheral model using the BHM and PPM APIs.

[6] ZC706 Evaluation Board for the Zynq-7000 XC7Z045 All Programmable SoC UG945 v1.5 September 10, 2014 (ug954-zc706-eval-board-xc7z045-ap-soc.pdf)

[7] ZC702 Board user Guide UG850 (v1.5) September 4,2015 (ug850-zc702-eval-bd.pdf) [8] Zynq-7000 AP SoC Technical Reference Manual UG585 (v1.10) February 23, 2015

(ug585-Zynq-7000-TRM.pdf) [9] Imperas VAP Tools User Guide, available in an Imperas M*SDK release.

[10] IMP_Binary_Interception_User_Guide.pdf is provided with M*SDK product in the IMP_SDK package.

[11] Integrating Power Models into Instruction Accurate Virtual Platforms for ARM-based MPSoCs ARM TechCon 2016 (26 October 2016) - R. Görgen (OFFIS), D. Graham (IMPERAS), K. Grüttner (OFFIS), L. Lapides (IMPERAS), S. Schreiner (OFFIS)

http://www.ovpworld.org/




https://www.xilinx.com/support/documentation/boards_and_kits/zc706/ug954-zc706-eval-board-xc7z045-ap-soc.pdf

https://www.xilinx.com/support/documentation/boards_and_kits/zc702_zvik/ug850-zc702-eval-bd.pdf

https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf

Documents

D3.2: User guide of the SAFEPOWER Virtual Platformsafepower-project.eu/wp-content/uploads/2018/03/D3... · V1.0 Document information Contract number 687902 Project website Contractual