An FPGAbased integrated environment for computer architecture

Download PDF
0 downloads 0 Views 3MB Size Report
Comment
Keywords: computer architecture; computer organization; computer architecture education; FPGAs; develop- ment board ... hazards that occur when instructions are executed are, for many ..... ware could be developed for visualization, but such a solution is .... and design: The hardware/software interface, 4th edition, Else-.
An FPGA-Based Integrated Environment for Computer Architecture ´ VESELKO GUSTIN, ˇ ˇ ˇ PATRICIO BULIC, DAMJAN SONC, ANDREJ STRANCAR Faculty of Computer and Information Science, University of Ljubljana, Ljubljana, Slovenia Received 21 September 2009; accepted 14 March 2010 ABSTRACT: We present a new, integrated environment used in computer-architecture education. The environment consists of a hardware platform and GUI software running on a PC. The hardware platform is entirely implemented in Xilinx Spartan-3 FPGA. The main part of the hardware platform is a 32-bit pipelined RISC processor with a trace/debug unit. This trace/debug unit is a hardware unit that enables debugging and transfers the pipeline contents to the PC. It also enables communication between the GUI application on the PC and the microprocessor core. Such a system makes it possible to download the students’ programs to the FPGA-based microprocessor and graphically depicts the processor’s internal state on the PC. © 2010 Wiley Periodicals, Inc. Comput Appl Eng Educ 21: 26–35, 2013; View this article online at wileyonlinelibrary.com; DOI 10.1002/cae.20448 Keywords: computer architecture; computer organization; computer architecture education; FPGAs; development board

INTRODUCTION Computer architecture is an important part of computer science, but it is one of the hardest to teach by example. At many universities, the course on computer architecture treats it not only from the programmer’s viewpoint; the course also covers the organization of the computer, for example, pipelining, instruction-level parallelism, memory hierarchies, and the I/O system. Students beginning a course on computer architecture often have a problem in understanding basic pipeline principles. It is very likely that one of the reasons for this is that the students are not able to see the process in reality. Processor features such as data, structural, and control hazards that occur when instructions are executed are, for many students, hard to understand without some sort of view of the internal state of the pipeline and the contents of the registers between the pipeline stages. Our aim was to create a system that would do just that. The simplicity of describing logical circuits through hardware description languages, such as VHDL, and the availability of FPGA circuits have encouraged us to implement an educational model of a 32-bit pipelined RISC microprocessor on which students can run their own programs. In addition to the processor, we also implemented a trace/debug unit that allows the students to trace the content in the processor’s pipeline and to transfer this Correspondence to P. Buli´c ([email protected], [email protected]). © 2010 Wiley Periodicals, Inc.

26

content to a PC system for every single cycle of the processor. Such a system makes it possible to download the students’ programs to the FPGA-based microprocessor and graphically depicts the processor’s internal state on the PC. In the literature that covers computer architecture and organization many hypothetical pipelined processors are described [1–4]. However, generally, they are all variations of the 32-bit pipelined MIPS. These hypothetical processors have a simplified ISA that is very close to the real architecture. The primary literature [1] for the subject used at our faculty describes such a processor called the hypothetical microprocessor (HIP), to which we will return later. As this model is well described in the Slovenian literature (the mother tongue of most of our students), we decided to base our system on this model. The basic structure of the implemented environment is presented in Figure 1. The environment consists of the FPGA-based system (the HIP microprocessor, the instruction and data memory, the trace/debug unit, the UART, and the I/O buffers), a GUI application running on a PC, and a keyboard and LCD connected to the FPGA-based system. The rest of this article is organized as follows. In the second section we provide a short overview of related work. In the third section we discuss hardware versus software emulation. In the fourth section we present the architecture and organization of the processor that we implemented and then used. In the fifth section the hardware implementation is presented, whereas in the sixth section we present the software implementation. The emulation details are presented in the seventh section and the laboratory

COMPUTER ARCHITECTURE

27

Figure 1 Basic structure of the presented integrated environment. The environment consists of the FPGA-based system (HIP microprocessor, instruction and data memory, trace unit, UART, and I/O buffers), a GUI application running on a PC, and a keyboard and LCD connected to the FPGA-based system. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]

