Introduction to the Video Frame Buffer IP
The Video Frame Buffer Read/Write IP allows you to move video data from the memory domain (AXI4-Memory Mapped interface) to the AXI4-Stream interface or vice-versa.
At a high level, it does the same as the AXI VDMA IP we have used in previous entries of the Video Series (Video Series 24, Video Series 25, Video Series 26…).
So why should you use the Video Frame Buffer IP cores and not the AXI VDMA IP?
The answer is documented in (Xilinx Answer 72543). Basically, the AXI VDMA IP takes bytes from the AXI4-Stream interfaces and simply moves them to memory, without caring about the format of the video data.
The Video Frame Buffer will need to be aware of the format of the data being transported from/to memory. It will be able to store the data in memory differently depending on the format selected. This is useful for Linux applications.
For example, the V4L2 formats YUYV and UYVY both represent YUV4:2:2 8-bits, the only difference is the way in which they are stored into memory.
The Video Frame Buffer IP is recommended for new designs.
The Video Frame Buffer Read/Write IPs are documented in (PG278).
Generating the Example Design for the Video Frame Buffer IP
Note: This is based on the example design available in the 2019.2 release.
Hardware (Vivado 2019.2) Example Design
To generate the hardware part (Vivado Design) of the Application Example Design follow the steps in Chapter 5 of (PG278). Example designs are available for the KC705, ZCU102, ZCU104 and ZCU106 boards. I would recommend starting with the example design even if you do not have any of the above mentioned evaluation boards. This is always the best starting point.
Note: to generate the example design with a Vivado WebPack license, use the ZCU104 board as starting point.
There are two different example designs. One for the Video Frame Buffer Read IP and one for the Video Frame Buffer Write IP.
I recommend using the example design for the Video Frame Buffer Write IP as it includes both the Video Frame Buffer Write and Video Frame Buffer Read IPs.
The Hardware design for the Video Frame Buffer Write IP example design is quite basic.
It uses a Video Frame Buffer Read IP to read data from memory to the AXI4-Stream interface.
This is then converted to Native video and back to the AXI4-Stream using the AXI4-Stream to Video Out and Video in to AXI4-Stream IPs.
Finally, the AXI4-Stream data is written back to memory using the Video Frame Buffer Write IP.
There are two things I think are important to note on this design:
- The two Video Frame Buffer IPs (Read and Write) have their interrupt outputs connected to the processor. This is a requirement. The Video Frame Buffer is an interrupt-based IP.
- The reset input for the two Video Frame Buffer IPs is connected to an AXI GPIO IP. This is important as it allows you to do a soft-reset (from the processor) of the IPs. As with any HLS IP, the Video Frame Buffer needs to be reset if the resolution changes.
Example Application (Vitis 2019.2)
To generate the example application, start within Vivado by exporting the hardware to Xilinx Vitis (File > Export > Export Hardware …).
Make sure that the bitstream is included in the exported hardware. This will create an XSA file.
Launch Xilinx Vitis and select a directory you want to use as the workspace.
In Vitis, select New > Platform project.
Enter the platform name of your choice (for example v_frmbuf_zcu104_pfm) and click Next.
Make sure Create from hardware specification (XSA) is selected and click Next.
Select the XSA file you have exported from Vivado, make sure that the A53 processor is selected and click finish.
Once the platform is created, click on Board Support Package under psu_cortexa53_0 > standalone on psu_cortexa53_0 and expand the Peripheral Drivers section.
Under Peripheral Drivers, look for the line corresponding to the Video Frame Buffer Write (v_frmbuf_wr) and click Import Examples.
Select the example (xv_frmbufwr_example) and click OK.
Running the example application
Note: The following steps assume that the board is powered up and connected through UART, with the BOOT mode switches set to JTAG mode and JTAG, and that a UART terminal (Tera Term for example) is opened to the correct COM port.
Build the application by selecting it and clicking on the hammer icon:
To launch the example application on hardware, right-click on the example design application and click Run As > Run Configurations…
In the Create, manage, and run configurations window, right click on Single Application Debug and click New Configuration.
In the Target setup tab of the configuration window, make sure psu_init (if running on ZCU102, ZCU104 or ZCU106 board) and program FPGA are enabled and click Run.
In the UART terminal, you should see that the application is trying different video resolution / color space combinations.
At the end of the application, it might give reasons why some of the tests didn’t work (basically if the hardware configuration does not support it).
The color space and video resolution tested are defined in the structures ColorFormats and TestModes in the application.
You can change these structures if you want to test less color formats or if you want to test different video resolutions.
Liked this Video Series?
- You can give Kudos using the Kudos button
- Share it on social media using the Share button
- Feel free to comment on this topic or to create a new topic on the forums to ask questions
Want more from the Video Series?
- You can find all of the previous video series here: Xilinx Video Series