FPGA SESSION CONTROL: A REMOTE LABORATORY FACILITY FORPLATFORM FPGA EDUCATION

by

Yamuna Rajasekhar

A thesis submitted to the faculty ofThe University of North Carolina at Charlotte

in partial fulfillment of the requirementsfor the degree of Master of Science in

Electrical Engineering

Charlotte

2008

Approved by:

Dr. Ronald R. Sass

Dr. James M. Conrad

Dr. Robert W. Cox

ii

c©2008Yamuna Rajasekhar

ALL RIGHTS RESERVED

iii

ABSTRACT

YAMUNA RAJASEKHAR. FPGA Session Control: A Remote Laboratory Facilityfor Platform FPGA Education. (Under the direction of DR. RONALD R. SASS )

In the future, it is expected that FPGAs will play a more prominent role, both in

embedded systems and as user-programmable components of general-purpose com-

puting systems. This means that more than just Electrical Engineering students will

need training in this area. By some estimate 5 to 10 times as many individuals.

However, the conventional pedagogical approach — lecture and lab — is unlikely to

scale to accommodate the student demand. Remote labs offer a scalable alternative

but a critical question is: whether remote labs are as effective as traditional labs.

This thesis evaluates the effectiveness of remote labs for FPGA education. This

thesis demonstrates that with the addition of an inexpensive piece of hardware and

appropriate software, many commercial off-the-shelf FPGA development boards can

be made suitable for use in a remote laboratory. The hardware and software required

to implement a remote laboratory has been developed and a remote laboratory facility

deployed at the University of North Carolina at Charlotte. Advantages, concerns, and

actual costs are reported. The experience of using this facility in a senior/first-year

graduate-level Platform FPGA course is also described. Although these data are

preliminary, survey results and first-hand experience with the laboratory were very

encouraging and suggests that further studies on student learning are warranted.

iv

ACKNOWLEDGMENTS

In my way of pursuing this Master’s degree, many people contributed in many

different ways, to make my success as a part of their own. I want to thank:

First of all, my parents — the reason for every one of my achievements; my super

mom, who makes sure that I never lose my focus; my very handsome father, for always

giving in to every one of my requests (or demands as he may say!). My phenomenal

brother, Raman, my role model, who keeps me grounded.

My adept adviser, Dr. Ron Sass, for his guidance and patience; my committee

members, Dr. Jiang Xie, Dr. Jim Conrad, and Dr. Robert Cox for all their support.

Chandrika, for being one of the reasons I pursued my Master’s degree. Ragi, for

being my biggest support system; Robin Jacob, for inspiring me to do a thesis and for

always believing in me; Andy, for being my number one motivator. Will, for being my

friend, encouraging me and teaching me so much; Shweta for being my stress buster,

and for all the coffee she’s made for me. I also want to thank Uday and Ragi (again!)

for being such great friends and for all their support and encouragement. And my

roommates and all other friends who helped in their own way.

And ofcourse, Sandeep. If I had to pen down all the reasons for which I’m thankful

to him, it could end up being more pages than this thesis!

I thank God for giving me so many wonderful people and this acknowledgment

only justifies a small fraction of the gratitude and love I feel for each one.

v

TABLE OF CONTENTS

LIST OF TABLES vii

LIST OF FIGURES viii

CHAPTER 1: INTRODUCTION 1

1.1 Problem Statement 2

1.2 Outline 5

1.3 Contributions 5

CHAPTER 2: BACKGROUND 7

2.1 Platform FPGAs 7

2.2 Modes of Laboratory Instruction 8

2.2.1 Traditional Labs 8

2.2.2 Simulated Labs 9

2.2.3 Remote Labs 10

2.3 Related Efforts 10

CHAPTER 3: DESIGN AND IMPLEMENTATION 17

3.1 Required Functionality 17

3.2 Hardware: Three Board Designs 19

3.2.1 Jura 20

3.2.2 AIREN 21

3.2.3 Sapphire 23

3.3 Software Organization 27

3.3.1 FSC Library 28

3.3.2 FSC Standalone Application 31

3.3.3 FSC Server 31

3.3.4 Case Example 33

vi

CHAPTER 4: EVALUATION 35

4.1 Facility and Course 35

4.2 Assessment 36

4.2.1 Cost/Benefit Analysis 37

4.2.2 Student Perception 38

4.2.3 Experiment to Guage the Learning Outcomes 41

CHAPTER 5: CONCLUSION 44

REFERENCES 45

APPENDIX A: GLOSSARY 48

APPENDIX B: SURVEYS AND QUIZZES 51

vii

LIST OF TABLES

TABLE 3.1: FSC error codes 29

TABLE 3.2: Public functions in FSC library 32

viii

LIST OF FIGURES

FIGURE 1.1: Required Platform FPGA skills versus number of students grad-

uated 3

FIGURE 2.1: Xilinx Virtex 4 ML-410 developer board 8

FIGURE 3.1: Logical design of hardware to support remote lab 19

FIGURE 3.2: Block diagram of FT 2332D 21

FIGURE 3.3: Jura board (GPIO lines tapped, JTAG not connected) 22

FIGURE 3.4: AIREN board 22

FIGURE 3.5: Sapphire board 24

FIGURE 3.6: Top layer (routing + solder mask) of Sapphire board 24

FIGURE 3.7: Bottom layer of the Sapphire board 25

FIGURE 3.8: Various states nodes in a pool of resources go through 26

FIGURE 3.9: (A) “Request” use-case (B) “Release” use-case 28

FIGURE 3.10: (A) “Power On” use-case, (A) “Restart” use-case, and (B) “Power

Off” use-case 30

FIGURE 3.11: (A) “Upload” use-case (B) “Select” use-case, and (C) “Boot”

use-case 31

FIGURE 3.12: Sequence of handling a connection 34

FIGURE 4.1: The assessment model developed to evaluate the effectiveness of

the remote lab facility 37

FIGURE 4.2: A plot of the students’ opinion of the different types of labs 40

FIGURE 4.3: Students’ idea of remote labs 40

FIGURE 4.4: Features of Remote labs that appealed to the students 41

CHAPTER 1: INTRODUCTION

Most Integrated Circuits (ICs1) are manufactured to perform a single function.

When these devices leave the factory, their operations are fixed. However, a Field-

Programmable Gate Array (FPGA) is a special type of IC that is manufactured

without a pre-assigned, specific function. These devices are like a “blank slate.”

They can be configured (and, in most cases, reconfigured) to perform almost any

desired digital circuit, even after being deployed in a product.

FPGAs were initially introduced as programmable logic devices and that is still

their primary role. Initially, this technology was introduced to provide ‘glue logic’

much the way other programmable logic technologies were (PLDs, PALs[3]). As IC

technology has advanced, so have FPGA devices. They have grown rapidly in both

size (logic and memory) and capability (special-purpose cores). Nowadays, many

FPGAs include built-in microprocessor cores, Ethernet, and high-speed serial cores.

Indeed, these so-called Platform FPGAs can host entire computing machines on a

single (reconfigurable) chip. As one would expect, FPGAs are used in numerous

embedded system projects. Indeed, from digital cameras to cell phones to vehicle

systems, FPGAs are extending their reach into most digital electronics. They have

even traveled into space in the Mars Rover. However, one might not realize that

FPGAs are also available as user-programmable components of general-purpose com-

puters. Nearly every high-end computing vendor (Silicon Graphics, Inc.[31], Cray

Inc.[6], SRC Computers, Inc.[32]) now offers an FPGA accelerator option. Third

party vendors also manufacture FPGA accelerator cards that can be plugged into

1Appendix A has a list of acronyms used in this thesis

2

desktops and workstations (Annapolis Micro Systems, Nallatech, DRC, Xtreme Data

are examples). Traditionally, innovations available on supercomputers trickle down to

commodity computing over time. So it is not unreasonable to imagine FPGA devices

becoming a common feature in desktop PCs one day in the future.

One consequence of this transition from surrogate component to a user-programmable

feature is its impact on the education and training needs of the workforce. Previously,

relatively few Electrical Engineers needed to know how to configure and use FPGA

technology. But, as the devices become more ubiquitous, the demand for a workforce

that understands this technology is likely to dramatically increase.

Unfortunately, the current pedagogical approach to FPGA education is not scal-

able. That is, the conventional approach to FPGA education which includes lectures

and laboratory assignments cannot be used to teach 10× as many students

Consider Figure 1.1. Along the x-axis are the skills needed to deploy a custom

computing machine on a Platform FPGA; roughly organized by discipline. The areas

under the three solid normal curves represents the number of undergraduate engineers

produced in 2006 (by discipline) according to U.S. Bureau of Labor Statistics [34].

(By creative license, a normal curve was chosen to reflect the diversity of different

curricula and departments; data for specific skills is not available.) To effectively use

this emerging Platform FPGAs, individual learners need to be exposed to a range

of topics and new guiding principles need to be established. Herein lies a significant

problem for how to teach FPGA concepts to 800,000 students a year with laboratories