assignments are discussed in the eighth section. In the ninth section we draw some conclusions.

RELATED WORK There have been many publications discussing the teaching of computer architecture and describing the use of software tools and simulators in computer-architecture education and, in addition, the use of FPGA-based systems in digital logic design and computer organization. In Ref. [5], for example, Clements describes several approaches to teaching computer architecture, and simulators are also introduced, whereas in Ref. [6], Kief et al. describe a new FPGA educational platform for teaching reconfigurable logic and digital design. In Ref. [7], another group, Djordjevic et al., discuss the challenges of teaching computer architecture and present a very flexible educational environment for teaching and learning about computer architecture and organization. The presented tool encompasses a number of software tools that are used both in laboratory settings and at home during self-study and allows students to write and execute their own assembly-language

programs, experience program execution through graphic simulation and animation, inspect implementation details down to the register transfer level, display timing diagrams, and test their knowledge. In Ref. [8], Castilla et al. present a cycle-by-cycle simulator to support the teaching of instruction-level parallelism (ILP) architectures. In Ref. [9], Khairurrijal et al. present a singleboard computer based on the AT89S52 microcontroller used in education. In Ref. [10], Mohanna et al. describe the teaching of microprocessors, microcontrollers, and digital signal processing using only a single target processor. In Ref. [11], Toral et al. show a novel approach to the teaching of digital signal processors (DSPs) based on an interactive multimedia educational tool. In Ref. [12], an earlier article of ours, we introduce computerarchitecture learning through the development of a very simple, non-pipelined FPGA-based microprocessor, and in Ref. [13], Abe et al. present an integrated laboratory for processor organization, compiler design, and computer networking. According to Andreu and Nussbaum [14], the inclusion of technology in higher education teaching makes the educational process more effective and attractive to students and leads to improvements in the students’ performance.

28

BULIC´ ET AL.

The main improvement of this work over previous works is the FPGA implementation of the pipelined processor along with the trace-and-debug unit. This trace/debug unit is a hardware unit that enables debugging and displaying the contents of every pipeline stage and transfers the pipeline contents to the PC, which is usually impossible with off-the-shelf processors as they do not offer the possibility to debug each pipeline stage—they only provide access to the program’s visible content through the JTAG interface and only after each instruction is completely executed. The other improvement over the previous work [12] is the presence of real I/O devices, which are controlled by the hardware implementation of a pipelined processor, and we think that this is an even more important advantage for the educational process.

the result actually appears on the display than, for example, when one of the registers changes. If a character appears on the display after the store command passes the MEM stage of the pipeline it encourages the students to consider the pipeline when they write programs. If a pipeline hazard appears the output is further delayed. On the other hand, the large improvement in motivation that we noticed can be partly due to our faculty’s curriculum. Computer architecture is the first subject that offers the students a closer contact with hardware other than a personal computer. FPGA technology, with its reconfiguration capabilities, means that the current model is not the end of our work: the HIP can and will be advanced with cache memory, dynamic branch prediction, etc. The flexibility of the FPGA circuit also leaves the communication protocol with a visualization module to the needs of specific applications.

