OpenHardSim: An Open Source Hardware Based
Simulator for Learning Microprocessors
Panayotis Papazoglou
Department of Electronic Engineering,
TEI of Athens, Athens, Greece
Department of Computer Engineering,
TEI of Central Greece, Lamia, Greece
papaz@teiste.gr
Abstract—Microprocessor (uP) Architecture and
Programming constitute core courses in computer science and
electronic engineering departments. A variety of tools has been
used for gaining more knowledge and understanding the basic and
advanced concepts of the course. These tools (hardware platforms
and simulators) are focused mainly on assembly programming.
Despite the existing tools, students still face great learning
difficulties. On the other hand, key issues are the corresponding
architecture and the programming features of the uP under
studying. The above issues are not fully addressed by the existing
tools. In this paper, a customizable hardware based uP simulator
is presented and final proposed. Using this simulator, an
experimental hypothetical educational uP can be built by students
and the professors can create the corresponding learning
scenarios. Based on the proposed approach, the experimental uP
consists of identical hardware based blocks that can be
reprogrammed for representing registers, arithmetic and logic
unit, etc. Thus, the students can act now as uP architecture and
assembly language designers gaining crucial knowledge in the
field.
Keywords—Learning microprocessors, hardware based
simulator, designing microprocessors, educational computer/CPU
I. INTRODUCTION
It is a common ascertainment that microprocessor (uP)
courses are quite complicated for the students. Many hardware
based educational platforms have been used during past years
(e.g. Z80 boards such as the legendary MPF-I). Due to high cost
and maintenance difficulties, these boards have been abandoned.
These boards constitutes today only a historical era of
educational engineering. Today, the above educational tools
have been replaced by visual software environments which
simulate uP operation using well known architectures.
Simulators constitute low cost tools which offer great
capabilities for studding typical uP models [2]-[4]. In other
approaches it is proposed, (a) the development of the
components that constitutes a computer at digital level [5] and
(b) the use of specialized training kits. The digital level
development is time consuming and does not involve the
software/assembly development and programming. Moreover,
in other studies the FPGA technology has been used for building
a uP with the desired architecture [6]. On the other hand, the
training kits do not offer the required freedom to professors for
designing educational scenarios. Despite the existence of the
978-1-5090-5467-1/17/$31.00 ©2017 IEEE
2017 IEEE Global Engineering Education Conference (EDUCON)
Page 157
Anastasios Moschos
Department of Electronic Engineering,
TEI of Athens, Athens, Greece
above tools, students still face significant understanding
difficulties in the corresponding courses. Thus, a totally new
approach has to be adapted by students and professors. Recently,
a totally different educational methodology based on object
oriented approach has been proposed for the very first time in
the literature [1]. Current paper presents a new implementation
of the simulator with advanced capabilities and new core
components based on the above educational concept and
discusses, (a) the capabilities of the hardware based simulator
tool in contrast with disadvantages of the existing simulation
tools, (b) the new student role for increasing the resulting
knowledge gain, (c) implementation issues and (d) educational
scenario for the lab.
II. A NEW EDUCATIONAL CONCEPT
A. The object oriented approach
Computer science students use simulation tools with
significant limitations such as, (a) Lack of tool adaptation to
custom uP architectures (only typical models can be simulated),
(b) Individual uP components cannot be studied, (c) Professors
cannot develop educational scenarios based on the
corresponding course requirements, (d) Students cannot be
familiarized with hardware level by using simulators.
According to the proposed approach in [1], a hardware
component collection is available. Based on the internal
software, each component behaves as a Register Block, Control
Block or Master Block which is proposed for the very first time
in this paper. Thus, the desired custom uP architecture consists
of the selected components. Using this object oriented approach,
the student selects the necessary components and builds the
desired architecture. The student has also to connect physical
channels for implementing the data and control bus respectively.
Finally, the new custom uP can be programmed using existing
assembly instructions (e.g. created by the professor) or by
creating new ones.
B. A different role for the student
Using the proposed simulator, the students can now also act
as block/object level designers and not only as
users/programmers. Note also that the students can create their
own assembly instructions. This different role creates a new
knowledge path for the students. Due to the hardware based
25-28 April 2017, Athens, Greece
simulator flexibility, the students can study even a single register
or a data transfer through the available buses.
III. SIMULATION TOOL & EXPERIMENT IN THE LAB
As mentioned before, a collection of hardware blocks are
available for building the desired uP architecture: (a) Register
Block – RB (for General and Special Purpose registers), Control
Block – CB (for Arithmetic/Logic Unit, Memory etc), Master
Block – MB (for Control Unit and other supervision operations).
The RBs and CBs are implemented with an AVR
microcontroller. The MB is implemented with a Raspberry Pi
microcomputer where control unit microcode, system control
code and GUI are executed.
A. System Architecture
Fig.1 shows the corresponding OpenHardSim Simulator
(OHSS) software and hardware architecture. The system
components support the simulator operation and management as
well as the experimental hypothetical computer/uP model under
investigation.
Raspberry Pi
Python Code Experimental Hypothetical
Computer Model
and two indicative LEDs. The behavior of RBs and CBs is
defined by C code. Additionally, the MB is implemented with a
Raspberry Pi, where the corresponding software is developed in
python.
Fig.2 shows the block board. For reducing the board size
(actual size 70mmx70mm), the SMD technology has been used
for the electronic components. All the blocks are built using the
same circuit and components for achieving reusability. On the
other hand, the block behavior is specified by the internal
software of the microcontroller. For register implementation, all
the corresponding blocks execute the same code. Fig.3 shows
how the AVR pins have been used for implementing Buses
(Data D0-D7, Control C12-C0), seven segment display control
(PC0-PC7), indicative LEDs (iLED1,2) and interrupt (INT0).
For accessing the target block an address is used. Thus, the
control bits are divided in two regions, a) 7bits (C12-C6) for
addressing and 6bits (C5-C0) for control command (fig.4). The
13bits form the control word. Using 7 bits of address, up to 128
blocks can be controlled. Additionally, 64 different commands
can be given to each block. The bit manipulation within the
block is based on the corresponding software. The bit usage
(address and command) can be changed by making changes to

