Western University

Scholarship@Western

Electronic Thesis and Dissertation Repository

8-28-2017 12:00 AM

lmproving Microcontroller and Computer Architecture Education

through Software Simulation
Kevin Brightwell, The University of Western Ontario

W
Supervisor: McIsaac, Kenneth, The University of Western Ontario
A thesis submitted in partial fulfillment of the requirements for the Master of Engineering
IE
Science degree in Electrical and Computer Engineering
© Kevin Brightwell 2017
EV
PR

Follow this and additional works at: https://ir.lib.uwo.ca/etd

Part of the Computer and Systems Architecture Commons, Digital Circuits Commons, and the
Engineering Education Commons

Recommended Citation
Brightwell, Kevin, "lmproving Microcontroller and Computer Architecture Education through Software
Simulation" (2017). Electronic Thesis and Dissertation Repository. 4886.
https://ir.lib.uwo.ca/etd/4886

This Dissertation/Thesis is brought to you for free and open access by Scholarship@Western. It has been accepted
for inclusion in Electronic Thesis and Dissertation Repository by an authorized administrator of
Scholarship@Western. For more information, please contact wlswadmin@uwo.ca.
 Abstract

In this thesis, we aim to improve the outcomes of students learning Computer Architecture
and Embedded Systems topics within Software and Computer Engineering programs. We de-
velop a simulation of processors that attempts to improve the visibility of hardware within the
simulation environment and replace existing solutions in use within the classroom. We desig-
nate a series of requirements of a successful simulation suite based on current state-of-the-art
simulations within literature. Provided these requirements, we build a quantitative rating of
the same set of simulations. Additionally, we rate our previously implemented tool, hc12sim,
with current solutions. Using the gaps in implementations from our state-of-the-art survey, we
develop two solutions. First, we developed a web-based solution using the Scala.js compiler

W
for Scala with an event-driven simulation engine through Akka. This Scala model implements
a VHDL-like DSL for instruction control definition. Next we propose tools for developing
IE
cross-platform native applications through a project-based build system within CMake and
a continuous integration pipeline using Vagrant, Oracle VirtualBox and Jenkins. Lastly, we
EV
propose a configuration-driven processor simulation built from the original hc12sim project
that utilizes a Lua-based scripting interface for processor configuration. While we considered
other high-level languages, Lua best fit our requirements allowing students to use a modern
high-level programming language for processor configuration. Instruction controls are defined
PR

through Lua functions using high-level constructs that implicitly trigger low-level simulation
events. Lastly, we conclude with suggestions for building a new solution that would better
meet requirements set forth in our research question building from successful aspects from this
work.

Keywords: Embedded systems, computer architecture, computer architecture simulation,

pedagogy, cross-platform application development

i
 Acknowledgements

I would like to acknowledge my advisor Dr. Kenneth McIsaac for his continued support
and mentorship throughout my undergraduate and graduate works. Thank you for taking the
time to debug, construct, and destruct ideas from all angles. Your direction has allowed me to
grow as a research, engineer and academic.
I would like to thank my peers in Dr. McIsaac’s lab for providing laughs and support over
the course of this work. I would like to extend the same thanks to those in Dr. Xianbin Wang
and Dr. Roy Eagleson’s labs for being supportive peers through forced geographic association.
I would like to thank my father and step mother, John and Amy Brightwell, and my mother
and step father, Kyra Hanson and Wilf Wityshyn, for listening to my complaints, failures and

W
successes throughout this work and never batting an eye of support. I would like to thank Mr.
Brad de Vlugt, Mr. Kyle Fricke, and Ms. Trinette Wright for their continued support over the
IE
course of this work providing friendship and a talking post repeatedly. Lastly, I would like
to thank my boyfriend Eric Pattara for his love, continuous support and delightful immaturity
EV
when I needed that most.
To any and all of my colleagues, peers, family and friends thank you for your support.
PR

ii
Contents

Abstract i

Acknowledgements ii

List of Figures vi

W
List of Tables viii

List of Listings
IE ix

List of Definitions xi
EV

List of Appendices xiii

1 Introduction 1
PR