HARDWARE VERSUS SOFTWARE EMULATION Students of computer science have difficulties in understanding microprocessors, and these difficulties tend to increase when the pipeline is introduced. Basic pipeline flow, data and control hazards, interrupt and trap responses, etc. are usually regarded as very difficult subjects, but they represent the fundamentals needed for any more advanced study of the subject. The lacks of practice and real-life examples are the main contributing factors here. For this reason the HIP emulation project was encouraged by lecturers because of their requirements to be able to teach computer architecture not only using literature and “blackboard” examples but also using practical examples. A working model of a literature microprocessor example supports the book and increases its value. It is not only a collection of drawings, tables, and state diagrams; it is also a real-world implementation. Students usually mistakenly regard hardware engineering as a difficult subject in the domain of a few international corporations, and so do not try to introduce their own creativity. However, a university-developed HIP model could be an example of what possibilities are there in the field of hardware engineering. The introduction to this section touches on the motives that led to hardware rather than software implementation. Without doubt, the software-based processor simulator is one of the most important developments in computer architecture education [5]; nevertheless, it lacks some of the important features available in a real processor. It also fails to present to the students the fact that the processor described in the literature that they have to study has almost all the capabilities of some off-the-shelf processors and that it can be implemented in hardware as well, and it can run the real-life programs. One software model that we developed previously is more portable, flexible, and easy to use, yet it lacks the very realism of the hardware emulation. While the software model is constrained to educational and demonstration purposes; a hardware implementation can also be used in a reallife application. Perhaps an even more important advantage for the educational process is the presence of real I/O devices, which are controlled by the hardware implementation of a pipelined processor. Of course it is possible to simulate the I/O devices, although it is very hard (and in our opinion it would be a good improvement for most simulators), but working with real I/O devices is much more motivating for students. A great improvement in our students’ motivation is, in our opinion, the biggest advantage over the simulated version of the HIP processor that we used before. If the programs that students have to write require the outputting of results to a LCD, the students pay much more attention to when

ARCHITECTURE AND ORGANIZATION The HIP is a modern 32-bit pipelined RISC microprocessor with 32 general-purpose registers. The design is very similar to the MIPS 2000 and MIPS 3000 [1–3]; therefore, our work is not limited only to our primary literature. The textbook [1] describes several versions of the HIP microprocessor’s organization, but we have chosen a five-stage pipelined implementation, which includes RAW (read after write) hazard detection and pipeline-forwarding logics. Conforming to the textbook [1], the pipeline has the following five stages: (1) (2) (3) (4) (5)

instruction fetch (IF), instruction decode (ID), execution (EX), memory access (MEM), and write back (WB).

The textbook is not specific about which branching technique should be used; the author only explains the options available to a microprocessor designer. We have chosen the simplest of all techniques, that is, the branch-never-taken strategy. The load delay is one cycle, while the branch delay (when taken) is two cycles. There is a single interrupt input; however, the vector-type interrupts can handle 60 different interrupts, while the priority must be resolved with external modules such as interrupt controllers. The HIP can also handle four traps: two for unaligned memory accesses, a signed number overflow, and an undefined instruction.

Instruction Set Architecture The HIP instruction set consists of fifty-two 32-bit instructions divided into two possible formats. According to its RISC behavior, memory accesses are performed only with the LOAD and STORE instructions, which can access byte, half-word, and wordsized operands. In its current realization there are no multicycle arithmetic operations (multiply and divide), but there are several bits in instruction format still available for later use. There are also a few control instructions, such as the software exception TRAP, the subroutine CALL, two conditional branches, an unconditional JUMP, and a return from exception instruction. Being able to handle interrupts, the HIP also has instructions for enabling and disabling interrupts and return-address handling.

COMPUTER ARCHITECTURE

HARDWARE IMPLEMENTATION The whole integrated environment consists of the hardware and the software parts, as shown in Figure 1. The hardware part of the integrated environment provides the HIP microprocessor with the trace/debug unit (yellow box in Fig. 1) and the IO control module (red box in Fig. 1). The hardware part is connected to the PC via an RS232. The core of the hardware part is the pipelined implementation of the HIP microprocessor. The implementation of the HIP processor core provides the direct access to the content of all the registers in the processor’s pipeline. The trace/debug unit is directly connected to the HIP processor core and has the following roles: (1) it receives the commands from the PC via an RS232 and generates the clock and other control signals for the HIP processor core according to the received command, (2) it reads the content of the registers in the processor’s pipeline in every clock cycle and sends the content to the PC via an RS232.

The I/O module provides the access to the I/O (i.e., the keyboard and LCD) for the HIP processor core such that students can control real I/O modules, which cannot be simulated directly from the HIP processor core.

Figure 2

29

Implementation Details The whole hardware part of the integrated environment is implemented in the Xilinx Spartan III FPGA using Xilinx EDK (Embedded Development Kit). We used the low-cost Xilinx Spartan-3E starter Kit development boards [15] to implement our design (Figure 2). The FPGA design consists of two parts: (1) The HIP core with data and instruction memories, the trace/debug unit, and the UART. (2) The Xilinx MicroBlaze processor core with I/O buffers and digital interfaces for a PS/2 keyboard and the Hitachi LCD module. This part is used to connect the HIP core to the external PS/2 keyboard and the Hitachi LCD display located at the development board.