that are maxed out teaching 80,000 students a year.

1.1 Problem Statement

With the increasing popularity and use of FPGAs, it is necessary to develop a

mechanism for training a broad range of computing students FPGA technology. It

is unlikely that the number Electrical Engineers (EE) will increase ten-fold; so sim-

ply giving electrical engineers advanced system and software programming skills is

3

Alg

ori

thm

s

Inte

gra

tin

g S

yste

ms

Op

erat

ing

Sys

tem

s

Dev

ice

Dri

vers

Net

wo

rkin

g

Sys

tem

Arc

hit

ectu

re

Co

mm

un

icat

ion

Har

dw

are

Des

ign

Ap

plic

atio

n D

evel

op

men

t

CpE EESoftware

74,000 (non−CpE) Electrical

79,000 Computer

857,000 Software

Production of Engineers by Discipline

Gra

duat

es

Platform FPGA Skills

Figure 1.1: Required Platform FPGA skills versus number of students graduated

4

unrealistic. (Not to mention the effect on the conventional Electrical Engineering

(EE) curricula.) It seems much more likely that Computer Science (CS) students and

Computer Engineering (CpE) students will pick up FPGA hardware skills. Hence, a

central concern of this work is how to scale teaching FPGA technology. To achieve

this it is necessary to provide FPGA access to this large number of learners. The way

we teach FPGA designs today — in traditional labs with benches and assigned lab

times — presents a barrier to this goal.

To teach FPGA design involves lab work but currently all FPGA labs are set up

as traditional EE labs. To handle 5× or 10× as many students, it is not feasible to

simply increase lab sizes. This leads to the fundamental question can a remote lab

facility increase accessibility of FPGAs yet preserve the experience of working with

FPGAs.

Assuming that the size of the FPGA-educated workforce needed in the future will

be dramatically larger than it is currently, the central question posed is whether remote

laboratories are more scalable (in their ability to teach a larger number of students)

while maintaining the integrity of learning outcomes achieved with traditional labora-

tories.

To prove this, we will analyze resource utilization, comparing cost, space, and time;

demonstrate the feasibility of using a remote lab facility; and evaluate the impact on

the learning in an FPGA course. Also, since student satisfaction is directly correlated

with retention, we gathered student feedback on using a remote laboratory facility.

(It can be safely said that if there is no retention, not only are the learning outcomes

not met but the students’ acceptance toward the concept of remote labs is not very

high!)

Thus, the target of this work is to develop a general purpose solution of the hard-

ware required to implement a remote laboratory facility and to develop the software

to support it. Also, based on the feedback received this resource can be improved to

5

suit the needs of the users.

To answer these questions, we will investigate the functionality and usability of

FPGA Session Control (FSC) with respect to student learning and ease of mainte-

nance, the analysis of quantitative arguments: space, cost and time for setting up a

remote laboratory versus a traditional laboratory. Another factor to be considered is

student perception with respect to the facility. This is measured by collecting feed-

back from the students. This data, although preliminary, suggests a positive response

by the students. Another metric was to evaluate learning outcomes. The students

are made to perform the labs remotely and traditionally and are assessed by means

of quizzes. By comparing the scores of students, learning outcomes can be analyzed.

1.2 Outline

The rest of this thesis is organized as follows. 2, begins with the definition and

characteristics of traditional, simulated and remote labs. The chapter concludes with

a survey of related efforts. 3 describes the design and implementation of FPGA Ses-

sion Control. It includes a description of the hardware used toward building the

remote lab facility and an explanation of the software to support the remote FPGA

laboratory facility. 4 describes the assessment of the facility where the anecdotal and

quantitative data collected is discussed and an experiment in to measure the produc-

tivity of the students performing the remote FPGA laboratories. Finally this thesis

concludes with a summary of the results and future work that can be incorporated.

1.3 Contributions

The FPGA Session Control Project is presently over 6,000 lines of C code in 45

files, plus PC board schematics, VHDL base systems, and documentation. Many

individuals at UNCC have contributed to the current (or previous version) of this

system. In its current form, the system includes a library, a standalone application,

multiple clients, a server and a hardware implementation (for initial boot). The aim

6

of this thesis is to judge whether this system is scalable and its impact on learning.

The specific contributions of this is thesis include:

• development of testing methodology (including all surveys, learning assessments

tools, and IRB-approved plan)

• collection and analysis of remote, traditional and, simulated laboratory cost

data

• development and oversight of the second version of FSC (that introduced client/server,

migrated functionality into a library)

• introduced software functions: list, erase slot, restart node

• integrated graphical user interface client into the system

• designed PC Board (with USB, RS-232, JTAG, and customizable place for lab-

specific experiments) that is compatible with many FPGA developer boards

• actively communicating the results and artifacts of the project to community

CHAPTER 2: BACKGROUND

This chapter is divided into three sections. The first section describes the func-

tionality of FPGAs in general. Next, the characteristics of traditional, simulated and

remote laboratories are explained. The chapter concludes with a related work section

that describes the prominent research in this area.

If the reader is conversant with these topics, one can skip this section with no loss

of continuity.

2.1 Platform FPGAs

Platform FPGAs are Integrated Circuits whose functionality can be configured in

the field. In other words, its functionality can be determined after it has been soldered

into a product. They are System-On-Chip (SOC) solutions; they are completely con-

tained within the FPGA[22]. An FPGA may be slower than an Application Specific

Integrated Circuit (ASIC) but it is reprogrammable, which is one of the most signifi-

cant differences between the two. FPGAs contain hard IP and soft IP. Hard IP consist

of components that are embedded into the FPGA fabric like CMOS transistors and

soft IP which are flip flops or Look Up Tables (LUTs) that can be added or removed

from the design. FPGA design is very flexible and thus is increasingly becoming

popular in general purpose computing. FPGAs contain processors, on-chip memory,

buses, bridges and networking and are thus capable of hosting entire systems. User

application specific intellectual property can be designed and connected to the FPGA.

Some available cores can be found in [38]. The components that typically compose

a SOC Platform FPGA are further explained in [30]. The study of such computing

systems that incorporate user-programmable switches to determine functionality or

8

Figure 2.1: Xilinx Virtex 4 ML-410 developer board

architecture is called Reconfigurable Computing. Figure 2.1 shows a Xilinx Virtex 4

ML-410 [40] FPGA developer board.

2.2 Modes of Laboratory Instruction

The introduction of widely available general-purpose computers and the Internet

has opened new doors to education. Explained in this section are the different ap-

proaches to performing laboratories.

2.2.1 Traditional Labs

The general norm of performing laboratories is the traditional method where the

students engage in prescribed tasks involving different physical components. In other

words, the student has to be physically present to access the lab equipment. This

9

method, although the the most elementary method to perform labs, is limiting in

the case of FPGAs. As in, to set up a traditional FPGA laboratory will include an

on-campus space that has lab benches, developer boards, and support equipment[29].

The support equipment on every lab bench might include a power supply, clock

frequency generator, logic analyzer, oscilloscope, and a PC/workstation. These labs

involve physically setting up of the equipment every time the laboratory is performed.

Also, after the experiment (lab) is performed, all the equipment has to be restored

properly. This is important because many times, the lab space is shared among

various courses. This can arguably be stated as a disadvantage of traditional labs.

Protagonists of traditional labs however argue that it is very important to provide

“hands on” experience to the students.

2.2.2 Simulated Labs

A simulated lab can be defined as a virtual lab done by the student with simulation

software on general purpose computers. Many times this software may be available

only on school computers. Simulated labs do not have the restricting factors of space

as with traditional labs. Also, they are very flexible in the sense that the simulation

can be stopped at any step for review or if there has been a mistake[7]. Most sim-

ulated platforms are exclusively in software and thus do not require any specialized

equipment. On the downside, the data involved in a simulated experiment is virtual

and can be easily offset[7]. Also, the cost of setting up a simulated laboratory is not

necessarily (significantly) less than that of setting up a traditional lab as simulation

software can be expensive. Modelsim [25] is one such simulation software that pro-

vides an environment for managing FPGA resources. It is currently available in the

market for $ 2500 [24]. This may not be feasible for some set-ups. For fields like net-

working, where simulation plays an important role, open source simulation software

like NS2 [17]is also available. Antagonists argue that simulated labs cannot bring the

same practical experience as a “hands on” lab[27].

10

2.2.3 Remote Labs

A third option is remote labs that have been recently introduced. A remote lab is a

lab involving real data that can be accessed through the Internet. Remote labs ideally

have “anytime, anywhere” accessibility. Although remote labs are relatively new,

they offer a lot of advantages over traditional or simulated labs. The space required

for such a lab is comparatively very small. Also, the cost to set up and maintain

the equipment is not great as it does not involve equipment for very individual. In

comparison with simulations, remote labs deal with real world data and hence can

provide more accuracy.

2.3 Related Efforts

Remote Labs are a relatively new concept. With the growth of the Internet and

