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: 
Contributor
Contributor
1,710 Views
Registered: ‎05-11-2018

Driving HDMI TX IP with non constant tppl and tlpf video

My design takes in two consecutive 60Hz 3840x2160 4ppc video frames via the HDMI RX IP and using an frame buffer converts them to two parallel 30Hz 3840x2160 video frames.  Due to the way the design was coded the TLPF will toggle between like 2200 and 2201 lines per frame since the vsync width varies by 1 in various frames.  I am attempting to take one of the 30Hz frames (166.666 MHz video clock) and drive it out the HDMI TX IP (4ppc at 74.25 MHz video clock).  I am feeding the video through a line buffer to convert between the video clock domains.  The output video of my line buffer is reset with the input vsync.  I have tried various video parameters for the output video but I either get video where my last line TPPL is either larger or smaller than all of the other TPPL for the other lines through out the frame.  The HDMI TX seems to not be able to support video with varying lines per frame and/or varying pixels per line within a frame. The output of the HDMI TX to a monitor either thinks there are 2161 lines and I see part of my image skewed at the top of the screen or I don't get any video at all out.  Is there some way I can correct this without having another frame buffer added to my design (not feasible with the KC705 board or our custom board).  Does the HDMI TX IP require that the input video have constant video parameters? I am using Vivado 2018.1.

Tags (2)
0 Kudos
10 Replies
Moderator
Moderator
1,656 Views
Registered: ‎10-04-2017

Re: Driving HDMI TX IP with non constant tppl and tlpf video

Hi @kmwilliams,

 

To summarize:

You are seperating a 60Hz 3840x2160 4ppc video stream into 2 30Hz 3840x2160 4ppc video streams.

Your 30Hz frames now alternate total lines per frame (TLPG) by 1 every frame.

Because of this size variation, the core is not behaving as you would expect.

 

 

You should not start with 2160 lines and end up with 2161 lines. Is this a design requirement or just something that is happening due to the code?

If this is an issue with the code, it should be easily fixed and looks like an issue with your counter. Are you using the AXI stream interface or native interface?

 

The AXI stream interface makes it easy to find frame boundaries. Take a look at page 6 of UG934 AXI4-Stream Video IP and System Design.

 

Regards,

Sam

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Contributor
Contributor
1,617 Views
Registered: ‎05-11-2018

Re: Driving HDMI TX IP with non constant tppl and tlpf video

Sam,

 

I have attached a zip file containing the following:

 

  • Screenshot of HDMI IP Block Design
  • Block Diagram of my design
  • Screenshots of waveforms showing variations in my line buffer output.
  • My line buffer verilog file.
  • Screenshot of small resolution simulation showing variations with constant frame and line rate video input.

My HDMI IP started from a 4PPC HDMI TX example design.  The following modifications were made to the implementation.

 

  • Remove TPG.
  • Remove Audio Blocks.
  • Remove passthrough related AXI blocks (implemented outside of the IP in my RTL).
  • Convert RX and TX blocks to Native Video.
  • Other minor changes for debug, resets, clocks.

Since my initial post I have modified my line buffer Verilog such thought now all of the output parameters are constant except for TLPF and VSW.

 

Constants

  • HSW (10)
  • HFP  (85)
  • HBP (83)
  • APPL (960)
  • TPPL (1138)
  • VFP (8)
  • VBP (5)
  • ALPF (2160)

Variations

  • TLPF (2174) VSW (2 or 3)
  • TLPF (2175) VSW (1 or 2)
  • TLPF (2176) VSW (1)
  • Pixel Clock 74.25 MHz

The input video varies similarly as above due to variations in frame buffer bandwidth (not my design).  It’s variations are slightly different but still only associated with TLPF and VSW.

 

Constants

  • HSW (10)
  • HFP  (85)
  • HBP (83)
  • APPL (960)
  • TPPL (1138)
  • VFP (8)
  • VBP (5)
  • ALPF (2160)

Variations

  • TLPF (2175) VSW (2 or 3)
  • TLPF (2176) VSW (2)
  • Pixel Clock 166.666 MHz

I simulated my line buffer using a small resolution (64x30 active video) where the frame rates and line rates are constant.  The same kind of variation of TLPF and VSW occurred except the variance was only one for TLPF and two for VSW.

 

The line buffer implementation was done for debug purposes only to verify the two 4k30hz video channels are correct.  The 4k30hz frame outputs shown in the block diagram are the design destination.  This path does not care about constant frame/line rates as there is another frame buffer down the path.  My debug path does not have that option.  I have already spent significant time on trying to get this debug path operational and switching now to an AXI implementation would likely require significantly more time to develop as I have only had limited experience with the AXI interfaces and not as a designer. 

 