The basic structure of the FPGA design is presented in Figure 3. The HIP processor core, memories, the UART, and the trace/debug unit are described in the VHDL (Very High Speed HDL) language and then synthesized in Xilinx Spartan III using Xilinx EDK. The design is modular and therefore expandable for future work.

HIP Microprocessor Core The HIP core can operate in two modes. In the first mode the instructions are fetched and executed in the normal way. More

Xilinx Spartan 3E 500 development board used for the hardware part of the implementation.

30

BULIC´ ET AL. The Role of the MicroBlaze Processor Core

Figure 3 Xilinx Spartan 3E 500 development board used for the hardware part of the implementation.

interesting is the second mode, where the pipeline acts as a slave to the trace/debug unit, making its pipeline and general-purpose registers visible to outside logic. For this mode to be able to operate a clock-enabled signal was added to every register in the core. This means that when the clock is disabled the current state of the microprocessor remains intact. The details of this operation will be described in the next section. The module consists of an arithmetic logic unit (ALU), a register file, a forwarding logic, and pipeline registers (Fig. 4). A great deal of effort was put into the optimization of those units; however, our abilities to make the core as tiny as possible were severely limited by the requirement that every single register is visible to the outside world. The design is, however, not very suitable for migrations from Xilinx to, say, Altera FPGAs, because specific Xilinx features such as distributed RAM resources were used [16,17].

Trace/Debug Unit The Trace/Debug unit is a hardware unit that enables debugging and transfers the pipeline contents to the PC. It also enables communication between the GUI application on the PC and the microprocessor core. The communication is via an RS-232 cable, according to a protocol we developed for this purpose. A cyclic redundancy check is made on each data packet in order to ensure that the communication is as reliable as possible. The protocol uses four different types of packets: acknowledge packets, the initialization of memory (downloading the program), the current program counter for breakpoint checking and, most importantly, the complete state of the microprocessor core. On the side of the microprocessor core the tracing unit generates a trace signal (clock disable), reads the demanded data, and sends them to the GUI application on the PC.

Memory HIP is based on the Harvard architecture, thus it allows the simultaneous fetching of instructions and data. For this purpose we implemented two RAM modules inside the FPGA using dedicated Block RAMs.

The MicroBlaze is a soft processor core designed for Xilinx FPGAs. As a soft-core processor, the MicroBlaze is implemented entirely in the general-purpose memory and logic fabric of Xilinx FPGAs. The MicroBlaze has a versatile interconnect system to support a variety of embedded applications. This MicroBlaze processor core is used to easily connect the simple I/O system (consisting of a PS/2 keyboard and a Hitachi LCD display) to the HIP processor core. Using the Xilinx EDK, we can connect the MicroBlaze core to a variety of I/O devices (GPIO, UART, Ethernet MAC, etc.) that are implemented as Xilinx IP cores and are available through the Xilinx EDK. The selected I/O devices are connected to the MicroBlaze core via the OPB (On-chip Peripheral bus) [18]. We can also connect a variety of user-defined devices to the OPB using the Xilinx Intellectual Property Interface (IPIF) [18] that is also available through the Xilinx EDK. The usual way of connecting the user-defined I/O devices is presented in Figure 5. The role of the third-party IP module is to form a connection between the IPIF and a user-defined I/O device. We have used the IPIF to connect the HIP core to the MicroBlaze core. As was pointed out before, the main role of the MicroBlaze core is to interconnect the HIP core with the PS/2 keyboard and the Hitachi LCD display. Both devices are available to the HIP programmer (student) and are visible through the two memory locations. Writing 8 bits to the address 0x000B0000 from the HIP processor actually writes a character to the LCD display. Similarly, when the HIP reads 8 bits from the address 0x000A0000, it reads the character from the keyboard buffer. The detailed structure of the FPGA-based design is presented in Figure 6. The LCD and the PS/2 keyboard are connected to the MicroBlaze processor core via the OPB bus and the associated controllers. The MicroBlaze core and the HIP core are connected via the OPB bus and the IPIF communication bridge.

