[J-core] HDMI

[Cedric BAIL]

On Tue, Oct 18, 2016 at 3:59 PM, BGB <cr88192 at gmail.com> wrote:
> 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).

Ah ! I see what you mean. Well, I was planning to follow Xilinx
description on how to implement TMDS as described there :
http://www.xilinx.com/support/documentation/application_notes/xapp495_S6TMDS_Video_Interface.pdf
. It was my understanding that the turtle would be based on the
Spartan 6 family and thus came to that assumption that the only clock
that would really matter would be the pixels rate as the TMDS part
would be handle by the IO output. Again, I am completely new to
hardware development and just gathering knowledge at this point. So if
any of my assumption is wrong, thanks for pointing it out !
-- 
Cedric BAIL