At these clock speeds, a lot to be dynamically drawn and computed. Will get a lot more out of the Hub and ext RAM than we think right now
I wonder how many COGs would be needed for basic 80x25/50/60 text mode with colour over simple DVI? Would two be enough with one streaming and the other rendering? I take it one COG doing all this is "impossible"?
Aspect ratio can be notified/controlled using the HDMI data packets.
Cool.
Chip, is the color engine still in play,?
No. It processes data going to the DAC channels, not the pins.
That is still going on, however. I need to make sure I do not have any conflict between the VGA H sync and the HDMI special signaling. That way, HDMI and VGA could both be put out simultaneously.
Chip, what about streaming frame buffers from external memory and feeding that to the HDMI streamer? Then we could have full bitmap graphics for multiple displays (not 8, but 2-4 would work I think?
Chip, what about streaming frame buffers from external memory and feeding that to the HDMI streamer? Then we could have full bitmap graphics for multiple displays (not 8, but 2-4 would work I think?
Yes, if we were to get HyperRAM working we should be able to do that.
Chip, what about streaming frame buffers from external memory and feeding that to the HDMI streamer? Then we could have full bitmap graphics for multiple displays (not 8, but 2-4 would work I think?
Yes, if we were to get HyperRAM working we should be able to do that.
How does the HDMI support interact with LUT use ?
eg if you enable LUT for RGB, does that make mixing in controls harder ?
There are now 45MHz 1M/2M/4MBit SPI 8 pin memories, as well as various DRAM in 8 pins, 32Mb/64Mb (84MHz), with QSPI interfaces.
Users might connects 2 or 4 of those to a P2 ?
HDMI is a final translation of pin output states from the streamer. LUT happens earlier.
Right, so if a system needed a mix of LUT and control, you would just subtract a few entries in the palette, to reserve as control-carriers.
eg a 256 LUT could cover 240 colours and 16 controls - that's sounding quite workable with 2x Quad memories ?
HDMI is a final translation of pin output states from the streamer. LUT happens earlier.
Right, so if a system needed a mix of LUT and control, you would just subtract a few entries in the palette, to reserve as control-carriers.
eg a 256 LUT could cover 240 colours and 16 controls - that's sounding quite workable with 2x Quad memories ?
HDCP Is need for an "HDMI" commercial screen by HDMI law.
How do you get handle this.
DVI do not need HDCP to get the Norm.
HDCP is controlled from the transmitter which can refuse to send protected content if the receiver fails to authenticate.
As I understand it, receivers will not refuse to work if the content is sent unencrypted, so there shouldn't be a problem.
If the P2 included the ability to be a HDMI receiver there might be problems.
HDCP is just about the most flawed encryption ever, competing for that title with the DVDCSS system. It's well known that cheap HDMI splitters can decrypt HDCP-protected signals, as the chinese people that designed them just plopped an HDMI receiver that can decrypt HDCP (likely intended for use in monitors) back-to-back with two transmitters. Oh, and it's so cryptographically weak that impersonating a device is easy and even the master key has been reverse engineered. Good job, HDMI standard people. Really spent that money well.
Chip, I misunderstood the whole thing... I thought you were simply trying to do HDMI in SW with the existing features, using the LUT ram for 8B/10B and the smartpins as serializers... *NOT* adding more stuff to the FPGA
"Star Trek: The Wrath of Ken" in 3, 2, 1...
Chip, I misunderstood the whole thing... I thought you were simply trying to do HDMI in SW with the existing features, using the LUT ram for 8B/10B and the smartpins as serializers... *NOT* adding more stuff to the FPGA
"Star Trek: The Wrath of Ken" in 3, 2, 1...
Ken knows and he's happy about it. Otherwise, I wouldn't have told him.
340MHz is comfortable for the P2 I find and the problem at 360 is more to do with regulation so 340 would seem more like the safe limit and 250MHz seems very comfortable.
Will we be able to get by with series resistors to interface to HDMI or will P2A directly interface do you think?
It's great that it includes so many video options ! The only problem is that now that you can do 250MHz, ADC, DAC, and 8/10b you almost have a way to do Gigabit Ethernet too ... And if you include hyperRAM support then it could do very useful applications.
340MHz is comfortable for the P2 I find and the problem at 360 is more to do with regulation so 340 would seem more like the safe limit and 250MHz seems very comfortable.
Will we be able to get by with series resistors to interface to HDMI or will P2A directly interface do you think?
I've found a design that has a 270 ohm series resistor on each +/- output to emulate a CML transmitter using 3.3V LVCMOS.
If I understand correctly, the 8b=>10b mapping has a goal of balancing the number of 1s and 0s (to get a DC-balanced stream overall). They have a concept of "disparity neutral" (perfectly balanced), and not all 8b values can map to a neutral 10b value. For bytes that map to a +2 or -2 disparity, there is a running total kept in the encoder, and the next time a non-neutral value gets encoded the encoder is supposed to pick an encoding that brings the disparity back to 0.
Now, if you are willing to not actually require the full 8 bits, you could probably get away with a single LUT that only encodes to the nearest disparity neutral mapping, then you wouldn't have to track disparity and correct for it on the fly. It looks like you could get 120 values that map to neutral 10b encodings, so that is almost 7 bits of color information per channel, though I have no idea how evenly distributed those 120 values are.
If I understand correctly, the 8b=>10b mapping has a goal of balancing the number of 1s and 0s (to get a DC-balanced stream overall). They have a concept of "disparity neutral" (perfectly balanced), and not all 8b values can map to a neutral 10b value. For bytes that map to a +2 or -2 disparity, there is a running total kept in the encoder, and the next time a non-neutral value gets encoded the encoder is supposed to pick an encoding that brings the disparity back to 0.
Now, if you are willing to not actually require the full 8 bits, you could probably get away with a single LUT that only encodes to the nearest disparity neutral mapping, then you wouldn't have to track disparity and correct for it on the fly. It looks like you could get 120 values that map to neutral 10b encodings, so that is almost 7 bits of color information per channel, though I have no idea how evenly distributed those 120 values are.
Jonathan
TMDS stands for transition-minimized differential signalling. So, their goal is to minimize the number of state changes. The transmitter must keep a 4-bit accumulator to track where things are, so that an appropriate 10-bit pattern can be picked to convey the next 8 bits' worth of data. It seems that on the receiver side, however, the decoding is much simpler, and no attention is really paid to whether or not transitions have actually been minimized. It seems that the transmitter just worries about this. So, it might be possible to even forego the transition minimization - unless it disrupts the data in a way where the receiver won't be able to sync to it. You wouldn't pass compliance tests, either. I'll do it all the way correctly, anyway.
How to deal with running-disparity, to get it DC free?
The streamer can not run a sum and then select which nibble to select trying to get to -+0
Maybe Just create a 8b/10b table that is half -1 and Half +1 and then just go for it, hoping for the best?
Or just use colors that are dc free?, there are 18 of those in the 5b/6b encoding part,
but only 4 of those in the 3b/4b, so hopefully that is the least significant bits of the rgb.
Safely only use these 72 colors then?
This is using both balanced portions of the encoding (as it splits the byte into 3-bit and 5-bit portions), I think you can actually have some more balanced encodings taking them as a whole.
Chip, I misunderstood the whole thing... I thought you were simply trying to do HDMI in SW with the existing features, using the LUT ram for 8B/10B and the smartpins as serializers... *NOT* adding more stuff to the FPGA
"Star Trek: The Wrath of Ken" in 3, 2, 1...
Ken knows and he's happy about it. Otherwise, I wouldn't have told him.
Comments
I would think that monitors would figure it out, just like they do for VGA signals.
Cool.
Chip, is the color engine still in play,?
I wonder how many COGs would be needed for basic 80x25/50/60 text mode with colour over simple DVI? Would two be enough with one streaming and the other rendering? I take it one COG doing all this is "impossible"?
No. It processes data going to the DAC channels, not the pins.
That is still going on, however. I need to make sure I do not have any conflict between the VGA H sync and the HDMI special signaling. That way, HDMI and VGA could both be put out simultaneously.
Yes, if we were to get HyperRAM working we should be able to do that.
Chip, you read my mind.
How does the HDMI support interact with LUT use ?
eg if you enable LUT for RGB, does that make mixing in controls harder ?
There are now 45MHz 1M/2M/4MBit SPI 8 pin memories, as well as various DRAM in 8 pins, 32Mb/64Mb (84MHz), with QSPI interfaces.
Users might connects 2 or 4 of those to a P2 ?
Right, so if a system needed a mix of LUT and control, you would just subtract a few entries in the palette, to reserve as control-carriers.
eg a 256 LUT could cover 240 colours and 16 controls - that's sounding quite workable with 2x Quad memories ?
Yes, all that would be possible.
HDCP = High-bandwidth Digital Content Protection
HDCP Is need for an "HDMI" commercial screen by HDMI law.
How do you get handle this.
DVI do not need HDCP to get the Norm.
HDCP is controlled from the transmitter which can refuse to send protected content if the receiver fails to authenticate.
As I understand it, receivers will not refuse to work if the content is sent unencrypted, so there shouldn't be a problem.
If the P2 included the ability to be a HDMI receiver there might be problems.
"Star Trek: The Wrath of Ken" in 3, 2, 1...
Ken knows and he's happy about it. Otherwise, I wouldn't have told him.
That seems fairly close to the 300 MHz where things go haywire, right?
Will we be able to get by with series resistors to interface to HDMI or will P2A directly interface do you think?
I've found a design that has a 270 ohm series resistor on each +/- output to emulate a CML transmitter using 3.3V LVCMOS.
Now, if you are willing to not actually require the full 8 bits, you could probably get away with a single LUT that only encodes to the nearest disparity neutral mapping, then you wouldn't have to track disparity and correct for it on the fly. It looks like you could get 120 values that map to neutral 10b encodings, so that is almost 7 bits of color information per channel, though I have no idea how evenly distributed those 120 values are.
Jonathan
TMDS stands for transition-minimized differential signalling. So, their goal is to minimize the number of state changes. The transmitter must keep a 4-bit accumulator to track where things are, so that an appropriate 10-bit pattern can be picked to convey the next 8 bits' worth of data. It seems that on the receiver side, however, the decoding is much simpler, and no attention is really paid to whether or not transitions have actually been minimized. It seems that the transmitter just worries about this. So, it might be possible to even forego the transition minimization - unless it disrupts the data in a way where the receiver won't be able to sync to it. You wouldn't pass compliance tests, either. I'll do it all the way correctly, anyway.
How to deal with running-disparity, to get it DC free?
The streamer can not run a sum and then select which nibble to select trying to get to -+0
Maybe Just create a 8b/10b table that is half -1 and Half +1 and then just go for it, hoping for the best?
Or just use colors that are dc free?, there are 18 of those in the 5b/6b encoding part,
but only 4 of those in the 3b/4b, so hopefully that is the least significant bits of the rgb.
Safely only use these 72 colors then?
Would "level balancing" make sense during blanking?
For that matter, is there blanking per scanline and or per frame?
For us analog guys, anyone have a link to somewhat digestable information on these digital streams?
I am looking forward to a proper play with all this.
35 37 38 39 41 42 43 44 45 46 49 50 51 52 53 54 56 57 58 60
67 69 70 71 73 74 75 76 77 78 81 82 83 84 85 86 88 89 90 92
99 101 102 103 105 106 107 108 109 110 113 114 115 116 117 118 120 121 122 124
131 133 134 135 137 138 139 140 141 142 145 146 147 148 149 150 152 153 154 156
163 165 166 167 169 170 171 172 173 174 177 178 179 180 181 182 184 185 186 188
195 197 198 199 201 202 203 204 205 206 209 210 211 212 213 214 216 217 218 220
This is using both balanced portions of the encoding (as it splits the byte into 3-bit and 5-bit portions), I think you can actually have some more balanced encodings taking them as a whole.
Jonathan
ROFLOL ;-) Good one.