increasing connectivity, the popularity of remote labs has surged. Some interesting

efforts are described below.

RMCLab [19] is a remote laboratory which targets electrical engineering courses

at the University of Patras, Greece, beginning in 2004. RMCLab incorporates an

FPGA in addition to “axillary modules” which include differential amplifiers, PLLs,

ADCs, and OpAmp circuits. The labs are broken down to employ different aspects

of hardware and circuit design and analysis. The hardware is connected through PCI

to a host server which integrates a signal generator, oscilloscope, and other special

hardware over a custom LPT interface. An augmented client-server architecture sub-

divides the conventional client architecture into a client and instructor client (IC),

and the server architecture into an application server (AS) and resource server (RS).

RMCLab’s custom design is quite specific to the available resources from the Uni-

versity. The individual servers coordinate access with incoming client requests with

available hardware resources. While such a system can supplement large class sizes,

one key drawback is portability to other classroom environments where these exact

11

resources do not exist.

Hashemian and Riddley [15] have a designed FPGA e-Lab, remote access system

targeted for digital design courses using FPGAs. Based on Xilinx’s Spartan-3E Starter

Kit the e-Lab uses Windows XP Remote Desktop connect the remote user with the

FPGA, data acuqisiton hardware, and LabView. Integrating a webcam and GPIO

to connect LEDs, switches, and control hardware on the actual FPGA. An obvious

advantage of such a system is the low start-up costs associated with acquiring the

Spartan Starter Kit and software tools.

A common criticism is whether students would adopt and use the remote system or

if the students would benefit for such a system. Nedic [27] report on NetLab from the

University of South Australia which aims to address the common concerns of remote

laboratories. With a similar design to the previous efforts, NetLab incorporates a

variety of laboratory equipment and even goes so far as to allow collaboration between

students. The paper concludes that while the remote lab setup did not directly out

perform conventional real labs, the authors suggest a mix of real and remote labs

throughout the education curriculum.

Corter et al [5] developed a model that investigates the relative effectiveness of

hands-on labs, remote labs and simulated labs. The labs conducted were focused on

the kinematics and dynamics of mechanisms such as linkages, cams and gears. To

draw a fair comparison, out of the six labs given to the class, three were given in

traditional format and three were given in hands-on traditional format. In addition

to the student outcomes and student satisfaction, student preferences for remote labs

were related to student characteristics, in thinking style and ability. The results

obtained by Corter et al show that among other criteria like preparatory instructions,

lab report, and team work, “physical presence in the lab” was rated least important

by the students. Also, actual learning outcomes were assessed by questions on the

midterm and final that were related to the content of the labs.

12

McCracken et al [23] developed a Multi-User Distance Laboratory (MUDL),a digi-

tal system laboratory, that was implemented using COTS components. Using MUDL,

students could implement and debug their designs on hardware (FPGA) that is re-

motely placed. A system is set up where multiple users can access a remote FPGA.

Also, the FPGA can be seen through video conferencing. To avoid resource con-

tention, several identical systems can be set up where a number of FPGAs can be

used. Lab maintenance can also be done remotely by lab technicians. They use the

Altera University Board (UP1) that has two FPGAs. The software interface that

was used was one that combined NetMeeting(a software used for high quality video

conferencing) and Virtual Network Computing(VNC, a software with which the re-

mote computer’s resources can be controlled). However, the limitations to this system

were the lack of ability to check voltages at other points than the actual probed pins

throughout the FPGA and the high usage of bandwidth due to NetMeeting and VLC

that are real-time programs.

Lab on the Web [28] is a virtual laboratory that aims to achieve flexibility in digital

and analog circuit design keeping in mind the cost, scalability and modularity. An

FPGA board is used as it allows for implementation of almost any circuit. Here,

the interface to the remote lab is achieved by combining Virtual Network Comput-

ing(VNC) secure remote desktop.test suites were developed that are lab experiments

which can be used by students. The test suites include an Analog Circuit - a sim-

ple circuit is set up which can demonstrate the use of a power supply, oscilloscope,

a switch matrix and a function generator all of which can be controlled remotely,

FPGA Programming - illustrates that the FPGA can be used remotely via the Inter-

net, Digital Signal Processing Experiment - An analog signal is captured then using

the ADC interface it is digitized. The signal is then passed to the FPGA using VHDL.

This system also provides a webcam so the users can look at the FPGA board. This

system was evaluated and it was found suitable for undergraduate courses.

13

“eLab” [41], implemented by the University of Bordeaux in France is an effort

toward increasing remote education for Electrical Engineering. The components that

make up this system are a pool of instruments that can be controlled remotely, a

group of servers and dedicated software. The digital circuits implemented by this

lab include Differential Pair Amplifier, Linear OpAmp operation, and RC filter. To

use this system it is imperative to have an account is necessary. Again, a camera is

placed in the eLab’s room that allows a live view of the instruments and servers. The

eLab webpage also contains various textbooks that are required for the courses that

use these labs. The web interface is a simple one that allows users to set data points,

frequency values and voltages. The results of these inputs can be then measured in

new pop up window which allows users to save the output. An interesting feature in

this system is that a “notebook” is automatically created that stores the results and

measurements of the user.

Gustavsson [14] implemented a remote laboratory that can be accessed by several

clients and each can choose from five experiments in basic circuit theory. The interface

used to make the settings is the Internet. This data is sent to the lab server which

forms the required circuit and connects the probes. The results and measured data is

then returned to the client via the lab server. Different client requests are handled by

means of a queue. Here, the author states that video and sound transmission from the

remote lab is unnecessary as in circuit theory it is not possible to see electrical current

or hear electrons moving. However, a project course is also offered where teams of

students design and implement control systems for small vehicles. In this course,

one of the labs involves a camera: the students test the performance of the camera

(light sensitivity, bearing resolution and light sensitivity). The main drawback to

this system is that only one student can control the experiments involving long time

constants and physical sensations.

Gurkan et al [13] present a remote laboratory for an optical circuits course. The

14

strategy used in this facility is to first introduce the students to the concepts in theory

and then proceed to prelaboratory activities. The prelaboratories include an orien-

tation video, simulation and laboratory procedures on-line. This work also includes

assessment of the learning outcomes and teaching methods. Here, the students con-

nect to the server using a Web-based client that connects to the LabView Web Server.

Three experiments were conducted; Optical Source Characterization, Optical Fiber

Link Attenuation and Fiber Connectors, Hands-On Skills Transferred From Remote

Labs. Based on performance of the students on these experiments, student success

was measured. A student opinion survey was conducted too.

Jrg Tuttas and Bernardo Wagner [33] developed a prototype on-line laboratory

that uses client-server methodology. The laboratory devices can be viewed through

webcams and can be controlled using a remote controller that is connected to the

Internet. A graphical editor is used (Petri net) along with software tools to design

the control program. The client opens a TCP/IP socket to an I/O server. The server

then sends the signals to the controller which reads the input and sends it back to

the client. The evaluation methods used include learning and reaction. Audio/video

recording, screen capturing and interviews and ratings were other methods used to

evaluate this distance-learning experiment.

Austin J. Che [4] at the Massachusetts Institute of Technology (MIT), explains the

benefits of setting up remote lab for biology using the iLab technology developed by

MIT. Che states that a general lab for biology that can be done remotely, leads to

shared costs, efficient use of resources and higher work efficiency.

AIM-Lab [10] is a remote lab for characterization of electronic devices like semicon-

ductors over the Internet. AIM-Lab includes 9 experiments that can be performed on

a CMOS test chip and a silicon carbide (SiC) diode. It is used for senior or first year

graduate level courses. The implementation includes a client/server model where the

server is written in C++ and Java is used for the GUI client. AIM-Lab provides the

15

users with predesigned experiments. The user can access the website and open the

client window, select an experiment and enter parameters (voltage, step size, etc).

The experiment, once set up, can be started and the client instructions will be sent

through the TCP/IP socket to the server. The server runs the experiment and the

results are presented as numerical data and graphs.

LabVIEW (Laboratory Virtual Instrumentation Engineering Workbench) [18] de-

veloped by National Instruments. An interesting implementation of this platform can

be read in [16]. It is used for data acquisition, instrument control and instrument

automation. This software can be used with Microsoft Windows, UNIX, Linux and

Mac OS.

Alamo et al [8] have developed a remote laboratory facility for microelectronic de-

vice characterization. It is implemented using a client/server model. The client side

application is a Java-enabled web browser. Eight devices are available to perform

various experiments and a semiconductor parameter analyzer along with a switch-

ing matrix enable the user to select one particular device. Simultaneous accesses

are made possible with the help of a queuing system. This system, located at Mas-

sachusetts, USA has been successfully used by students in Singapore in a graduate

level in electronics materials.

From the above descriptions, it can be noted that many researchers are investigating

the effectiveness of remote labs in their respective fields. Many of the labs implement

FPGAs due to their flexibility and reconfigurability, but the number of remote labs

for FPGA education are relatively very few. The target of this thesis is to widen

