-
-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LCD Bus Compatible Input #14
Comments
Hi vasimr,
You can wrap the HDMI module with a module of your own that translates the input.
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.
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. |
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? |
Yes
This can be done. There are two ways:
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.
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.
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. |
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. 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. 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. |
Hi,
Would it be possible to rework a version of the HDMI video transmitter to accept a LCD bus compatible input?
That would be and input of RGB[D:0] (for bit depth D), hsync, vsync, clk, and de (data enable).
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.
Thanks.
The text was updated successfully, but these errors were encountered: