UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer fisherjeff
Observer
492 Views
Registered: ‎09-12-2018

Video Frame Buffer Write Data Corruption

Jump to solution

Hi,

I'm having a problem with the Video Frame Buffer Write IP on a Zynq UltraScale+ that I can't figure out. I have had it working in the past but something must have changed in my hardware design. If I roll the bitstream and DTB back I can see that it does work, but because I haven't been able to come up with a good way to use source control with Vivado (side note: any tips here would be very helpful), I don't know exactly what the differences are.

In my design, I have two different v_frmbuf_wr blocks: One is fed by a Video In to AXI4-Stream and the other by a TPG. Both exhibit the same behavior, where every other 8 bytes of data is zeroed out. Here is a partial hexdump of an NV12 TPG frame, for example:

 

00000000  ff ff ff ff ff ff ff ff  00 00 00 00 00 00 00 00  |................|
*
000000a0  e1 e1 e1 e1 e1 e1 e1 e1  00 00 00 00 00 00 00 00  |................|
*
00000140  b2 b2 b2 b2 b2 b2 b2 b2  00 00 00 00 00 00 00 00  |................|
*
000001e0  95 95 95 95 95 95 95 95  00 00 00 00 00 00 00 00  |................|
*
00000280  69 69 69 69 69 69 69 69  00 00 00 00 00 00 00 00  |iiiiiiii........|
*

I have deleted both pipelines and completely rebuilt the TPG pipeline from scratch, exactly (as far as I can tell) following the 2018.2 ZCU106 TRD but I still continue to see this behavior. Here are the relevant device tree elements, which I verified closely match the ones from my working bitstream/DTB:

 

&tpg_core {
    reset-gpios = <&gpio 82 1>;
    clocks = <&clk 71>;

    ports {
        #address-cells = <1>;
        #size-cells = <0>;

        port@0 {
            reg = <0>;
            xlnx,video-format = <XVIP_VF_YUV_420>;
            xlnx,video-width = <8>;

            tpg_out: endpoint {
                remote-endpoint = <&vcap_tpg_in>;
            };
        };
    };    
};

&tpg_framebuffer_wr {
    #dma-cells = <1>;
    compatible = "xlnx,axi-frmbuf-wr-v2.1";
    reset-gpios = <&gpio 83 1>;
    clocks = <&clk 71>;
    clock-names = "fclk0";
    xlnx,dma-addr-width = <32>;
    xlnx,pixels-per-clock = <1>;
    xlnx,vid-formats = "yuyv", "uyvy", "nv12", "rgb888";
};

vcap_tpg {
    compatible = "xlnx,video";
    dmas = <&tpg_framebuffer_wr 0>;
    dma-names = "port0";

    ports {
        #address-cells = <1>;
        #size-cells = <0>;

        port@0 {
            reg = <0>;
            direction = "input";

            vcap_tpg_in: endpoint {
                remote-endpoint = <&tpg_out>;
            };
        };
    };
};

And here are the relevant portions of my block design:

 

 

I did verify that all the IP settings on my TPG pipeline are identical to the ZCU106 TRD, and even added the data FIFO just in case but nothing I have been able to do has changed the behavior whatsoever. Any assistance would be GREATLY appreciated.

 

0 Kudos
1 Solution

Accepted Solutions
Observer fisherjeff
Observer
470 Views
Registered: ‎09-12-2018

Re: Video Frame Buffer Write Data Corruption

Jump to solution

Okay, I've been trying to figure this out for WEEKS. Sure enough, I figured it out an hour after posting on the forum...

Apparently the AXI HP slave port on the PS must be 128 bits no matter what. In my case, my v_frmbuf_wr is running at 1 sample/clock, which corresponds to an AXI4-Stream data width of 64 bits. Accordingly, I'd thought that the right thing to do was to set the slave port to also be 64 bits, but it turns out I needed to convert to 128 bits at the interconnect and add a FIFO.

View solution in original post

2 Replies
Observer fisherjeff
Observer
480 Views
Registered: ‎09-12-2018

Re: Video Frame Buffer Write Data Corruption

Jump to solution

Not sure why these didn't come through the first time – trying again...

tpg.pngblock design.png

0 Kudos
Observer fisherjeff
Observer
471 Views
Registered: ‎09-12-2018

Re: Video Frame Buffer Write Data Corruption

Jump to solution

Okay, I've been trying to figure this out for WEEKS. Sure enough, I figured it out an hour after posting on the forum...

Apparently the AXI HP slave port on the PS must be 128 bits no matter what. In my case, my v_frmbuf_wr is running at 1 sample/clock, which corresponds to an AXI4-Stream data width of 64 bits. Accordingly, I'd thought that the right thing to do was to set the slave port to also be 64 bits, but it turns out I needed to convert to 128 bits at the interconnect and add a FIFO.

View solution in original post