LCD Bus Compatible Input

[vasimr]

LCD Bus Compatible Input

[sameer]

Hi vasimr,

Would it be possible to rework a version of the HDMI video transmitter to accept a LCD bus compatible input?

You can wrap the HDMI module with a module of your own that translates the input.

That would be and input of RGB[D:0] (for bit depth D), hsync, vsync, clk, and de (data enable).

For DE, you could gate the HDMI clock so it's only active when data is enabled. But it might be better to just set the RGB to 0 since there is a nonzero setup time for an HDMI sink to recognize a source.

I have an application where I would like to be able to drive the transmission externally with the signals above, however, it appears that there is additional logic which relies on the frame size.

The resolution has to be known at synthesis-time (it's parameter-controlled). But you could change the module to use an hsync/vsync input.

[vasimr]

Thanks for responding.

I can see how to change the HDMI module to accept a LCD bus input for DVI, however, it seems unclear how to do this for the HDMI packets. You are calculating "video_guard" and "video_preamble" based on screen parameters, which would be unknown with hsync / vsync. Is that what you meant by the resolution needing to be known at synthesis time? Would the solution instead be to have dedicated registers to specify the frame_width, frame_height , screen_width , and screen_height?
My use case requires dynamic resolution change.
Since the HDMI module does not seem to support this outright, is there any special logic required by the HDMI spec for a resolution change? i.e. does it need to reset the frame?
Also, since the module doesn't do anything with the hotplug, is there any special behavior required by the HDMI spec for hotplug?
I can look through the spec myself, but I figured that if you happen to know the answer, it would be quicker to ask.

[sameer]

Is that what you meant by the resolution needing to be known at synthesis time?

Yes

My use case requires dynamic resolution change.

This can be done. There are two ways:

• The resolution could be changed from parameters to registers, but that makes it possible to produce bad configurations (i.e. hsync/vsync for a 1000x1000 frame is undefined)
• If you know what exact resolutions you'll be using, you could instantiate the module a few times and swap between those.

You might need to change the clock frequency to support other resolutions -- see the table in the readme. Looking at CEA-861-D, I do see that there are some video codes with the same pixel clock frequency but different resolution, not sure I've added all of those though (feel free to make a pull request).

Since the LCD bus has hsync/vsync, I'm not sure how feasible it will be to identify what resolution is needed though. Is the LCD clock changing or anything? Maybe you could use the highest HDMI resolution possible and draw the LCD input onto a subsection of the screen to start with, and eventually implement some linear scaling so it fills the screen. Either way you probably need some holding RAM to transfer the frames.

Since the HDMI module does not seem to support this outright, is there any special logic required by the HDMI spec for a resolution change? i.e. does it need to reset the frame?

It's not explicitly mentioned in the spec, from what I've read. If you change the resolution I think it'll be treated as though you plugged in a new HDMI source.

Also, since the module doesn't do anything with the hotplug, is there any special behavior required by the HDMI spec for hotplug?

Nope! If you want to save active power consumption, you can gate the clock signals on the hotplug. There is some state in the module but it won't affect connecting with another sink.

[vasimr]

Instantiating multiple cores isn't really an option, since that would take too many resources. Although switching between output resolutions in a ROM may be doable. Either way the clock frequency would have to be changed on the fly, which is fine since the Xilinx 7-series supports this.
As for invalid frame sizes, that's fine. The idea would only be to use frame sizes that are supported.

I'm wondering how the HDMI TX chips work if the frame size is needed by the spec. Perhaps this is why some of the older ones required setting the frame parameters via I2C. I am guessing the newer chips do resolution detection via the timings.
If the pixel clock is kept constant, then you can figure out the timings within a single frame. I am guessing if you have a counter for the width which you set to 0 during detection and then increment each pixel clock while the DE signal is asserted, you will get your width. Then you do the same thing with Y, but with a state incrementor, where it needs to see hsync ->de, and disables when it sees hsync -> hsync (during the v-blank).

Anyway, for this application, I have the ability to set the resolutions using the older method (like via I2C). So I can output the LCD bus, plus a register for screen_width, screen_height, frame_width, and frame_height.

My concern that I have though is the guard / preamble. Though I guess the blanking periods are on the left and top of the video output, so that should be fine (if the generation logic had the h-blank for the line afterwards, then the two cores would be out of sync). It might be simpler to let the HDMI module drive the screen timing though, and do some spaghetti consolidation for the hsync and vsync - otherwise I need to have to duplicate the screen counting logic.

One thing that I didn't see in the HDMI module is an ability to inhibit / reset. Is that something you could add? Like and enable signal and a reset signal (synchronous reset would probably be best)? If I change the resolution dynamically, I would want to reset the frame to the beginning.