WEB-BASED ACCESS TO EDUCATIONAL PROTOTYPING BOARDS USED IN INSTRUMENTATION LABORATORY C.G. Haba, L.Breniuc "Gh.Asachi" Technical University of Iaşi, Iaşi, Romania E-mail: cghaba@ee.tuiasi.ro Abstract: We present a set of web-based tools permitting remote configuration and test of hardware-software instrumentation applications implemented using an XESS XS40-010XL prototyping board (XSB). The tools denoted as Remote XSTools (RXST) provide a set of webbased interfaces to the XESS XSTools. Using RXST students have access to the XSB which is equipped with a XILINX XC4010XL FPGA and an 8031 microcontroller (µc)[1]. They can configure the FPGA to implement different digital designs and test their operation by sending stimuli and getting back visual information about the status of the outputs. Keywords: remote laboratory, distance learning, education in measurement 1 INTRODUCTION Rapid technological development challenges education by providing increased opportunities. However, they can be of great help in developing of modern educational tools, designed for local access or web-delivery [2,3]. These tools can provide interactivity and animation offering a flexible, faster and friendlier learning. The increased use of computers into laboratory brought important benefits among which we point: out-of-class assignments, extending to use of the computers in the classroom and to making the computer an integral part of the educational process (replacement of traditional laboratories with virtual or remote laboratories). We have created a set of web-based tools allowing the remote configuration of the XSB in order to allow student to implement and test simple digital hardware-software instrumentation applications out of laboratory. RXST provide a set of web-based interfaces for the XESS XSTools providing similar look and functionality. Using RXST, students can configure the FPGA to implement different digital designs and test their operation by sending stimuli and getting back visual information about the state of outputs. Mixed hardware-software designs can be experimented remotely by partitioning the application into modules that are either hardware implemented (FPGA) or software implemented as a program loaded into the memory of the µc. 2 EQUIPMENT AND SOFTWARE The central focus of the laboratory is to teach digital measurements and measurement microsystems and has the necessary equipment to support multiple sets of student experiments. The laboratory equipment used consists of: PC Pentium computers, XESS XS95-108 version 1.4 development boards, XESS XS40-010XL version 1.4 development boards, 8051 microcontroller-based development systems, digital multimeters, oscilloscopes, signal generators, power supplies. The XESS XS40-010XL and XESS XS95-108 are development boards each one including: 8031 microcontroller, 32/128 Kbytes SRAM, 100 MHz programmable oscillator, parallel port, mouse/keyboard PS/2 port, VGA monitor port, 7-segment LED, 84-pin breadboard interface, serial EEPROM socket, 9V DC power jack and 5V / 3.3V regulators. The two boards differ in the Xilinx programmable integrated circuit mounted in the 84-pin socket, i.e. the XC4010XL FPGA or the XC95108 CPLD respectively. For our set of remote tools, we have allocated one PC, one XS40-010XL board and one µc based development board. Student laboratory works require some software tools for their successful completion. Software installed on the computers to be used with systems includes: Xilinx Foundation [4]; Xess XSTools [5]; Franklin Software for programming the 8031/51 µc.
XESS XSTools consists of additional software for the XSB with four components: xsload for uploading the configuration file to the FPGA and the program file for the µc; xsport for applying signals to the XSB using the parallel port; xstest for testing if the XSB is well functioning; xssetclk for setting the frequency of the on board programmable oscillator. If the Windows OS is available, students may use GXSTools which are the correspondent to the XSTools commands providing a Windows (graphical) interface. GXSTools consists of gxsload, gxstest, gxsport and gxssetclk respectively (Fig.1). For the web based applications we have configured a PC with RedHat Linux version 7.0 and installed the Apache v.1.3.22 HTTP server. a) b) c) d) Fig.1. The GXSTools: a)gxstest, b) gxssetclk, c) gxsport, d) gxsload. 3 IMPLEMENTATION We are developing our tools in order to work on a network architecture like the one depicted in Fig.2. For the moment, the web server and the instrument configuration and control software are run on the same computer. Web Server Client Web browser Web Server Client Web browser Instrument control Internet Instrument control Internet Parallel cable Serial cable. Database Parallel cable. Database XSBoard uc Board XSBoard Serial cable Fig.2. XSBoard connection to the network: a) feedback through µc; b) direct feedback. The system works as follows: The user accesses the RXST web page. One has the possibility to choose one of the tools: RXSTest, RXSSetclk, RXSLoad and RXSPort (most often will be the last two ones). Accordingly, student's browser will load the corresponding html form. In order to upload configuration files into the XSB the user will use the RXSLoad form (Fig.2b). One must provide the configuration.bit file for the FPGA and the.hex file containing the program for the 8051 µc from their local machine. This is a two step process. First, the user will select his.bit
and/or the.hex file from his local machine using a file selection dialog and upload them to the remote server. In case of a successful uploading the server will return a new RXSLoad form. Fig.3. RXSLoad Html form for remote downloading the configuration of FPGA and the program for the 8031 µc. Fig.4. RXSPort Html form for remote sending stimuli to the XSB and visualizing the change in the seven-segment LED status.
This new form differs from the previous one by a message indicating the name of the files which had been successfully uploaded. The file names also appear in the corresponding text fields of the form. The user can now configure the downloading parameters (board type, parallel port, file format, etc.) and post the form to a CGI script on the web server by pressing the LOAD button. The script will run XESS xsload program with the uploaded files and the posted parameters. The user will get back the RXSPort html form by which he can send stimuli to the XSB. The browser window containing the RXSPort form also contains the image of the XSB. The presence on the XSB of the 7-segment LED was thought to permit the visualization of the operation of the implemented project if, by design, all or some of the outputs are connected to the segments of the display. Similarly, in our remote tools, we have to make in such a way that if a change occurs in the status of any of the led segment, this will also be reflected in the browser window showing the XSB. In order to achieve this capability we have provided two solutions. In the first one (Fig.2a), signals driving the seven LED segments are read by an 8051µC based system and sent to the computer via a serial connection. The seven led segments are connected to the pins P1.0 - P1.7 of the 8051 µc. When the µc receives on the serial line the character "r" (which means read), it reads port P1 and sends back on the serial line the result. A CGI script implementing the XSB view reads the serial port and changes the color of the segments in the view accordingly. In this way, students can use both the FPGA and µc on the XSB, without supplementary restrictions to those given in the XSB manual. The second solution uses the µc on the XSB and some extra circuitry for sending the status of the LED segments via the serial connection (Fig.2b). This solution save the extra µc system but imposes additional restrictions to the implemented design. Fig.5. Implementation of a 7-segment LED driver. In Fig.5 is depicted the schematic of an application circuit implemented on the XSB that allows us to activate the segments of the 7-segment LED by applying the corresponding binary
inputs using the RXSPort. The schematic consists of two parts: a) interconnection part - contains the circuitry which provides the interconnection between the µc and the RAM memory where the µc program is stored. In Fig.5, a dashed line delimits this part of circuitry. b) user application part - contains the circuitry implementing user application. In the interconnection part we can first distinguish the interconnection between the PC parallel port and the FPGA (inputs PC_D[7,0] and internal signals PC_D_IN0 PC_D_IN7). These signals are used to reset the µc (PC_D_IN0) and for sending test signals to the studied circuit (PC_D_IN1-PC_D_IN3). The upper byte A[15,8] of the RAM address is also used for selecting the application implemented in the FPGA. The XSB v.1.4 has a 128kB RAM memory, only 32kB are used for program code and data. The lower byte A[7,0] of the RAM address is multiplexed with data. The addresses A[7,0] are obtained with signal ALE_IN and register OFD8. The FPGA also receives from the µc signals CLK(clock), ALE (demultiplexes addresses and data, ADDRESS LATCH), RD_ (read signal, READ), WR_ (write signal, WRITE), PSEN (program memory selection, PROGRAM SELECT ENABLE). In order to see the RAM as both data and program memory we AND signals RD_ and PSEN_. The µc receives from the FPGA the signals RST (reset µc), CE_=A_IN15 (validation of 32kB RAM between hexadecimal addresses 0000-7FFFH, OE_ (validation reading RAM memory - A16 is connected to ground so we select 64kB of RAM. The memory space 8000- FFFFH is reserved for application implemented in FPGA. The validation for reading buffer D_DRV is obtained using signals RD_ and the selection signal of address FxxxH. In our example, the user application part implements a 7-segment LED driver using a 3- to 8- line decoder/demultiplexer with active-low outputs and three enables. The three binary inputs are connected to the parallel port lines PC_D3-PC_D1 which can be toggled using the RXSPORT tool. Each of the first seven binary combinations corresponds and activates one of the seven led segments whereas the last one corresponds to the decimal point. Because the decimal point is not used on the XSB, application of the last combination has no effect. The system clock is generated be the on board 100MHz programmable oscillator. In our implementation, the oscillator is set to 10MHz so the only transfer rate we can use for the serial link is 2400 bauds. 4 DISCUSION The interfaces were designed in such a manner that they look very similar to the interface windows of the graphical versions of XST (compare Fig.1, 3 and 4). In this way, the use of RXST will be familiar to those working with the original GXSTools. We are studying different variants of our system where, the communication between the PC and the XSB will be made only through one communication port, either the serial or the parallel one. These systems bring the advantage of saving one communication port but have other drawbacks. In this first version of RXST the user is restricted to the visualization of maximum seven outputs, in the same way students are when using the XSB for implementing and testing simple designs. The system can be extended so more than seven outputs can be observed. The graphical interface should be changed accordingly. For the implementation in Fig.2a the outputs will be connected to the XSB pins. In order for the µc to read these outputs, its port lines will be hardwired to the corresponding XSB pins. In the second implementation (Fig.2b) the connections are made internally. This brings the advantage that the user can not only observe the design outputs but also can define and observe other test points in the circuit.
The interconnection part can be implemented as a macro and inserted in the standard library of the Xilinx Foundation schematic editor. The user will only have to take care of inserting this macro in his design, analyze and eliminate possible conflicts resulting in multiple allocation of FPGA pins. Both set-ups offer students the possibility to replay or continue their experiments, imagine and test new experiments outside the laboratory. This set of tools gives them the opportunity to test digital and mixed hardware-software design using this set of tools that lies between real testing and simulation. 5 CONCLUSION We have presented our work aiming to design efficient tools for long-distance education. Using RXST, students outside the laboratory can replay or continue their laboratory experiments using a remote computer with Internet access. Further work will seek to enhance the possibility of observing the operation of the implemented design by increasing the number of feed-backed signals from the XSB. Several issues remain still to be addressed in order to optimize and provide shared and secure access to the XSB. 6 AKNOWLEDGEMENTS The authors greatly acknowledge Xilinx Inc for donating to our faculty the XS Boards and the Xilinx Foundation software used in this laboratory. Xilinx and Foundation are trademarks of Xilinx, Inc. All XC-prefix product designations are trademarks of Xilinx, Inc. All XS-prefix product designations are trademarks of XESS Corp. Franklin Software is a trademark of Franklin Software Inc. REFERENCES 1. D. Van den Bout, "The Practical Xilinx Design Lab Book", Prentice Hall, 1999. 2. B.Aktan, C.A.Bohus, L.A.Crowl, M.H. Shor, "Distance Learning Applied to Control Engineering Laboratories", IEEE Trans Education, vol. 39, no. 3., pp. 320-326, 1996. 3. C. McCormack, D. Jones, "Web-Based Education" System, John Wiley &Sons Inc.,1977. 4. ***, "Foundation Series Quick Start Guide 1.5"-0401762, Xilinx Inc., San Jose, California, 1998. 5. ***, "XSTOOLs V4.0 User Manual. GUI-Based and Command Line-Based XS Board Utilities", X Engineering Software Systems Corporation. 2001.