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.
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 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 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?
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 ?
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
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...
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
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.
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)
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:
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.
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.
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 ?
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:
Better add a resistor between the NPN collector and the PNP base.
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 ?
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.
Comments
Question:
Does the HDMI logic support pixel repetition? E.g. TMDS clock = 250MHz and pixel clock = 12.5MHz for 320x240 source.
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.
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.
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...
Nice!
Well, that can be abused for a quick flat shaded fill mode too.
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?
Doesn't it have to be the 4-bit one...
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 ?
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
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
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.
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)
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:
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:
So, you can go from GND to VIO in 16 steps of 220mV.
Is HDMI purely digital still?
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.
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:
Better add a resistor between the NPN collector and the PNP base.
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}) endmoduleHere 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 8And 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 clockI think encod has not been amended from the first idea at the top and should be:
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.