FPGA education. Also, the use of a webcam in this project is unnecessary because

the primary objective of this facility is to teach system-level design to senior/graduate

students and since the facility consists of a cluster of 64 FPGA boards, it is not feasible

to have a webcam for each one. Another interesting fact to note is the evaluation

methods used in these facilities. Since there is no standard method of proving the

16

effectiveness, it can be seen that the trend is to collect feedback from the students

using the facility. Although, anecdotal data is arguably not the strongest means of

proving facts, it is very helpful to improve the facility. Another method is to test the

students and derive learning outcomes. The most significant difference of the work

described in this thesis is that it is comparatively more scalable in the sense that the

hardware and software are both flexible to fit in different environments.

CHAPTER 3: DESIGN AND IMPLEMENTATION

In order to demonstrate the feasibility, evaluate the effectiveness, and compare

remote labs with traditional labs, it was necessary to design and implement an op-

erational remote lab for platform FPGA education. This chapter enumerates the

required functionality of such a system, the hardware, and the software implementa-

tions.

3.1 Required Functionality

To complete Platform FPGA laboratory assignments, there are several fundamental

interactions the student has with the hardware. Below we describe some of these

interactions and identify the functionality as either essential (must be handled by

remote facility) or just valuable (would be helpful but not strictly required).

Perhaps the single most important interaction is over an RS-232 serial port. All

labs involve creating a base system and that usually includes a processor or a micro-

controller. Even if the primary objective of the lab is to test a hardware core, a

processor is often used to coordinate and report the results of the test. Results are

almost always sent over a serial port that, in a traditional lab, is hooked up to a PC

with a null modem cable. Terminal software (minicom, hyperterm, etc) is used to

observe the output transmit input. In a remote lab, there must be a mechanism to

capture and transmit serial communication (both input and outputs).

Another extremely important capability the student needs is the ability to configure

the FPGA. Many of the developer boards support two mechanisms for doing this.

The student can hook up a JTAG cable which allows the FPGA to be configured

on-the-fly and, with the addition the right tools, provides the ability to debug. With

18

introduction of Integrated Logic Analyzers, the JTAG option is becoming increasingly

popular and makes having a serial port less important for seeing the results of a test.

The alternative mechanism used to configure an FPGA involves copying the bitstream

to a CompactFlash card. This involves physically removing the CompactFlash (CF)

memory card from the developer board, plugging it into a CF reader on a PC, coping

files, onto the card, then putting CF card back into the FPGA board. To be useful,

a remote lab would have to support the JTAG option and having a mechanism to

support the CF would be valuable.

Another critical function is the ability to apply and cut power to the board. That

is, one has to be able to turn the board on and, in the likely case that a student

misconfigures the chip, the ability to cold reset by turning off the board. The ability

to do a warm reset (usually implemented as a push button a development board) is

valuable but not critical.

In addition to diagnosing design mistakes with the serial port and JTAG, several

LEDs can be extremely useful debugging tools. One LED will illuminate RED if

the configuration on the CompactFlash card is invalid. It is not uncommon for new

students to make a simple mistake such as copying the wrong file onto the CF or

not notice that disk is full. The LED is very helpful at identifying these mistakes

because the only other symptom of the problem is “no output.” Two other LEDs on

the boards we use are labeled PLB and OPB Bus Err. Their actual function can be

varied but, by default, they identify errors that are often caused by corrupted pointers

in C or addressing errors. These two can be helpful but are not required.

To be completely functional, a remote laboratory facility would also support the

ability of students to create a physical off-chip peripheral and hook up their hardware

to the FPGA. For example, one might want to connect an Analog-to-Digital device

or an accelerometer to some I/O pins of the FPGA. These laboratory assignments

are extremely valuable and as an effort to achieve this, a board has been developed

19

Figure 3.1: Logical design of hardware to support remote lab

to support the addition of some hardware to the remote lab facility. This board

is explained in detail in 3.2. In this case, at first the students would set up their

hardware, and then switch to system level design. This means that the students will

have to perform at least one lab traditionally to set up their hardware, and then can

perform their labs remotely. Although this will work for small scale experiments,

to design and test something complex like an accelerometer means one has to have

constant physical contact or an enormously complex, special-purpose lab set up. From

a practical point of view, we would argue that these sort of labs be conducted on

much simpler (and less expensive) FPGAs that are either purchased by the students

or borrowed from the department shop.

3.2 Hardware: Three Board Designs

One approach to supporting a remote lab would be to simply buy a workstation, a

JTAG connector, a null modem cable, and digital I/O card for every developer board.

While feasible, this is unnecessarily expensive. The proposed design aggregates all of

the support services onto a single workstation as illustrated in Figure 3.1.

As shown, the setup consists of (two) racks of FPGA boards, that are intercon-

nected and that are connected to the Gigabit Ethernet network. To control power,

20

we use a Switched Power Distribution Unit (PDU). The APC Model AP7960, allows

up to 24 outlets to be switched using the SNMP protocol over a standard Ethernet

connection. Each FPGA development board is connected to one outlet, allowing for

remote control of power to individual boards. A key element to this set up is a custom

board that connect to the FPGA that connects USB to RS-232. This is explained

in detail in the next section 3.2. The USB from all the boards then connect to the

server via USB hubs. Reducing the FPGA board interface down to a single USB con-

nection allows for easier scaling when connecting tens of boards to a single computer.

For example, using more than two RS-232 connections on a server usually requires

special expansion cards. Powered USB hubs are used to aggregate the connections

to multiple FPGA interface boards to the server. The server is also connected to the

network. Any client who attempts to connect to the board has to go through the

firewall and then be authenticated by the server. The server then opens a connection

that enables the client to communicate with the FPGA board.

Future Technology Devices Inc. (FTDI) makes an integrated circuit, the FT2232D,

which can be configured to support three communications (UART, JTAG, and GPIO)

modes simultaneously. It also has a USB client interface for connecting to the server.

Figure 3.2 shows the high level block diagram of the FT2232D [12]. It allows us to

capture required I/O and communicate it to the server. Most of the hardware require-

ments can be accomplished with the FTDI chip. The different design descriptions

below are different form factors to achieve the same functionality.

3.2.1 Jura

DLP-2232M [11] is an evaluation module which deploys the FT2232D chip. It is a

single board, USB Dual Channel Serial/Parallel Ports with a variety of configurations.

It also has with an EEPROM that is in-circuit configurable via USB. It is compatible

with full speed USB 2.0. This module supports integral power control which makes

it a good choice for low-powered, high-powered, and USB bus-powered products.

21

Figure 3.2: Block diagram of FT 2332D

A custom module (named Jura) was developed at UNC-Charlotte. The Jura board

integrates the DLP-2232M module with JTAG headers, DB9 serial connectors and

a MAX232A UART to RS-232 voltage level converter. The total cost of this device

as built was $55 and shown in Figure 3.3. However, over $30 of this was in the

DLP-2232M evaluation module.

3.2.2 AIREN

The AIREN board [20] was built specifically for the Spirit cluster. It integrated a

Serial ATA network with the 64 ML-410 nodes in the cluster. The main aim of this

board was to evaluate using SATA connections in a High Performance Computing

communications network. The third version of this board includes a USB interface

which allows for JTAG programming as well as serial port readout from each board.

22

Figure 3.3: Jura board (GPIO lines tapped, JTAG not connected)

Figure 3.4: AIREN board

23

3.2.3 Sapphire

The Sapphire board was built to provide a generic cost effective solution that can

be used with most FPGA developer boards to facilitate building a remote lab facility.

This is a four layered board. Since there is no module, compact placing of individual

components was necessary to achieve a small size (2.69” long and 1.39” wide). This

board facilitates the connection between the serial port on the FPGA to the USB hub.

In addition to this, it also has JTAG headers that are be used to configure the FPGA

boards. Two JTAG connectors are provided, one 2×7 pin EJTAG (enhanced JTAG)

mostly used with MIPS[26] and also a single row (8 pin) generic header compatible

with most download cables. It works with a 6MHz crystal. The USB type B receptor

is used. There are 8 GPIO lines that can be used I/O communication with the FPGA

boards. These GPIO lines can be used to capture the error signals mentioned in 3.1.

A highlight of this board is the ability add hardware to it. Thus, the board can

be used for projects that include some hardware skills and can be used to obtain a

remote connection to an FPGA. The RS232 connector is used for serial connection.

The transmit and receive lines of the MAX232 line driver chip are tapped and jumpers

are provided for users who may not have a RS232 connector. They can use the tapped

lines directly. Figure 3.5 shows the sapphire board.

Figure 3.6 and Figure 3.7 show the top and bottom layers of the board. All the

main components are placed top layer and the bottom layer is used for the capacitors

and resistors making efficient use of space.

By placing the FTDI-2232D and related components directly on the PCB the cost

can be reduced to just $30 per board. The FTDI module is a very cost effective

alternative to the Xilinx Platform cable USB which also serves as a USB based JTAG