SOFTWARE IMPLEMENTATION The software part of the presented integrated environment runs on a PC. It consists of a GUI application and a HIP assembler. The GUI application is responsible for downloading the students’ programs to the FPGA-based microprocessor and graphically depicts the processor’s internal state on the PC. The GUI application was developed in Delphi Studio, while the HIP assembler was developed in Microsoft Visual Studio. From the GUI application the students are able to: (1) Edit, write, and compile assembler programs for the HIP processor. (2) Download the compiled code into the HIP instruction memory implemented in FPGA. (3) Run, debug, and trace the programs executed by the HIP processor and visually trace the internal state of the HIP pipeline.

The GUI application is presented in Figure 7. The leftmost window contains the assembler code of the program and the possible breakpoints. When running a program the assembler instruction currently being fetched is highlighted. The second window (top right) shows the contents of the registers, both pipeline and general purpose, and the third window (bottom right) is used for the communication logs between the FPGA-based system and the GUI application. There is also a dialog box, which is used to set up the communication parameters and the trace interval. Through the

COMPUTER ARCHITECTURE

Figure 4

The synthesis of the HIP core. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]

31

32

BULIC´ ET AL.

fore complementary: a student can develop his assignment on the software simulator and later try it on the hardwired one.

EMULATION DETAILS

Figure 5 The architecture of the MicroBlaze core bus interface for general-purpose I/O devices.

program the user can compile, download, and run the assembly code. There are three modes of running the code: 1. Step by step: The user must click a button for each single instruction. After that the contents of the window that holds register values are refreshed. 2. Continuous step by step: This mode is essentially the same as the above, but the stepping is done automatically. 3. Run: The program runs until it hits a break point when the window with the register data is refreshed.

Breakpoints were also realized in the PC application in order to simplify the logic used on the FPGA and allow greater flexibility of the system. The current value of the program counter is sent and compared with the breakpoint addresses and when there is a match the GUI application stops the microprocessor. This software uses the compiler taken from the software simulator of the HIP microprocessor that was developed prior to our work [19]. The hardware and software simulators are there-

Figure 6

The data necessary for a visualization of the state of the microprocessor are composed of the contents of the pipeline stage registers. Due to the large quantity of the data (512 bits), it is almost impossible to visualize them in a user-friendly fashion, using only seven segment displays and LEDs that are available on the Spartan-III or almost any other FPGA demonstration board. Additional hardware could be developed for visualization, but such a solution is necessarily more complicated and, most important of all, more expensive. We have decided to transmit the content of the pipeline registers via a serial communication to a personal computer through a serial RS-232 cable. As the data are transmitted serially, the HIP also generates them serially. Its pipeline stage registers are connected to form one 512-bit shift register (Fig. 8). The content of the registers rotates 512 cycles until the primary state is restored. During each cycle 1 bit is transmitted using an application-adapted UART controller. In addition to the register contents, 1 byte of information relating to the interrupt or trap responses is transmitted. The data are then processed and visualized by the personal computer. In Figure 9 we can see a typical program written by the students (leftmost window) and executed on the HIP core. The HIP currently fetches the instruction at line 18 (sw 0(r2), r4). The registers IR and PC1 between the IF and the ID pipeline stage contain the previous instruction from the address 0x0000002C and the associated program counter. The registers PC2, A, B, and IR1 between the ID and EX stages contain the nop instruction from the address 0x00000028. This instruction is now executed in the EX stage and the result will be transferred to the registers between the EX and MEM stages on the next rising clock edge. The registers C, MAR, SDR, and IR2 between the EX and MEM stages contain the lw r4, 0(r2) instruction from the address 0x00000024. Finally, the registers C1 and IR3 contain the instruction sw 0(r2), r4 from the address 0x00000020.

The detailed structure of the hardware implemented in the Xilinx Spartan 3 FPGA.

COMPUTER ARCHITECTURE

Figure 7

Figure 8

33

GUI application. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]

The pipeline registers are implemented as one 512-bit register.