What does using an axi interface version of the HDMI IP get me that the Native Video version can’t?  Would I have to make additional changes to the example design beyond not converting the TX/RX blocks to Native Video?  Would I have to add any blocks to my current HDMI block design or anything else to fix the problem I am having? 

 

Any help you can provide would be greatly appreciated.

 

Thanks,

 

Kerry

0 Kudos
Moderator
Moderator
1,573 Views
Registered: ‎10-04-2017

Re: Driving HDMI TX IP with non constant tppl and tlpf video

Hi Kerry,

 

The AXI-Stream interface is a user-friendly interface that strips timing out which allows the user to run at a slower clock speed; it also connects directly to most of our IP. I generally recommend using the AXI-Stream interface over the native interface. Looking at your RTL the logic would be much simpler if you were using our AXI-Stream interface. Take a look at UG934 page 6. The timing information is then put back into the system using the VTC which is included in the SubSystem and shown in our example design.

 

If you want to stick with the native interface, please take a look at your RTL design.

Taking a look at the RTL provided, it looks like your issue is here. If you are starting with 1 stream that is constant and ending up with multiple streams that are not constant, this is a problem that needs to be fixed. As long as your RTL outputs varying values for Lines per frame/or Pixels per line, you will have issues.

 

Also with this RTL is Vivado giving you any critical warnings? If so, please remove all of these warnings.

 

For clarification:

What version of Vivado are you using?

When you say input video, are you talking about video from the HDMI RX SubSystem or video from your RTL into the HDMI TX SubSystem?

 

 

Regards,

Sam

 

 

 

 

 

 

 

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Moderator
Moderator
1,561 Views
Registered: ‎10-04-2017

Re: Driving HDMI TX IP with non constant tppl and tlpf video

Hi Kerry,

 

I was thinking of a way of doing this without writing your own FSM.

 

One way is to use our broadcaster to split the AXI-Stream into two equivalent streams and then to push the data into memory using the Video frame buffer write. Then the data could be read out by the Video frame buffer read, reading out half the number of frames. This resulting stream is then pushed directly into the HDMI TX SS.

 

To read out half the number of frames I can quickly think of 2 techniques.

1. Write every other frame into a different memory location and only read from that location.

2. Read out the data at 1/2 the speed that you are writing it in at.

 

Both of these will require a working knowledge of the Video frame buffer. See PG278.

 

-Sam

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Contributor
Contributor
1,550 Views
Registered: ‎05-11-2018

Re: Driving HDMI TX IP with non constant tppl and tlpf video

Sam,

 

To answer some of your questions.

 

1. I don't see any significant critical warnings other than set_false_path, set_clock_groups or set_property mark_debug xdc commands that are no longer valid due to changes in my design over time.

2. I am using Vivado 2018.1.

3. In my last post input_video meant the input to my line buffer and/or input to the HDMI TX (output of our video_splitter block represented by the DMUX symbol).  I am attaching a new block diagram as I don't think the one in my previous zip file was complete.

4. The video_splitter block is controlled by another engineer whom likely does not have the bandwidth to make additional changes to it at this time. So removing the variability of the tlpf and vsw may not be possible but I will ask.

5. Altering the overall frame work of the design as far as your suggestion of using the video frame buffer and broadcaster will be too large of an effort just for implementing a visual debugging tool.

 

Questions

1.  If I switch to using a HDMI TX AXI interface will it matter if the video (sof) varies from frame to frame.

2. Does the HDMI IP use the HDMI RX parameters to generate the HDMI output to the monitor since no video parameter information is included in the AXI interface.

3. My thought is to feed sof, eol, valid and data signals into the line buffer memory to transfer from the video splitter clock domain to the AXI4 clock domain or something along that lines.  Is that what you were previously suggesting?

4. Would it make sense for me to configure the v_hdmi_tx_ss to be axi4 and add the Video In to AXI4-Stream and Video Timing Controller blocks to my block design with my native video as the input to my block design and the Video In to AXI4-Stream block?  If so would assume the Video In to AXI4-Stream would need to be independent clocks (video splitter input and axi clock output). 

5. Would I need to Enable Sync Generation in the Video Timing Controller?  If so, is this timing independent of my frame video timing?  It has parameters in order to set the video frame rates and line rates.  Will I still run into problems if my native video frame is varying given the frame parameter generation would be fixed?  What happens if the sync generation timing is complete or not complete when the next sof comes in?  I see this being an issue regardless of my tlpf varying just because of the 166.666MHZ(native) to 150MHz (AXI) conversion through the line buffer.

 

Am I making this more complicated than it needs to be?

 

Kerry

 

 

Block_Diagram.PNG
0 Kudos
Moderator
Moderator
1,529 Views
Registered: ‎10-04-2017

Re: Driving HDMI TX IP with non constant tppl and tlpf video

Hi Kerry,

 