controller. However, the list price of the Xilinx cable is $199, compared to the $30

for the Sapphire board.

24

Figure 3.5: Sapphire board

Figure 3.6: Top layer (routing + solder mask) of Sapphire board

25

Figure 3.7: Bottom layer of the Sapphire board

Typical Board Operations

Figure 3.8 shows the state diagram of a typical FSC session. The possible states

a board can be in are available, allocated, initialized, ready, booting, running, and

powered off. The available state occurs when a board has not been allocated to any

student, the power is off. The allocated state reserves a particular board (or set of

boards) for exclusive access to one student. It also automatically applies power to the

allocated board(s). The board is in the initialize state while the bootloader is loading,

which takes approximately 40 seconds. In the ready state the board is ready for use

and can be pinged. While it is ready we can go into the upload state. During the

upload state the fsc server is transferring a FPGA configuration file to a slot on the

board. The client then selects a slot, and issues the boot command. The boot state

configures the FPGA fabric with the configuration program and loads the software.

After the board finishes booting it is in the running state. When the board is in this

state, as far as we know, the board is being used by a student. When the student is

finished with the board they can power down the board and release it.

26

Figure 3.8: Various states nodes in a pool of resources go through

27

3.3 Software Organization

To fully realize the potential benefits of a remote lab, several layers of software

are needed to allocate and return boards, maintain consistency, and provide a single

view over the Internet. FPGA Session Control software does this. Specifically, FPGA

Session Control (FSC) incorporates the functionality of R-Boot[7], that focused on

connecting a server to a single FPGA board, with a client-server model and a custom

command set running over a standard TCP/IP network. The ability to remotely

access the FPGAs from anywhere on or off campus gives students the unique ability

to work on labs and research without stepping in to the laboratory. FSC improves

the remote FPGA experience by providing clients (GUI-based and command-line) and

improves lab administration. (With R-Boot, users could leave the boards locked or,

worse, powered on. On exit, FSC releases all of the resources unless it was explicitly

told otherwise.)

The FPGA Session Control (FSC) software consists of a library, an Internet server,

several (command-line and graphical user interface) clients, and a stand-alone command-

line application. The server and client link to the FSC library and run on the remote

laboratory’s server. The clients are compiled and run on the end-user’s machines.

The software is responsible for coordinating access (ensuring mutual exclusion, en-

forcing permissions) to and control/observation (configuring, executing user designs,

capturing outputs) of the FPGA resources. This core functionality is accomplished in

the FSC library which uses several files installed on the server to keep track of the state

of the FPGA resources. Specifically, the boards file (installed in /etc/fsc/boards by

default) is a database of all the FPGA resources managed by the system. This file is

manually maintained by the administrator. Every FPGA board is either <available>

or assigned to a specific user. The inuse file (installed in /var/fsc/inuse by de-

fault) is directly managed by the library; it keeps track of the state of each FPGA

board. Other files (such as /etc/fsc/users and /var/fsc/logfile) are used to

28

Figure 3.9: (A) “Request” use-case (B) “Release” use-case

grant permissions and log events in the system.

3.3.1 FSC Library

The public interface of FSC Library consists of about thirty-five functions and

several data types. By default, the development files (/usr/include/fsc/fsc.h and

/usr/lib/libfsc.a) are installed on the server. Written in C, all public functions

begin with the prefix fsc (to avoid conflicts with other libraries). The library is

designed to facilitate the primary use-cases of an FPGA Session Control. The simplest

two are “Request” and “Release” which are used to allocate FPGA resources by name

and return resources. The common functionality is factored and the elaborated use-

cases are shown in Figure 3.9. In both use-cases, the application first creates a “board

set” which is then passed to the specific operation.

The subroutine fscrc t fsc make boardset ( char *list, fsc boardset t *ns

) creates a board set. Its first argument is a string that is a textual description of

the desired resources. Each FPGA board has a name which corresponds to its DNS

host name on the network. Valid strings include a single name, a range of host names

(separated by a hyphen), or a sequence of names and ranges (separated by a comma).

For example, each of the following are valid strings from which a boardset can be

29

Table 3.1: FSC error codes

FSC OK operation succeededFSC USRERR operation failed; something was wrong with the inputFSC NETERR operation failed; something was wrong with the socket interfaceFSC CONFERR operation failed; something was wrong with the server setup

constructed.

n00

larry,curly,moe

n00-n07

n00-n07,n32-n39

This assumes that these are valid hosts and, in order for range to work properly,

host names have to end in the same number of fixed digits (node00 not node0 if there

are between 11 and 99 hosts that begin with node). The second parameter is the

address of a board which is a variable that can be declared

fsc_boardset_t ring ;

The return value is an error code. Most functions return one of four results as

shown in Table 3.1.

Once a boardset has been successfully allocated, both operations can easily be

accomplished by the appropriate subroutine.

fscrc_t fsc_request ( fsc_boardset_t ns ) ;

fscrc_t fsc_release ( fsc_boardset_t ns ) ;

NOTE: a third use-case also exists. fsc request any allows the application to spec-

ify a characteristic (“ml310” versus “ml410”) and the library will find an available

resource. The goal of this manuscript is give an understanding of the requirements

30

Figure 3.10: (A) “Power On” use-case, (A) “Restart” use-case, and (B) “Power Off”use-case

and design of the system. An interested reader is referred to the documentation which

includes a complete description of the interface in Doxygen [35].

The next required functionality is the ability to power on and off the FPGA re-

sources. (At the request of users, a third functionality “restart” was added after the

design was implemented. It power cycles the resources with a safe time delay between

off and on.) The use-cases are shown in Figure 3.10.

Another functionality that is vital is to upload a file to the required FPGA re-

sources. The first step to achieve this is to make a <.ace> file. This file can then be

uploaded using the fsc upload command. After uploading a file to a particular slot,

it may be required to select that particular slot. In FSC, unlike previous versions, the

slot is not explicit and must be specified. To do so, the fsc select slot command

is used. One thing to note while using this command is that the board must in ready

state. Once the appropriate file is uploaded and the proper slot is selected, boot can

be used to run the design on the FPGA. When finished, it is recommended to halt

the board before power down and release. This can be done using fsc halt. The

use-cases are shown in Figure 3.11

The above mentioned commands are the ones used frequently. Table 3.2 enlists a

31

Figure 3.11: (A) “Upload” use-case (B) “Select” use-case, and (C) “Boot” use-case

comprehensive list of all the functions (user oriented) offered by the FSC library.

3.3.2 FSC Standalone Application

The FSC standalone application is a collection of C programs that do not require

the client interface to run. The standalone application of FSC depends on the library

to provide the required functionality. This application has its own subroutines (for

e.g. request) that call the library’s function.

While using the standalone application, to upload an ace file, the file has to be

copied onto the server first. Although tedious, it provides the same functionality as

the command-line client.

3.3.3 FSC Server

This section has been developed completely by Dr. Ron Sass. But for complete

understanding of this project, an explanation is provided.

The actual path of communication between the FPGA resources and the user is

32

Table 3.2: Public functions in FSC libraryFuntion Descriptionfsc init sets up a global statefsc make boardset creates a boardsetfsc my boardset creates a boardset of all the nodes allocated to userfsc request attempts to allocate a requested boardfsc request any attempts to allocate a particular type (ml310/ml410)fsc release attempts to release all owned boardsfsc power up applies power to the outlet(s) associated with the board(s)fsc power down removes power from the outlet(s) associated with the boardsfsc power status checks the status of powerfsc upload transfers an ace file to the FPGAfsc select slot changes the slot on the board(s)fsc erase slot blanks out the selected slotfsc reboot reboots the board to the selected slotfsc halt halts the boardfsc get status fills in the status fields of a node setfsc set mode changes the operating mode (normal/superuser)fsc list table of information on all the resourcesfsc display attempts to reproduce the console for each node in the set

set up by the server. To remotely power on/off the FPGAs, SNMP protocol is used.

The server program starts a TCP/IP server that translates client messages into FSC

library calls and sends response back to client. To achieve this a custom TCP/IP

socket protocol was implemented. This eliminates the need for multiple ssh connec-

tions per board by a single user and requires only one connection (client;command-line

or GUI). So the server creates a socket and waits for a request for connection. Once

a request comes through, it parses the message and accepts the connection and exe-

cutes that command. This is done for every new connection that comes through to

the server. When the connection is established, the client can send commands that

will be appropriately intercepted by the server and then executed. So it can be said

that one TCP/IP server *PER* FPGA board; these servers simply move serial data

from FPGA consoles to TCP/IP and back.

33

FSC Client

FSC has two versions of the client software. One is the graphical client (developed

by another student). And the other one is the command line client. The graphical

client and command-line are functionally equivalent; the differences are in presenta-

tion only. The client starts by using ssh port-forwarding to tunnel to FSC server. As

more boards are requested by the server, additional port forwards are added to specific

serial port servers. When a user issues a command, it is parsed in the same man-

