【正文】 or processing through the high speed USB20 munication channel As described in the next section the host application municates with the USB port using Advanced Programming Interface API calls for data input and output According to Nios processor instructions embedded DMA hardware operations transfer data from memory to the Nios data path and into the hardware task logic by means of the Avalon interface The data stream is processed through the hardware accelerator DMA operations stream the filtered output result from the hardware tasklogic back to external memory see Fig 7 The final result is output to the on board VGA digitaltoanalog channel which is peripheral to the NiosII processor and is supported by embedded DMA hardware transfers However a digital to analog converter for a VGA port is not always implemented on a development board so a possible alternative is the resulting binary image to be channeled back to the host puter via the USB connection for further processing or simply for displayThe assessment of the design performance that is presented in Section 8 includes all the above activity stepsIt is important to note that the above system is not merely a blackbox custom design implemented for a particular application but represents a design methodology that can be used for a wide range of custom applicationsThe technical details of the operations abstracted above are well documented for the user of the particular development platform so that every aspect of the design can be tested for repeatability A more detailed analysis of the system development techniques is however out of the scope of the present article 7 Hostbased setup and application On the host part a vision system is implemented appropriate for a spectrum of industrial applications The host puter is a Windows XP Pentium IV featuring an onboard high speed USB 20 controller and a NI 1408 PCI frame grabber The host application is a LabVIEW virtual instrument VI that controls the frame grabber and performs initial processing of the captured images see Fig 9 The frame grabber can support up to five industrial cameras performing different tasks In our system the VI application captures a full frame sized 640 240 pixels It can produce even smaller frames in order to trade size for transfer rate The LabVIEWhost application municates with the USB interface using API functions and a Dynamic Link Library DLL and transmits a numeric array out of the captured frame An advantage of using LabVIEWas a basis for developing the host application is that it includes a VISION library able to perform fast manipulation of image data or a preprocessing of the image if it is necessary When the reception of the image array is pleted at the hardware board end the system loads the image data to the filter coprocessor and 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 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 240 and 640