[J-core] HDMI

BGB cr88192 at gmail.com
Tue Oct 18 19:43:38 EDT 2016

On 10/18/2016 6:11 PM, Cedric BAIL wrote:
> 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 !

I could be wrong as well, since if using this chip, and the chip can do 
it, well then...

my experience in this area is more limited to microcontrollers.
I have worked with modulation similar to that described, but typically 
at somewhat lower frequencies (typically 30-100 kHz), which is more 
useful for things like motor-controls and audio.

I don't know as much about the capabilities of FPGAs.

More information about the J-core mailing list