ner as standalone but instead of library calls, messages to the server are generated.

The server’s responses are are displayed (in command-line, output is to standard out;

GUI, to appropriate window in GUI). The command-line client is the same as the

standalone application in appearance, but is functionally different. The client does

not require that the ace file be copied manually to the server. The client makes FSC

easier to use.

A diagrammatic representation of the sequence of events between the server and

client is as shown in Figure 3.12.

3.3.4 Case Example

Suppose User A needs to run a Partial Reconfiguration test on four boards. The

first thing to do to ensure he is allocated the boards on the first go is to do a listing.

According to the list, he can then request for the range of boards he requires. Once the

boards are successfully allocated to him, he must power them up. Then he can upload

his design (ace file) onto the FPGA boards. The next step will be to ensure that the

right slot is selected and then boot that slot. Once he issues the boot command, after

about a 40 second delay, the boards will be running his design. Once he is done he

must halt the board and then power it down. The final step is to release the board

(after which it becomes available for use by other users).

34

Figure 3.12: Sequence of handling a connection

CHAPTER 4: EVALUATION

While the advantages and disadvantages of remote laboratory can simply be stated,

the most important question — how does remote laboratories effect learning? — can

only be answered by experimentation. This section presents a preliminary evaluation

based on the data collected from two semesters of using the remote laboratory facility

exclusively in a course.

4.1 Facility and Course

The Reconfigurable Computing Systems (RCS) laboratory at the University of

North Carolina at Charlotte (UNCC) is primarily focused on FPGA-based computer

architecture research. Several different FPGA boards are available to support various

on-going projects. One of these projects is the Reconfigurable Computing Cluster

(RCC) Project [9] which is investigating the feasibility of using Platform FPGAs to

build cost-effective petascale high-performance computers. The project was seeded

with two Xilinx ML-310 [39] developer boards (Virtex II Pro [37] in an ATX form

factor) and a simple, custom network adapter card. These boards were used to make

a demonstration in a proposal for a larger investigation. The lab has since added four

more ML-310s and a cluster of 64 ML-410 [40] boards (Virtex 4 FX [36] in an ATX

form factor). The ML-310s are now largely used for education and have been fitted

with the Jura boards described. Currently the ML-410s are used for research as part

of the RCC project (scientific application development and architecture research). In

addition to teaching, the remote lab facility is being frequently used by researchers

but their experience has not been included in this study.

Fundamentals of Reconfigurable Computing is a course offered at University of

36

North Carolina at Charlotte (UNCC) in the ECE department. It is appropriate for

undergraduate Seniors and first-year Master’s students. It assumes that students have

taken a sequential logic course (covering synchronous state machines), have experience

with a Hardware Description Language (VHDL [1] or Verilog [21]), and are able to

synthesize simple FPGA designs. At UNCC, the prerequisite is a sophomore-level

course. Students have the option of taking an Embedded Systems course where they

solder small projects and learn about interfacing before taking the Reconfigurable

Computing course as well. The primary goal of the course is to give the students

a detailed understanding of how FPGA devices work and how to design FPGA-

based computing systems. Students write HDL cores but the emphasis is on single-

chip system-level design — processors, on-chip communication, and system software.

Hence, the course is a ideal first-test of a remote laboratory facility.

This course has run three times at the University. The second time was in the

Fall of 2007 and this was the first class to be included in our evaluation. It consisted

of about 30 graduate students (mostly Master’s students) and initially four Seniors

(one finished the course). The second class to be considered in the evaluation was in

Summer 2008. The class consisted of 17 students.

4.2 Assessment

To evaluate the effectiveness of this approach to teaching FPGAs, proper assess-

ment of the different aspects of this system is necessary. For this, an assessment

model was developed. Figure 4.1 shows the key elements to this analysis were stu-

dent perception, student learning and, cost/benefit analysis. These are explained in

detail in the following sections.

As shown in Figure 4.1, the assessment is divided as Formative and Summative.

Formative assessment can be defined as a method where feedback from learning ac-

tivities is used to adapt the teaching to meet the learner’s needs [2]. The surveys

conducted as part of this evaluation is a means of formative assessment. Summative

37

Figure 4.1: The assessment model developed to evaluate the effectiveness of theremote lab facility

assessment can be defined as a means to measure student learning with the help of

tests. The quizzes given to the students can be categorized as a means of summative

assessment.

4.2.1 Cost/Benefit Analysis

While the advantages of using a remote lab facility versus a traditional lab may

seem obvious, we quantify these advantages below for completeness.

Space An important aspect of remote labs to consider is the significant space savings

by setting up a remote lab instead of a traditional lab. The space required by a single

traditional lab bench is 6 feet by 3 feet. This would include space for a workstation

and an FPGA board. If we assume that there are 25 students approximately in a

Reconfigurable Computing class and if we provide a 4×4 matrix placement of the lab

desks, the total space needed will be 32 feet into 16 feet, leaving room for movement

between desks. In the remote lab infrastructure that we have implemented, there are

two FPGA racks which together measure 5 feet into 3.5 feet and 7 feet tall. Thus we

38

can see that the amount of space required for a remote lab setup is very less compared

to that required by a traditional lab.

Cost The space required to set up a remote lab has a direct impact on the cost.

Ideally the cost of lab space (per square foot) in the university is approximately

US$1054, which means setting up a remote lab would prove to be more cost effective

than setting up a traditional lab. In addition to this, there are significant cost savings

for the students as well. The students are not required to purchase a board. In

addition to this, depending on the number of students enrolled in that class, the

students may have to share the resources in a traditional lab whereas while using a

remote lab facility, students can access a board through the Internet from their own

workstations.

Time Another factor to consider is time. With remote labs, students can do their

labs at their own time. Remote labs do not require the student to perform the lab

within a particular time slot. Sometimes synthesis of a design may take a couple of

hours or more. In this case the student may start a synthesis, move on to something

else and come back to it later. Thus, time constraints can be considered less with

remote labs.

Another valuable aspect is the additional features can be added with ease to the

existing features of FSC. This helps in enhancing the software to fit the needs of the

users.

4.2.2 Student Perception

Since student satisfaction can be correlated with retention, the following feedback

was gathered on using a remote lab. This feedback was collected over two semesters,

with two surveys per semester.

Fall 2007 Two surveys were conducted, for feedback purposes, one at the beginning

of the semester and one at the end of the semester. From the initial survey, the

39

general perception was that the “anytime, anywhere” that comes with remote labs

appealed to the students. The second survey was more detailed. It was conducted

after the completion of all the labs for the course. After working with remote labs,

97% of the students stated that they enjoyed the experience of working with remote

labs. 85% of the students felt that they not only had more time to explore and learn

but they also had more opportunity to re-try if their labs did not work the first time.

The students also liked not having to “check out” boards or having to buy one. Thus,

we can say that remote labs proved to be most cost effective for students.

The response of the students was not completely positive though. One main com-

plaint that the students had was the lack of visual feedback while performing the

labs. The other factors that discouraged the students were slow Internet connection

at their end, not having enough “hands on” experience with FPGAs, “buggy” session

software, and sometimes the congestion of resources(since they were using a pool of 4

ML-310 boards). FSC has addressed the problems with the session software. In the

next semester, the course would be using a pool of 64 ML-410s which will alleviate the

congestion of resources. To give the students more ’hands on’ experience, lab times

could be allotted where the students can see and learn about the physical components

of the board. Also, the new version of the FSC software is looking to address the

issue of visual feedback as well.

Summer 2008 Summer 2008 was the third time this course was conducted. The

pattern was retained from the first evaluation where one survey was conducted at

the beginning of the semester and one at the end. The survey results although not

drastically different from the data that was collected the first time, provided pretty

good insights. The initial survey showed that 76% of the students had never worked

with remote labs. The second survey was tweaked based on the feedback received

from the first time. 80% of the students said that they enjoyed working with remote

labs. Figure 4.2 is a comparison of which type of lab(traditional, simulated or remote)

40

Figure 4.2: A plot of the students’ opinion of the different types of labs

Figure 4.3: Students’ idea of remote labs

the students found “very helpful”. 93% students felt that they had more opportunity

to retry the lab if something was not right. One interesting feedback from this survey

was that 66% of the students did not feel the need for the equipment to be physically

present in front of them. Also, 73% of the students felt they had more time to explore

and learn on their own.

Figure 4.3 shows the increase in student acceptance of remote labs after they ac-

tually had performed the labs remotely.

Anecdotal results show that the students were generally favorable to remote labs.

41

Figure 4.4: Features of Remote labs that appealed to the students

Some suggestions include setting up “help” sessions for the students who have doubts

and difficulties performing the labs, and setting up one lab where the students get

some “hands-on” experience with FPGAs. Figure 4.4 that shows the best aspect of

remote labs according to the students.

From this feedback, we can conclude that students could benefit from some hands

on contact at least initially students were unclear about what was actually happening

in the lab, the software needs to be much more robust and reliable, but that said, this