the AVR code. Using 13bit for the block control, a system
Keyboard Screen
User Main Memoryy
User Input GUI/TEXT
Interface
1. Simulator
commands
Source Code
Simulator
scaling up can be achieved.
Supervision &
2. Hypothetical Control
CPU Instructions Simulator Control Unit
Control

Data Control
AVR Board Bus Bus AVR Board
Register Control Block
Block C Code (ALU) C Code

AVR Board
Register
Block C Code

Experimental/Hypothetical Computer
Experimental/Hypothetical uP

Fig. 1. System Architecture Fig. 2. Block (AVR) board

C4
CONTROL
The OHSS is controlled through a raspberry Pi which supports C12-C5 PC0-PC7 BUS
user input and GUI/Text interface for displaying current CONTROL
BUS
7SEG
CTRL
operations and results. The user/programmer enters the source
code for the hypothetical computer/uP model and gives the 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21

proper commands to the simulator for storing data and assembly ΑΤmega32Α

instructions in the main memory or executing the source code. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Fig.1 consists of the simulator environment and the D0-D7 iLED1 C0-C3
DATA CONTROL
experimental hypothetical computer model (gray area). The BUS
iLED2
BUS
INT0
source code of the hypothetical computer model is entered in the
main memory (within raspberry) and the Control Unit exchanges Fig. 3. AVR pin usage
signals (Data and Control) with other uP components such as C12
7bit 6bit
C0
C6 C5
registers (Register Blocks), ALU (Control Block), etc for Control
implementing assembly instruction execution. The software Address
command
within Raspberry Pi is written in Python and the software in
AVR boards in C. Control Word
B. Component Implementation
Fig. 4. Control Word (Address, Command)
Each RB/CB component is implemented as an autonomous
mini board with a 40pin AVR microcontroller, two seven
segment displays which show in real time the register contents

978-1-5090-5467-1/17/$31.00 ©2017 IEEE 25-28 April 2017, Athens, Greece

2017 IEEE Global Engineering Education Conference (EDUCON)
Page 158
 C. An Educational Scenario
