School of Electronics, Indore
SCHOOL OF ELECTRONICS, DAVV, INDORE
A Training Report (2) on
IPTG/GENKIT/Simvision
Trainee:
Vivek Joshi
(08MTES17)
Under the Guidance of
Alok Mehta
Anshuman Goswami
Jerome Lion
Ennio Salemi
(ST Ericsson)
Nishit Gupta (ST)
Fortnightly project report 2.
1
School of Electronics, Indore
S.No.
1.
2.
3.
Title
Project Report No.
Name
Place of Work
Details
2
Vivek Joshi (08MTES17)
ST Ericsson, Greater Noida, U.P.
4.
Project Area
IPTG Tool, GENKIT and Simvision
5.
Period of Report
August 25 to September 10
6.
Submitted to
School of Electronics, DAVV, Indore.
7.
Work done
As mentioned in following pages
8.
Books and
studied
9.
Working hours
10.
Leave days in week
 How-to documentation by
Ennio Salemi for compilation
of the SoC platform.
 Configuration files of different
initiators like SVA (Smart
Video
Accelerator),
SIA
(Smart Imaging Accelerator),
B2R2 (Image Post Processing
Engine for Blit Blend Rotate
Resize) and Cortex A9 (ARM
core) for the HD Camcorder
use case.
 IPTG Lab Notes (2 labs) by
Nishit Gupta.
Doc.
8 (Excluding half hr. of lunch)
(9:00am to 5:30pm IST)
September 7 and 8*
*There are 5 working days in a week. Saturday and Sunday is off.
Fortnightly project report 2.
2
School of Electronics, Indore
1- PURPOSE
This document describes the second fortnight of my training in ST Ericsson,
Greater Noida, UP.
2- SCOPE
IPTG Lab Exercises and introduction to Simvision and GENKIT tools
3- INTRODUCTION
The purpose of these labs is to make the user comfortable in writing the
configuration file for IPTG and to generate a platform using genkit. The
main approach is to define and model the characteristics of IP traffic through
a combination of traffic modeling and IP modeling. To write a
configuration file for a specific IP, one may consider the given IP as a
series of synchronized processes. IPTG regards any single process as a
behavior. The IP, therefore,
is described by IPTG as a series of behaviors
where each of them represents a particular type of IP traffic. In these labs
the user will be introduced to the
following three bus protocols:
1. STBus Protocol: Lab1 is dedicated to STBus protocol and an example
platform PLT-iptg_stbus_bca is used for demonstrating various STBus
specific operating modes of iptg.
2. AHB Protocol: Lab2 is dedicated to AHB protocol and an example
platform PLT-iptg_tac_ahb is used to explain AHB iptg features.
4. LAB 1
Lab1 is dedicated to STBus based initiators and is further divided into 3
parts:
1. TRAFFIC: In this mode an IP is defined by its overall bus traffic.
2. STBUS_PLUG: This mode defines an IP in terms of its internal traffic.
An STBus plug interface is used to finally convert the IP internal traffic to
the traffic on COM ports.
3. GENKIT: This is used to generate stbus based platforms at bca
abstraction level.
The objective of this lab is to write the configuration file for an IP from its
specification using the STBus protocol and then simulate it in a given
platform. This lab is intended to guide the user for writing IPTG
configuration file based on some statistics specification and sequence of IP
traffic. The example platform consists of 6 IPTG bca initiators which
communicates to a memory through interconnect in IUS based simulation
environment. This lab is also intended to show how one can emulate the IP
traffic using IPTGs.
Fortnightly project report 2.
3
School of Electronics, Indore
4.1 Writing configuration file using IPTG_BEHAVIOUR_POLICY or
IPTG_BEHAVIOUR_SEQ
Suppose one have to write a configuration file to define the traffic for an IP
which has the following characteristics:
 IP waits for 500ns for the system to be initialized.
 IP reads or writes 512 bytes from address range selected randomly
within 0x00 to 0x200.
 IP reads or writes 512 bytes from address range selected randomly
