Monitoring System for Optical Fiber Network Security

Transcription

1 University of Manitoba Department of Electrical & Computer Engineering ECE 4600 Group Design Project Progress Report Monitoring System for Optical Fiber Network Security by Group 04 Alexander Luft Katrina Mae Soriano Pawanpreet K Sidhu Daniel Tweed Lucy Apuugum Academic Supervisor(s) Prof. Sherif Sherif, Ph.D., P.Eng. Industry Supervisors Michael Brown, P.Eng. Norscan Instruments Ltd. Yolande Cates, P.Eng. Norscan Instruments Ltd. Date of Submission January 12, 2015 Copyright 2015 Alexander Luft, Daniel Tweed, Katrina Mae Soriano, Lucy Apuugum, Pawanpreet K Sidhu

2 TABLE OF CONTENTS Table of Contents 1 Introduction Project Progress Graphical User Interface (Alexander) Hardware Abstraction Layer (Lucy) Bus Control Module (Daniel) Data Storage Module (Katrina) Data Acquisition Module (Pawanpreet) Future Work Conclusions References Appendix A Updated Gantt Chart List of Figures 1 Graphical user interface A.1 Updated Gantt chart for the optical monitoring unit project i

3 1 Introduction 1 Introduction The objective of this project is to take an existing monitoring system for fibre optic networks, which was developed by Norscan Instruments Ltd. with LabVIEW, and implement it as a custom embedded system [1]. The project is being developed as a native Linux application running on a BeagleBone Black single-board computer and as custom hardware modules implemented in a field programmable gate array on the LOGi-Bone cape. The hardware modules use the Wishbone bus standard for inter-module communication. Currently, the project is behind schedule approximately two weeks due to delays in some of the hardware modules. The team has developed a strategy and a revised schedule so the project will be successfully completed by the beginning of March. Additionally, there is no planned budget expense for this project as all hardware and development tools are provided by the project sponsor, and no additional funds have been spent. 2 Project Progress The project has been divided into five independent modules along logical functional divisions [1]. These modules are the Graphical User Interface (GUI), Hardware Abstraction Layer (HAL), Bus Control (BCM), Data Storage Module (DSM), and Data Acquisition (DAQ). As outlined in the Gantt chart in Appendix A, the team has completed all preliminary work and design for each of the modules. Implementation and testing is complete for the GUI and the HAL, and underway for the BCM, DSM and DAQ. The GUI and the HAL are ahead of schedule, the BCM is on schedule, and the remaining modules are behind schedule by approximately two weeks due to reasons specific to each modules implementation. These reasons are outlined in the specific modules subsection to follow. The Gantt chart has been revised to reflect the progress made, the current status of the project, future work remaining, and changes to the schedule to make up for delays and get the project completed on time. 1

4 2 Project Progress 2.1 Graphical User Interface (Alexander) The Graphical User Interface (GUI) provides users with control and data display functions and has been developed as a native Linux application written in C++, using Qt Creator, and employing a Qt C++ widget for plotting and data visualization [2]. Qt Creator was selected for the GUI development because of the available plotting and visualization tools, as well as the existing knowledge of C++ by the team members. The GUI implements pipes, which is a Linux standard inter-process communication method, to send commands from the GUI to the HAL, to receive feedback from the HAL, and to receive the raw data from the HAL. Other methods were considered, including threads and shared memory, but pipes were selected because the team members involved are familiar with them and they are easy to implement. The GUI design shown in Figure 1, provides clear access to commands to start, stop or exit the system, visual display of data in a real-time plot, and a command status window. The Settings and About tabs have been inserted as placeholders for future improvements which are not being implemented by this project. Figure 1. Graphical user interface. 2

