Shop Learn P1 Docs P2 Docs
HDMI added to Prop2 - Page 3 — Parallax Forums

HDMI added to Prop2

1356721

Comments

  • RaymanRayman Posts: 12,914
    I found a nice article on development of DVI and HDMI:
    https://www.fpga4fun.com/files/WP_TMDS.pdf

    Seems encryption can be done with DVI too... So, I guess it's mainly sound that HDMI adds.
    But, you can transmit video only over HDMI as it is backwards compatible with DVI...
  • TonyB_ wrote: »
    Rayman wrote: »
    I was reading something that made it sound like there were more possible control tokens defined...

    I think video only needs two bits though for hsync and vsync, or something like that...

    More tokens than the four for the syncs would require more hardware. They couldn't be done in software.

    Bit 0 of the long for HSync and bit 1 for Vsync with other bits of the low byte zero seems the simplest scheme and I imagine Chip has done it that way.

    There is also a data enable signal, DE.
  • jmgjmg Posts: 14,979
    TonyB_ wrote: »
    More tokens than the four for the syncs would require more hardware. They couldn't be done in software.

    Bit 0 of the long for HSync and bit 1 for Vsync with other bits of the low byte zero seems the simplest scheme and I imagine Chip has done it that way.

    If more are needed, is there a simple bypass of the 8b:10b encode that can be used ?
    with 32b in, it seems there could even be room to allow 2 bits to control direct pass thru of codes, up to 3 fields if needed (do these get used adjacent ?)
    11b => 3 x 10b size from 30 bits
    10b => 2 x 10b size from 20 bits
    01b => 1 x 10b size from 10 bits
    00_ccccccb => 8b:10b encode of 24 bits, 6 bits spare for specific HW codes if required.
  • cgracey wrote: »
    In this 8-bit to 10-bit encoder, the TMDS state machine generates needed tokens from the input bytes. There are also four special control codes that can be sent which are different from the byte-data tokens. That is all that can be done. Something like audio would be at a higher level, where you would probably use control codes to signal the data. point is, I think we have all the hardware that would ever be needed.

    Okay if it is just the regular 4 control preamble 10 bit values required for the H/V sync inputs on channel 0 plus the other 256 input combinations for 8 bits of video per channel that your streamer supports then I am not sure if any audio or other HDMI functions will be possible as they require special 10 bit values to be sent which might not be generated by 8 bits (but I didn't check that).

    The data guard band needs to be able to send 10'b0100110011 for two of the channels.
    The video guard band needs to be abled to send 10'b1011001100 and 10'b0100110011.
    The actual 10bit values for the TERC4 4 bit mappings I believe are found in the code below.

    DVI only is still okay, but not quite as flexible as full HDMI.

    module TERC4_encoder(
    	input clk,
    	input [3:0] data,
    	output reg [9:0] TERC
    );
    
    reg [9:0] TERC_pre;
    
    initial
    begin
    	TERC_pre=0;
    end
    
    always @(posedge clk)
    begin
    	// Cycle 1
    	case (data)
    		4'b0000: TERC_pre <= 10'b1010011100;
    		4'b0001: TERC_pre <= 10'b1001100011;
    		4'b0010: TERC_pre <= 10'b1011100100;
    		4'b0011: TERC_pre <= 10'b1011100010;
    		4'b0100: TERC_pre <= 10'b0101110001;
    		4'b0101: TERC_pre <= 10'b0100011110;
    		4'b0110: TERC_pre <= 10'b0110001110;
    		4'b0111: TERC_pre <= 10'b0100111100;
    		4'b1000: TERC_pre <= 10'b1011001100;
    		4'b1001: TERC_pre <= 10'b0100111001;
    		4'b1010: TERC_pre <= 10'b0110011100;
    		4'b1011: TERC_pre <= 10'b1011000110;
    		4'b1100: TERC_pre <= 10'b1010001110;
    		4'b1101: TERC_pre <= 10'b1001110001;
    		4'b1110: TERC_pre <= 10'b0101100011;
    		4'b1111: TERC_pre <= 10'b1011000011;
    	endcase
    	// Cycle 2
    	TERC <= TERC_pre;
    end
    
  • jmgjmg Posts: 14,979
    edited 2018-10-17 00:29
    rogloh wrote: »
    The data guard band needs to be able to send 10'b0100110011 for two of the channels.
    The video guard band needs to be abled to send 10'b1011001100 and 10'b0100110011.
    The actual 10bit values for the TERC4 4 bit mappings I believe are found in the code below.

    Do those ever send adjacent ?
    Could a optional direct 10b pathway, as I suggest above, cover those, without needing the extra verilog to hard-code them ?

  • TonyB_TonyB_ Posts: 2,001
    edited 2018-10-17 00:42
    jmg wrote: »
    TonyB_ wrote: »
    More tokens than the four for the syncs would require more hardware. They couldn't be done in software.

    Bit 0 of the long for HSync and bit 1 for Vsync with other bits of the low byte zero seems the simplest scheme and I imagine Chip has done it that way.

    If more are needed, is there a simple bypass of the 8b:10b encode that can be used ?
    with 32b in, it seems there could even be room to allow 2 bits to control direct pass thru of codes, up to 3 fields if needed (do these get used adjacent ?)
    11b => 3 x 10b size from 30 bits
    10b => 2 x 10b size from 20 bits
    01b => 1 x 10b size from 10 bits
    00_ccccccb => 8b:10b encode of 24 bits, 6 bits spare for specific HW codes if required.

    That's an interesting idea, jmg. This could reduce logic needed slightly.
    jmg wrote: »
    rogloh wrote: »
    The data guard band needs to be able to send 10'b0100110011 for two of the channels.
    The video guard band needs to be abled to send 10'b1011001100 and 10'b0100110011.
    The actual 10bit values for the TERC4 4 bit mappings I believe are found in the code below.

    Do those ever send adjacent ?
    Could a optional direct 10b pathway, as I suggest above, cover those, without needing the extra verilog to hard-code them ?

    Video guard band has 10'b1011001100 on channels 0 (B) & 2 (R) and 10'b0100110011 on channel 1 (G) at the same time.
  • Adding just the basics was approx +2 percent logic.
  • roglohrogloh Posts: 4,588
    edited 2018-10-17 00:47
    @jmg,

    In terms of adjacency well you need to be able to switch from sending the SYNC preambles to a guard band pattern to a bunch of TERC4 encoded 10b symbols to guard band to preamble to guard band to active video on a minimum of 2 pixel boundaries if you want to support HDMI data packets being mixed with the video/sync stuff.

    More accurately, the guard bands have to be 2 pixels wide (same symbol in both pixels). Packets and active video tend to be a multiple of 8 bits.
  • RaymanRayman Posts: 12,914
    Would be great if could do dual-link DVI to get SVGA at 800x600.
    Seems technically feasible but maybe no monitor would take it?
  • Rayman wrote: »
    Would be great if could do dual-link DVI to get SVGA at 800x600.
    Seems technically feasible but maybe no monitor would take it?

    I think most older consumer grade DL-DVI monitors were built for higher resolutions such as 2560x1600 (I have a Dell one), and they don't use DL-DVI for their lower resolutions. Perhaps some monitors software would allow 800x600 using dual link but I don't think the market will be very big. DL-DVI didn't seem to last too long before Display port and HDMI monitor interfaces took over.
  • jmgjmg Posts: 14,979
    rogloh wrote: »
    Video guard band has 10'b1011001100 on channels 0 (B) & 2 (R) and 10'b0100110011 on channel 1 (G) at the same time.

    Ah ok, so my idea can always load 3 x 10b bypass codes for R,G,B and I presume any unused slot has a NOP form ?
    That also simplifies streamer as the feed rate is always the same.
  • TonyB_TonyB_ Posts: 2,001
    edited 2018-10-30 01:27
    jmg wrote: »
    TonyB_ wrote: »
    Video guard band has 10'b1011001100 on channels 0 (B) & 2 (R) and 10'b0100110011 on channel 1 (G) at the same time.

    Ah ok, so my idea can always load 3 x 10b bypass codes for R,G,B and I presume any unused slot has a NOP form ?
    That also simplifies streamer as the feed rate is always the same.

    I wrote first sentence, expanding on what rogloh said.

    If bit 0 of the long were used as the Display Enable (not_Blanking) signal, it could select either:

    24-bit RGB data in bits 31-8 to be converted into three 10-bit symbols by TMDS, or
    3 x 10-bit control symbols in bits 31-2, with no conversion required.
  • jmgjmg Posts: 14,979
    TonyB_ wrote: »
    I wrote first sentence, expanding on what rogloh said.

    If bit 0 of the long were used as the Display Enable (not Blanking) signal, it could select either:

    24-bit RGB data in bits 8-31 to be converted into three 10-bit symbols by TMDS, or
    3 x 10-bit control symbols in bits 2-31, with no conversion required.

    Yup, does that cover all the bases, and save some logic at the same time :) ?

  • Sorry jmg, I misunderstood what you asked about adjacency, but now I know what you meant.

    Yes I think allowing data being streamed out to be able to inject raw 10bit symbols on individual pixel boundaries (differently per channel) would fix all the HDMI formatting issues. If the streamer can do this that would be great. I guess you just need an extra mux to select between serially shifted raw 10bits for that channel read from the 32 bit word or the usual 8b10b mapped RGB output.
  • Cluso99Cluso99 Posts: 18,063
    edited 2018-10-17 01:19
    I am wondering if we could just use smart pins as a UART(s) with a variable number of bits (eg 10 bits). We would need to be able to sync the smart pins though.

    We would effectively be sending 4 bits at 250MHz.

    Should be able to test this out with the current P2 chip, even if it takes 4 cogs to try it.
  • cgraceycgracey Posts: 13,853
    Right. I was just looking over the murky details of audio inclusion and it seems we'd need to be able to put raw 10-bit packets down each lane. No problem, because we have the bits. Here's how it will work:
    rrrrrrrr_gggggggg_bbbbbbbb_xxxxxx00 = 8b/10b pixel encoding
    xxxxxxxx_xxxxxxxx_xxxxxxxx_rrggbb01 = 2b/10b control encoding
    rrrrrrrrrr_gggggggggg_bbbbbbbbbb_1x = raw 10b encoding
    
  • jmgjmg Posts: 14,979
    cgracey wrote: »
    Right. I was just looking over the murky details of audio inclusion and it seems we'd need to be able to put raw 10-bit packets down each lane. No problem, because we have the bits. Here's how it will work:
    rrrrrrrr_gggggggg_bbbbbbbb_xxxxxx00 = 8b/10b pixel encoding
    xxxxxxxx_xxxxxxxx_xxxxxxxx_rrggbb01 = 2b/10b control encoding
    rrrrrrrrrr_gggggggggg_bbbbbbbbbb_1x = raw 10b encoding
    

    Yes, that seems flexible.
    Can the middle line, be swallowed into the bottom line, if that saves significant logic ?
  • Perfection. :smile:
  • cgraceycgracey Posts: 13,853
    jmg wrote: »
    cgracey wrote: »
    Right. I was just looking over the murky details of audio inclusion and it seems we'd need to be able to put raw 10-bit packets down each lane. No problem, because we have the bits. Here's how it will work:
    rrrrrrrr_gggggggg_bbbbbbbb_xxxxxx00 = 8b/10b pixel encoding
    xxxxxxxx_xxxxxxxx_xxxxxxxx_rrggbb01 = 2b/10b control encoding
    rrrrrrrrrr_gggggggggg_bbbbbbbbbb_1x = raw 10b encoding
    

    Yes, that seems flexible.
    Can the middle line, be swallowed into the bottom line, if that saves significant logic ?

    Good point! Yes, it can, and might as well be.
  • cgraceycgracey Posts: 13,853
    So, here is all we need:
    rrrrrrrr_gggggggg_bbbbbbbb_xxxxxxx0 = 8b/10b pixel encoding
    rrrrrrrrrr_gggggggggg_bbbbbbbbbb_x1 = raw 10b encoding
    
  • TonyB_TonyB_ Posts: 2,001
    edited 2018-10-17 01:38
    cgracey wrote: »
    So, here is all we need:
    rrrrrrrr_gggggggg_bbbbbbbb_xxxxxxx0 = 8b/10b pixel encoding
    rrrrrrrrrr_gggggggggg_bbbbbbbbbb_x1 = raw 10b encoding
    

    Or this?
    RRRRRRRR_GGGGGGGG_BBBBBBBB_xxxxxxx0 = RGB 8b/10b pixel encoding
    rrrrrrrrrr_gggggggggg_bbbbbbbbbb_x1 = raw 10b encoding
    
  • cgraceycgracey Posts: 13,853
    That would be better.
  • This is sounding pretty cool. How many HDMI displays can a P2 drive at the same time?
  • cgraceycgracey Posts: 13,853
    David Betz wrote: »
    This is sounding pretty cool. How many HDMI displays can a P2 drive at the same time?

    Eight.
  • There is a demo...
  • cgracey wrote: »
    David Betz wrote: »
    This is sounding pretty cool. How many HDMI displays can a P2 drive at the same time?

    Eight.
    Wow! Maybe JRetSapDoog can make an HDMI version of his WordFire/Quby four screen game console. This is 640x480, right?
  • cgraceycgracey Posts: 13,853
    edited 2018-10-17 02:03
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    This is sounding pretty cool. How many HDMI displays can a P2 drive at the same time?

    Eight.
    Wow! Maybe JRetSapDoog can make an HDMI version of his WordFire/Quby four screen game console. This is 640x480, right?

    Yes, but to get unique screens at that resolution, you'd have to use a tile mode to conserve memory.

    640*480 could be realized as 80x60 of 8x8-pixel tiles. That would only be 4800 bytes for 8-bit tile pointers or 9600 bytes for 16-bit tile pointers. 9600 bytes * 8 screens = 76,800 bytes. That's only ~15% of P2 hub RAM. Then, you'd need the tile definitions, which would be 64 bytes per for 8bpp tiles.
  • Oh here we go racing the beam HDMI Style...
  • Hey since we're on the topic, do any of those extra control functions mentioned and plan for do things like switch aspect ratio?

  • cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    This is sounding pretty cool. How many HDMI displays can a P2 drive at the same time?

    Eight.
    Wow! Maybe JRetSapDoog can make an HDMI version of his WordFire/Quby four screen game console. This is 640x480, right?

    Yes, but to get unique screens at that resolution, you'd have to use a tile mode to conserve memory.

    640*480 could be realized as 80x60 of 8x8-pixel tiles. That would only be 4800 bytes for 8-bit tile pointers or 9600 bytes for 16-bit tile pointers. 9600 bytes * 8 screens = 76,800 bytes. That's only ~15% of P2 hub RAM. Then, you'd need the tile definitions, which would be 64 bytes per for 8bpp tiles.
    That shouldn't be much of a problem since his console is primarily for word games. Tile graphics should be interesting as well.

Sign In or Register to comment.