Shop Learn
HDMI added to Prop2 - Page 8 — Parallax Forums

HDMI added to Prop2

1568101121

Comments

  • TonyB_TonyB_ Posts: 1,674
    edited 2018-10-19 19:27
    Decoding the TMDS 10-bit outputs reproduces the 8-bit inputs here.

    Question:
    Does the HDMI logic support pixel repetition? E.g. TMDS clock = 250MHz and pixel clock = 12.5MHz for 320x240 source.
  • Not currently.

    In the analog space, this is trivial. Works great. Just pick your pixel clock and go. Simple bitmap support is just a loop, with the sync and bits needed to make a frame, or frames for interlaced display.

    However, at 250Mhz, there is more than enough time to prep the pixels into a line RAM buffer for streaming out to HDMI. May even get it all done during the porch, leaving time for sprites, or other things, like tiles, characters.

    Was +2 percent for what we got. I personally feel it's totally worth it, but the design was right up against maximums. OnSemi does need some amount for their testing, and I hope that can flex some, or these features will come at a cost in the near future.

  • cgraceycgracey Posts: 13,554
    TonyB_ wrote: »
    Decoding the TMDS 10-bit outputs reproduces the 8-bit inputs here.

    Question:
    Does the HDMI logic support pixel repetition? E.g. TMDS clock = 250MHz and pixel clock = 12.5MHz for 320x240 source.

    Yes. If a new 10-clock frame starts and there's no new data, it repeats the last value, updating the ones' accumulator for 8b video data.
  • cgraceycgracey Posts: 13,554
    edited 2018-10-19 20:28
    I made a modification to the smart pin logic to facilitate LVDS output.

    There is a binary DAC output mode, where you can have the pin output highs and lows using the DAC setting for 'high' and $00 for 'low'.

    I changed it around so that in binary DAC output mode, a high is {P[7:4],P[7:4]} and a low is {P[3:0],P[3:0]}. This way, you can set the high and low output values, separately, to 4-bit resolution.

    This will allow us to use 123.75-ohm DAC mode as a digital output that toggles between, say, $FF for high and $CC for low, keeping the activity up near VIO. In that case, you would set the DAC value to $FC. This way, we won't need current-limiting resistors and you can set any kind of output levels you want for high and low.

    Question: Might it be better to use P[0] to signify GIO- or VIO-based toggling, and then P[7:1] can give us 7-bit resolution on amplitude. What I just made lets you do any crazy combo (low = 2V, high = 1V), but we only get 4 bits of resolution in our settings (3.3V/16 = ~206mV), whereas 7 bits would give us ~26mV steps (3.3V/128).

    I'm going to test it in a minute here...
  • Wait! I somehow thought more than one pixel was involved. At 250, it is just 10 clocks per individual pixel. Doh!

    Nice!

    Well, that can be abused for a quick flat shaded fill mode too. :D
  • cgracey wrote: »
    I made a modification to the smart pin logic to facilitate LVDS output.

    There is a binary DAC output mode, where you can have the pin output highs and lows using the DAC setting for 'high' and $00 for 'low'.

    I changed it around so that in binary DAC output mode, a high is {P[7:4],P[7:4]} and a low is {P[3:0],P[3:0]}. This way, you can set the high and low output values, separately, to 4-bit resolution.

    This will allow us to use 123.75-ohm DAC mode as a digital output that toggles between, say, $FF for high and $CC for low, keeping the activity up near VIO. In that case, you would set the DAC value to $FC.

    I'm going to test it in a minute here...

    Neat. So thats ~0.2v steps for a 3v3 VIO
  • cgraceycgracey Posts: 13,554
    Tubular wrote: »
    cgracey wrote: »
    I made a modification to the smart pin logic to facilitate LVDS output.

    There is a binary DAC output mode, where you can have the pin output highs and lows using the DAC setting for 'high' and $00 for 'low'.

    I changed it around so that in binary DAC output mode, a high is {P[7:4],P[7:4]} and a low is {P[3:0],P[3:0]}. This way, you can set the high and low output values, separately, to 4-bit resolution.

    This will allow us to use 123.75-ohm DAC mode as a digital output that toggles between, say, $FF for high and $CC for low, keeping the activity up near VIO. In that case, you would set the DAC value to $FC.

    I'm going to test it in a minute here...

    Neat. So thats ~0.2v steps for a 3v3 VIO

    Yes. I added more to that post. What do you think about biasing the binary DAC output modes against either GIO or VIO for 7-bit resolution, or is two random 4-bit levels better to have?
  • RaymanRayman Posts: 11,932
    You need to toggle between 1.0 and 1.4V for LVDS, right?
    Doesn't it have to be the 4-bit one...
  • jmgjmg Posts: 14,640
    cgracey wrote: »
    This will allow us to use 123.75-ohm DAC mode as a digital output that toggles between, say, $FF for high and $CC for low, keeping the activity up near VIO. In that case, you would set the DAC value to $FC. This way, we won't need current-limiting resistors and you can set any kind of output levels you want for high and low.

    Question: Might it be better to use P[0] to signify GIO- or VIO-based toggling, and then P[7:1] can give us 7-bit resolution on amplitude. What I just made lets you do any crazy combo (low = 2V, high = 1V), but we only get 4 bits of resolution in our settings (3.3V/16 = ~206mV), whereas 7 bits would give us ~26mV steps (3.3V/128).

    I'm going to test it in a minute here...

    I'm not quite following.
    You can still output differential digital, on two pins, right ? (saving the DAC power and added jitter)

    This is some additional DAC mode ? Does it change/affect any existing DAC modes ?

    The single bit to flag VIO/GIO sounds useful, as this could be used for Logic threshold testing - is this only in HDMI path, or is this a new DAC mode for general use ?
  • jmgjmg Posts: 14,640
    edited 2018-10-19 21:24
    Rayman wrote: »
    You need to toggle between 1.0 and 1.4V for LVDS, right?
    Doesn't it have to be the 4-bit one...

    LVDS receivers can usually work down to GND, with some common mode upper limit. **
    - but the HDMI spec says 3.3V and 500mV down from there (10mA/50ohms)
    I guess that's to allow the stronger N-MOSFETS to be used as drivers.


    A variant of the 4-bit mode, could be a coarse/fine split, so the upper bits set the logic base point in 206mV steps, and the lower bits are modulated onto that, allowing ?? mv steps.
    eg If you wanted to allow up to 800mV of modulation, that's then 50mV steps ?

    ** Addit:
    Checking FIN1002 (LVDS RX), that has 0~2.4V common mode window, with 3.0V~3.6V Vcc, and the differential signal > 100mV, keeping inside the common mode limits
  • RaymanRayman Posts: 11,932
    edited 2018-10-19 22:14
    If 2.4V is allowed, couldn't you just put ~1k resistors on both pins?
    Seems that could give you the right voltage range on the 100 Ohm resistor at end of the line...
    I guess that might slow it down some though...
  • jmgjmg Posts: 14,640
    Rayman wrote: »
    If 2.4V is allowed, couldn't you just put ~1k resistors on both pins?
    Seems that could give you the right voltage range on the 100 Ohm resistor at end of the line...
    I guess that might slow it down some though...

    330 ohms from both differential pins, should give ~ 10mA for HDMI (+ve terminated) or LVDS (gnd terminated)
    Buys a little ESD protection for free too :)
  • jmg wrote: »
    cgracey wrote: »
    This will allow us to use 123.75-ohm DAC mode as a digital output that toggles between, say, $FF for high and $CC for low, keeping the activity up near VIO. In that case, you would set the DAC value to $FC. This way, we won't need current-limiting resistors and you can set any kind of output levels you want for high and low.

    Question: Might it be better to use P[0] to signify GIO- or VIO-based toggling, and then P[7:1] can give us 7-bit resolution on amplitude. What I just made lets you do any crazy combo (low = 2V, high = 1V), but we only get 4 bits of resolution in our settings (3.3V/16 = ~206mV), whereas 7 bits would give us ~26mV steps (3.3V/128).

    I'm going to test it in a minute here...

    I'm not quite following.
    You can still output differential digital, on two pins, right ? (saving the DAC power and added jitter)

    This is some additional DAC mode ? Does it change/affect any existing DAC modes ?

    The single bit to flag VIO/GIO sounds useful, as this could be used for Logic threshold testing - is this only in HDMI path, or is this a new DAC mode for general use ?

    I think Chip is talking about modifying what the doc calls 'BIT_DAC' mode for LVDS output. I'm no expert but it seems that HDMI and LVDS could use differential digital with the appropriate series resistors.

  • cgracey wrote: »
    Tubular wrote: »
    cgracey wrote: »
    I made a modification to the smart pin logic to facilitate LVDS output.

    There is a binary DAC output mode, where you can have the pin output highs and lows using the DAC setting for 'high' and $00 for 'low'.

    I changed it around so that in binary DAC output mode, a high is {P[7:4],P[7:4]} and a low is {P[3:0],P[3:0]}. This way, you can set the high and low output values, separately, to 4-bit resolution.

    This will allow us to use 123.75-ohm DAC mode as a digital output that toggles between, say, $FF for high and $CC for low, keeping the activity up near VIO. In that case, you would set the DAC value to $FC.

    I'm going to test it in a minute here...

    Neat. So thats ~0.2v steps for a 3v3 VIO

    Yes. I added more to that post. What do you think about biasing the binary DAC output modes against either GIO or VIO for 7-bit resolution, or is two random 4-bit levels better to have?

    Probably the most general case (two 4 bit levels) is the most useful, I think. There will be other uses for this mode, I think, and I think 200mV granularity is fine.

    How does the translation work - %0000 becomes %00000000 but %FFFF becomes %FFFF0000 (3.11V) ? Or would it be better to add 0.1V offset so
    %0000 becomes %00001000 (~104mV) and
    %1111 becomes %11111000 (~3.2V)

  • TonyB_TonyB_ Posts: 1,674
    edited 2018-10-19 23:31
    jmg wrote: »
    Rayman wrote: »
    If 2.4V is allowed, couldn't you just put ~1k resistors on both pins?
    Seems that could give you the right voltage range on the 100 Ohm resistor at end of the line...
    I guess that might slow it down some though...

    330 ohms from both differential pins, should give ~ 10mA for HDMI (+ve terminated) or LVDS (gnd terminated)
    Buys a little ESD protection for free too :)

    From studying the docs, HDMI receivers have 50 ohm pull-up resistors to 3.3V on the inputs and LVDS receivers 100 ohm across the inputs. These are equivalent when calculating the series resistor value R on the P2 outputs for a particular differential voltage Vdiff at the receiver. I reckon:
    Vdiff	R	
    0.4	360-330		LVDS
    0.8	150		HDMI
    1.0	110-100		HDMI
    
  • cgraceycgracey Posts: 13,554
    Tubular wrote: »
    cgracey wrote: »
    Tubular wrote: »
    cgracey wrote: »
    I made a modification to the smart pin logic to facilitate LVDS output.

    There is a binary DAC output mode, where you can have the pin output highs and lows using the DAC setting for 'high' and $00 for 'low'.

    I changed it around so that in binary DAC output mode, a high is {P[7:4],P[7:4]} and a low is {P[3:0],P[3:0]}. This way, you can set the high and low output values, separately, to 4-bit resolution.

    This will allow us to use 123.75-ohm DAC mode as a digital output that toggles between, say, $FF for high and $CC for low, keeping the activity up near VIO. In that case, you would set the DAC value to $FC.

    I'm going to test it in a minute here...

    Neat. So thats ~0.2v steps for a 3v3 VIO

    Yes. I added more to that post. What do you think about biasing the binary DAC output modes against either GIO or VIO for 7-bit resolution, or is two random 4-bit levels better to have?

    Probably the most general case (two 4 bit levels) is the most useful, I think. There will be other uses for this mode, I think, and I think 200mV granularity is fine.

    How does the translation work - %0000 becomes %00000000 but %FFFF becomes %FFFF0000 (3.11V) ? Or would it be better to add 0.1V offset so
    %0000 becomes %00001000 (~104mV) and
    %1111 becomes %11111000 (~3.2V)

    You normally have the DAC value stored in P[7:0]. In digital DAC output mode, P[7:4] are used for the high state and P[3:0] are used for the low state.

    When OUT is high, the DAC is set to {P[7:4], P[7:4]}. When OUT is low, the DAC is set to {P[3:0], P[3:0]}.

    The 4-bit values get recast like this:
    %0000 --> $00000000 =  0/15 of 3.3V
    %0001 --> $00010001 =  1/15 of 3.3V
    %0010 --> $00100010 =  2/15 of 3.3V
    %0011 --> $00110011 =  3/15 of 3.3V
    %0100 --> $01000100 =  4/15 of 3.3V
    %0101 --> $01010101 =  5/15 of 3.3V
    %0110 --> $01100110 =  6/15 of 3.3V
    %0111 --> $01110111 =  7/15 of 3.3V
    %1000 --> $10001000 =  8/15 of 3.3V
    %1001 --> $10011001 =  9/15 of 3.3V
    %1010 --> $10101010 = 10/15 of 3.3V
    %1011 --> $10111011 = 11/15 of 3.3V
    %1100 --> $11001100 = 12/15 of 3.3V
    %1101 --> $11011101 = 13/15 of 3.3V
    %1110 --> $11101110 = 14/15 of 3.3V
    %1111 --> $11111111 = 15/15 of 3.3V
    

    So, you can go from GND to VIO in 16 steps of 220mV.
  • Ah yes that's the trick. I remember coming across it when driving TTL LCD displays from reduced bit depth, couldn't quite remember the details of what they did, but what you posted is perfect.
  • cgraceycgracey Posts: 13,554
    The new digital DAC mode works fine. For high-speed digital signalling, I don't think 8-bit precision is needed. 4-bit will be just fine.
  • RaymanRayman Posts: 11,932
    So, will this make talking to 1.8V digital interfaces easier?
  • TonyB_TonyB_ Posts: 1,674
    edited 2018-10-22 20:34
    Including precise voltages:
    %0000 --> $00000000 =  0/15 of 3.3V = 0.00V
    %0001 --> $00010001 =  1/15 of 3.3V = 0.22V
    %0010 --> $00100010 =  2/15 of 3.3V = 0.44V
    %0011 --> $00110011 =  3/15 of 3.3V = 0.66V
    %0100 --> $01000100 =  4/15 of 3.3V = 0.88V
    %0101 --> $01010101 =  5/15 of 3.3V = 1.10V
    %0110 --> $01100110 =  6/15 of 3.3V = 1.32V
    %0111 --> $01110111 =  7/15 of 3.3V = 1.54V
    %1000 --> $10001000 =  8/15 of 3.3V = 1.76V
    %1001 --> $10011001 =  9/15 of 3.3V = 1.98V
    %1010 --> $10101010 = 10/15 of 3.3V = 2.20V
    %1011 --> $10111011 = 11/15 of 3.3V = 2.42V
    %1100 --> $11001100 = 12/15 of 3.3V = 2.64V
    %1101 --> $11011101 = 13/15 of 3.3V = 2.86V
    %1110 --> $11101110 = 14/15 of 3.3V = 3.08V
    %1111 --> $11111111 = 15/15 of 3.3V = 3.30V
    

    Is HDMI purely digital still?
  • jmgjmg Posts: 14,640
    Rayman wrote: »
    So, will this make talking to 1.8V digital interfaces easier?

    Hmm.. Looks like one way at least...
    The Logic IN threshold will still be offset at 1.65v, ie not ideal for 1.8V
  • RaymanRayman Posts: 11,932
    Should be fine for cmos
  • cgraceycgracey Posts: 13,554
    jmg wrote: »
    Rayman wrote: »
    So, will this make talking to 1.8V digital interfaces easier?

    Hmm.. Looks like one way at least...
    The Logic IN threshold will still be offset at 1.65v, ie not ideal for 1.8V

    You can select A>D mode, where D is the internal 8-bit R-2R DAC used for level sensing. You can pick your input logic threshold in 13mV increments then.
  • cgraceycgracey Posts: 13,554
    edited 2018-10-20 04:25
    See the last modes...

    PAD_IO_modes.png
    1223 x 779 - 49K
  • jmgjmg Posts: 14,640
    cgracey wrote: »
    See the last modes...
    Those bottom modes had me a little confused.

    You mention above D here means internal 8-bit R-2R DAC, but that's missing from the table, sounds like a 5th DAC mode (higher resistance again?)
    OUT, 1.5k I expect means soft drive via 1.5k, but where does 1.5k relate to an input, or is that driven as not-feedback, but from the same pin (not a Pin B?) ?
    Two modes look identical, is that a typo, or was there spare space ?

    What is the Tpd of this DAC-Threshold path ?
  • cgraceycgracey Posts: 13,554
    edited 2018-10-20 05:31
    jmg wrote: »
    cgracey wrote: »
    See the last modes...
    Those bottom modes had me a little confused.

    You mention above D here means internal 8-bit R-2R DAC, but that's missing from the table, sounds like a 5th DAC mode (higher resistance again?)
    OUT, 1.5k I expect means soft drive via 1.5k, but where does 1.5k relate to an input, or is that driven as not-feedback, but from the same pin (not a Pin B?) ?
    Two modes look identical, is that a typo, or was there spare space ?

    What is the Tpd of this DAC-Threshold path ?

    This internal DAC only feeds the comparator.

    In those modes, if DIR is high, OUT may drive in 1.5k-ohm mode or the comparator output may drive true or inverted.

    You could use this mode to close a voltage feedback loop around the internal DAC to make a programmable voltage supply, for example. If you use mode %1111_0DDDDDDDD, you could do this:

    vsupply.jpg

    Better add a resistor between the NPN collector and the PNP base.
    1047 x 1093 - 214K
  • cgraceycgracey Posts: 13,554
    edited 2018-10-21 02:56
    I think I've got the HDMI implemented.

    Here is the Verilog code that generates the bitstreams:
    // cog xfr hdmi
    
    module			cog_xfr_hdmi
    (
    input			resn,
    
    input			clk,
    
    input			ena,		// enable
    input			cap,		// capture data
    input		[31:0]	dat,		// data
    
    output reg	 [7:0]	hdmi		// hdmi output
    );
    
    
    // capture pixel data and convert to hdmi (pixel every 10th clock)
    
    reg	 [3:0] cnt;
    reg	[31:0] d;
    
    wire start		=	cap || cnt == 4'h9;
    wire encod		=	!d[1];
    
    `regscan (cnt, 4'b0, ena, start ? 4'b0 : cnt + 1'b1)
    `regscan (d, 32'b0, cap, dat)
    
    reg  [2:0][4:0] bal_old;
    wire [2:0][4:0] bal_new;
    wire [2:0][9:0]	tmds;
    
    cog_xfr_hdmi_tmds cog_xfr_hdmi_tmds_inst2	// red
    	(
    	.d		(d[31:24]),
    	.bal_old	(bal_old[2]),
    	.bal_new	(bal_new[2]),
    	.tmds		(tmds[2]),
    	);
    
     cog_xfr_hdmi_tmds cog_xfr_hdmi_tmds_inst1	// green
    	(
    	.d		(d[23:16]),
    	.bal_old	(bal_old[1]),
    	.bal_new	(bal_new[1]),
    	.tmds		(tmds[1]),
    	);
    
     cog_xfr_hdmi_tmds cog_xfr_hdmi_tmds_inst0	// blue
    	(
    	.d		(d[15:08]),
    	.bal_old	(bal_old[0]),
    	.bal_new	(bal_new[0]),
    	.tmds		(tmds[0]),
    	);
    
    `regscan (bal_old[2], 5'b0, start, encod ? bal_new[2] : 5'b0)
    `regscan (bal_old[1], 5'b0, start, encod ? bal_new[1] : 5'b0)
    `regscan (bal_old[0], 5'b0, start, encod ? bal_new[0] : 5'b0)
    
    wire [9:0] red_pat	=	encod ? tmds[2] : d[31:22];
    wire [9:0] grn_pat	=	encod ? tmds[1] : d[21:12];
    wire [9:0] blu_pat	=	encod ? tmds[0] : d[11:02];
    
    wire red		=	red_pat[cnt];
    wire grn		=	grn_pat[cnt];
    wire blu		=	blu_pat[cnt];
    wire tic		=	cnt < 4'h5;
    
    `regscan (hdmi, 8'b0, ena, {red, !red, grn, !grn, blu, !blu, tic, !tic})
    
    endmodule
    

    Here is the sub-module that translates 8-bit R/G/B color data into 10-bit TMDS:
    // cog xfr hdmi tmds
    
    module			cog_xfr_hdmi_tmds
    (
    input		[7:0]	d,		// r/g/b data
    
    input		[4:0]	bal_old,	// balance in
    output		[4:0]	bal_new,	// balance out
    
    output		[9:0]	tmds		// tmds pattern, lsb first
    );
    
    
    // convert 8-bit color data to 10-bit tmds pattern
    
    wire [3:0] ones_d	=	d[7] + d[6] + d[5] + d[4] + d[3] + d[2] + d[1] + d[0];
    
    wire xnr		=	ones_d > 4'h4 || ones_d == 4'h4 && !d[0];
    
    wire [8:0] m		=	{!xnr, m[6:0] ^ d[7:1] ^ {7{xnr}}, d[0]};
    
    wire [3:0] bal_m 	=	m[7] + m[6] + m[5] + m[4] + m[3] + m[2] + m[1] + m[0] - 4'h4;
    
    
    wire bal_zero		=	~|bal_old || ~|bal_m;
    
    wire bal_sign		=	bal_old[4] == bal_m[3];
    
    wire inv_m		=	bal_zero ? !m[8] : bal_sign;
    
    assign tmds		=	{inv_m, m[8], m[7:0] ^ {8{inv_m}}};
    
    
    wire [4:0] bal_add	=	bal_zero ? !m[8] ? -{bal_m[3:0], 1'b0}
    						 :  {bal_m[3:0], 1'b0}
    			:	bal_sign	 ? -{bal_m[3:0], 1'b0} + {3'b0,  m[8], 1'b0}
    						 :  {bal_m[3:0], 1'b0} - {3'b0, !m[8], 1'b0};
    
    assign bal_new		=	bal_old + bal_add;
    
    endmodule
    
    
    //	bal_m	1's	0's	 1-0's	 0-1's
    //	--------------------------------------
    //	0100	8	0	 8	-8
    //	0011	7	1	 6	-6
    //	0010	6	2	 4	-4
    //	0001	5	3	 2	-2
    //	0000	4	4	 0	 0
    //	1111	3	5	-2	 2
    //	1110	2	6	-4	 4
    //	1101	1	7	-6	 6
    //	1100	0	8	-8	 8
    


    And here's where the HDMI code interfaces into the streamer:
    wire hdmi_ena		=	act[1] && hdmi_mode;	// hdmi enable
    wire hdmi_cap		=	pinu && hdmi_mode;	// hdmi capture
    
    wire [7:0] hdmi;
    
    cog_xfr_hdmi cog_xfr_hdmi_inst				// hdmi encoder
    	(
    	.resn		(resn),
    	.clk		(clk),
    	.ena		(hdmi_ena),
    	.cap		(hdmi_cap),
    	.dat		(dat),
    	.hdmi		(hdmi)
    	);
    
    wire [15:0][31:0] outm	= {	24'b0, datb & 8'h80,	// rfbyte_bits, 1-bit
    				24'b0, datb & 8'h40,
    				24'b0, datb & 8'h20,
    				24'b0, datb & 8'h10,
    				24'b0, datb & 8'h08,
    				24'b0, datb & 8'h04,
    				24'b0, datb & 8'h02,
    				24'b0, datb & 8'h01,
    				24'b0, datb & 8'hC0,	// rfbyte_bits, 2-bit
    				24'b0, datb & 8'h30,
    				24'b0, datb & 8'h0C,
    				24'b0, datb & 8'h03,
    				24'b0, datb & 8'hF0,	// rfbyte_bits, 4-bit
    				24'b0, datb & 8'h0F,
    				hdmi_mode ? {24'b0, hdmi} : dat,	// not rfbyte_bits
    				32'b0 };		// disabled
    
    wire [127:0] outpx	=	{96'b0, outm[pinp[3:0]]} <<	// pin output wraps around
    				{pinp[6:4], 3'b0};
    
    `regscan (outp, 64'b0,
    !ena || pinu || hdmi_ena,				// update pin outputs
    	!ena	?	64'b0
    		:	outpx[127:64] | outpx[63:0])	// outp valid on 4th clock
    
  • Thanks for sharing Chip!
  • cgracey wrote: »
    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.
    cgracey wrote: »
    So, here is all we need:
    rrrrrrrr_gggggggg_bbbbbbbb_xxxxxxx0 = 8b/10b pixel encoding
    rrrrrrrrrr_gggggggggg_bbbbbbbbbb_x1 = raw 10b encoding
    
    cgracey wrote: »
    I think I've got the HDMI implemented.

    Here is the Verilog code that generates the bitstreams:
    ...
    wire encod		=	!d[1];
    ...
    wire [9:0] red_pat	=	encod ? tmds[2] : d[31:22];
    wire [9:0] grn_pat	=	encod ? tmds[1] : d[21:12];
    wire [9:0] blu_pat	=	encod ? tmds[0] : d[11:02];
    ...
    

    I think encod has not been amended from the first idea at the top and should be:
    ...
    wire encod		=	!d[0];
    ...
    
  • cgraceycgracey Posts: 13,554
    edited 2018-10-20 15:29
    TonyB_,

    If we use d[1] then we avoid conflict with d[0] which may be in use by the same driver, in order to generate a concurrent set of VGA signals. It is our only option.
Sign In or Register to comment.