facility could distance learning. A copy of these surveys can be found in Appendix B.

4.2.3 Experiment to Guage the Learning Outcomes

Although student perception was arguably strong enough evidence to prove the

increasing interest in remote labs, it does not state anything about the productivity

of the students. An experiment was set up to measure the remote productivity versus

local productivity of students. In this, half of the students were made to perform

a lab remotely while the other half did it in the traditional way. For the next lab,

the students who performed the lab remotely were made to do it the traditional

way and vice versa. Then a comparison of the scores were made to check for better

productivity.

42

Before assigning the labs, some objectives were drawn. These are based on the

knowledge the students are expected to gain after performing the labs.

• creating a template core and modifying it to include multiple registers

• writing VHDL to perform calculations on the values stored in the registers

• creating a standalone C program to drive your new core

• building a linux specific base system for the ML310

• compiling the linux kernel

• configuring linux kernel for use with the ML310

• using a cross-compiler

To properly assess the the learning outcomes, the students were given quizzes to

test the knowledge gained. The scores of the students on the quizzes show that the

above objectives were met. The quizzes were given to the students during class time

after the lab demos were over. A copy of the quizzes can be found in Appendix B.

The quizzes, once graded, were taken into account for assessment. The maximum

grade possible on the quizzes was 10 points. The grades of the students who did the

labs traditionally and remotely were averaged and compared. It showed that for the

first lab, the students who did it traditionally had an average score of 7.85, while the

students who did it remotely had an average score of 9 points. In the second lab, the

students who did it traditionally were averaged at 7.77 points and the students who

did it remotely were also averaged at 8.66 points. One must take into account that

the students’ individual aptitude also matters but as long as the scores of the students

are not drastically decreasing this factor can be ignored. Also, a student who does

the lab traditionally once, has to do the lab remotely the other time. And the fact

that there is not much increase in the scores of students doing it traditionally shows

43

that the productivity with remote labs is better. Thus from the outcomes achieved by

this experiment, it can be safely stated that the students’ performance with remote

labs are equal if not better than the students’ performance with traditional labs.

CHAPTER 5: CONCLUSION

Experience with a remote laboratory facility was limited to two semesters, so the

data is sparse and the conclusions are far from definitive. That said, the prelimi-

nary results are very encouraging. From an administrative point of view, there are

significant advantages to rolling out a remote laboratory facility and the costs are

modest. In terms of student learning, the data is generally positive. Initially, the

students (who are very familiar with traditional engineering laboratories) seem wary

of not having physical access. However, survey results suggest that by the end of the

semester, nearly all students preferred the remote facility to a traditional laboratory

setting. Hence the preliminary results are very encouraging and suggest that a more

comprehensive study is warranted.

Future Work

Since the data collected is preliminary, a longitudinal study is warranted. An

implicit feature of remote labs is that they enable distance learning, since students do

not need to be physically present in the lab to do assignments. However, the impact

on learning for distance education has yet to be evaluated.

45

REFERENCES

[1] P. J. Ashenden. The Designer’s Guide to VHDL. Morgan Kaufmann PublishersInc., San Francisco, CA, USA, 2001.

[2] P. Black and D. William. Inside the black box: Raising standards throughclassroom assessment. Phi Delta Kappan, 80(2):139–144, October 1998.

[3] S. D. Brown and Z. G. Vranesic. Fundamentals of Digital Logic with VERILOGDesign. McGraw-Hill, Inc., New York, NY, USA, 2002.

[4] A. J. Che. Remote biology labs. In E-ducation without borders, pages 127–140,Washington, DC, USA, 2005. IEEE Computer Society.

[5] J. E. Corter, J. V. Nickerson, S. K. Esche, C. Chassapis, S. Im, and J. Ma.Constructing reality: A study of remote, hands-on, and simulated laboratories.ACM Trans. Comput.-Hum. Interact., 14(2):7, 2007.

[6] Cray Inc. Cray Inc., the supercomputer company, February 2008. http://www.cray.com/.

[7] K. Datta and R. Sass. Rboot: Software infrastructure for a remote fpga labora-tory. In Proceedings of the 15th Annual IEEE Symposium on Field-ProgrammableCustom Computing Machines (FCCM’07), pages 343–344. IEEE Computer So-ciety, 2007.

[8] J. A. del Alamo, L. Brooks, C. McLean, J. Hardison, G. Mishuris, V. Chang,and L. Hui. The mit microelectronics weblab: a web-enabled remote laboratoryfor microelectronic device characterization. In Proceedings of the 2002 WorldCongress on Networked Learning in a Global Environment, pages 52–64, 2002.

[9] R. S. et al. Reconfigurable computing cluster (rcc) project: Investigating thefeasibility of fpga-based petascale computing. In Proceedings of the 15th An-nual IEEE Symposium on Field-Programmable Custom Computing Machines(FCCM’07), pages 127–140. IEEE Computer Society, 2007.

[10] T. Fieldly, M. Shur, H. Shen, and T. Ytterdal. Aim-lab: a system for remotecharacterization of electronic devices and circuits over the internet. Devices,Circuits and Systems, 2000. Proceedings of the 2000 Third IEEE InternationalCaracas Conference on, pages I43/1–I43/6, 2000.

[11] Future Technology Devices International Ltd. DLP Design, DLP-2232MModule/Evaluation Kit, 2005. http://www.ftdichip.com/Documents/

DataSheets/DLP/dlp2232m-v14-ds.pdf.

[12] Future Technology Devices International Ltd. FT2232D Dual USB UART/FIFOI.C., 2007. http://www.ftdichip.com/\discretionary-Documents/DataSheets/DS FT2232D.pdf.

46

[13] D. Gurkan, A. Mickelson, and D. Benhaddou. Remote laboratories for opticalcircuits. Education, IEEE Transactions on, 51(1):53–60, Feb. 2008.

[14] I. Gustavsson. A remote laboratory for electrical experiments. In Proceedingsof 2002 ASEE Annual Conference, pages 11285–11293, Washington, DC, USA,2002. American Society for Engineering Education.

[15] R. Hashemian and J. Riddley. Fpga e-lab, a technique to remote access a lab-oratory to design and test. Microelectronic Systems Education, 2007. MSE ’07.IEEE International Conference on, pages 139–140, June 2007.

[16] L. Hesselink, D. Rizal, and E. Bjornson. Cyberlab: Remote access to laboratoriesthrough the world-wide-web. In Proceedings of the SSGRR 2000 Computer &eBusiness International Conference, Compact disk paper 224 and electronic pro-ceedings http://www.ssgrr.it/en/ssgrr2000/proceedings.htm, L’Aquila,Italy, July 31 - August 6 2000. Scuola Superiore G. Reiss Romoli.

[17] Information Sciences Institute, USC. The network simulator - ns-2, February2008. http://www.isi.edu/nsnam/ns/.

[18] N. Instruments. Distance-learning and remote laboratories using labview,September 2007.

[19] D. Karadimas and K. Efstathiou. An integrated platform, implementing real,remote lab-experiments for electrical engineering courses. In WBED’07: Pro-ceedings of the sixth conference on IASTED International Conference Web-BasedEducation, pages 631–636, Anaheim, CA, USA, 2007. ACTA Press.

[20] W. V. Kritikos. Feasibility of serial ata cables for the physical link in highperformance computing clusters. Master’s thesis, University of Kansas, May2007.

[21] J. M. Lee. VERILOG QuickStart: A Practical Guide to Simulation and Synthesisin VERILOG. Kluwer Academic Publishers, Norwell, MA, USA, 2002.

[22] P. Marchal. Field-programmable gate arrays. Commun. ACM, 42(4):57–59, 1999.

[23] S. McCraken, Z. Zilic, and H. Y. H. Chan. Real laboratories for distance educa-tion. Journal of Computing and Information Technology, 11(1):67–76, 2003.

[24] Mentor Graphics. Informant - your resource for simulation information, January2008. http://www.model.com/resources/informant/2006/03 2006.htm.

[25] Mentor Graphics. Model sim, January 2008. http://www.model.com/.

[26] MIPS Technologies. MIPS, March 2008. http://www.mips.com/company/

about-us/.

[27] Z. Nedic, J. Machotka, and A. Nafalski. Remote laboratories versus virtual andreal laboratories. Frontiers in Education (FIE 2003) 33rd Annual, 2003.

47

[28] P. Pawan, S. Pepic, I. J. S. K. Wong, and G. Gulak. Lab on the web. InProceedings of the 4th IEEE International Conference for Upcoming Engineers(ICUE), volume 4. IEEE, May 2005.

[29] Y. Rajasekhar, W. Kritikos, A. G. Schmidt, and R. Sass. Teaching fpga systemdesign via a remote laboratory facility. In Proceedings of the 2006 InternationalConference on Field Programmable Logic and Applications (FPL), pages 127–140, Washington, DC, USA, 2008. IEEE Computer Society.

[30] A. G. Schmidt. Quantifying effective memory bandwidth in platform fpgas.Master’s thesis, University of Kansas, May 2007.

