FPGA-based Weblab Infrastructures Guidelines and a prototype implementation example Ricardo J. Costa1, Gustavo R. Alves1, Mário Zenha-Rela2, Rob Poley3, Campbell Wishart3 ISEP/CIETI/LABORIS1, FCTUC/CISUC2, Heriot-Watt University/DSG3
[email protected];
[email protected];
[email protected];
[email protected];
[email protected]
Abstract- Recent trends show an increasing number of weblabs, implemented at universities and schools, supporting practical training in technical courses and providing the ability to remotely conduct experiments. However, their implementation is typically based on individual architectures, unable of being reconfigured with different instruments/modules usually required by every experiment. In this paper, we discuss practical guidelines for implementing reconfigurable weblabs that support both local and remote control interfaces. The underlying infrastructure is based on reconfigurable, low-cost, FPGA-based boards supporting several peripherals that are used for the local interface. The remote interface is powered by a module capable of communicating with an Ethernet based network and that can either correspond to an internal core of the FPGA or an external device. These two approaches are discussed in the paper, followed by a practical implementation example. Keywords: Weblabs, FPGAs, reconfigurable systems, remote labs, remote experimentation.
I.
INTRODUCTION
Weblabs are becoming a widely used resource for supporting technical courses, allowing students to interact with real equipment from everywhere and at anytime without physically being present in a classical lab. This new type of labs are an added value for education, enabling to include more practical work and giving students the ability to repeat the experiments done in classical labs. Among others, two aspects have been contributing to increase the number of weblabs implemented at universities and schools, namely the technological evolution that causes several instruments to be factory-equipped with Ethernet physical interfaces, and the increasing number of students in technical courses, requiring more labs to be available for their practical training, which may pose economical constraints for institutions. Commonly less expensive than a classical lab, which requires several workbenches for students training, the implementation of a weblab infrastructure may also became expensive depending on the cost of the adopted equipment. Besides increasing flexibility and costs savings, other advantages should also be pointed to weblabs, namely the contribution they bring for increasing collaboration among institutions by enabling knowledge sharing in specific areas. All these aspects contribute to the number and variety of weblabs available
today, although a large majority is focused in engineering courses [1,2,3,4]. Typically each weblab infrastructure is developed following specific and distinct technical implementations, with several hardware and software architectures that use different programming languages to remotely control the equipment [5,6,7]. These aspects are impairing a higher proliferation of weblabs in different areas, while the difficulties of reusing and interfacing different modules used in their infrastructures are decreasing the collaboration among institutions. To overcome these problems, some authors have being proposing generic software and hardware architectures [8,9], but more efforts and contributions are needed. We contribute to this endeavor by proposing a reconfigurable infrastructure, focused at the hardware level, which allows creating, sharing and reusing instruments and other experiment-related modules. Section II discusses a set of guidelines on how to create reconfigurable weblabs infrastructures capable of reusing different instruments and modules. Section III presents two approaches that allow remotely controlling and monitoring those infrastructures and describes an architecture for sharing instruments and modules typically used in weblabs. Section IV describes an implementation of an FPGA-based weblab infrastructure, and section V presents the web interface developed for controlling the implemented infrastructure. Section VI concludes the paper. II.
HARDWARE SPECIFICATION GUIDELINES
To increase weblabs acceptance, two aspects must be considered regarding their implementation: • costs are minimized; • a flexible reconfigurable architecture is adopted. Nowadays, weblabs include PCs with several individual instruments connected through instrumentation buses like PXI (PCI eXtended to Instrumentation), GPIB, and more recently with LXI (LAN eXtensions for Instrumentation). Although these architectures guarantee high performance by using dedicated instruments, they are expensive and require several hardware/software modules with specific functions eventually not necessary for some experiments. To reduce expenses and to target a universal architecture for implementing weblab infrastructures with reconfiguration capabilities, two devices must be considered: μC/μPs
consumption reconfigurability I/O pins
μC/μP low/medium (depends on the μC/μP) low good few/medium
hardware architecture
rigid and not able of changing
price
reconfiguration languages processing rate
manufacturer dependent (assembly) typically very high
FPGA lower/medium (depends on the FPGA) low very good many many logic ports able to be interconnected to define several hardware architectures (e.g. μC/μP) may use standard hardware languages (VHDL or Verilog) medium/high
Considering a weblab containing several independent measurement instruments and specific devices controlled by PCs running as WebServers, which require a certain accommodating space, an alternative solution based on FPGAs would not only reduce the total cost but also the space for accommodation, as several instruments could be implemented inside a single FPGA. The existence of soft and hard TCP/IP cores for FPGAs, supporting the interconnection to the internet, promotes the adoption of FPGAs as the main hardware device for implementing a typical weblab infrastructure able to be remotely accessed for controlling/monitoring an UUT (Unit Under Test), as illustrated in figure 1.
FPGA
Internet
UUT
Fig. 1. Conceptual weblab infrastructure using FPGAs.
If a weblab requires several instruments to control/observe an UUT, it may happen that a single FPGA does not have sufficient space or resources to accommodate all of them. To overcome this limitation, two approaches may be followed: a) using one FPGA able to be reconfigured with several instruments/modules; or b) use one FPGA for each instrument/module; Although the second approach is technically easier to implement than the first one, since instruments/modules defined by cores are implemented in different FPGAs without requiring specific routing tasks inside them, costs may increase together with the required space to accommodate the infrastructure, when compared to the first approach that uses one FPGA to accommodate all the instruments/modules. These two solutions are illustrated in figure 2. FPGAs
FPGA Multimeter
Dedicated Controller
Multimeter Function Generator
TABLE I DIFFERENCES BETWEEN µC/µPS AND FPGAS
users
Oscilloscope
(Microcontrollers/Microprocessors) and FPGAs (Field Programmable Gate Arrays). Although μC/μPs have well defined hardware architectures with high processing rates and functionalities changing according to software, they don’t have the same flexibility guarantied by FPGAs. Each FPGA may be reconfigured with several cores specifying μC/μPs, instruments and dedicated controllers required for every weblab, given them more reconfiguration capabilities than μC/μPs. Cores are specified in hardware languages, schematic files or state-diagrams parsed and simulated by specific manufacturer dependent IDEs (Interface Development Tools) that generate bitstream files used to reconfigure an FPGA. The design options for μC/μP-based circuits, in terms of programming languages and associated tools, are much larger than those available for FPGA-based circuits, where typically VHDL and Verilog are adopted by all IDEs. Therefore, spite μC/μP represent a good choice for implementing reconfigurable weblab infrastructures, they are not flexible as FPGAs, which can support several instruments/modules inside. These can range from simple ones to others with high processing demands, able to run in multitasking, all specified in standard languages that may be shared by all weblab infrastructures. Table I summarizes some relevant aspects that promote the use of FPGAs, instead of μC/μPs, to implement reconfigurable weblab infrastructures.
a) single FPGA for several modules/instruments
UUT UUT
Function Generator
FPGA b) one FPGA for each module/instrument
Fig. 2. Solutions for implementing instruments/modules on an FPGA-based weblab infrastructure.
Referring to solution a), suppose that in a specific instant the FPGA encapsulates a multimeter, a function generator and a dedicated module to control/monitor the UUT. If an oscilloscope is required to acquire a signal from the UUT and the FPGA doesn’t have enough space for its encapsulation, a reconfiguration process can solve the problem through two possible options: • Total Reconfiguration or; • Partial Reconfiguration (Static or Dynamic). In the first option (Total Reconfiguration) using a new instrument requires reconfiguring all the FPGA by stopping its operation. This may be an uninteresting option for experiments using many instruments at the same time, since it requires stopping the weblab operation for changing them. Moreover, depending on the complexity of new instruments/modules and on current FPGA configuration, this option typically requires more time to reconfigure the weblab than the second one [10]. Therefore, the second option (Partial Reconfiguration) may be more appropriated if one needs many instruments to conduct an experiment, since it allows reconfiguring only part of the FPGA with one or more
TABLE II FPGA RECONFIGURATION OPTIONS
III.
REMOTE ACCESS
Typically the weblab should use several instruments/modules, each one requiring a web interface for remote control/monitorization. All instruments/modules and their web interfaces must be shared, so the entire community may reuse them to easily create new remote experiments by reconfiguring the weblab infrastructure. To fulfill these requirements, figure 4 presents a general view of an architecture that allows distributing all instruments/modules and the web interfaces. web interfaces for each instrument/module
web server web server
a configuration memory block is changed
requires stopping the operation (e.g. Cyclone - Altera)
requires stopping the operation (e.g. Spartan3- Xilinx)
does not require stopping the operation (e.g. Virtex4 - Xilinx)
low FPGA prices
medium FPGA prices
high FPGA prices
Since it only works with digital I/O signals, a simple FPGA is not sufficient to implement a weblab infrastructure, requiring A/D and D/A converters to acquire/supply analogue signals from/to the UUT. Furthermore, the analogue signals may have voltages and currents levels not compatible with the converters, which require power drivers to interface the FPGA and the UUT. To accomplish some of these requirements, there are nowadays many FPGA-based boards bringing more components associated with the FPGA, as exemplified in figure 3, namely A/D and D/A converters, memories, LCD displays, interface ports, etc. [11]. Static-Partial-Reconfiguration Spartan-3E
Dynamic-Partial-Reconfiguration Virtex5
Fig. 3. Examples of FPGA-based boards.
On top of all the potentialities offered by FPGA-based boards, a specific architecture is still required to enable
Instruments/ modules files main web interface
Partial reconfiguration Static Dynamic some FPGAs may implement
Total reconfiguration all FPGAs implement the entire configuration memory is changed
accessing the experiments and to reconfigure remotely the weblab infrastructure with the required instruments/modules. For interfacing them to the internet, allowing the remote control/monitorization of the UUTs, specific web interfaces should be provided to users and specific modules should also be integrated within the weblab infrastructure.
mobile phones, PDAs, smart phones or PCs
Internet
Ethernet PHY
devices, without changing the others inside. Two alternatives are available for Partial Reconfiguration: a) Static or b) Dynamic. Static Reconfiguration requires stopping the FPGA to change an instrument/module. In contrast, if Dynamic Reconfiguration is adopted, an experiment my keep running even if an instrument/module is changed. So, assuming we wanted to use the oscilloscope in the weblab, only a logic space would be reconfigured without affecting the rest of it, eventually the one occupied by an instrument not in operation in that instant (e.g. replacing the multimeter). Besides the high complexity of Partial Reconfiguration, the costs involved are also higher than Total Reconfiguration, because not all FPGAs support this option. Moreover, adopting Partial Reconfiguration requires knowing the present configuration inside the FPGA to rearrange the logic resources and to free the space for the new instrument/module [10]. Table II maps the main differences between these options.
weblab infrastructure
Fig. 4. Distributed architecture proposed for FPGAs-based weblabs.
To implement this architecture, at least one main web interface must be available from the weblab infrastructure working as a bridge to other resources. This interface should provide services for transferring all modules/instruments files into the FPGAs and for accessing the web interfaces, used by each instrument/module, namely for downloading them from the WebServers into the user’s devices (PC, PDA, mobile phone or smart phone). With this solution, the amount of available memory in the FPGA-based board is not relevant, since all applications will be distributed among different servers. At the same time, this architecture facilitates the cooperation among institutions, allowing them to share modules/instruments that may be reused for conducting new experiments. The remote access to this infrastructure requires implementing specific modules together with the FPGAbased board. For this purpose there are two approaches that may be adopted: • Hybrid Approach, by using an independent Micro Web Server (MWS) connected to the FPGA-based board; • System-on-Chip (SoC) Approach, by using a TCP/IP core inside the FPGA. A. Hybrid Approach The Hybrid Approach uses a MWS connected to an FPGAbased board, as illustrated in figure 5. Inside this MWS or in the web server, an interface, implemented in any web software language (e.g. HTML or JAVA), is available for
JTAG
modules/ instruments
The user typically downloads the interface from the MWS to his/her accessing device, and controls/monitors the MWS pins. Some of these work as switching I/O signals, while others control the JTAG infrastructure. Commonly, this test infrastructure is used to reconfigure an FPGA and should also be adopted if the number of pins required to monitor the FPGA is higher than those available in the MWS. Using the remote experiment interface, users may control the instruments/modules inside the FPGA that will send or receive data from/to the UUT using the A/D, D/A converters or the digital I/O signals. The advantage of this approach is related to the implementation simplicity since there are already several MWS available in the market whose offer is expected to grow in the near future. Noteworthy, some MWS are internally built with FPGAs, which evidence the power and wide acceptance of these devices for building microelectronic circuits [12]. Based on a web research, table III presents some commercial MWS. TABLE III SOME COMMERCIAL MICRO WEB SERVERS Product(s) XPort AR; Micro100 CS8900A-H PICDEM.net™ 2 USB/Ethernet Module SB70LC Serial.-Eth. SBC65EC
modules/ instruments
D/A A/D I/O
FPGA-based board
Analog
Digital
UUT
UUT
Fig. 5. Hybrid Approach for remote accessing weblab infrastructures.
Company Lantronix Olimex Microchip Cyan NetBurner Modtronix
TCP/IP CORE
Internet
Analog
Digital
illustrated in figure 6, the TCP/IP core will send/receive commands through the internet to control/monitor all modules/instruments inside the FPGA.
Ethernet PHY
D/A A/D
FPGA-based board
I/O
Micro Web Server
I/O
Internet
Ethernet PHY
Digital I/O
I/O
users, so they can access the infrastructure. Connecting the MWS to the Internet, through the Ethernet Physical interface (PHY), allows controlling/monitoring the UUT using a set of I/O signals or the JTAG interface, typically available in all FPGA-based boards.
Website http://www.lantronix.com/ http://www.olimex.com/ http://www.microchip.com/ http://www.cyantechnology.com/ http://www.netburner.com/ http://www.modtronix.com
Fig. 6. SoC Approach for remote accessing weblab infrastructures.
All commands are sent using a specific web interface that should be available from the FPGA memory or from an independent memory located in the FPGA-based board. Once downloaded to the remote accessing device, the interface allows the user to control/monitor the UUT through a set of I/O pins (digital or analog), in the same way as in the Hybrid Approach. At least two options are available for implementing the SoC approach: a) using an independent TCP/IP core, or b) using a TCP/IP core dependent of a commercial μC/μP core. Usually in both solutions TCP/IP cores are sold by companies, however, using a solution dependent of a μC/μP core will not guarantee platform independence, required for a weblab infrastructure, since they only work with a specific μC/μP embedded as a soft/hard core inside the FPGA. A solution based on an independent TCP/IP core is preferred because it is usually available in a standard hardware language allowed to be used by any IDE for reconfiguring the FPGA (usually the manufacturer supports the required changes to adapt the core for a specific FPGA). From a web research, table IV presents several TCP/IP cores, where only Xilinx provides a μC/μP dependent core, and only OpenCores provides a core free of charge. Since low prices and high flexibility are the main goals for building the weblab infrastructure, we consider this last option to be the most appropriated one, because it is free, independent of any μC/μPs, and has already been tested by several users, as described in the indicated website. TABLE IV SOME AVAILABLE TCP/IP CORES
Typically, each MWS allows users to establish a web connection to control/observe its I/O pins, and some provide several internet services like: FTP, HTTP, SSH, Telnet, among others. However, this architecture requires at least two devices (FPGA + MWS), and each MWS has specific characteristics hampering their adaptation to different weblab infrastructures (it may require many software changes). Therefore, depending on the MWS choice, prices may be much higher and flexibility may be lower compared to the SoC Approach. B. SoC Approach In this approach a MWS is no longer required, since the FPGA will have a TCP/IP core implemented inside. As
Company
Products example
IP Cores
WPA2 802.11i for WiFi
Website http://www.ipcores.com/
System Level Sarance OpenCores Xilinx HiTech Global CAST Aurora
IPETH100M-Eth. MAC High Speed Ethernet IP Eth. MAC 10/100 Mbps OPB / Lite, PLB EMAC
http://www.slscorp.com/ http://www.sarance.com/ http://www.opencores.org/ http://www.xilinx.com/
DMAC-10/100 Ethernet
http://www.hitechglobal.com/
MAC-L10/100 Eth. Lite SSN8006: Eth. MAC
http://www.cast-inc.com/ http://www.auroravlsi.com/
Nevertheless, the SoC Approach is harder to implement since instruments/modules inside the FPGA must be attached
to the TCP/IP core. Furthermore, remote reconfiguration is more difficult compared to the Hybrid Approach because it is necessary to use the TCP/IP core module already inside the FPGA to reconfigure the other instruments/modules, which requires the use of Partial Reconfiguration. To demonstrate the viability of the suggested solutions we implemented, in a FPGA-based board, a function generator (FG) as this instrument is typically used by every electronic experiment. IV.
IMPLEMENTED PROTOTYPE
The FG was described as a set of Verilog modules synthesized and mapped into an FPGA. The FG can be controlled both locally and remotely through the web, using Total Reconfiguration without the remote reconfiguration capability (that should be a request in future developments). For this purpose we selected the Lantronix MWS [13] to control remotely, through a set of I/O pins, the FG implemented into a Spartan 3E FPGA-based board. Figure 7 presents the implemented infrastructure and an oscilloscope attached to the FPGA-based board used to monitor the selected waveforms. Oscilloscope
MWS
• • • • • •
Push button 3 allows specifying the time scale factor (from 0 to 7) when triangular waveform is selected (all the other waveforms don’t use the time scale factor); The knob button allows increase/decrease the time scale of each waveform; LEDs 1 and 2 indicate which is the selected waveform (sinusoidal, triangular, DC or square); LED 3 indicates if the FG is able to be controlled remotely or locally; LED 4 indicates if a local or a remote user made a change in the time scale by changing the knob button (this LED will turn on/off on every knob change); The LCD indicates the state of the FG: selected wave, time scale factor (only for triangular waveform), the time scale indicated by the knob value (in percentage), and remote/local control. push button 2
knob button push button 3
push button 1
waveform type
time scale factor selected
control mode
LED 4
LEDs 1,2 and 3
time scale percentage
Fig. 8. Physical interfaces used to control locally the function generator.
FPGA-based board
Fig. 7. Implemented weblab infrastructure based on the Lantronix MWS and on the FPGA-based board Spartan-3E from Xilinx.
The implemented instrument follows therefore the hybrid approach described in the previous section. The MWS provides the resources for implementing the remote control interface while the several ports and peripherals supported by the FPGA-based board are used for implementing the local control interface. A. Local control The local control/observation is made through push buttons, a knob button, LEDs and an LCD display, as illustrated in figure 8. The local control features may be summarized as follows: • Push button 1 allows selecting a sinusoidal, triangular, DC or square waveform; • Push button 2 allows changing the type of control: local or remote;
B. Remote control All FG features can be remotely controlled using a set of commands available in the Lantronix MWS that can change and monitor the state of each one of its 8 I/O signals. This number is insufficient to directly control/monitor all the FG features so it was necessary to define a communication protocol based on two groups of signals: • A Data Bus with 4 input/output signals used to read/write data from/to the FG; • A Control Bus with three output signals that define the meaning of values available in Data Bus and an RW signal that defines the Data Bus lines as outputs (RW=1) or as inputs (RW=0); Each signal corresponds to a physical pin, defined as an output or as an input, that connects the MWS to the FPGA, as illustrated in table V. TABLE V CONNECTIONS BETWEEN LANTRONIX AND THE FPGA-BASED BOARD Pins Lantronix 8 (out) 9 (out) 10 (out) 11 (out) 1 (in/out) 2 (in/out) 3 (in/out) 4 (in/out)
FPGA A6 (in) B6 (in) E7 (in) F7 (in) B4 (in/out) A4 (in/out) D5 (in/out) C5 (in/out)
Name
ControlBus [0] ControlBus [1] ControlBus [2] RW DataBus [0] DataBus [1] DataBus [2] DataBus [3]
For selecting remote control/monitorization, users must either press push button 2 or send a command through the Lantronix. Tables VI and VII summarize the implemented protocol according to the value of the RW signal, respectably.
interface hiding the sequence of commands/data sent to/received from the Lantronix MWS.
TABLE VI
A PDA web interface was developed through a collaboration agreement between our lab (CIETI/LABORIS) and an M.Sc. student from Heriot-Watt University (Scotland). During the development a Telnet connection was provided to access the weblab and an IP webcam was used for returning an image of the infrastructure plus an image of an oscilloscope attached to the output of the FG, allowing the student to have a visual feedback of all remote actions. The interface was developed for the PDA HP iPAQ 214 [14] with a compatible JVM named NSICOM CrEme™ (Java™ Enabler for Windows CE) [15] that provides some additional tools to seamlessly integrate with the Netbeans IDE tool [16] used during the development. Since the web interface was developed for a PDA (typically with a lower processing power than a PC), only light Java packages were used (e.g. Java AWT interface was adopted rather than Java Swing that is more appropriated for the J2SE). Furthermore, due to PDA screen limitations, it was also decided to have two distinct web interfaces for accessing the FG: one for controlling and another for monitoring, as illustrated in figure 9. Users may switch between the control/monitor web interfaces using the corresponding button located at the bottom of each interface. The Control web interface allows selecting the waveform, the time scale factor, and the time scale, by changing the slide bar. The Monitor web interface provides an image of the weblab and all information regarding the current operation of the FG (waveform selected, the scale value and the time scale factor).
IMPLEMENTED PROTOCOL TO CONTROL THE FG (RW=0) Control Bus [0] [1] [2] 0 0 0 0 0 1 0 1 0 1 0 1
Definition
waveform control type (remote/local) knob control (time scale) time scale factor
[3] -
Data Bus [2] [1] ΔB -
[0] Δ Δ ΔA Δ
TABLE VII IMPLEMENTED PROTOCOL TO MONITOR THE FG (RW=1) Control Bus [0] [1] [2]
Data Bus [3] [2] [1] [0] DC wave 0 0 square wave 0 1 0 0 0 triangular wave 1 0 sin wave 1 1 remote contr. 1 0 0 1 local contr. 0 0 1 0 knob [11:8] (time scale) x x x x 0 1 1 knob [7:4] (time scale) x x x x 1 0 0 knob [3:0] (time scale) x x x x 1 0 1 time scale factor x x x Note 1: In table VI all pins in Lantronix must be defined as outputs; Note 2: In table VII pins 1, 2, 3 and 4 in Lantronix must be defined as inputs; Note 3: Δ means that a transaction low to high will change the waveform, the control type or the time scale, depending on values presented in ControlBus; Note 4: ‘x’ means logic levels 0 or 1; Note 5: ‘-‘ means don’t care; Note 6: ΔA and ΔB represents a sequence transition of signals DataBus[0] and DataBus[1] for increasing or decreasing the time scale. Definition
The set of commands provided by the Lantronix Telnet server allowed remotely controlling all the I/O signals for testing the protocol, as illustrated in table VIII, which exemplifies the process of changing a waveform.
V.
THE DEVICE WEB INTERFACE
TABLE VIII EXAMPLE OF COMMANDS SENT FOR CHANGING A WAVEFORM >enable
(cpm)#set cp10 0
(enable) #cpm
(cpm)#set cp11 0
(cpm)#set cp8 as output
(cpm)#get cp1 1
(cpm)#set cp9 as output
0 (0x00000000)
(cpm)#set cp10 as output
(cpm)#set cp1 0
(cpm)#set cp11 as output
(cpm)#get cp1 1
(cpm)#set cp1 as output
0 (0x00000001)
(cpm)#set cp8 0
(cpm)#set cp1 0
(cpm)#set cp9 0
Since the protocol allows controlling and monitoring the weblab, it was necessary to previously define the direction of each I/O line. As exemplified in figure 9, the first commands define the direction of the Control and Data Bus, while the subsequent commands allow changing the FG waveform. To save remote users from understanding the protocol in order to control the FG parameters we developed a simple web
Fig. 9. Control/Monitor web interfaces for controlling/monitoring the FG.
Every command sent to the weblab infrastructure should give some feedback so users may get the guarantee that each command was really done remotely. So, by changing the slide bar, the percentage and the value of the time scale will be displayed. Button scale, wave or the control/remote button, used to change the control type (remote or local), will become
green, if the action made remotely was done correctly, or red, if some error occurs. Besides the technical challenge for developing the web interface, requiring knowledge in web programming, software architectures and usability web design procedures, it was also very important for the student to understand the implemented protocol for controlling the FG. As the protocol was defined from the scratch it was necessary to write a technical document with all protocol details, and several e-mails were also exchanged for clarifying some aspects. Moreover, if another instrument/module would be developed, the described protocol could not be adapted. Therefore, the difficulties posed by this collaboration and the strict protocol avoid its adoption to other instruments. We believe that adopting a Std. interface like the IEEE 1451.0 [17,18], which defines a set of open, common, network-independent communication interfaces for connecting transducers, will facilitate the implementation and sharing of different instruments/modules, in a compatible weblab infrastructure. VI.
CONCLUSIONS AND FUTURE WORK
The increasing number of technical courses requires more lab facilities for student’s practical training. Aiming to reduce expenses and promote flexibility in the conduction of remote experiments, recent trends show an increasing number of weblab infrastructures justified by the spreading of internet services and technical instruments able to be remotely accessed. However, weblabs do not follow any standard for their implementation, the equipment used is expensive and their features are not able to be changed for specific experiments. The solution presented in this paper proposes a new concept for implementing weblabs based on the FPGA reconfiguration capabilities, which enable to accommodate different instruments and modules required by the current experiment (oscilloscopes, function generators, multimeters, etc.). By following this approach, i.e. using an FPGA-based board able to be accessed remotely, institutions and students may redefine different experiments reusing the instruments/modules defined through hardware languages. Based on this approach, a function generator was created (in Verilog hardware language) able to be controlled locally and remotely using an FPGA-based board and a MicroWebServer. The local access is provided through a set of physical interfaces in the FPGA-based board, and the remote access is provided using a specific web interface for a PDA-type client. For remote controlling the FG, a specific protocol was defined and a technical document with its description was shared for developing the web interface. The use of a specific protocol posed some difficulties during the development, and it is not compatible with other instruments that may be developed in the future. Therefore, based on the acquired experience, we believe that adopting the IEEE 1451.0 Std. for interfacing the instruments/modules, will facilitate the development process in a cooperation
framework. We plan to develop other instruments commonly used in electronic experiments by following the referred Std. from the early specification phase. REFERENCES [1] [2] [3] [4] [5]
[6] [7]
[8]
[9]
[10]
[11] [12]
[13] [14] [15] [16] [17] [18]
Jing Ma and Jeffrey V. Nickerson, “Hands-On, Simulated, and Remote Laboratories: A Comparative Literature Review”, ACM Computing Surveys, Vol. 38, No. 3, Article 7, September 2006. Massachusetts Institute of Technology (MIT), “The MIT Microelectronics WebLab”, 2005. Available at: http://ilab.mit.edu/ServiceBroker/ accessed on April 27th, 2009. University of Deusto, “Weblab@University of Deusto”, 2009. Available at: http://weblab.deusto.es accessed on May 11th, 2009. Faculty of Engineering-University of Porto (FEUP), “FEUP Labs”, 2007. Available at: http://elabs.fe.up.pt/ accessed on April 27th, 2009. C. Gravier, J. Fayolle, B. Bayard, M. Ates and J. Lardon, “State of the Art About Remote Laboratories Paradigms - Foundations of Ongoing Mutations”, International Journal of Online Engineering (iJOE), Vol. 4, No. 1 2008. C. Mergl, “Comparison of Remote Labs in Different Technologies”, Vol. 2, No. 4 Special Issue 20 years of LabVIEW, 2006. Javier García-Zubia, Pablo Orduña, Ignacio Angulo, Jaime Irurzun and Unai Hernández, ”Towards a Distributed Architecture for Remote Laboratories”, Remote Engineering and Virtual Instrumentation (REV’08), June, 23rd–25th Dusseldorf, Germany, 2008. Rui Marques, Jaime Rocha, Silviano Rafael, and J. F. Martins, “Design and Implementation of a Reconfigurable Remote Laboratory, Using Oscilloscope/PLC Network for WWW Access”, IEEE transactions on industrial electronics, Vol. 55, No. 6, June 2008. Awkash Agrawal, Sanjay Srivastava, “WebLab: A Generic Architecture for Remote Laboratories”, 15th International Conference on Advanced Computing and Communications (ADCOM 2007), 18-21 December 2007. Manuel G. Gericota, Gustavo R. Alves, Miguel L. Silva and José M. Ferreira, "Run-Time Management of Logic Resources on Reconfigurable Systems", Proceedings of the Design, Automation and Test in Europe 2003 Conference and Exhibition (DATE'2003), Munchen, Germany, pp. 974-979, March 2003. Spartan-3E and Virtex-5 FPGA Families Starter Kits, Available in: http://www.xilinx.com/products/devboards/ accessed on April 27th, 2009. S.Cuenca, A. Grediaga, H. Llorens and M. Albero, “Performance Evaluation of FPGA-Embedded Web Servers”, 14th IEEE International Conference on Electronics, Circuits and Systems (ICECS 2007), 11-14, pp.1187–1190, December 2007. XPort AR Evaluation Kit, Available in: http://www.lantronix.com/device-networking/embedded-deviceservers/xport-ar-evaluation-kit.html accessed on April 27th, 2009. PDA HP iPAQ 214. Available in: http://www.hp.com/ accessed on April 27th, 2009. CrEme™ - The Java™ Enabler for Windows® CE. Available in: http://www.nsicom.com/ accessed on April 27th, 2009. NetBeans IDE. Available in: http://www.netbeans.org/ accessed on April 27th, 2009. Song, E.Y. and Kang Lee, “Understanding IEEE 1451-Networked Smart Transducer Interface Standard”, IEEE Instrumentation & Measurement” Magazine 11, April 2008. Kang Lee, et. al., “IEEE Std 1451.0™ - IEEE Standard for a Smart Transducer Interface for Sensors and Actuators - Common Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats”, 21 September 2007.