LABORATORY ASSIGNMENTS The course is offered in the second year of the undergraduate university program at the Faculty of Computer and Information Science (where it is mandatory for all students) and at the Fac-

ulty of Education, Department of Mathematics and Computer Science. The FPGA-based integrated environment is used in the first semester. Students learn computer architecture and internal processor organization through the writing of assembly programs. During the first weeks they get acquainted with the HIP processor architecture and its assembly and machine language. At this stage the exercises are made on a simulator of the non-pipelined HIP processor. Besides writing short programs in assembly language the students have to be able to explain how some machine-code instructions are actually executed in the hardware. In the middle part of the semester they get acquainted with the pipelined version of the HIP processor. From this stage on the exercises are made in the FPGA-based integrated environment. The fact that they can work on something “real” was shown to be an important motivating factor for most of them, especially when the topics become more advanced and difficult to understand. According to our experience, the key factors that make this environment an excellent tool for a computer-architecture course are the trace capability at the pipeline level and the integration of I/O devices (LCD and keyboard) into the system. Many students are surprised when they actually see that an instruction does not affect the I/O device immediately when it enters the pipeline, but only three clock periods later (in the HIP case) when it reaches the memory access stage of the pipeline.

34

BULIC´ ET AL.

Figure 9 Emulation details. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]

In order to achieve a good understanding of the concepts present in a pipelined processor, the students must write several assembly-code programs and run them on the implemented HIP processor. Then they have to find all the possible hazards, first by manual program analysis and then by observing how the program is executed in the processor, so that they can compare the results. Finally, they have to optimize the given assembly code. The instructors also ask them to comment on the way the program is executed, about the performance, and the limitations. During this part of the course the students can choose between some pre-prepared specifications for the assembly programs or they can implement some ideas of their own.

CONCLUSIONS We have presented a new integrated environment that allows us to view the internal activities taking place within a real and running processor. The main goal was to make it possible for each student to work with a hardwired educational processor instead of just simulating the processor. The main advantages of the presented environment over the previous and related works that are based mainly on simulators and the use of off-the-shelf processors are:

(1) the FPGA implementation of the pipelined processor along with the trace-and-debug unit that enables debugging and displaying the content of every pipeline stage. The off-the-shelf processors enable access only to the program’s visible content after each instruction is executed; (2) the presence of real I/O devices that are controlled by the hardware implementation of a pipelined processor. The students can work on something “real” that was shown to be an important motivation factor for most of them, especially when topics become more advanced and difficult to understand; (3) the practice showed that by using the presented tool the students can easily achieve a good understanding of the concepts present in a pipelined processor, which is very important as the weekly hours for lab exercises are shrinking in the new Bologna studies.

This article describes the design of an integrated educational environment. The design is based on the use of Xilinx tools and low-cost, Xilinx Spartan-3E starter Kit development boards. In future work we will try to extend the HIP ISA with multiplication instructions and to implement the sequential Booth multiplier in the third stage, implement more complicated branch prediction logic and extend the trace/debug unit in such a way as to access the content of the multiplier registers and branch predictors.

COMPUTER ARCHITECTURE

ACKNOWLEDGMENTS The authors would like to thank the students who have been involved in the development and implementation of parts of this project: Blaˇz Kelbl, Rok Gregoriˇc, and Iztok Starc. This project was partially funded through grant P2-0359.

REFERENCES [1] D. Kodek, Arhitektura in organizacija raˇcunaliˇskih sistemov (in Slovene), BI-TIM, 2008. [2] J. L. Hennessy and D. A. Patterson, Computer architecture—A quantitative approach, 4th edition, Elsevier/Morgan Kaufman Publishers, San Francisco, CA, 2007. [3] D. A. Patterson and J. L. Hennessy, Computer organization and design: The hardware/software interface, 4th edition, Elsevier/Morgan Kaufman, Burlington, MA, 2009. [4] D. M. Harris and S. L. Harris, Digital design and computer architecture, Morgan Kaufman Publishers, San Francisco, CA, 2007. [5] A. Clements, The undergraduate curriculum in computer architecture, IEEE Micro 20 (2000), 13–22. [6] C. J. Kief, M. S. Pattichis, L. H. Pollard, G. Alonzo Vera, and J. E. Parra, An XUP-UNM educational platform: A dual-FPGA platform for reconfigurable logic, Comput Appl Eng Educ 17 (2009), 232–239. [7] J. Djordjevic, B. Nikolic, T. Borozan, and A. Milenkovic, CAL2: Computer aided learning in computer architecture laboratory, Comput Appl Eng Educ 16 (2008), 172–188. [8] I. Castilla, L. Moreno, C. Gonz´alez, J. Sigut, and E. Gonz´alez, SIMDE: An educational simulator of ILP architectures with dynamic and static scheduling, Comput Appl Eng Educ 15 (2007), 226–239.

