vertical video flipping using external memory -凯发k8网页登录

this example uses:

this example shows how to design an application to flip an incoming video stream vertically.

you will use external memory to store a video frame to accomplish this task. you can use this technique for designing and implementing other vision applications requiring access to the external memory.

supported hardware platform

xilinx® zynq® zc706 evaluation kit fmc-hdmi-cam mezzanine card

introduction

to flip the incoming video stream from hdmi source (rx), the fpga logic writes the video frames a line at a time to the external memory. later, the fpga logic reads the stored image back, a line at a time in the reverse order, thus flipping the image vertically. the read video frame is then sent to the hdmi out (tx). video frames are stored in a ping-pong buffer in the pl-ddr, which enables independent memory write and read operations. a separate, ps-ddr is used for storing video frames during transfer of data to the hdmi out. the diagram below highlights the overall data flow.

modeling

in the top model, the fpga logic is connected with the external memory and the hdmi in/out blocks.

the model includes the fpga logic. it is linked as a referenced model from the top model. this image shows the contents of the videoflipping subsystem inside the soc_video_flipping_fpga model.

the fpga logic consists of four key components:

axi4 master write controller receives video from hdmi rx and writes the data into ddr. one line of data is written per burst. when one frame finishes, it sends the end of frame (eof) signal to trigger axi4 master read controller.
axi4 master read controller reads the lines of the video frame from the external memory ping-pong buffer in reverse order. one line of data is read per burst. new read requests are paused if the downstream read fifo block is not ready to process data. when a frame is fully read from memory, the read controller waits for the next eof signal from the write controller to start reading in a new frame. if the memory controller doesn't have enough bandwidth, the read controller may be still processing the earlier frame when the write controller finishes writing in the next frame. in this case, the read controller will throw an error using errframedrop signal.
write fifo buffers the data written to the ping-pong buffer when the ddr memory controller asserts the backpressure signal (highlighted red arrow), to allow video data from hdmi source to be processed. the write fifo should be large enough to prevent overflow and accommodate any delay in writing to the external memory. in this example the depth of the write fifo is set to 2048 to accommodate 1 hd line of backpressure.
read fifo buffers the data from the read controller when the dma in the hdmi tx asserts the backpressure signal (highlighted red arrow). the backpressure is propagated to the upstream axi4 master read controller to stop requesting data from ddr. notice that since the axi4 master read controller will not pause during the read burst, it is important to make sure that the read fifo has enough room to store data even after its ready signal de-asserts. in this example, the depth of the read fifo is set to 2048 and the almost full threshold is set to 128. when the fifo has 128 samples, the read fifo sends 'full' signal to upstream block to stop any new read requests. in the meanwhile, it can buffer 2048-128 = 1920 samples without an overflow. the setting is sufficient even for a 1080p frame.

in the hardware implementation, the hdmi tx includes two dma frame buffers and one video timing controller (vtc), for robust and tear free video output. the dmas may send backpressure to dut when the memory controller is busy with other read or write transactions. in the fpga model, the backpressure signal hdmioutputready is set to always true for simulation only (which indicates that the memory controller is always available). in practice, this signal often toggles between high and low. the read fifo block in the dut is used to handle this backpressure.

simulation

the memory bandwidth requirement must be considered when designing an application that interfaces with external memory. what is the rate that you need to transfer data to/from memory to satisfy the requirements of your algorithm? specifically, for vision applications, what is the frame-size and frame-rate that you must be able to maintain?

for the selected zc706 board, pl ddr controller is configured with 64-bit axi4-slave interface running at 200 mhz. the resulting bandwidth is 1600 mb/s. let's first evaluate if the memory bandwidth is sufficient to maintain a 1920x1080p video stream at 60 frames-per-second. as the video format is ycbcr 4:2:2, we require 2 bytes-per-pixel. however, for the dut axi4 read and write, each pixel is zero-padded to 4 bytes, this equates to a throughput requirement of

the calculated throughput satisfies the bandwidth requirement.

to simulate 1080p 60fps case, run the following command and then simulate the model

soc_video_flipping_set_parameters("1080p")

the output is shown as below.

if you want to model another dut accessing the same external memory, you can use memory traffic generator block to simulate the contention before the implementation, so you can save effort on hardware debugging. in this model, two memory traffic generator blocks, contention write and contention read block, are modeled to mimic the axi transactions of another frame buffer. the throughput of two memory traffic generators is calculated as

the total required bandwidth of memory controller is which is less than its maximum bandwidth 1600 mb/s. uncomment contention write and contention read block, simulate the model for 1080p again, the output is teared at the bottom. you will also get assertion by 'soc_video_flipping_fpga/videoflipping/assertion' block that frame get dropped.

simulation shows that memory controller can not meet the bandwidth requirement for the dut and memory traffic generators. you may need to consider reducing the frame resolution, or making dut algorithm more efficient, for example implementing pack/unpack 16bit ycbcr pixel to 32bit, other than zero padding.

the top model runs in accelerator mode by default. if you want to inspect the logged data in logic analyzer, change the top model to normal mode. it is best to simulate with 480p or smaller frame size for faster results.

implementation

following products are required for this section:

hdl coder™

before implementation,

set the simulation mode to 'normal' on the top model.
comment out contention write and contention read blocks.
run this command if the model has been changed for the frame size other than 1080p.

soc_video_flipping_set_parameters("1080p")

to implement the model on a supported soc board use the tool. make sure you have installed required products and fpga vendor software before implementation. to open soc builder click, configure, build, & deploy button in the toolstrip and follow these steps:

on the setup screen, select build model. click next.
on the select build action screen, select build, load and run. click next.
on the select project folder screen, specify the project folder. click next.
on the review memory map screen, to view the memory map, click view/edit. click next.
on the validate model screen, to check the compatibility of the model for implementation, click validate. click next.
on the build model screen, to build the model, click build. an external shell opens when fpga synthesis begins. click next.
on the connect hardware screen, to test the connectivity of the host computer with the soc board, click test connection. to go to the run application screen, click next.

the fpga synthesis often takes more than 30 minutes to complete. to save time, you can use the provided pregenerated bitstream by following these steps.

close the external shell to terminate synthesis.
copy pregenerated bitstream to your project folder by running this copyfile command below.
load the pregenerated bitstream and run the model on the soc board by clicking load and run.

copyfile(fullfile(matlabshared.supportpkg.getsupportpackageroot, ...
 'toolbox','soc','supportpackages','xilinxsoc','xilinxsocexamples', ...
 'bitstreams','soc_video_flipping_top-zc706.bit'),'./soc_prj');

four leds on the zc706 are driven by signals and can be used for debugging the design:

gpio_led_left is driven by axi4 master write data valid. it should be on or blinking when the application is running.
gpio_led_center is driven by axi4 master read data valid. it should be on or blinking when the application is running.
gpio_led_right is driven by write fifo ready. it should be always on, otherwise axi4 write data get dropped.
gpio_led_0 is driven by read fifo ready. it could be on or off. the data won't get dropped in this fifo because the upstream controller will handle this backpressure properly.

conclusion

this example shows modeling of axi4 master interfaces for accessing external memory in random fashion using soc blockset. you can use this technique to model vision applications involving external memory. one such example is which builds further on this example.