5 2 Project Progress The design, implementation, and testing of the GUI alone and in communication with the HAL has been completed. The GUI is ahead of schedule and ready for integration and testing with the other modules. 2.2 Hardware Abstraction Layer (Lucy) The Hardware Abstraction Layer (HAL) has been implemented as a user-space driver to provide access for higher level applications to the data received from the hardware systems. The HAL implements the kernel-space driver provided by ValentFX which provides functions to access the LOGi-Bone through a general purpose memory controller [1]. An application program interface has been implemented to allow higher level applications access to the general purpose memory controller functions without directly accessing the kernel space driver or the hardware. Named pipes are used for communication of data and commands between the software applications. Other methods of inter-process communication were considered, such as threads or shared memory, but pipes were selected for their ease of implementation and the knowledge level of the team members. A polling routine is used to check for available data and retrieve the sampled data from the LOGi-Bone in near real-time to avoid overflow of the hardware systems. The design, implementation, and testing of the HAL has been completed ahead of schedule. Testing of the HAL in communication with the GUI has been completed and the HAL is ready for integration and testing with the other system modules. 2.3 Bus Control Module (Daniel) The design of the Bus Control Module (BCM) has been divided into three components: Syscon - System Controller which generates the clock and reset signals; Intercon - consisting of the address decoder, crossbar switch bus connection, and the bus arbiter; and the GPMC-Wishbone Interface - an IP core provided by ValentFX, which was implemented without modification [3]. State machines were designed for both the Intercon and Syscon to meet the specifications outlined in the project 3

6 2 Project Progress proposal. The Syscon was written in Verilog HDL as a custom module using the Xilinx Digital Clock Manager tools to generate the system clock [4]. For the Intercon, direct development of a custom module was determined to be too complex given both the time available and the knowledge and experience level of team members. Three IP cores were evaluated for this component, but were to be for specific applications having a single master and single slave, rather than a general purpose interconnection. Ultimately, the Intercon was adapted from VHDL code generated by the Wishbone Builder application available from OpenCores [5]. Address decoding for the slave devices, bus arbitration, and optional signals which were not being used in this application, needed to be customized. The process of writing test benches to verify the operation of these components was delayed due to the need to learn how to write VHDL test benches. The design and implementation of the BCM has been completed on schedule. Component integration and testing is underway and is expected to be completed on schedule. 2.4 Data Storage Module (Katrina) The Data Storage Module (DSM), which responsible for storing and retrieving of data to and from the SDRAM, is divided into five components: Wishbone Interface, Packet Decoder, Data Flow Controller, Status Register Updater, and SDRAM Controller. State machines were designed for the components to meet the specifications outlined in the project proposal. The components and test benches were implemented in Verilog, although the test benches still need to be refined. An IP core from OpenCores was selected to be used for the wishbone interface and two SDRAM controller IP cores, from OpenCores and Hamsterworks, were evaluated. The Hamsterworks' SDRAM controller was selected as it was developed for use with the LOGi-Pi [6], which uses the same FPGA and SDRAM chips as the LOGi-Bone. The IP core code is also short and simple, making it easier to understand. One problem encountered with the SDRAM controller is that it has only been tested for frequencies up to 100 MHz [6], whereas the specification for the system clock is 133 MHz and the SDRAM controller must be operated at a higher frequency than the system clock. Testing of 4

7 2 Project Progress the SDRAM controller at higher frequencies is still in progress and has led to delays. If results turn out to be negative, the alternatives are to rework the SDRAM controller so that it runs faster than the SDRAM and/or change the frequency of memory access requests or the operating frequency of the system. The design and implementation of the DSM has been completed on schedule but component integration and testing has been delayed due to researching IP cores and additional testing as outlined above. 2.5 Data Acquisition Module (Pawanpreet) The Data Acquisition (DAQ) module is responsible for interfacing with the analog-to-digital converter (ADC) subsystem, provided by the project sponsor, and sending the data to the DSM. The ADC subsystem communicates with the DAQ using the serial peripheral interface. The DAQ acts as both a wishbone master and a slave device to receive commands from the BSM or to send data to the DSM, implementing a first-in, first-out (FIFO) buffer to temporarily store data until it is granted access to the system bus. The major tasks associated with the development of the DAQ are the design and implementation of an ADC interface, the FIFO and FIFO monitoring unit, and implementation of interfaces to the wishbone bus. For the application of the project, a serial interface to the ADC was designed. This interface uses shift registers to capture data from the ADC, which is then stored in the FIFO buffer. The FIFO buffer has been designed with a 2 kilobyte capacity based on the calculated worst case wait time before having bus access. Design of the state machines, ADC interface and FIFO system has been completed on schedule. These components have been implemented in Verilog and testing is in progress. The implementation of the wishbone bus interfaces is still in progress. Overall, this module is behind schedule due to these components being more complex to implement than expected. 5

8 3 Future Work 3 Future Work Future work, which remains for the project, is completion of the implementation and verification of the hardware modules, and module integration and testing. As per the revised Gantt chart in Appendix A, the completion of component implementation and testing has been extended for three weeks to accommodate for the delay and account for potential issues that may arise. System integration and testing between all five modules and project sign-off has been moved forward by one week, to be completed by the beginning of March. To make up for the delay the group will make use of the slack time which was anticipated in the original project schedule. The team is also committing more hours per week and redirecting efforts from modules which are on or ahead of schedule to the delayed hardware modules. 4 Conclusions The decomposition of the project into independent modules which could be developed in parallel has allowed for significant progress to be made. Some delays were encountered resulting from tasks being more complex or taking longer than expected and additional skills needing to be acquired to work with available IP cores. Future work consists of completing the implementation and testing of our hardware components and integrating the modules into a complete system. Although we are behind schedule with implementation and testing of the hardware components, we are ahead of schedule with the development and integration of the software components of our system. Our team will be able to commit more hours per week and divert effort from the software and bus control modules towards ensuring the completion of the hardware modules. With this plan and our revised schedule, which can be found on the Gantt chart in Appendix A, we are confident that the project will be completed by the first week of March. 6

9 REFERENCES References [1] A. Luft, D. Tweed, K. Soriano, L. Apuugum, and P. Sidhu, Monitoring system for optical fiber network security, Department of Electrical and Computer Engineering, University of Manitoba, Project Proposal, September [2] Qcustomplot documentation. [Online]. Available: documentation/index.html [Accessed: October 8, 2014]. [3] J. Piat and M. Jones. (2013) Gpmc-wishbone wrapper, logi-hard. [Online]. Available: github.com/fpga-logi/logi-hard/blob/master/hdl/wishbone/gpmc wishbone wrapper.vhd [Accessed: June 26, 2014]. [4] Xilinx. (2013, December) Spartan-6 fpga clocking resources: User guide. [Online]. Available: guides/ug382.pdf [Accessed: October 5, 2014]. [5] OpenCores. (2013, December) User s manual: Wishbone builder. [Online]. Available: guides/ug382.pdf [Accessed: October 6, 2014]. [6] Hamsterworks. (2013) Simple sdram controller. [Online]. Available: nz/mediawiki/index.php/simple SDRAM Controller [Accessed: December 11, 2014]. 7

10 Appendix A Updated Gantt Chart The Gantt chart shown in Figure A.1 has been revised to reflect the progress made, the current status of the project, future work remaining, and changes made to make up for delays and get the project completed on time. # Task / Milestone Start End September October November December January February March Preliminary Work 2 Component Design and Testing 2.1 Design Packet Decoder 28/09/14 25/10/ DAQ Components 28/09/14 13/12/ Design State Machine 28/09/14 18/10/ Design Interface to ADC 19/10/14 29/11/ Design FIFO Monitoring System 30/11/14 13/12/14 Legend 2.3 Data Storage Components 28/09/14 03/01/ Design State Machine 28/09/14 15/10/14 - Completed Design SD RAM Controller 19/10/14 20/11/ Design Data Flow Controller 30/11/14 03/01/15 - In Progress 2.4 Bus Control Components 28/09/14 13/12/ Design State Machine 28/09/14 11/10/14 - Future Start Design Syscon Module 12/10/14 25/10/ Design Intercon Module 26/10/14 15/11/14 - Delayed Implement GPMC-Wishbone Interface 09/11/14 13/12/ Implement Wishbone Bus Modules 09/10/14 13/01/ Implement Components in Verilog 26/10/14 24/02/ HAL Components 21/09/14 20/12/ Design of the API 21/09/14 25/10/ Implement API functions 12/10/14 15/11/ Implement the LOGiBone driver 16/11/14 20/12/ GUI Components 12/10/14 13/12/ Design GUI mock-ups 12/10/14 08/11/ Get Supervisor Approval of GUI Layout 09/11/14 15/11/ Implement code for GUI 26/10/14 13/12/ Component Integration and Testing 16/11/14 07/02/15 3 Module Integration and Testing 3.1 Integrate Modules and Testing 04/01/15 28/02/ Finalize System and Sign-off 01/04/15 01/04/15 Figure A.1. Updated Gantt chart for the optical monitoring unit project. 8