【導(dǎo)讀】基于FPGA的快速圖像處理系統(tǒng)的畢業(yè)設(shè)計(jì)(中英文翻。我們?cè)u(píng)估改進(jìn)硬件軟件架構(gòu)的性能目的是為了適應(yīng)各種不同的圖像處理任。務(wù)這個(gè)系統(tǒng)架構(gòu)采用基于現(xiàn)場(chǎng)可編程門陣列FPGA和主機(jī)電腦PC端安裝LabVIEW. 應(yīng)用程序用于控制圖像采集和工業(yè)相機(jī)的視頻捕獲通過(guò)USB20傳輸協(xié)議執(zhí)行傳。輸FPGA控制器是基于ALTERA的CycloneII芯片其作用是作為一個(gè)系統(tǒng)級(jí)可編。程芯片SOPC嵌入NIOSII內(nèi)核該SOPC集成了CPU片內(nèi)外部?jī)?nèi)存?zhèn)鬏斝诺篮蛨D像。數(shù)據(jù)處理系統(tǒng)采用標(biāo)準(zhǔn)的傳輸協(xié)議和通過(guò)軟硬件邏輯來(lái)調(diào)整各種幀的大小與其。更高的速度和更低的成本的追求其解決方案轉(zhuǎn)移到了現(xiàn)場(chǎng)可編程門陣列FPGA身。電視信號(hào)的處理機(jī)械操縱時(shí)要求非常嚴(yán)格FPGA可以更好的去執(zhí)行當(dāng)需要嚴(yán)格的。部分通過(guò)嵌入的NIOSII處理器進(jìn)行關(guān)聯(lián)并利用USB20作為溝通渠道。SOPC-Builder作為一個(gè)工具駐留在Quartus環(huán)境中其作用是將NIOSII與外。的NIOSII的性能以及電腦主機(jī)與FPGA板之間的USB20傳輸性能現(xiàn)有FPGA的性。的做法就是將數(shù)據(jù)通過(guò)usb返回至電腦主機(jī)再做進(jìn)一步處理成為簡(jiǎn)單的圖像

　　

【正文】 sends the output to the VGA controller via SRAM memory see Fig 7 Alternatively the output can be sent back to the host application by means of a write Nios mand The procedure is repeated with the next captured frame 8 Evaluation of the system performance The above set up was tested with various capture rates and frame resolutions Using several testversions of the SLS USB20 megafunction we measured receive rx and transmit tx throughput between the host PC and the target hardware systemWe use a payload of 307200 bytes for both directions We find that using the Nios II HAL driverthe latest evaluation version 12 of the IP core transfers in high speed operation 65Mbits per second in receive mode and about 80 Mbps in transmit mode In full speed the transfer rate is 9 MbpsHowever data transfer rate from the host puter to the hardware board is only one factor that affects the performance of an image processing system designed according to a hostcoprocessor architecture like the one studied here There are also software issues to be taken into account both at the host end and at the NiosII embedded processor side For example frame capturing and serialization prior to transferring are factors that limit frame rate in video applications On the other hand the NiosII embedded processor controls the data flow following instruction code downloaded to embedded memory as described in Section 5So the overall performance of the system depends on the finetuning of all these factors The LabVIEW software allows for an efficient handling of array structures and also possesses image grabbing and vision tools that reduce processing time on the host side Beside the above software limitations there are also hardware issues related to an integrated SystemonaProgrammablechip like the time needed for Direct Memory Access DMA transactions between units The performance of the hardware board is divided into the processing rates of the hardware filter coprocessor and the performance of the rest of system like external memory buffers and the interconnect fabric This second factor adds an overhead depending on memory clocking and the structure of the interconnect unitsWe evaluate the performance of the proposed architecture taking into account and measuring when possible the following delay times Time to grab an image frame and serialize it Transfer time over the USB20 channel Nominal time needed by the coprocessor filter in order to process the image frame Overhead time needed for data flow and control in the integrated hardware system Table 1 summarizes the response time of the above operations and reports frame rates for two typical frame sizes As a whole the system results in a practical and stable video rate of 20 frames per second at an image resolution of 320 240 pixels Similarly larger frames with dimensions 640 480 pixels can be transferred and processed at a rate of approximately seven frames per second When the board is clocked at 100 MHz the hardware image filter processes a 640 480 pixels frame in a minimum of 31 ms while DMA transfers and other control flow add approximately 30 ms in order to transfer image data between units The frame is transferred from the host puter to the hardware board in approximately 26 ms Other possible latencies include proper data manipulation by the NiosII instruction code and depend on the frame size As a conclusion delays are divided between software and hardware procedures on both sides of the system The hardware filter coprocessor does not substantially delay the overall system performance Host and NiosII processing time and transfer rates over the munication channel can be a bottleneck for large frames Since open core USB20 embedded technology is still developing one may expect it soon to make even better use of the available bandwidth Table 2 summarizes the hardware requirements for the overall system we implemented in this study see also Fig 7 The table reports number of logical elements and memory bits needed to implement the functions presented above in a medium FPGA chipthe Altera Cyclone II EP2C35F672C6 The full potential of this chip is 33000 Logic elements and 480000 memory bits The table also reports clock frequencies for the soft processor and the external DDR2 memory Clocks were implemented by means of two Phase Locked Loops PLLs Fig 7 9 Comparison with other systems In the following we present a parison with other image processing solutions in terms of performance and flexibility In order to establish some numerical parison between the presented architecture and a purely software solution we performed a series of experiments We synthesized designs with variations of the basic filter operations introducing different degrees of putational plexity We also implemented in hardware a Sum of Absolute Differences SAD algorithm for dense depth map calculationswhich is based on correlation operations and is much more intensive putationally than simple convolution We pared the results with the same algorithms implemented in software and running on a Pentium IV processor at 3 GHz with 512 MB RAM Typical results are presented in Fig 10 and summarized in Table 3 The software results were attained by programming analytically the corresponding procedures in NIs LabVIEW languageusing optimized library functions for array processingWe used precaptured AVI video sequences and processed each frame with the same image functions as in the hardware version of the algorithm Frame resolutions of 320 240 and 640 480 pixels were assessed separately since they need different transferring times to our hardware coprocessor Table 3 shows frame rates for processing video files of both resolutions as a function of putational plexityIn the first colum