Changes

Jump to: navigation, search
no edit summary
Applications that are based on such a video processing chain, often have a 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 memorysimultaneously) 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].
In During the first development of this project, a single-bank version if of the systemhas been tested as well. In this case all the masters that need to access the SDRAM make use of bank #0 and no SDRAM controller is instantiated in PL. Thus all master compete for the unique SDRAM bank. In this case it is pretty ease to create a testbed that saturates the actual available bandwidth. This may lead to clear anomalies such as flickering on display and an abnormal increase of the video latency. Although this configuration can not guarantee to meet requirement [[#SR2|SR2]], it can nevertheless be tailored to overcome these performance issues. The ''QOS-301'' module integrated in Zynq comes to help, as described in <ref name="xapp1266">Mrinal J. Sarmah, Naveen Kumar Gadddipati, ''XAPP1266 Using Quality of Service (QoS) Capabilities in Zynq-7000 AP SoC Devices, v1.0 September 18, 2015</ref>. By configuring proper priorities at ''Memory Interconnect'' level, it has been verified that, even in case of near-to-bandwidth-saturation condition,  unico banco di ram per riduzione costi ma più fragilevideo anomalies disappear.
[1] In this context, video latency is the time a video frame takes to traverse the chain, from the input interface to the visualization device.
[2] Bank #35 is optimized for such connectionsa connection, as described in detail [[Programmable_logic_(Bora)#Routing_information_2|here]].
==Future work==
4,650
edits

Navigation menu