In this section, an indicative educational scenario based
on an experimental hypothetical computer/uP model is
presented. For building an educational computer/uP, some
hardware components have to be reused (e.g. RB).
Reusability is a key issue in the resulting system. Thus each
component of the same type (e.g. RBs) has the same
behavior (executes the same code). Fig. 5 shows an
experimental computer/uP architecture which consists of
two general purpose registers (A and B) implemented in
AVR boards. The special purpose registers such as PC
(Program Counter), IR (Instruction Register), SP (Stack
Pointer), Control Unit and main memory are implemented
within Raspberry Pi.
Experimental CPU/Microprocessor (uP)
AVR Board
Register
AVR Board
Register
Block-A Block-B
Control Block
Control Unit
(ALU) Registers
Fig. 5. Experimental Hypothetical Computer/uP
Fig. 6 shows the two AVR boards (Register Blocks)
connected with the raspberry Pi.
Fig. 6. Registers A,B and the Raspberry Pi
Assembly Instruction Execution
The first experimental hypothetical computer/uP model
supports the following assembly commands (table 1):
TABLE 1. SUPPORTED INSTRUCTION SET
Instruction Operation
MOV A,X A=X
978-1-5090-5467-1/17/$31.00 ©2017 IEEE
2017 IEEE Global Engineering Education Conference (EDUCON)
Page 159
MOV B,X B=X 02 4 (X=1byte)
ADD A,B A=A+B 03 4
INC A A=A+1 04 4
INC B B=B+1 05 4
DEC A A=A-1 06 4
DEC B B=B-1 07 4
JNZ addr If ZF=0 goto 08 4 (addr=2byte)
addr
The assembly programmer (student) enters instructions
inside the main memory. When the assembly program is
completed (all the instructions have been stored in the main
Experimental Hypothetical Computer memory), the execution starts (within the experimental
Main Memory hypothetical computer). Assume that the first two
instructions are MOV B,5 (performs the operation B=5) and
ADD A, B (performs the operation A=A+B). The instruction
Control Bus
execution procedure follows the known 4 phase operation:
(a) fetch instruction from memory, (b) decode, (c) execute
Data Bus
and (d) store the result. The whole implementation procedure
SP
Source Code
is analyzed as follows:
Step 1: The 4 bytes of the instruction (locations PC+0, PC+1,
PC+2, PC+3, PC=Program Counter) are transferred in
the IR (special purpose register) for decoding. Number 5
(0b00000101) is applied to the data bus (I/O pins of the
Raspberry Pi). This number is recalled from the address
PC+3 (each instruction is 4 bytes long where the fourth
byte of the current instruction represents the integer
value). The special purpose register PC holds the address
of the first byte of the instruction that will be executed
(PC+0 is the address of the first byte).
Step 2: the number 0b0000010000010 is applied to the
control bus. The first 7 bits (MSB to LSB) represents the
address of the register B (0000010) and the rest 6 bits
represents (000010) the command to the register
(2=Load/Write a value to the register). Note that the
sequence of steps 1 and 2 can be changed.
Step 3: An interrupt pulse is sent to all the AVR boards (pin
INT0 of the AVR microcontroller). When the interrupt is
recognized, each AVR reads the control word. Initially,
the first 7bits of the control word are analyzed. As
mentioned before, a unique address is assigned to every
AVR and thus, only one block responds.
Step 4: The target AVR (RB or CB) takes action based on
the control command which is stored in the rest 6bits of
the control word. Thus, the number 5 is stored in
Register-B
Step 5: After the increment of the PC and the corresponding
instruction decoding, the contents of the registers A and
B must be read. This action is performed in two stages:
(a) read from Register-A (control word=address of
register A + control command for read), INT0 activation,
read contents through data bus, store register A contents
OpCode Total length in the temporary register of ALU, (b) read from Register-
(bytes)
B (control word=address of register B + control
01 4 (X=1byte) command for read), INT0 activation, read contents
25-28 April 2017, Athens, Greece
 through data bus, store register B contents in the second for uP, complete OHSS tools/kits have to be constructed.
temporary register of ALU Each kit consists of, (a) Raspberry Pi, (b) Computer screen,
(c) Keyboard/mouse, (d) AVR Boards and (e) Cables. Table
Step 6: Perform the addition within ALU (A+B) 3 shows the cost of the kit components for a lab working
Step 7: Store the result to register A in three stages: (a) send station (for two students per station).
control word (control word=address of register A +
control command for load/write), apply result in data TABLE 3. ITEM/COMPONENT COST LIST
bus, (b) INT0 activation and (c) load/write result in Item/Components Usage Cost per item
register A
User Interface/Simulator
Table 2 shows at bit level the above actions for executing Raspberry Pi Control/Experimental $42
the two instructions (MOV, ADD). model

