Bureaucrats, dave_user, Administrators
8,154
edits
Changes
no edit summary
{{Applies To Bora}}
{{Applies To BoraX}}
{{AppliesToBORA_TN}}
{{AppliesToBORA_Xpress_TN}}
{{InfoBoxBottom}}
From the functional point of view, it is required to (FR denotes a functional requirement):
*<span id="FR1">[FR1]</span> acquire two independent video streams
*<span id="FR2">[FR2]</span> mix the input stream streams and visualize them on a HDMI monitor
*<span id="FR3">[FR3]</span> visualize informational and statistical data on a 7" LVDS TFT LCD.
Safety requirements (SR for short) are:
*<span id="SR2">[SR2]</span> once started, video processing chain must be independent from the software running on PS, that is it must keep operating even in case software running on PS hangs.
The implementation combines different techniques that are available on Zynq platform, to implement a hardware/software partitioning scheme meeting these requirements.
==Implementation==
At top level, the natural PS/PL [2] partitioning has been exploited: the video processing chain is entirely implemented in the PL, while PS domain is used for initializing, supervising and informational data visualization. The following section describes in more detail the actual implementation.
[1] At the time of this writing not all of the shown modules have been completed.
[2]
PS (Processing system): indicates the dual Cortex-A9 block.
PL (Programmable logic): indicates the FPGA fabric, including Logic Cells, DSP modules, BRAMs, clock resources etc.
===PL subsystem===
PL subsystem integrates several functional modules. The video processing chain is described first, as it represents the most important part of it.
Video frames encapsulated in AXI4 streams are then stored - by AXI-VDMAs not shown in the picture - in two independent buffers, both implemented on SDRAM bank #1 (this 16-bit wide bank refers to U14 component of BoraEVB board). Frames are then retrieved by AXI-VDMAs from these buffers and are forwarded to [http://www.xilinx.com/products/intellectual-property/ef-di-osd.html Xilinx On-Screen Display LogiCORE IP block] (named ''video mixer'' in the diagram) that mixes them. The resulting stream in processed by ''LCD controller #1'' module that converts it to TMDS signals feeding the external monitor.
The ''latency gauge'' module is used to perform video latency measurement. Specifically, it is used to measure the time it takes a frame takes to traverse the entire video chain, from the input to the output interface.
To satisfy requirement [[#FR3|[FR3]]], a second controller (''LCD controller #0'' in the diagram) is instantiated, feeding a 7" LVDS LCD. LVDS signals are generated by the FPGA directly.
===Video latency and SDRAM arbitering===
Applications that are based on such a video processing chain, often have a an additional performance requirement in terms of video latency [1]. For this reason the ''latency gauge'' module has been implemented. It is based on a bank of 32-bit 10ns-resolution timers that allows to measure this latency precisely. This bank - that is encapsulated in an IP - is accessible by PS via AXI-Lite bus in order to expose these measurements for offline manipulation and visualization on 7" display.
Apart from the requirement [[#SR2|[SR2]]], the availability of two independent SDRAM banks provides an advantage in terms of performances too, in particular when video latency is a concern. This configuration, in fact, allows to isolate all the SDRAM traffic related to the video processing chain from all the other traffic originating either in PS or PL domain (i.e. the stream feeding 7" LCD, data read/written by Linux kernel and applications running of top of it, etc.). This solution simplifies management of concurrent SDRAM accesses dramatically, because video processing combined bandwidth requirement (there are four VDMAs accessing the memory simultaneously) is much smaller than the (theoretical) bandwidth provided by the controller/SDRAM subsystem. However, this solution comes at the price of adding a dedicated chip that is interfaced to the FPGA bank #35 [2].