35

[9] Khairurrijal, M. M. Munir, A. Suhendi, H. Thaha, and M. Budiman, An AT89S52 microcontroller-based single board computer for teaching an instrumentation system course, Comput Appl Eng Educ 15 (2007), 166–173. [10] Y. Mohanna, M. Hamad, R. Jabr, A. Alaeddine, and O. Bazzi, Teaching microprocessors, microcontrollers, and digital signal processing courses using only one target processor: The newborn dsPIC30FTM from MicrochipTM, Comput Appl Eng Educ 15 (2007), 185– 191. [11] S. L. Toral, F. Barrero, M. R. Mart´ınez-Torres, and S. Gallardo, Interactive multimedia teaching of digital signal processors, Comput Appl Eng Educ 15 (2007), 88–98. [12] V. Gustin and P. Bulic, Learning computer architecture concepts with the FPGA-based Move microprocessor, Comput Appl Eng Educ 14 (2006), 135–141. [13] K. Abe, T. Tateoka, M. Suzuki, Y. Maeda, K. Kono, and T. Watanabe, An integrated laboratory for processor organization, compiler design and computer networking, IEEE Trans Educ 47 (2004), 311– 320. [14] H. B. Andreu and M. Nussbaum, An experimental study of the inclusion of technology in higher education, Comput Appl Eng Educ 17 (2009), 100–107. [15] Xilinx, Inc., Spartan-3E Starter Kit, http://www.xilinx.com/products/ devkits/HW-SPAR3E-SK-US-G.htm. [16] Xilinx, Inc., Spartan 3 FPGA Family Complete Data Sheet, Xilinx, Inc., San Jose, CA, 2005. [17] Xilinx, Inc., Using Look-Up Tables as Distributed RAM in Spartan-3 Generation FPGAs, XAPP464 (v2.0), March 1, 2005. [18] M. Maaref, Creating an OPB IPIF-based IP and using it in EDK, XAPP967 (v1.1), Xilinx, Inc., February 26, 2007. [19] D. Sonc and A. Strancar, WinHIP, University of Ljubljana, laps.fri.uni-lj.si/ars/ars1/index.html, 2001.

BIOGRAPHIES Patricio Buli´c received his B.Sc. degree in electrical engineering, and M.Sc. and Ph.D. degrees in computer science from the University of Ljubljana, Slovenia, in 1998, 2001 and 2004, respectively. He is an Assistant Professor at the Faculty of Computer and Information Science, University of Ljubljana. His main research interests include computer architecture, digital design and parallel processing. He is a member of the IEEE Computer Society and ACM.

ˇ Damjan Sonc is an assistant lecturer at the Faculty of Computer and Information Science, University of Ljubljana. He holds a M.Sc. in computer science. His research interests include parallel computer architectures, speech synthesis and recognition.

Veselko Guˇstin received his B.Sc. degree in electrical engineering, and M.Sc. and Ph.D. degrees in computer science from the University of Ljubljana, Slovenia, in 1971, 1974 and1979, respectively. He is an Associate Professor at the Faculty of Computer and Information Science, University of Ljubljana. His main research interests include computer architecture, programmable logic and parallel processing. He is a member of the IEEE Computer Society.

ˇ Andrej Strancar is an assistant lecturer at the Faculty of Computer and Information Science, University of Ljubljana. He holds a Ph.D. in computer science. His research interests include computer architectures, digital signal processing and speech synthesis and recognition.