[J-core] HDMI

[BGB]

On 10/18/2016 1:47 PM, Cedric BAIL wrote:
> Hello,
>
> 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.


I would admittedly think it may be easier to pull off composite, 
component, or VGA output. while these are analog, it shouldn't be too 
difficult to pull off using DPWM and some external RC low-pass filter 
circuits. with these, it should also be possible to get usable output at 
a significantly lower clock speeds.

similarly, there are no message structures or similar required.


there are differences between how output is done:
     VGA (or SCART): send separate R, G, B, and H/V sync signals;
     component: send Y signal, and U/V signals; H/V sync integrated into Y.
         likely the sync signals are output separately and then combined 
into the output externally.
         alternate is clamping duty-cycle values in the output logic.
             ex: for non-sync output, duty-cycle can't go below 64 
(below this point is sync/retrace).
     composite: similar to component, though color gets funky.
         could make sense for composite to generate component and 
modulate externally.
         though, this could be the simplest case if doing monochrome 
(much less simple for color).
         S-video is a compromise between component and composite (U and 
V are multiplexed).


DPWM basically consists of endlessly adding the duty-cycle value into an 
accumulator and using the carry bit as an output. there would be an 
accumulator per output channel (Y,U,V or R,G,B). any H/V sync signals 
would be pulldowns.

for component or composite, sync could be done internally, but requires 
clamping DPWM ranges (to avoid accidental sync signals, 1), or could be 
added in externally.

1: say, non-sync duty-cycle ranges between 64 and 192, with extreme 
values reserved for sync signals.


for output buffers, I would think probably it would make most sense to 
expose the framebuffer in a simple fixed format (memory-mapped at some 
location), and leave most of the rest to software. then software draws 
into the buffer, and the video output quietly makes passes over this 
buffer and sends it to the display. all this may happen asynchronously.

if driving VGA, a likely sensible raster format is RGB32 (so, 
640x480=1.2MB), or RGB565 if memory is tight. if driving component or 
composite output, then YUYV or similar makes sense (640x480 = 600kB).

there are trade-offs.


if driving component from an RGB framebuffer, it would be necessary to 
convert on output. one simple, if not terribly accurate conversion is 
GDbDr, or:
     Y=G, U=(B-G)/2+128, V=(R-G)/2+128
slightly better is:
     Y=(2*G+B+R)/4, U=(B-G)/2+128, V=(R-G)/2+128

better is possible but involves more complex arithmetic.


another idle thought could be using a framebuffer that is either RGB or 
YUV depending on what kind of display is used, possibly with a register 
which controls some behaviors (as appropriate for the display type, 
controlling sync and modulation behavior).

software would then be responsible for setting this register and filling 
the framebuffer contents, as appropriate for the display type (could 
avoid needing too much external electronics, just a few R/C filter 
circuits).

combined framebuffer could be:
     RGBx32 or VYUx32;
     YUYV or GBGR.


just a few thoughts, could be wrong here.