within 0x200 to 0xfff.
The selection between above 3 processes can be done in various ways using
IPTG_BEHAVIOUR_POLICY or IPTG_BEHAVIOUR_SEQ as described
below:
 IPTG_BEHAVIOUR_POLICY:
❏ RANDOM
Any behavior is selected randomly.
❏ INCREMENTAL
Next behavior is chosen for execution.
❏ <{unsigned{,unsigned}}>
Same policy as for RANDOM but keeping a percentage
criterion for each behavior occurrence. Percentage 1 is a special
case. If user defines a percentage of 1 for a given behavior,
then that behavior will be executed.
Only once in the beginning of simulation.
 IPTG_BEHAVIOUR_SEQ :
❏<{unsigned | (unsigned {unsigned | * unsigned | )*unsigned}}>
Describe the sequence of execution for behavior. The
following .cfg file describes the use of
IPTG_BEHAVIOUR_SEQ
 To analyse the result open the transaction database for database
(SST2_DB) and generated traces (fifo_trace.vcd) in simvision.
Following traces are available in TRAFFIC mode :
For example for the first initiator, we can see the following traces
IPTG_CONF1_BEHAVIOUR : Behaviour traces
Behaviour traces : specify the state of the various IPTG
behaviours with respect to time.
Fortnightly project report 2.
4
School of Electronics, Indore
4.2 Writing configuration flle using
BEHAVIOUR_DATA_LENGTH or
BEHAVIOUR_TIME_LENGTH
Suppose one have to write a configuration file to define the traffic for
an IP which has the following characteristics:
 IP reads or writes 512 bytes from address range selected randomly
0x00 to 0x200.
 IP reads or writes at address range selected randomly 0x00 to 0x200
for 100ns.
BEHAVIOUR_DATA_LENGTH : specifies the no. of bytes to be
transffered in a behaviour.
❏ <unsigned>: in bytes
BEHAVIOUR_TIME_LENGTH : signifies for how much time a
behaviour will be active.
❏<unsigned long>: in ns
4.3 Writing configuration file using BEHAVIOUR_ADDR and
BEHAVIOUR_ADDR_POLICY
Suppose one have to write a configuration file to define the traffic for
an IP which has the following characteristics:
 IP reads or writes 1024 bytes from address range selected
randomly between 0x0 to 0xfff.
 IP reads or writes 1024 bytes starting from address range 0x0.
For every next transaction new address generated is the
summation of previous address and no. of bytes transferred in
last transaction or interface width (whichever is higher).
 IP reads or writes 1024 bytes by selecting 20% time addresses
from 0x0 to 0x200 and 80% time addresses from 0x200 to
0xfff.
BEHAVIOUR_ADDR : gives the address or range of addresses used
by a behaviour.
❏ <{>: start of keyword entry
❏ <}>: end of keyword entry
❏ <(>: start a range of addresses
❏ <)>: end a range of addresses
❏ <~>: separate the start and end addresses of a range
❏ <;>: separate two addresses or two ranges of addresses
Fortnightly project report 2.
5
School of Electronics, Indore
❏ <hex>: address value
❏ <{ALL}>:
Example 1 {(0x0000~0x1fff);(0x3000~0x4fff)}
Example 2 {(0x0000~0x1fff)=80;(0x3000~0x4fff)=20}
Example 3 {ALL}
BEHAVIOUR_ADDR_POLICY : describes how the next address is
to be generated.
❏ RANDOM
Randomly selects next address from range specified by
BEHAVIOUR_ADDR
❏ INCREMENTAL
Next address is selected in incremented way.
4.4 Writing configuration file using BEHAVIOUR_OPCODE and
BEHAVIOUR_OPCODE_POLICY
Suppose one have to write a configuration file to define the traffic for
an IP which has the following characteristics:
 IP reads 256 bytes of data by randomly selecting opcodes between
LD1, LD2 and LD4.
 IP writes 256 bytes of data by selecting opcodes between ST1, ST2
and ST4 in a incremental way.
 IP writes 256 bytes of data by selecting 10% times ST1 and ST2
each and remaining 80% times ST4 opcode.
BEHAVIOUR_OPCODE : describes the opcodes by a behaviour.
❏ <{>: start
❏ <}>: end
❏ <;>: separate two opcodes
❏ <=int>: percentage of this opcode used by the behaviour
❏ <string>: list of all COM opcode
Example 4 {ST4;LD4;ST16}
Example 5 {ST4=40;LD4=40;ST16=20}
Example 6 {ALL}: all opcodes are used
BEHAVIOUR_OPCODE_POLICY : describe the next opcode
generation algorithm for a behaviour.
Select any opcode randomly from the given set of opcodes.
➥with percentage
Fortnightly project report 2.
6
School of Electronics, Indore
➥without percentage
Select the next opcode from the given set of opcodes.
❏ <RANDOM>
❏ <INCREMENTAL>
Writing configuration file using BEHAVIOUR_BD and
BEHAVIOUR_BD_PEAK
Suppose one have to write a configuration file to define the traffic for
an IP which has the following characteristics:
 IP writes 1024 bytes of data at a rate of 10Mbps.
 IP writes 1024 bytes of data at a rate which should not exceed
100Mbps.
BEHAVIOUR_BD : State the bandwidth or rate at which data will be
transferred for a behaviour.
BEHAVIOUR_BD_PEAK : Signify the maximum rate of data
transfer for a behaviour.
❏ <unsigned>: in Mb/s (where 1 M = 1024 x 1024)
❏ <lab unsigned>: in Mb/s (where 1M = 1024 x 1024)
4.5 Writing configuration file using BEHAVIOUR_SEQ
Suppose one has to write a configuration file to define the traffic for
an IP which has the following characteristics:
 IP stores 16 bytes of data using ST4 opcodes at some specific
address locations, i.e. 0x0, 0x10, 0x20 and 0x30.
 IP reads 16 bytes of data using LD4 opcodes from some specific
(above specified) address locations.
BEHAVIOUR_SEQ: Describe the sequence of operations for
behaviour. It describes either the opcode followed by address
and byte-enable with optional data or NOP with the time length
(in ns).
4.6 Writing configuration file for IP modeling
Data representation is inconsistent with other equivalent
sections. The objective of this lab is to write the configuration
file for an IP modeling and then simulate it in a given
platform. A plugin interface "STBus Plug" is being used for IP
modeling, which can be either read or written. Plugin interface
is represented by a FIFO with a threshold value and
address/opcode generator to convert the IP traffic to the bus
traffic . In case of IP modeling, the bus traffic generated by the
IP is split into two parts: (1) IP traffic that fills the plugin FIFO
Fortnightly project report 2.
7
School of Electronics, Indore
and (2) plugin FIFO traffic on the bus. Following labs are
intended to guide the user for writing IPTG configuration files
based on the IP specification and its plugin interface
specification.
Suppose one has to write a configuration file to define the traffic for
an IP using STBUS_PLUG mode which has the following
characteristics:
 IP waits for 500ns for the system to be initialized.
 IP writes 256 bytes in 8 packets of 16 bytes each of which are
written on specified addresses.
4.7 Writing the configuration file using IPTG_READ_SWITCH
Suppose one has to write a configuration file for an IP which has
following characteristics:
 IP is having a read interface and in each behaviour it should not
wait for consumption of all responses to switch to a new
behaviour rather it should switch to a new behaviour as soon as
all the data has been requested to bus for current behaviour.
IPTG_READ_SWITCH: Read plugin switches to the new
behaviour, when the last threshold message is ready to be sent.
❏<0 | 1>
4.8 Writing the configuration file using
BEHAVIOUR_BLANKING
Suppose one has to write a configuration file for an IP using
STBUS_PLUG mode which has following characteristics.
IP is having a write interface..
IP starts filling the fifo after an interval of 2000 ns from the start of the
behavior.
BEHAVIUOR_BLANKING: Specify the time interval before an IP
could start filling or emptying FIFO at the start of each behaviour.
❏<unsigned long>: in ns
4.9 Writing the configuration file using
BEHAVIOUR_DURATION
Suppose one has to write a configuration file for an IP using
STBUS_PLUG mode which has following characteristics.
 First behaviour reads 512 bytes.
 Second behaviour reads 512 bytes for 1000ns.
 Third behavior expects to read 512 bytes but have a maximum
duration of 50 ns
Fortnightly project report 2.
8
School of Electronics, Indore
 BEHAVIOUR_DURATION: it gives the length of behaviour
for STBUS_PLUG mode.
❏<unsigned long>: in ns
4.10 Writing the configuration file using
BEHAVIOUR_REQ_SPACE
Suppose one has to write a configuration file for an IP using
STBUS_PLUG mode which has following characteristics:
Each behaviour has a delay of 200 clock cycles between consecutive
messages but in different modes.
 BEHAVIOUR_REQ_SPACE: Indicate the minimum number of
clock cycles between two messages in STBUS_PLUG mode.
❏ <unsigned> [0|1|2]
4.11 Writing the configuration file using
IPTG_OUTSTANDING_MSG
Suppose one has to write a configuration file for an IP using
STBUS_PLUG mode which has following characteristics:
 IP can’t have more than one outstanding message at time.
IPTG_OUTSTANDING_MESSAGE : Describe the number of
outstanding messages at any time(in case of TLM_STBUS COM ).
❏ <unsigned>
4.12 Writing the configuration file using IPTG_REAL_TIME for
a read IP
Suppose one has to write a configuration file for an IP using
STBUS_PLUG mode which has following characteristics:
 The fifo can underflow that is the IP continues to read even if
the FIFO is empty.
IPTG_REAL_TIME: Determine the type of IP to be modeled. The
FIFO of the STBus plug-in interface can be overloaded for real-time
IP (the evolution of the FIFO will be traced and reported at the end of
simulation).
❏ <0 | 1>
4.13 Writing the configuration file using DEFINE
 DEFINE: This defines a parameter in either numeric constants
or some expressions, involving simple arithmetic which
evaluates to a numeric constant. To define a parameter in the
main configuration file, following syntax is used.
Fortnightly project report 2.
9
School of Electronics, Indore
$DEFINE <parameter_name> <parameter_value>
4.14 Writing the configuration file using RANDOM_ADDRESS
Suppose one has to write a configuration file for an IP using
STBUS_PLUG mode which has following characteristics:
 IP writes 256 bytes to a address selected randomly.
RANDOM_ADDRESS : This defines a parameter whose value is
determined randomly between a specified range. To use this
parameter, user should specify : start value of the range, end
value of the range, seed value for randomization and the
no of bits to be masked.
$RANDOM_ADDRESS <parameter_name> <start_address>
<end_address> <no_of_mask_bits> <seed>
4.15 Writing the configuration file using
BEHAVIOUR_CONNECT
Suppose one has to write a configuration file for an IP using
STBUS_PLUG mode which has following characteristics:
 Whenever IP is doing a NOP operation or waiting for all
responses to be consumed it can send the request of next
behaviour (but will not consume) to have pre filling of PLUG
FIFO.
BEHAVIOUR_CONNECT: This keyword specifies the connection
between the behaviours.
❏<bool>
4.16 Writing the configuration file using
IPTG_STBUS_PLUGIN_FIFO_LINK
Suppose one has to write a configuration file for an IP using
STBUS_PLUG mode which has following characteristics:
 IP reads and write data from memory through its interface with
following conditions :
 It cannot write to memory until it has not read anything (FIFO
empty).
 It cannot read from memory if it is not able to write (FIFO full).
IPTG_STBUS_PLUGIN_FIFO_LINK : Indicate whether stbus
plugin fifos of all initiators defined under IP_COMPONENT section
above are linked or not . If set to 1, it will link stbus plug fifos of all
the initiators within a same IP and will follow synchronization in fiforead and fifo-write.
❏ <bool>
Fortnightly project report 2.
10
School of Electronics, Indore
4.17 Write the configuration file using
IPTG_BEHAVIOUR_LINK
Suppose one has to write a configuration file for an IP using
STBUS_PLUG mode which has following characteristics:
 All the behaviours of no. of IPs (2 in this case) are synchronized
in a way that they switch together.
IPTG_BEHAVIOUR_LINK : Indicate whether the behaviours of all
initiators defined under IP_COMPONENT section above are
linked or not. If behaviours are linked then all behaviors are
synchronized in a way that they start at the same time.
❏<bool>
4.18 Writing the configuration file using event based
synchronization scheme
(WAIT, GEN, BEHAVIOUR_SYNC_DATA_LENGTH and
BEHAVIOUR_SYNC_WAIT keywords)
Suppose one has to write a configuration file for a number of initiators
(2 in this case)which are synchronized as below:
 First initiator cannot read the data in its first behaviour until
second initiators has not written 32 bytes to memory in its first
behaviour.
 Second initiator cannot write further 32 bytes until the first
initiator has not consumed all the data in the first behaviour.
 WAIT: Wait for an event on signal specified. This is an
optional keyword used for synchronization. There must be a
GEN <signal> in any other initiator corresponding to this
WAIT<signal>.
 GEN: Generate an event on signal specified. This is an optional
keyword used for synchronization. There must be a WAIT
<signal> in any other initiator corresponding to this
GEN<signal>.
 BEHAVIOUR_SYNC_WAIT: IPTG will wait for an event,
specified by BEHAVIOUR_SYNC_WAIT and start consuming
the data from FIFO as soon as this event is notified by any other
initiator.
❏ <string>
 BEHAVIOUR_SYNC_DATA_LENGTH: Generate an event
on signal specified after the specified amount of data has been
written or read from the FIFO.
Fortnightly project report 2.
11
School of Electronics, Indore
❏<<unsigned> <string>>
5. GENKIT
The objective of this lab is to make an IPTG based architecture
platform using Genkit. This lab is intended to guide the user for
using Genkit and associated components to make an example
platform. This lab is also intended to show how one can use Genkit
generated platform to analyse the performance of IP and also that
of the used interconnect.
Making an example platform through GENKIT
Suppose one has to generate an interconnect for 6 different
IPTGs and a memory with following characteristics:
 3 IPTGs at STB T2 level of 32, 64 and 128 bytes each.
 3 IPTGs at STBus T3 level of 32, 64 and 128 bytes each.
 A 64 byte Memory at STBus T3 level.
To make an interconnect between these IPTGs and the
memory, one may need the following components:
 2 ( 32 to 64 byte ) Size Converters.
 2 ( 128 to 64 bytes ) Size Converters.
 3 STBus Nodes at T3 level of 64 bytes bus size.
 1 ( STBusT2 to STBusT3 ) Type Converter.
 1 Buffer at T3 level of 64 bytes bus size.
 a set of node to connect above components.
An example platform based on above components can be easily
assembled in Genkit GUI.
Fortnightly project report 2.
12
School of Electronics, Indore
Before generating the platform, Genkit first checks the system rules for any
protocol violation. Once it is done, if specified model is correct then it can generate
the system. User may choose the abstraction level, simulation environment and
other infrastructure while generating the system. The generated platform can then
be used instead of what has been used in lab1/STBUS_PLUG or lab1/TRAFFIC.
The various files/directories generated by Genkit for this example platform are
present in lab1/GENKIT folder. One can make more complex platform by
specifying more IPTGs and complex interconnect depending upon requirement.
6. LAB 2
Lab2 is dedicated to AHB based initiators. With this protocol only traffic mode is
used. The objective of this lab is to write the configuration file for an IP from its
specification using the AHB protocol and then simulate it in a given platform. This
lab is intended to guide the user for writing IPTG configuration file based on some
statistics specification and sequence of an IP traffic. The example platform consists
of 1 IPTG ahb initiator which communicates to a memory through interconnect in
IUS based simulation environment.
Fortnightly project report 2.
13