[J-core] HDMI

BGB cr88192 at gmail.com
Tue Oct 18 18:59:04 EDT 2016


On 10/18/2016 5:07 PM, Cedric BAIL wrote:
> On Tue, Oct 18, 2016 at 2:55 PM, BGB <cr88192 at gmail.com> wrote:
>> On 10/18/2016 1:47 PM, Cedric BAIL wrote:
>>> As I have been quite interested by having a working 2D graphics stacks
>>> with the j-core once the turtle is out, I have started to learn a bit
>>> about how to write an HDMI output. I still need to learn more about
>>> vhdl and would love any pointer to a good book/tutorial.
>>>
>>> I have figured out that actually we don't need to implement HDMI, but
>>> only a basic DVI as HDMI support it as the possible simplest
>>> implementation. This should make our life quite easier as finding DVI
>>> specification is way easier
>>> (http://www.cs.unc.edu/~stc/FAQs/Video/dvi_spec-V1_0.pdf). Reading the
>>> specification, there is one very interesting point. All device should
>>> support the "
>>> Low Pixel Format Support" which is a 640x480 @60Hz with 24bits per
>>> pixels. Even the frequency is well defined (Pixels at 25.175 MHz and
>>> Horizontal Frequency of 31.5 kHz, but I needs to check that HDMI
>>> follow the same requirements as I can only find 25.2Mhz/31.5kHz/60Hz
>>> and 25.175Mhz/31.47KHz/59.94Hz on my own HDMI output).
>>>
>>> I would argue that being able to handle that resolution with j-core
>>> seems sane and the most likely working target. Anything above would be
>>> quite hard to get usable. I guess it would simplify the work on the
>>> vhdl if we only need to handle one resolution and one timing. Would
>>> this clocks be any problem in the current design of the turtle board ?
>>>
>>> There are a lot of article on Internet that are interesting to read to
>>> understand what is going on and how things should work with HDMI. I
>>> have found this link http://fpga4fun.com/HDMI.html to be a good
>>> starting point. If anyone has other link to share, it would be
>>> interesting.
>>>
>>> I just wanted to drop this here, so that if anyone start to be looking
>>> at the topic, they would have a better/quicker understanding. It also
>>> could be a starting point to discuss the general design of how a 2D
>>> unit could work itself. I have a lot of question and will just drop a
>>> few of them here, just to start a possible discussion. How/When does
>>> the kernel get notified of the rendering of a frame ? Do we need to
>>> expose a way to list resolution even if we do handle just one ? How do
>>> we store video memory (around 1.2MB per scanout buffer) ? As I would
>>> like to add a simple blitter unit to provide hardware plane, where
>>> should that be ? Inline with the scanout or completely independent ?
>>> What about color conversion ?
>>>
>>> That's just a few questions I am starting to think about and it would
>>> be nice to see people share their though on the topic. Especially with
>>> the constraint of the turtle/j-core in mind, we need to be smart to
>>> manage to get something usable !
>>
>> I am not sure, but a few thoughts.
>>
>> my thought here is that the 250MHz needed to pull off HDMI output may be out
>> of reach for lower end FPGA's, but I am not sure.
> Why do you think we need 250Mhz ? For the lower pixels format, aka
> 640*480 @60Hz, we only seems to need 25Mhz. Is there something I
> missed ? Also the turtle will only come with an HDMI output, like the
> RPi do.

25MHz is the pixel-rate, but the pixels need to be sent as a serial 
stream of bits; this pushes the required bitrate up *considerably*, and 
you would end up needing to drive 250MHz on the output pins (and for 
serial parts of the interface).

contrast with the analog interfaces, one doesn't need to send nearly as 
many bits, and the bits don't need to get through reliably; it is more 
just the faster the DPWM is, the higher the output image quality can be 
(one might only need a few bits per pixel to get "acceptable" output).



More information about the J-core mailing list