Elad Hadar Omer Norkin Supervisor: Mike Sumszyk Winter 2010/11, Single semester project. Date:22/4/12 Technion – Israel Institute of Technology Faculty of Electrical Engineering High Speed Digital System Lab (HS DSL)

Project motivation Implementing a video analysis designs on GIDEL PROCSTAR III platform that will enable usage and exploration of a new development platform (PART I – PROCHILs, PART II – PROCWIZARD, PROCAPI, PROCMegaFIFO ). Proper usage of development tools throughout all stages of implementation from algorithm to hardware. Preparing a clear user-guide that will enable a fast and simple ramp-up of the tools and the appropriate flow.

PROCHILs is a Hardware-In-the-Loop acceleration tool for running Simulink designs on FPGAs. Automatically translate Simulink designs into FPGA code (compatible with the PROC board installed on the target PC) and run it under Simulink.

We have measured the input data processing time of the Hardware generated by ProcHIL and the equivalent Software simulation for different length data vectors. There is a significant acceleration of the processing time using the generated Hardware, especially for longer data vectors.

Ratio between the Hardware & Software running time for different length input vectors An exponential curve fitting will give us that the ratio converges to ~128.

Even when considering the highest processing ratio, we get a rate of which is very low. For 512x512 pixels image it means 1.04 [Frames/Sec] which is insufficient for video streaming. Not suited for applying on streaming data designs (Real-Time designs)

A set of functions that provide the means to access PROC boards by supplying methods that enable real-time configuration and querying of the board. Motivation: Learning and practice of effective debug methodology using PROCAPI while streaming video through an image processing design. PROCAPI allows the user to control data transfer between the PC and the PROC board (using a controllable DMA channels). In PROCHIL this ability is transparent to the user.

Main goals and phases of work 1)Learning PROC API, PROCMegaFIFO 2)Define and build an integrated DSPbuilder design combining PROCAPI video streaming functions, data channels and PROCMegaFIFO memories.

GiDEL PROCAPI (Version 8.8) ALTERA’s DSPBuilder blockset for Simulink (Version 10.1) ProcWizard (Version 8.8) Quartus II (version 10.1) Matlab (Version 2009a) OpenCV (Version 2.1) GiDEL PROCStar III (Altera Stratix III) board (4-FPGA)

System block diagram

Project flow

Prewitt edge detector implementation Controller Prewitt edge detector

Pixel neighborhood storing

Controller

Preventing pipe contamination enableBit and clken are both connected to read_acknowledge from FIFO IN. Data pipeline of the Prewitt edge detector is stages long. When FIFO IN is empty: 1.Stop all data propagation in order to avoid garbage in the pipe that will affect the algorithm correctness. 2.The writing will resume only when a new valid pixel arrives at the end of the data pipeline.

Interrupt control Two inputs: 1.WE - Is FIFO IN empty? 2.AD – Is the arriving pixel the last pixel of a frame? One output: 1.dmaInterrupt

Controller implementation Data may be propagating or stopped. Pixel is not the last pixel of a frame One cycle state interrupt is sent Frame is finished but the FIFO IN is empty  AD is always on until New pixel resets the counter

Interrupt controller

Signal compiler

Quartus

Source & Header files Read Frame Display Frame

C code structure opening camera Setting DMA channels Define new buffers Capturing new frame Write the frame from input buffer to input FIFO Interrupt Show original frame Main function (pre processing) Second thread function (post processing) Loop Write the frame from output FIFO to output buffer Show processed frame Blue-OPENCV function Purple-API function Red-interrupt

Frame Rate We used TIC & TOC macros using OpenCV functions to asses the video output stream frame rate. We did so by measuring time elapsed for presenting 30 frames, And thus concluding frame rate. Full Prewitt edge detector design: 12[fps] Empty design- image capture and present- Hardware: 25[fps] Empty design- image capture and present- Simulink: 23[fps]

Frame loss detection

By creating another version of the Prewitt edge detector, we managed to divide the doubled number back to its value

Time delay We have also noticed a time delay between the original input stream and the filtered one. We had 2 hypotheses to the cause of that delay: The delay was caused by the code complexity, by the multiple loops, memory copying. The delay is caused by the FIFO and its size, due to an accumulation of frames in the FIFO waiting to be extracted. Although we made many optimizations in the C++ code, the delay was not reduced at all. When we reduced the FIFOs size from 8MB to1MB the time delay decreased dramatically from about 3 seconds to less than half a second.

STRATIX III FPGA DSP-Builder based edge detection design Time delay We assumed that FIFO OUT is always near empty, because the extraction of the processed images is not limited by the hardware’s rate (12[fps]), and performed at the high rate that the DMA can accomplish. The delay is mainly because of the time it takes the images to pass through the 1MB FIFO IN at a rate of 12[fps]. That calculates to 4 images delay, and means second delay, as observed by us.

Results & Conclusions Frame rate is satisfying - 12 No frames are lost! Time delay is very low – less than half a second

Useful outputs An implemented template for all video streaming processing algorithms. Only minimal effort is needed to integrate a new algorithm and run it! A full user-guide which enables a fast and simple ramp-up of the tools, summs up all conclusions made and consists of needed background knowledge.