TABLE 2. BIT OPERATIONS FOR INSTRUCTION EXECUTION Displaying information

Computer Screen $70
and results
Step Operation Control (bus) word Data bus
Apply Entering
1 number 5 to - 00000101 Keyboard/mouse $10
commands/source code
data bus
Apply AVR Board Simulator component $10
0000010000010
control
2 0000010=addr REG B - Pi Cables HDMI/Power $5
word to
000010=control command
control bus Board Cables Flat 40pin $2
Send
3 Interrupt - -
(INT0) In computer labs, there are available computer screens and
Load/Write thus the total cost is reduced. For building a complete lab kit
4 register - -
from scratch, three or more AVR board are required. Note
(B=5)
(1) (Read REG A) that the general or special purpose register files can be
0000001=addr REG A implemented in the same AVR board. As an example, $159
000001=control command (3) Store A are required for a complete lab kit including three AVR
5
Read (2) Send Interrupt (INT0) in ALU T1 boards. Future work includes:
REG A, B (4) (Read REG B) (6) Store B
0000010=addr REG B in ALU T2 (a) Developing more AVR boards for implementing more
000010=control command registers, ALU, etc, (b) Upgrading current user interface for
(5) Send Interrupt (INT0) easier simulator management, (c) Building new software
Perform
6
A+B
- - components for automated educational scenarios
(1) development by the professors and (d) Writing Lab exercises
Load/Write 0000001000010 (3) Store and user manuals (professors/students) for the proposed
7 register 0000001=addr REG A result (A+B) simulator
(A=A+B) 000010=control command in A
(2) Send Interrupt (INT0) REFERENCES
Steps 1-4: MOV B,5 & Steps 5-7: ADD A,B
[1] P.M.Papazoglou, D.A.Karras, “A Hardware Based Novel Educational
Methodology for Teaching Microprocessor Architectures Using Object
Oriented Approach”, International Review on Computers and Software
IV. CONCLUSIONS AND FUTURE WORK (IRECOS), Vol 10, No 10 (2015)
A novel hardware based simulator for learning uP [2] Bruno Nova, Joao C. Ferreira, Antonio Araujo, “Tool to Support
Computer Architecture Teaching and Learning”, Proceedings of the 2013
(OpenHardSim Simulator - OHSS) has been presented in 1st international Conference of the Portuguese Society for Engineering
this paper. OHSS is a very promising educational tool where Education (CISPEE), IEEE
the students act as uP designers and assembly programmers. [3] Shine V.J., Sathish P.K, “Teaching Computer Architecture Using
The proposed tool, gives to students also the hardware point Simulation Tools”, (IJCSIT) International Journal of Computer Science
of view (focused on architecture) of the uP. Thus, the and Information Technologies, Vol. 5 (2) , 2014, pp. 1411-1413
students are involved as uP architecture designers and [4] Chi-Fai Chau, Yu-Fai Fung, “A Tool for Self-Learning Assembly
assembly programmers. Note that the students can also Language Programming and Computer Architecture: Design and
create their own assembly instructions. It is obvious that the Evaluation”, Wiley Periodicals Inc,. Comput Appl Eng Educ; Published
online in Wiley InterScience (www.interscience.wiley.com); DOI
proposed hardware based simulator is in the initial stage. As 10.1002/cae.20310, 2009
mentioned in the paper, is an open source educational tool. [5] N. L. V. Calazans and F. G. Moraes, “Integrating the teaching of computer
This means that the students or professors can change the organization and architecture with digital hardware design early in
simulator software as well as the supported assembly undergraduate courses”, IEEE Trans. on Educ. 44, 2001, pp. 109±119.
instructions within the experimental hypothetical [6] I. Kastelan, N. Teslic, M. Temerinac, “Generic Processor for Unified
computer/uP model. For designing and developing a new lab Computer Engineering Learning Platform”, IEEE Global Engineering
Education Conference (EDUCON), 2013

978-1-5090-5467-1/17/$31.00 ©2017 IEEE 25-28 April 2017, Athens, Greece

2017 IEEE Global Engineering Education Conference (EDUCON)
Page 160