[31] Silicon Graphics Inc. ””, February 2008. http://www.sgi.com/.

[32] SRC Supercomputers, Inc. Delivering programmer-friendly reconfigurableprocessor-based computers, February 2008. http://www.srccomp.com/.

[33] J. Tuttas and B. Wagner. Distributed online laboratories, August 2001.

[34] U.S. Department of Labor, Bureau of Labor Statistics. Bureau of labor statistics- occupational outlook handbook, December 2007. http://www.bls.gov/oco/

ocos027.htm.

[35] D. van Heesch. Doxygen, source code documentation generator tool, July 2007.http://www.stack.nl/∼dimitri/doxygen/.

[36] Xilinx. Virtex-4 FPGA / User Guide. http://direct.xilinx.com/support/

documentation/user guides/ug070.pdf.

[37] Xilinx. Virtex-II Pro / Virtex-II Pro X Complete Data Sheet. http://direct.xilinx.com/bvdocs/publications/ds083.pdf.

[38] Xilinx. Products and services, intellectual property, March 2008.

[39] Xilinx, Inc. Ml310 embedded development platform. http://www.xilinx.com/ml310.

[40] Xilinx, Inc. Ml410 virtex-4 fx embedded development platform. http://www.

xilinx.com/ml410.

[41] T. Zimmer, M. Billaud, and D. Geoffroy. A remote laboratory for electricalengineering education. In Proceedings of the 23rd International Conference onMachine Computing, pages 19–21, Washington, DC, USA, 2006. IEEE ComputerSociety.

48

APPENDIX A: GLOSSARY

ADC — Analog to Digital Converter

AIM — Automated Internet Measurement

AS — Application Server

ASIC — Application Specific Integrated Circuit

ATX — Advanced Technology Extended

CF — Compact Flash

CMOS — Complementary Metal Oxide Semiconductor

COTS — Commodity off-the-shelf

CpE — Computer Engineering

DB 9 — Serial Communications D-Shell Connector, 9 Pins

DRC — DRC Computers, name of a company

EE — Electrical Engineering

EJTAG — Enhanced JTAG

FPGA — Field-Programmable Gate Array

FSC — FPGA Session Control

FTDI — Future Technology Devices Incorporation

GPIO — General Purpose Input Output

GUI — Graphical User Interface

49

HDL — Hardware Description Language

IC — Integrated Circuit

I/O — Input/Output

IP — Intellectual Property (or Internet Protocol see TCP/IP)

JTAG — Joint Test Action Group

LED — Light Emitting Diodes

LPT — Line Printer Terminal

LUT — Look Up Table

MIPS — Million Instructions per Second

MUDL — Multi-User Distance Laboratory

Op-Amp — Operational Amplifier

OPB — On-chip Peripheral Bus

PAL — Programmable Array Logic

PC — Personal Computer

PCB — Printed Circuit Board

PCI — Peripheral Component Interconnect

PDU — Power Distribution Unit

PLB — Processor Local Bus

PLD —Programmable Logic Device

PLL — Phase Locked Loop

50

RC — Resistor-Capacitor (circuit)

RCC — Reconfigurable Computing Cluster

RCS — Reconfigurable Computing Systems

RS — Resource Server

RS-232 — Recommended Standard 232 (computer serial interface, IEEE)

SATA — Serial Advanced Technology Attachment

SGI — Silicon Graphics, Inc.

SNMP — Simple Network Management Protocol

SOC — System-On-Chip

SRC — Seymore Cray’s Initials, name of a company

TCP/IP — Transmission Control Protocol/Internet Protocol

UART — Universal Asynchronous Receiver Transmitter

USB — Universal Serial Bus

VHDL — Very High speed integrated circuit Descriptive Language

VNC — Virtual Network Computing

51

APPENDIX B: SURVEYS AND QUIZZES

The surveys and quizzes used to gather feedback on the system and assess learning

outcomes are included on the following pages. The same survey was given at the

beginning of the class in Fall 2007 and Summer 2008. The second survey from Fall

2007 was updated for Summer of 2008. Assessment quizzes were given in Summer

2008 only.

52

Survey 1: Fall 2007 and Summer 2008

ECGR 6090 – FUNDAMENTALS OF RECONFIGURABLE COMPUTING

Questionnaire

Please answer the following questions to facilitate research on Remote Labs: TRADITIONAL LABS: A real, hands-on lab where students engage in prescribed tasks involving different physical components. In other words, the student has to physically be present to access lab equipment.

1. Are you familiar with traditional lab settings? Yes No

2. Have you taken a course with a traditional lab?

Yes No

3. If the answer to question 2 was Yes, was the lab helpful in terms of learning? 1-Very Helpful 2-Sometimes Helpful 3-Rarely Helpful

SIMULATED LABS: A virtual lab done by the student with simulation software on general purpose computers. The software may only be available on school computers but there are open, shared labs available – perhaps in multiple locations.

4. Are you familiar with simulated lab settings? Yes No

5. Have you taken a course with a simulated lab?

Yes No

6. If the answer to question 5 was yes, was the lab helpful in terms of learning? 1-Very Helpful 2-Sometimes Helpful 3-Rarely Helpful

REMOTE LABS: A real lab that can be accessed through the Internet. Remote labs ideally have anytime, anywhere accessibility. While doing these labs the TA is available through electronic communication.

7. Are you familiar with remote lab settings?

Yes No

8. Have you taken a course with a remote lab? Yes No

9. If the answer to question 8 was yes, was the lab helpful in terms of learning?

1-Very Helpful 2-Sometimes Helpful 3-Rarely Helpful

There will be another survey conducted at the end of the semester. To help facilitate the survey, please make a note of the time required to complete your labs for this class.

~Thank you for taking this survey~

53

Survey 2: Fall 2007

ECGR 6090 – Fundamentals of Reconfigurable Computing

Questionnaire

Please answer the following questions to facilitate research on Remote Labs:

1. After working with remote labs, does the idea appeal to you?

Yes No

2. Since you did the labs from your own workstation, did you feel like you had less

time/space constraints?

Yes No

3. If yes, did you also feel you got a chance to explore and learn much more on your own?

Yes No

4. Did you feel like you had more opportunity to re-try if your lab/experiment did not work

the first time?

Yes No

5. Do you feel you would have performed better if you had some type of physical

components to visually show that your lab is working/not working?

Yes No

6. Did remote labs distract/discourage you in anyway?

Yes No

If yes, how?

7. In your experience what was the best thing about working with remote labs?

8. What was the worst?

54

Survey 2: Summer 2008

ECGR 6890, Summer 2008

QuestionnairePlease answer the following questions to facilitate research on Remote Labs

1. After working with remote labs, does the idea appeal to you?

Yes No

2. Since you did the labs from your own workstation, did you feel like you had less time/spaceconstraints?

Yes No

3. Did you feel like you had more opportunity to re-try if your experiment did not work forthe first time?

Yes No

4. With remote access, would you say you had more time to explore and learn much more onyour own?

Yes No

5. Do you feel you would have performed better if you had some type of physical componentsto visually show that your lab is working/not working?

Yes No

6. What, in your opinion, was the best thing about working with remote labs?

• Anytime Anywhere accessibility

• No time constraints

• Not having to share resources

• more opportunity to explore on your own

• not having to buy a board

7. In this course, using FPGAs for system level design, did you feel the need to have the equip-ment physically present in front of you?

Yes No

8. Which statement of the following best describes your experience with remote labs?

• Remote labs are excellent

• I feel the sotware session was buggy otherwise the experience was good

• I feel working with traditional labs is much better

• I don’t feel any difference between remote and traditional labs

• A traditional lab is better as a TA is always available

• Doing a remote lab was not great because of the slow internet connection at my end

55

Quiz Lab 2

ECGR 6090 Name: __________________________

Lab 2 – Quiz

1. Draw the blocks of your system. (5 pts)

2. You have three registers (assume the address of the first one to be 0x70000000). If you

added 3 more registers to your system, what would their addresses be? (3 pts)

3. What if the PLB2OPB bridge address range was changed to ‘0x00000000 to

0x6FFFFFFF’? (2 pts)

4. In which directory is the file user_logic.vhd? (2 pts)

5. What is IPIF and how does it relate to the core? (2 pts)

6. Is the core that you added hard or soft IP? (1 pt)

56

Quiz Lab 3

ECGR 6890, Summer 2008 Name: __________________________

Lab 3 - Quiz

1. Draw the base system to the best of your ability.(4 pts)

2. What command did you execute in order to extract the three archives (linux-base, mkrootfs, and busbybox).(1 pt)

3. Give the Name and the Version of the Linux Kernel. (1 pt)

4. What Application is initially running on the PowerPC after our bitstream is configured to the FPGA? (1

pt)

5. What does BSP stand for? At what point did you generate the BSPs and what does it do?(2 pts)

6. What command did you use to create your lab3_ppc executable which

runs on the PowerPC405?(1pt)