1. Final Presentation Packet I/O Software Management Application PISMA® Supervisor: Mony Orbach D0317 One-Semester Project Liran Tzafri Michael Gartsbein

2. בלמ"ס Background – Desired System Parallel Processing System Based on Altera FPGA Using Nios core Sampling System PreprocessingSystem Data Stream Analog Input N

3. בלמ"ס Equivalent System Data Stream Parallel Processing System Based on Altera FPGA Using Nios core Parallel accelerator Algorithm MultiCore Embedded System PCI ProcStarII board Based on STRATIX II Data Packages Generator & Flow Management Our Project

4. בלמ"ס Block Diagram PCIBUSPCIBUS Hardware processing Transmitter Reciever Analyzer Software processing Generator The Host Application

5. בלמ"ס The Host Application System flow: System flow: Host Application generates times of arrival (TOA) vector in software The Host App sends the vectors to the hardware system and gets the results The communication is through PCI bus It will also make processing in software The results are analyzed

6. בלמ"ס Project Objectives Programming the Host application, which will generate the data Programming the Host application, which will generate the data  Creating modular design  Defining the interface and protocol to the board with the relevant groups Adding software processing to the Host program for comparison with hardware Adding software processing to the Host program for comparison with hardware Testing simulations results Testing simulations results

7. בלמ"ס Stratix 2 FPGA on Altera board PCI bus Host PC’s fan Tools

8. בלמ"ס Tools   Stratix 2 FPGA Altera board Altera board Gidel’s Proc wizard and IP cores Gidel’s Proc wizard and IP cores … Host PC Host PC Visual Studio 2005 Visual Studio 2005

9. בלמ"ס Host Application Interface Inputs Inputs  Packet noise parameters  Missing elements parameters  Region of interest  Operation mode Outputs Outputs  System throughput  Vectors after hardware or software processing This image is for illustation only

10. Packet Structure : Packet Generator Output * Sync=0x55555555 ID Control BitsLen TOA2 TOAN 64 bits (DWORD) Num TOA=N... Padding (if necessary)=0x55555555 Start TimeNum Params=M TOA1... Param1 ParamM 8 bits Nios Number (For Sw) TypeSw/HwVersionUnused

11. Packet Structure : Packet Receiver Input * *For further details see the Packet Structure document ID Control bitsLen Durat (1) 64 bits (DWORD) Ass1 Num Seq=MNum Assoc=N Ass2…AssN Conf level 1 (1) Sync=0xAAAAAAAA Start Time Num non zero Assoc Unused … Pad=0x55 Finish Time Num pulses (1) Delay (1) Conf level 2 (1)… Durat (M) Conf level 1 (M) Num pulses (M) Delay (M) Conf level 2 (M)[Padding] Sync=0xAAAAAAAA E

12. בלמ"ס Packet Generator\Receiver Interface Inputs Inputs  Was the data series identified  Average period  Number of values assigned to the data series  Indexes of these values Outputs Outputs  TOA vectors of random length between 8 to 1024  Each TOA is a DWORD (32 bits)  Each vector has 1 to 3 data series with a random period between 10 to 10000, and noise  Percentage of noise in each vector is an input to the Host App  Percentage of missing data from each vector is an input to the Host App

13. Host App Operation Modes In order to check the performance of the system, there should be two modes of operation: Correctness test: Checks correctness for finite number of packets Performance test: Packets will be sent continuously, elaborated in next slides

14. API Functions Communication with the board is done using Gidel’s API functions These functions offer a comparatively simple way to send, and receive data from the board These also offer important tools for working with the board, such as resetting it, checking how much data it contains, etc.

15. Packet Send Chain (HW) Packets are generated continuously, by the Packet Generator®. Here, the Packet contains only the data (TOAs), an ID, and the length The Packets are forwarded to the Packetizer®, which adds a “header” and “footer” to the packet, according to the interface

16. Packet Send Chain (Cont.) The Packetizer® then forwards a bit stream to the RxTx entity The data is then sent immediately to the hardware (using DMA and Gidel’s API)

17. Packet Send Chain (SW) – Refers to The SW Processing Entity Packets are generated and Packetized like in HW Those are sent through the SW Rx\Tx entity This entity contains a thread pool, from which it selects an available thread, or waits until one is available The chosen thread gets the stream of data of the packet, and independently processes it

18. Packet Receive Chain (HW) While there is data in hardware, it is read continuously, and stored in a local FIFO The Depacketizer® entity transforms the DWORD stream from the FIFO into packets Performance of the system is checked: number of packets processed compared with the run time

19. Packet Receive Chain (SW) When one of the processing threads is done with a packet, it writes the result to a similar local FIFO as seen in HW The Depacketizer® entity can read data from this FIFO as with the HW chain

20. The SW Processing The software processing entity makes the same manipulations over the input data as the hardware The component is implemented in a code package delivered by the algorithms team This sw package can be replaced if a newer version comes

21. בלמ"ס This page was left blank on purpose

22. בלמ"ס Special Problems Problem: Naming the project with a meaningful name Problem: Naming the project with a meaningful name Solution: Packet I/O Software Management Application (PISMA) Solution: Packet I/O Software Management Application (PISMA) Problem: Integration and synchronicity between different project parts/groups Problem: Integration and synchronicity between different project parts/groups Solution: Defining an all-accepted Interface Problem: Debugging hardware and software simultaneously Problem: Debugging hardware and software simultaneously Solution: Signal Tap, differential diagnosis

23. בלמ"ס Special Problems Problem: 1 MB limit on sending to hardware Problem: 1 MB limit on sending to hardware Solution: Solved Solution: Solved Problem: Hard to measure real performance Problem: Hard to measure real performance Solution: Different tests when each time another part of the system is disabled

24. Installation The detailed installation how-to guide is available in the Final project document Any configuration to the development environment (visual studio etc..) is also documented at the same location.

25. Usage The usage is done by creating configuration files (with the vectors parameters) and passing commands line arguments to the program Details at the final document

26. Data analysis The program outputs (with the processing results) statistics about the time spent in the computations The program creates a log file with the TOAs indices and their associations to a sequence In the hardware run, statistics about the different ICs, or clock ticks spent in HW available

27. Future Development In general, the design of the system allows to add new functionality relatively easily Any part can be replaced or improved

28. Future Development (cont.) New groups (other than the lbs group) can use our sw with their hw New processing hardware (different algorithm or better accelerator) can be tested Improvement to the packet generation algorithm, new features etc Improvement to the packet sending/receiving unit