1.1 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Software versus Hardware . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Survey of other and previously completed works 17

2.1 Previous Work: hc12sim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Hardware Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Evaluation of existing simulation technologies . . . . . . . . . . . . . . . . . . 23

iii
 2.2.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2 hc12sim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.3 ShelbySim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.4 EDCOMP: Flexible Web-Based Educational System . . . . . . . . . . 27
2.2.5 p88110: A Graphical Simulator for Computer Architecture and Orga-
nization Courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.6 EASE - An Extensible Architecture Simulation Engine . . . . . . . . . 31
2.2.7 TinyCPU and TinyCSE: Hardware simulations for education . . . . . . 32
2.2.8 CPU Sim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.9 Emumaker86: A Hardware Simulator for Teaching CPU Design . . . . 40

W
2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3 procsim.scala: Scala-based event-driven processor simulation for the web

IE 45
3.1 Introduction to Scala and Akka . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Event- and Message-driven Simulation . . . . . . . . . . . . . . . . . . . . . . 48
EV
3.3 Scala.js - Scala transpiler for JavaScript . . . . . . . . . . . . . . . . . . . . . 49
3.4 Implementation of procsim.scala . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.1 VHDL-like DSL configuration and runtime-based instructions . . . . . 50
PR

3.4.2 Akka-based Components . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5 Technology Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.6 Analysis of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4 Developing cross-platform C++ applications 59

4.1 Modernizing hc12sim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Cross-platform development . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.1 Access to multiple platforms within a single host platform . . . . . . . 62
4.2.2 Building with cross-platform tools . . . . . . . . . . . . . . . . . . . . 64
4.3 Testing Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4 Improving developer work flows within CMake . . . . . . . . . . . . . . . . . 68

5 Lua-based configuration-driven processor simulation 76

iv
 5.1 Utilizing runtime configurations through scripting . . . . . . . . . . . . . . . . 77
5.1.1 Scripting language selection . . . . . . . . . . . . . . . . . . . . . . . 77
Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Java and Scala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Lua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Scripting language decision . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1.2 Lua integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.3 Configuration versus Simulation entities . . . . . . . . . . . . . . . . . 90
5.2 Lua-based Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3 Instruction definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

W
5.3.1 Opcode and Operand encoding . . . . . . . . . . . . . . . . . . . . . . 99
5.3.2 Instruction execution: Side-effect-based compilation . . . . . . . . . . 102
IE
5.4 Project design and technical flaws . . . . . . . . . . . . . . . . . . . . . . . . 109
5.4.1 Compiler strain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
EV
5.4.2 Loss of pedagogical gains for high- versus low-level constructs . . . . . 110
5.5 Analysis of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6 Conclusion 114
PR

6.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Bibliography 120

A Procsim headers 132

A.1 Memory Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
A.2 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
A.3 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
A.4 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Curriculum Vitae 171

v
List of Figures

1.1 ECE 3375 - Course Sentiment Analysis Results [24], [25] . . . . . . . . . . . . 4

1.2 WinIDE12Z Integrated Development Environment [26] . . . . . . . . . . . . . 6
1.3 Freescale M68HC12 development board built by Western Engineering Elec-
tronics Shop for use in ECE 3375 . . . . . . . . . . . . . . . . . . . . . . . . . 6

W
1.4 StackOverflow 2016 developer survey results for desktop operating systems
[36, Sec. VIII. Desktop Operating System] . . . . . . . . . . . . . . . . . . . . 12

2.1
IE
hc12ide Integrated Development Environment showing a student error in an
incorrect specification of an instruction mnemonic. . . . . . . . . . . . . . . . 18
EV
2.2 hc12sim Instruction Generator showing the meta information for addressing
modes, execution, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Block diagram of TinyCPU showing the internal architecture [29, p. 869] . . . 33
PR

2.4 State chart of TinyCPU execution path [29, p. 869] . . . . . . . . . . . . . . . 33