"4. The video_splitter block is controlled by another engineer whom likely does not have the bandwidth to make additional changes to it at this time. So removing the variability of the tlpf and vsw may not be possible, but I will ask."

 

I believe that the variability of the tlpf and vsw violates the HDMI spec. In doing so, you will most likely have issues on all interfaces and IP's.

 

If you are not able to change this, then you will have to remove the other engineer's module and use our IPs to replace their incorrect module.

 

Here is what that will look like.

  1. The video comes in from the HDMI RX SubSystem and is transferred out using AXI-Stream.
  2. This video stream is put into memory using the Video Frame Buffer Write at 60FPS.
  3. The video stream is pulled out of memory using the Video Frame Buffer Read at 30FPS.
  4. The video stream is then duplicated using the broadcaster to create 2 video streams. 
  5. These output streams are then converted from AXI-S to native mode using the AXI4-Stream to Video out core + the VTC core.

 

This is a fairly straightforward process if you have experience with Frame Buffers, embedded design, and video. The interesting part of this will be steps 2+3. You will need to drop half of the frames in a manner of your choosing.

 

To answer your questions:

1.  If I switch to using an HDMI TX AXI interface will it matter if the video (sof) varies from frame to frame?

I am assuming that you are talking about the SOF relative to the line number. This must stay the same for both interfaces.

 

2. Does the HDMI IP use the HDMI RX parameters to generate the HDMI output to the monitor since no video parameter information is included in the AXI interface?

This is taken care of by the software drivers. They control the HDMI to let it know what the incomming how data should be formatted. The HDMI TX core then generates the correct timing information.

 

3. My thought is to feed sof, eol, valid and data signals into the line buffer memory to transfer from the video splitter clock domain to the AXI4 clock domain or something along that lines.  Is that what you were previously suggesting?

I am suggesting using our Frame Buffers with AXI. These take care of sof, eol, valid and data. Because AXI-S does not contain VSYNC and HSYNC the AXI-S can run at any speed fast enough to push all the data through at the requested FPS.

 

4. Would it make sense for me to configure the v_hdmi_tx_ss to be axi4 and add the Video In to AXI4-Stream and Video Timing Controller blocks to my block design with my native video as the input to my block design and the Video In to AXI4-Stream block?  If so would assume the Video In to AXI4-Stream would need to be independent clocks (video splitter input and axi clock output).

No. Your Block design is based on the example design and looks fine. The problem we are solving is the module which has been coded incorrectly.

 

5. Would I need to Enable Sync Generation in the Video Timing Controller?  If so, is this timing independent of my frame video timing?  It has parameters in order to set the video frame rates and line rates.  Will I still run into problems if my native video frame is varying given the frame parameter generation would be fixed?  What happens if the sync generation timing is complete or not complete when the next sof comes in?  I see this being an issue regardless of my tlpf varying just because of the 166.666MHZ(native) to 150MHz (AXI) conversion through the line buffer.

Yes, your variation is the issue.

 

Am I making this more complicated than it needs to be?

You are trying to work around a broken module. Either fix the module or replace it.

 

Regards,

Sam

 

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
Newbie kfung
Newbie
1,524 Views
Registered: ‎07-03-2018

Re: Driving HDMI TX IP with non constant tppl and tlpf video

Sam,

 

My responses are in red

 

1.  If I switch to using an HDMI TX AXI interface will it matter if the video (sof) varies from frame to frame?

I am assuming that you are talking about the SOF relative to the line number. This must stay the same for both interfaces.

No SOF would still occur on first pixel of line one. I was referring to with the varying rate of the vsync due to changing TLPF, I would think the the SOF would not occur on a constant frame rate as well.  The time between sof would vary.  Note even if you drive my line buffer with a test pattern generator that does produce a constant TLPF and TPPL.  There is still variability in the number of TLPF (variation of one line count).  This variation is caused by the difference in clock speeds 166.666 MHz and 74.25MHz.  Otherwise the line buffer input and output video would walk from each other causing overruns or underruns of the memory.  A frame buffer would be needed to avoid this and I don't have the memory for two frame buffers.

 

 

2. Does the HDMI IP use the HDMI RX parameters to generate the HDMI output to the monitor since no video parameter information is included in the AXI interface?

This is taken care of by the software drivers. They control the HDMI to let it know what the incomming how data should be formatted. The HDMI TX core then generates the correct timing information.

 

3. My thought is to feed sof, eol, valid and data signals into the line buffer memory to transfer from the video splitter clock domain to the AXI4 clock domain or something along that lines.  Is that what you were previously suggesting?

I am suggesting using our Frame Buffers with AXI. These take care of sof, eol, valid and data. Because AXI-S does not contain VSYNC and HSYNC the AXI-S can run at any speed fast enough to push all the data through at the requested FPS.

