FPGA-based Weblab Infrastructures Guidelines and a prototype implementation example

1. FPGA-based Weblab InfrastructuresGuidelines and a prototype implementation example Authors: Ricardo Costa (ISEP/CIETI/LABORIS) (rjc@isep.ipp.pt / http://www.laboris.isep.ipp.pt/rjc ) and Gustavo Alves (ISEP/CIETI/LABORIS), Mário Zenha-Rela (FCTUC/CISUC), Rob Poley (Heriot-Watt University), Campbell Wishart (Heriot-Watt University) ICELIE'2009 Porto, 3-5 November 2009

2. Presentation outline • Introduction • Architectural considerations • Remote access • Implemented prototype • Conclusions and future work

3. Introduction - More labs required for practical work at campus and after classes Provide access to real experiments throughthe web Solutions Create more labs allow students to interact with real equipments from everywhere at anytime without physically being present in a classical lab WEBLABS feature Cost ! status several hardware and software architectures problems use a reconfigurable hardware infrastructure with I&M able to share solution i) - only qualified people are able to develop them; ii) - the adopted instruments and modules (I&M) may be expensive with many features not required; iii) - reusing and interface I&M is not simple + Flexibility/Reuse of I&M - Price + Collaboration

4. Proposal: use FPGA-based Boards Architectural considerations I Typical Weblab architecture:

5. Architectural considerations II • Benefits of using FPGAs for replacing the instruments and the instrumentation server: • costs will be reduced; • reconfiguration capabilities allow implementing different measurement instruments; • and provides modularity and flexibility in the construction of weblab infrastructures. Conceptual weblab architecture using an FPGA

6. Architectural considerations III Two solutions for using FPGAs for implementing a Weblab infrastructure:

7. Remote access I Generic architecture:

8. Remote access II Suggested architectures for the Weblab infrastructures: Hybrid approach SoC approach

9. Remote access III Some solutions available in the market: Hybrid approach SoC approach

10. Implemented prototype I Adopted devices: Spartan-3E starter kit - XILINX A/D and D/A I/O ports Lantronix module (MicroWebserver) LCD display I/O ports Ethernet port Ethernet port

11. Implemented prototype II Implemented weblab infrastructure Function generator

12. Implemented prototype III Physical interfaces used to control the function generator Control / monitor web interfaces for controlling / monitoring the function generator Developed through a collaboration agreement between CIETI/Laboris and an M.Sc. Student from Heriot-Watt University (Scotland)

13. Conclusions Adopting this architecture will: • simplify the creation of Weblab infrastructures; • allow sharing and reusing instruments and modules; • increase collaboration; • - reduce costs.

14. Future work It was necessary to specify a logical interface! Some difficulties appeared during the collaboration because… IEEE 1451.0 Std. Difficulties to understand/explain all details… NO STANDARD !!! It 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. It would be difficult to use the FG on another Weblab infrastructure, based on the presented architecture…

15. THANKS FOR YOUR ATTENTION Ricardo Costa e-mail: rjc@isep.ipp.pt webpage: http://www.laboris.isep.ipp.pt/rjc

16. Architectural considerations – extra • Benefits of using FPGAs for replacing the instruments and the instrumentation Server: • costs will be reduced; • reconfiguration capabilities allow implementing different measurement instruments; • and provides modularity and flexibility in the construction of weblab infrastructures. But…other solution could be the adoption of μps / μcs !!! Conceptual weblab architecture using an FPGA

17. Architectural considerations – extra Why adopting FPGA instead of μps / μcs ?

18. Architectural considerations – extra FGPA reconfiguration options (Total or Partial Static or Partial Dynamic ?):

19. Architectural considerations – extra Example of two FPGA-based Boards solutions from Xilinx:

20. IEEE 1451.0 Std. • IEEE Standard for a Smart Transducer Interface for Sensors and Actuators—Common Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats • (IEEE Std 1451.0™-2007) • - It is the basis to interoperate all members of the IEEE 1451 family enabling the control of trigger and status signals, the operation modes definitions, etc. • - all transducers must implement a TIM (transducer interface module) - the Std. defines all functions performed by TIMs; • all transducers are specified by a TEDS (Transducer Electronic Data Sheets) - the Std. defines all functions to read/write form/to the TEDS; • - Provides a set of Application programming interfaces (APIs) to facilitate • communications with the TIM and with other applications through a NCAP (Network Capable Application Processor).

21. IEEE 1451.0 Std.