2.5 TinyCSE execution state diagram modified from Figure 2.4 to include inter-
rupts (broken lines show changes from TinyCPU [29]) [28, p. 640] . . . . . . . 34
2.6 CPU Sim 4.0.0 IDE during debugging with Assembly Editor open [52] . . . . . 37
2.7 CPU Sim Machine Instruction configuration interface showing combination of
fields to create a microcode and an assembly instruction. . . . . . . . . . . . . 38
2.8 CPU Sim 4.0.0 IDE module specification dialog showing modification of Trans-
fer Register to Register Array microinstruction [52] . . . . . . . . . . . . . . . 39
2.9 Emubuilder86 Control Builder: State machine definition [56, p. 325] . . . . . . 41

3.1 Graphical representation of three Actors sending bi-directional messages [70]. . 48

5.1 URISC hardware architecture with microcodes [6]. . . . . . . . . . . . . . . . 92

vi
5.2 Control unit for the 16-bit URISC architecture from [6, p. 331]. . . . . . . . . . 111

W
IE
EV
PR

vii
List of Tables

1.1 ECE 3375 Course “Level of enthusiasm before taking the course” as reported
by undergraduate students following course completion [24], [25]. . . . . . . . 5

2.1 Qualitative requirement rating of hc12sim [40] . . . . . . . . . . . . . . . . . . 25

2.2 Qualitative requirement rating of ShelbySim [35], [45] . . . . . . . . . . . . . 27

W
2.3 Qualitative requirement rating of EDCOMP [30] . . . . . . . . . . . . . . . . . 29
2.4 Qualitative requirement rating of p88110 [31] . . . . . . . . . . . . . . . . . . 31
2.5
2.6
IE
Qualitative requirement rating of EASE [34] . . . . . . . . . . . . . . . . . . . 32
Qualitative requirement rating of TinyCPU/TinyCSE [28], [29] . . . . . . . . . 35
2.7 Qualitative requirement rating of CPU Sim [39] . . . . . . . . . . . . . . . . . 40
EV
2.8 Qualitative requirement rating of Emumaker86 [56] . . . . . . . . . . . . . . . 42
2.9 Summary of Evaluation for Simulators . . . . . . . . . . . . . . . . . . . . . . 43
PR

3.1 Summary of requirement matching for procsim.scala. . . . . . . . . . . . . . . 58

5.1 Summary of requirement matching for procsim. . . . . . . . . . . . . . . . . . 113

viii
List of Listings

2.1 Sample of the JSON output used to generate code within hc12sim. BEQ per-
forms a branch if two values were equal. . . . . . . . . . . . . . . . . . . . . . 21
3.1 An example DSL source written in Scala to emulate BASIC called “Baysick” [1] 47

W
3.2 Normal definition of Instruction. . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3 Reified definition of Instruction. . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4 Clock pulse message for Akka . . . . . . . . . . . . . . . . . . . . . . . . . . 54
IE
3.5 Actor that listens for ClockPulse messages and prints the time. . . . . . . . . 55
4.1 Vagrant file that describes a Ubuntu 14.04 box with modern GCC 5.X and
EV
LLVM Clang 3.7 compilers installed. . . . . . . . . . . . . . . . . . . . . . . 65
4.2 CMake script showing how two test suites, time and encoding, are defined
as part of a project, core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
PR