I assume this is in reference to replacing the other engineers block that controls the interface to the DDR3 (video splitter block contains a DDR3 MIG by the way) with the frame buffer blocks as you described in your 5 steps.  This is less likely to happen given time constraints.  Have a meeting shortly to discuss what plan going forward will be. Whether to fix the variability of output of video splitter or to punt on this effort are the likely choices.

 

4. Would it make sense for me to configure the v_hdmi_tx_ss to be axi4 and add the Video In to AXI4-Stream and Video Timing Controller blocks to my block design with my native video as the input to my block design and the Video In to AXI4-Stream block?  If so would assume the Video In to AXI4-Stream would need to be independent clocks (video splitter input and axi clock output).

No. Your Block design is based on the example design and looks fine. The problem we are solving is the module which has been coded incorrectly.

Assuming I have a  960x2160 (4 pixels per clock, 96 bit data) 30Hz video stream with 166.66MHz pixel clock.  How would you suggest interfacing to the HDMI TX IP AXI interface that runs at 150MHz?  

 

5. Would I need to Enable Sync Generation in the Video Timing Controller?  If so, is this timing independent of my frame video timing?  It has parameters in order to set the video frame rates and line rates.  Will I still run into problems if my native video frame is varying given the frame parameter generation would be fixed?  What happens if the sync generation timing is complete or not complete when the next sof comes in?  I see this being an issue regardless of my tlpf varying just because of the 166.666MHZ(native) to 150MHz (AXI) conversion through the line buffer.

Yes, your variation is the issue.

If this idea is your answer to my question 4 above can you provide a little guidance on how to configure the VTC and Video In to AXI blocks.  Using my line buffer I would already have video coming in the 150MHz (once I changing the timing parameters to account for changing from 74.25 MHz (Native) to 150MHz(AXI).  But this would have the issue with TLPF toggling between 2176 and 2175.  I could change the line buffer to put video into the line buffer and output AXI directly.

 

Regarding detection, sync generation and registers.  If don't care about changing the parameters than I shouldn't need the AXI lite for register access.  I think that would complicate things as I think I would have to modify the microblaze to add address space.

 

0 Kudos
Contributor
Contributor
1,379 Views
Registered: ‎05-11-2018

Re: Driving HDMI TX IP with non constant tppl and tlpf video

Sam,

 

Can I change the AXI clock from 150 MHz to 166.666MHz by customizing clk_out2 of the clk_wiz block in the mb_ss_0 block?  Will the system correctly alter the TX and RX video streams (HDMI and AXI) to account for the change in clock?  Would I need to change anything else in order to make it properly make the changes?  I am thinking that if I match the AXI clock speed to that of my video splitter pixel clock then I can eliminate the variability. 

 

Kerry

0 Kudos
Moderator
Moderator
1,371 Views
Registered: ‎10-04-2017

Re: Driving HDMI TX IP with non constant tppl and tlpf video

Hi Kerry,

 

I will try to answer both posts here.

 

First, when using AXI-Stream and the HDMI RX/TX SubSystems and internal pipe IP such as the Frame buffers, you need a clock speed that is fast enough to meet your throughput needs. Because the AXI-Stream only sends the data and line/frame separation, you can use a clock that works for you. It does not need to match the line speed as with native mode. (Since 166.666 is faster than 150 this should be fine)

 

There is buffering internal to most of the video IP cores that can take care of clock domain crossings. Please check the Product Guide for each IP if you need buffering.

 

One thing that you should remember with any data stream is that your stream throughput must be larger downstream or you will run into overflow situations and loose data. Alternatively, if you are not providing enough data to your downstream source, you can run into starving or underflow situations.

 

 

To close the previous post.

 

If you choose to use your current Verilog module, your design will not work. You can either fix the module or use another method to downsample the frame rate. (My suggestion is through buffering)

 

If you use the HDMI TX/RX SubSystems in AXI-S mode, the VTC is included within the Subsystem.

To close this. The HDMI RX IP provides a consistent line per frame count of video data at 60 FPS, which you will then need to downsample to 30FPS in a manner of your choosing and then stream to the HDMI TX IP for transmission. There is a pass-through design for the HDMI SubSystems that I recommend you take a look at as well as and example design for the frame buffers.

For specific instructions on how to use any of these IP's, please take a look at their Product Guides and provided example designs. If you have a specific question on each of the IP's, please make a new post for the IP.

 

 

Regards,

Sam

 

 

 

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Moderator
Moderator
768 Views
Registered: ‎11-09-2015

Re: Driving HDMI TX IP with non constant tppl and tlpf video

HI @kmwilliams,

 

This topic is still open and is waiting for you.

If your question is answered or your issue is solved, please mark the response which helped as solution (click on the button "Accept as solution" below the reply)

If this is not solved/answered, please reply in the topic giving more information on your current status.

Best Regards,


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos