Virtual Cycle-accurate Hardware and Software Co-simulation Platform for Cellular IoT

75 Pages·2017·1.62 MB·English

P M
rin A
te R
d b CE
y Tryck L TOV
erie AR
t i E-h & PA
use TR
t, Lund 20 IK ELFBO Virtual Cycle-accurate Hardware and Software
17 R
G
Co-simulation Platform for Cellular IoT
MARCEL TOVAR
PATRIK ELFBORG
MASTER´S THESIS
V
irtu DEPARTMENT OF ELECTRICAL AND INFORMATION TECHNOLOGY
al C FACULTY OF ENGINEERING | LTH | LUND UNIVERSITY
y
cle-accu
rate H
ard
w
are an
d
S
o
ftw
are C
o
-sim
u
latio
n
P
latfo
rm
fo
r C
ellu
lar Io
T
Series of Master’s theses
Department of Electrical and Information Technology L
U
LU/LTH-EIT 2017-602 N
D
2
0
http://www.eit.lth.se 17
Virtual Cycle-accurate Hardware and Software
Co-simulation Platform for Cellular IoT
Marcel Tovar
[email protected]
Patrik Elfborg
[email protected]
Department of Electrical and Information Technology
Lund University
Supervisor: Liang Liu
Examiner: Erik Larsson
October 4, 2017
(cid:13)c 2017
Printed in Sweden
Tryckeriet i E-huset, Lund
Abstract
ModernembeddeddevelopmentflowsoftendependonFPGAboardusageforpre-
ASIC system verification. The purpose of this project is to instead explore the
usage of Electronic System Level (ESL) hardware-software co-simulation through
theusageofARMSoCDesignertooltocreateavirtualprototypeofacellularIoT
modem and thereafter compare the benefits of including such a methodology into
the early development cycle. The virtual system is completely developed and ex-
ecuted on a host computer, without the requirement of additional hardware. The
virtual prototype hardware is based on C++ ARM verified cycle-accurate mod-
els generated from RTL hardware descriptions, High-level synthesis (HLS) pre-
synthesis SystemC HW accelerator models and behavioural models which imple-
ment the ARM Cycle-accurate Simulation Interface (CASI). The micro-controller
of the virtual system which is based on an ARM Cortex-M processor, is capable
of executing instructions from a memory module.
This report documents the virtual prototype implementation and compares
boththesoftwareperformanceandcycle-accuracyofvariousvirtualmicro-controller
configurations to a commercial reference development board. By altering fac-
tors such as memory latencies and bus interconnect subsystem arbitration in co-
simulations, the software cycle-count performance of the development board was
shownpossibletoreproducewithina5%errormargin,atthecostofapproximately
266 times slower execution speed. Furthermore, the validity of two HLS pre-
synthesis hardware models is investigated and proven to be functionally accurate
within three clock cycles of individual block latency compared to post-synthesis
FPGA synthesized implementations.
The final virtual prototype system consisted of the micro-controller and two
cellular IoT hardware accelerators. The system runs a FreeRTOS 9.0.0 port, ex-
ecuting a multi-threaded program at an average clock cycle simulation frequency
of 10.6 kHz.
i
ii
Popular Science Summary
Designing and simulating embedded computer systems virtually
Cellularinternetofthings(IoT)isanew not begin their work properly until the
technology that will enable the inter- hardware is finished, which makes the
connection of everything: from street process very long, and the fact that the
lights and parking meters to your gas hardware has been printed on silicon
or water meter at home, wireless cellu- greatly restricts the possibility of do-
lar networks will allow information to ingchangestoaccommodatelatesystem
be shared between devices. However, in requirement alterations; which is quite
order for these systems to provide any likely for a tailor-made application spe-
usefuldata,theyneedtoincludeacom- cific system such as a cellular IoT chip.
puterchipwithasystemtomanagethe
A currently widespread technology
communication itself, enabling the con-
used to mitigate the previously men-
nectiontoacellularnetworkandtheac-
tioned negative aspects of embedded
tualtransmissionandreceptionofdata.
design, is the employment of field-
Such a chip is called an embedded chip
programmable gate array (FPGA) de-
or system.
velopmentboardswhichoftencontaina
Traditionally, the design and ver- micro-controller (with a processor and
ification of digital embedded systems, some memories), and a gate array con-
that is to say a system which has both nectedtoit. TheFPGApartconsistsof
hardwareandsoftwarecomponents,had a lattice of digital logic gates which can
to be done in two steps. The first beprogrammedtointerconnectandrep-
step consists of designing all the hard- resent the functionality of the hardware
ware, testing it, integrating it and pro- being designed. The processor can thus
ducing it physically on silicon in or- execute software instructions placed on
der to verify the intended functional- the memories and the hardware being
ity of all the components. The second developed can be programmed into the
step thus consists of taking the hard- gatearrayinordertointegrateandver-
ware that has been developed and de- ifyafullhardwareandsoftwaresystem.
signing the software: a program which Nevertheless, this boards are expensive
will have to execute in complete com- and limit the design to the hardware
pliance to the hardware that has been components available commercially in
previously developed. This poses two the different off-the-shelf models, e.g. a
mainissues: thesoftwareengineerscan- specific processor which might not be
iii
the desired one. con implementation. The clock cycle-
Now imagine there is a way to de- accuratelevelisoneofthehighestaccu-
sign hardware components such as pro- racy system simulation methods avail-
cessors in the traditional way, how- able, and it consists of representing the
ever once the hardware has been im- digital states of all hardware compo-
plemented it can be integrated together nents such as signals and registers, in
withsoftwarewithouttheneedofprint- a cycle-by-cycle manner.
ingaphysicalsiliconchipspecificallyfor By using the ARM SoC Designer
this purpose. That would be extremely ESL tool, we have co-designed and co-
convenient and would save lots of time, simulated several microcontrollers on a
would it not? Fortunately, this is al- detailed, cycle-accurate level and con-
ready possible due to Electronic Sys- firmed its behaviour by comparing it to
tem Level (ESL) design, which is com- a physical reference target development
pilation of techniques that allow to de- board. Finally, a more complex vir-
sign,simulateandpartiallyverifyadig- tual prototype of a cellular IoT system
ital chip, all within any normal laptop was also simulated, including a micro-
or desktop computer. Moreover, some controller running a a real-time operat-
ESL tools such as the one investigated ing system (RTOS), hardware accelera-
in this project, allow you to even simu- torsandserialdatainterfacing. Partsof
late a program code written specifically this virtual prototype where compared
for this hardware; this is known as vir- to an FPGA board to evaluate the pros
tual hardware software co-simulation. andconsofincorporatingvirtualsystem
The reliability of simulation must simulation into the development cycle
however be considered when compared and to what extent can ESL methods
to a traditional two-step methodology substitute traditional verification tech-
or FPGA board usage to verify a full niques. The ease of interchanging hard-
system. This is because a virtual hard- ware, simplicity of development, simu-
waresimulationcanhaveseveraldegrees lation speed and the level of debug ca-
ofaccuracy,dependingonthespecificity pabilitiesavailablewhendevelopingina
of component models that make up the virtual environment are some of the as-
virtual prototype of the digital system. pects of ARM SoC Designer discussed
Therefore, in order to use co-simulation in this thesis. A more in depth de-
techniques with a high degree of confi- scriptionofthemethodologyandresults
dence for verification, the highest accu- can be found in the report titled Vir-
racydegreeshouldbeemployedifpossi- tual Cycle-accurate Hardware and Soft-
bletoguaranteethatwhatisbeingsim- ware Co-simulation Platform for Cellu-
ulated will match the reality of a sili- lar IoT.
iv
Acknowledgements
We would like to thank first and foremost Magnus Midholt and Michal Stala at
ARM Sweden for giving us the opportunity to carry out this project in a new and
exciting field for us, and for their continuous support and encouragement. We
would also like to thank everyone else at the ARM LPWAN team for aiding us at
several occasions as we build up an understanding of the system.
Furthermore, we would also like to thank our supervisor Liang Liu for his
guidanceindeterminingacleargoalforthethesisaswellashishelpincondensing
all of the broad work we have done into a coherent project.
v
vi
Table of Contents
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Cellular IoT and ARM Wireless Business Unit . . . . . . . . . . . . . 3
1.3 Aims and challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Previous work and alternative tools . . . . . . . . . . . . . . . . . . 4
1.5 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Electronic System Level Design 7
2.1 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 System simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 ARM SoC Designer 17
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Modelling libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 The canvas & simulator . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Processor core models and ELF files . . . . . . . . . . . . . . . . . . 21
4 Developing a Virtual System Micro-controller 23
4.1 Virtual hardware base configuration . . . . . . . . . . . . . . . . . . 23
4.2 Start-up code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Compiling the start-up binary . . . . . . . . . . . . . . . . . . . . . 26
5 Software Performance of a Minimal System 27
5.1 Reference development board . . . . . . . . . . . . . . . . . . . . . 27
5.2 Altering the bus and memory subsystem . . . . . . . . . . . . . . . . 29
5.3 Benchmark software functions . . . . . . . . . . . . . . . . . . . . . 30
5.4 The testbench ELF image . . . . . . . . . . . . . . . . . . . . . . . 30
5.5 Compilation of the test binaries . . . . . . . . . . . . . . . . . . . . 31
5.6 Testing the systems. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6 Co-design and Integration of Hardware Blocks 33
6.1 Integrated hardware blocks . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Wrapping SystemC with ESL APIs. . . . . . . . . . . . . . . . . . . 35
vii