4.3 Test output from CTest [2] from Microsoft Visual Studio Community 2015 for
procsim showing organization provided by CMake configuration. . . . . . . . . 75
5.1 Example of exposing a C++ class to Python [3]. . . . . . . . . . . . . . . . . . 79
5.2 Table used to describe project information for the Lua.org site [4] . . . . . . . 84
5.3 class player that holds two fields, one for hitpoints (hp) and one for bullets
a player has (adapted from [5]). . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.4 Utilize the class player within a Lua script (adapted from [5]). . . . . . . . 88
5.5 Required bindings to allow utilization of class player from Lua (adapted
from [5]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.6 Configuration of Figure 5.1 for the URISC processor [6]. . . . . . . . . . . . . 93
5.7 (Continued) Configuration of Figure 5.1 for the URISC processor [6]. . . . . . 94
5.8 Clock configuration for the processors main clock (cut from Listing 5.6). . . . 96

ix
5.9 Register configuration for the program counter (cut from Listing 5.6). . . . . 97
5.10 Memory unit configuration for the program counter (cut from Listing 5.6). . . . 98
5.11 Processor utilizing memory mapping functionality. . . . . . . . . . . . . . . . 100
5.12 Encoding of the opcode and operands of the SUBLEQ Instruction (cut from
Listing 5.6). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.13 Execution definition for the SUBLEQ Instruction (cut from Listing 5.6). . . . 104
5.14 Local variable definitions within an Instruction:exec() method. . . . . . . 106
A.1 Source for procsim/memory/MemoryUnit.hpp. . . . . . . . . . . . . . . . . 132
A.2 Source for procsim/memory/Register.hpp. . . . . . . . . . . . . . . . . . 140
A.3 Source for procsim/time/Clock.hpp. . . . . . . . . . . . . . . . . . . . . . 143
A.4 Source for procsim/time/AsyncTimerReceiver.hpp. . . . . . . . . . . . . 146

W
A.5 Source for procsim/time/Timer.hpp. . . . . . . . . . . . . . . . . . . . . . 148
A.6 Source for procsim/encoding/Algorithm.hpp. . . . . . . . . . . . . . . . 155
IE
A.7 Source for procsim/encoding/Code.hpp. . . . . . . . . . . . . . . . . . . . 158
A.8 Source for procsim/encoding/Operand.hpp. . . . . . . . . . . . . . . . . . 162
EV
A.9 Source for procsim/core/Instruction.hpp. . . . . . . . . . . . . . . . . . 164
A.10 Source for procsim/core/Proc.hpp. . . . . . . . . . . . . . . . . . . . . . 168
PR

x
List of Definitions

Application Programming Interface (API) A software layer between a developer that uti-
lizes a library or program and the library or program itself. APIs are designed to hide imple-
mentation details and ease developer usage.

W
Arithmetic Logic Unit (ALU) In a computer system, ALUs are responsible for performing
arithmetic operations on binary input such as addition, shifts, multiplication, division.
IE
Complex Instruction Set Computer (CISC) A type of microprocessor architecture that uti-
lizes larger, instructions aiming to reduce the software instructions required to complete a task
EV
[7], [8]. CISC architectures are used in most general applications based on Intel® x86 ISA [9].

Domain-Specific Language (DSL) A computer programming language that is specialized to

a particular application space (domain). For example, HTML is a DSL used to layout websites
PR

but could not be used to program an embedded device. Similarly, C++ is an excellent language
for creating applications but is very poor at describing layout for a webpage.

Embedded Systems Topics involving characteristics of embedded systems, techniques for

embedded applications, parallel input and output, synchronous and asynchronous serial com-
munication, interrupt handling, applications involving data acquisition, control, sensors, and
actuators, implementation strategies for complex embedded systems [10, p. 118]

Computer Architectures Topics involving computer organization and architecture. Includ-

ing, but not limited to processor organization, instruction set architecture, memory system
organization, performance, and interfacing fundamentals [10, p. 118]

Graphical User Interface (GUI) Any interface based on rendering graphically, for example
a window with buttons.

xi
Hardware Description Language (HDL) A programming language used to describe the struc-
ture and behaviour of electronic circuits. These languages are used to synthesize simulated and
physical circuit layout from the gate and register transfer level [11].

Instruction Set Architecture (ISA) The design of an interface between software and hard-
ware designs in a computing environment. Including but not limited to assembly language and
microcode design. Once realized, an ISA is referred to as an Instruction Set Implementation.

Integrated Development Environment (IDE) A tool used for developing hardware and soft-
ware components that provides integrated tools for the current development context. For ex-
ample, Xilinx ISE [12], JetBrains IntelliJ IDEA1 , or Eclipse2 .

W
Just-in-Time Compiler (JIT) A traditional compiler that operates at runtime to perform op-
timization on running code. JITs are typically found in interpreted languages such as on the
IE
JVM or in JavaScript. JITs vastly improve the runtime of the code they compile as they often
utilize semantics such as code path tracing and known constant analysis that is not necessarily
EV
available at compile-time.

Reduced Instruction Set Computer (RISC) A type of microprocessor architecture that uti-
lizes small, highly-optimized set of instructions used to reduce power and improve instruction
PR

performance [7], [8]. These architectures are commonly used in embedded, mobile (ARM),
and high-performance server applications (IBM POWER).

Reification The process by which an abstraction (usually a String representation) of software

is converted into an explicit object. For example, JavaScript’s eval(script) compiles and
executes the content of the script passed and any state changes within the script are applied
to the global scope.

Transpiler A compiler that compiles one language to another. Typical transpilers convert one
language to JavaScript to allow use in web applications. For example, Scala.js and TypeScript
both compile their respective language to JavaScript.

1
Available: https://www.jetbrains.com/idea/
2
Available: http://www.eclipse.org

xii
List of Appendices

Appendix A Procsim headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

W
IE
EV
PR

xiii
Chapter 1

Introduction

W
Embedded systems and computer architectures are a critical part of both computer and software
IE
engineering undergraduate programs [10], [13]–[16]. Over time, it is expected that knowledge
EV
of embedded systems and computer architectures will be required given projections of rapid

growth of positions in both systems software developers (+13%) and computer occupations

(+12.5%) for 2020 [17]. At our institution, Western University, four courses cover embedded
PR

systems and computer architectures, ECE 3375 - Microprocessors and Microcomputers, ECE

3389 - Computer System Design, ECE 3390 - Hardware/Software Co-Design and ECE 4460

- Real-time and Embedded Systems [18]. These topics are taught through the use of industry

focused software such as Intel Quartus Prime (formerly Altera Quartus II) [19], Xilinx ISE

WebPACK [12] or WinIDE [20]. These established industry tools are complex and powerful

for industry but we have anecdotally found students often feel overwhelmed during use. Ad-

ditionally with the prevalence of high-level programming languages, embedded systems work

has become increasingly difficult for students. Students are troubled connecting high-level

concepts to low-level details in computer architectures largely due to theoretical discontinu-

1
2 Chapter 1. Introduction

ities between lecture materials and the “black box” of hardware.

1.1 Research Question

This thesis attempts to answer the following research question:

Can improvements and increased usage of software simulation technologies within

laboratory exercises in undergraduate embedded system and computer architecture
courses improve student engagement in laboratory and assignment exercises?

W
Given the overall research question, there exist sub-questions:

IE
1. Are simulation software beneficial to improvements in student outcomes in computer

and software engineering programs?

EV

2. What elements of simulation software should be required for successful implementation

within an undergraduate course?

PR

Each of these questions are elaborated in further sections.

1.2 Motivation

Students in computer engineering have a growing requirement to have strong knowledge of

both embedded systems and computer architectures due to increases in computer engineering

careers [10], [17]. Unfortunately, many students do not show enthusiasm for subjects surround-

ing computer architecture and embedded systems [16], [21]. This lowered enthusiasm reduces

student achievements and creates implicit barriers for learning new material [15], [21].
1.2. Motivation 3

At Western University, students in all students in Electrical & Computer Engineering de-

gree programs must take the course ECE 3375 - Microprocessors and Microcomputers [22],

[23]. We utilized the feedback students provide through end-of-semester course evaluations to

gauge student enthusiasm and sentiment regarding ECE 3375. In order to extract sentiment,

we applied a simplistic approach. If a comment was overtly positive or negative, we stated it

was positive or negative respectively. If a comment was indistinguishable, we erred to neu-

tral to try and remove our own biases. Unfortunately due to confidentiality, we are unable to

provide these comments directly. As seen in Table 1.1, student enthusiasm for ECE 3375 at

W
Western University is mixed. Unfortunately, our collected data is not broken down between

computer and software engineering – both are required to take this course. Additionally, with
IE
primitive sentiment analysis applied to results from 2013 and 2014 [24], [25], shown in Fig-
EV
ure 1.1a, we can see that after completion of the course, students are pleased overall with the

course content itself as approximately 73% of students found the experience positive. How-

ever, by filtering comments regarding the laboratory sessions and applying the same technique
PR

for sentiment as the course, shown in Figure 1.1b, we find that students are likely very unhappy

with the lab components as approximately 33% stated negative reviews and only 24% stated

positive reviews. Due to time constraints, we were unable to compile a formal survey due to

time required for ethics approvals and program duration.

Researchers have found that there are concerns with low-level hardware constructs being

taught to high-level Computer Science, Software Engineering and Computer Engineering grad-

uates [15], [16]. Additionally, we can corroborate the following claims by Ristov et. al. [15]

regarding student’s opinions on microprocessor courses:

Observation 1. Disjointed material between lectures, theoretical and practical ex-

4 Chapter 1. Introduction

W
IE
(a) Course Sentiment
EV
PR

(b) Lab Sentiment

Figure 1.1: ECE 3375 - Course Sentiment Analysis Results [24], [25]
1.2. Motivation 5

ercises. Students could not transfer knowledge gained from either lectures or the-
oretical exercises to practical exercises [. . . ]

Observation 2. Inappropriate programming and simulation environment. Students

faced installation problems [. . . ] leading to aversion to presented material and
exercises.

Observation 3. No “real world” application. [. . . ] Students [raise] the main ques-

tion: Why we are learning this, and how and where shall I use it?

([15, p. 340])

Given our first-hand experiences in both taking and assisting in the instruction of ECE 3375

W
and ECE 3390, these claims are repeated by students during laboratory exercises and review

sessions creating hostility towards the subject matter. In a direct example supporting observa-
IE
tion 2, students in ECE 3375 use the WinIDE12Z Integrated Development Environment [20],

shown in Figure 1.2, for completing laboratory work ranging from simple “hello world” as-
EV

sembly programs to hardware interfacing. In ECE 3375, students found WinIDE complicated,

frustrating and “outdated” [24], [25] directly supporting both observation 2 and observation 3.
PR

Additionally students found it difficult to move from lecture material that presented embedded

systems as “translucent” devices composed of inner components to the literal “black box” of

the physical hardware shown in Figure 1.3.

With sentiment analysis and the comments provided by students in course evaluation feed-

Initial Level of Enthusiasm

Year 2013 2014 Total
High % 45.6 57.8 53.0
Medium % 54.2 33.3 41.6
Low % 0.0 8.9 5.4
Total # 59 90 149

Table 1.1: ECE 3375 Course “Level of enthusiasm before taking the course” as reported by
undergraduate students following course completion [24], [25].
6 Chapter 1. Introduction

W
IE
Figure 1.2: WinIDE12Z Integrated Development Environment [26]
EV
PR

Figure 1.3: Freescale M68HC12 development board built by Western Engineering Electronics
Shop for use in ECE 3375
1.2. Motivation 7

back [24], [25], we extracted several common propositions for improving laboratory sessions:

Proposition 1. Increase the number of laboratory sessions

Proposition 2. Add tutorial sessions to course schedule

Proposition 3. Change course material to use modern processors

Proposition 4. Replace laboratory microcontrollers with different hardware

Proposition 5. Improve and/or replace software within laboratory

W
All of these considerations were brought to the course instructor and limitations were noted
IE
for each. For Propositions 1 and 2, while the addition of more hands-on experience has been
EV
shown to improve student outcomes [15], [16], due to the large amount of financial resources

required to add more laboratory sessions, this option is likely unavailable for many programs.

In addition, due to the layout of the current course laboratory sessions, there does not exist
PR

enough weeks in the 12-week course to add more sessions given current staffing resources. It

is reasonable to assume that these issues are prevalent at other institutions. Thus, both Propo-

sitions 1 and 2 can not be implemented given financial and temporal restrictions.

Proposition 3 asks the instructor to change the current course material to use more modern

hardware and software architecture. There are several reasons why this is not beneficial to the

improvement of learning outcomes. The current architecture used is the Freescale M68HC12.

This architecture provides a simple Complex Instruction Set Computer (CISC) Instruction Set

Architecture (ISA) with only four 16-bit addressable registers (SP, PC, X, Y); two eight-bit accu-

mulators (A, B) and multiple addressing modes [27]. The software abstractions of the Freescale
8 Chapter 1. Introduction

M68HC12 assembly is similar to current Intel® x86 processors [9]. Parallels between ar-

chitectures allows instructors to use more simple architectures that still allow students to apply

concepts to newer architectures while simultaneously reducing the cognitive “base knowledge”

required to succeed. Using simpler architectures like the Ultimate Reduced Instruction Set

Computer (URISC, [6]) has been shown to be very beneficial to improving student outcomes

[6], [28]–[31]. Additionally, by changing course materials, it leads into changing the labora-

tory hardware which Proposition 4 discusses. Unfortunately, replacing laboratory equipment

requires significant investment and with justifications for Proposition 3 showcasing that there

W
is not noticeable improvements in learning outcomes, the cost-benefit analysis does not prove

worthwhile to adjust both Propositions 3 and 4.

IE
The last proposition, Proposition 5 is the most attainable. Researchers have found that
EV
improving software technology in the classroom and laboratory can vastly improve the learn-

ing outcomes of students while improving engagement [10], [15], [16], [21], [30], [32]–[35].

Students within ECE3375 are immediately presented with the interfaces shown in Figure 1.2.
PR

Students have expressed immense frustrations with the software when used in the laboratory

exercises and often encounter hardware issues that are not caused by their own work [24], [25].

Other researchers have found hardware solutions problematic with hardware-specific problems

common such as broken peripherals and unconnected pins [21]. These errors are hard to de-

bug, if not impossible for students with no prior knowledge. Teaching assistants and instructors

are often unable to debug these issues without the aid of technicians. These hard-to-diagnose

hardware issues lead to strained teaching resources and frustrations, supporting a large poten-

tial gain by replacing this ageing software with new tooling. Given these justifications, this

thesis looks to investigate the requirements surrounding replacing the current software in use
1.3. Problem Statement 9

within the ECE 3375 course and propose a configurable solution for others to utilize in other

courses.

1.3 Problem Statement

Our analysis of the current state of the ECE 3375 course showcased the pervasive dislike and

discomfort with the current laboratory exercises [24], [25]. Given previous analysis, we chose

to improve the current software used within the laboratory exercises and the classroom. To do

this, a current survey of known technologies is completed to ascertain whether a new solution

W
should be created or an existing solution will provide the requirements. Therein the formal

problem becomes:
IE
Can a solution be provided to students that is configurable for hardware and soft-
EV
ware interfaces and showcases the connection between hardware and software
while focusing on pedagogy rather than industry performance?
PR

While the formalization is accurate, “striking the right balance between teaching sufficient

details of hardware components and their working principles, and important theoretical con-

cepts useful for programming the computer is always a challenge.” ([34]) From reviewing

many existing software solutions to this problem, we propose the following requirements for a

successful solution:

Requirement 1. Must be available for use outside of the laboratory on personal computers

including all major desktop platforms (e.g. Windows, macOS and Linux)

Requirement 2. Provide a student configurable system for different ISAs including configura-

tion of:
 10 Chapter 1. Introduction

2.a. microcode and assembly instructions

2.b. execution semantics (i.e. how a processor executes code)

2.c. internal hardware components and connections

2.d. external peripherals

Requirement 3. Focus on pedagogy over simulation accuracy as best as reasonable

Requirement 4. Simulations must allow:

4.a. viewing of the current state of hardware components

W
4.b. stepping at the assembly and microcode level

4.c. setting of breakpoints to ease debugging

IE
EV
4.d. connecting “external” peripheral components

Requirement 5. Provide a modern user interface that is similar to current high-level program-
PR

ming IDEs

Requirement 1: Personal computer usage. Requirement 1 outlines that any software must

be cross-platform. StackOverflow’s Developer survey [36] found that approximately 47.9% of

those surveyed used a non-Microsoft Windows environment (macOS or Linux). The metrics

recorded for 2016 desktop operating systems are shown in Figure 1.4. While other metrics

show that over 80% of computers are Microsoft Windows [37], we believe the StackOverflow

survey is better given students in computer and software engineering programs likely go on to

become hardware or software developers [36, Sec. II. Developer Profiles]. Further, StackOver-

flow has found the year-over-year change to show a decrease in Microsoft Windows-based op-

Reproduced with permission of copyright owner. Further reproduction prohibited without permission.