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

HDMI added to Prop2

1246721

Comments

  • cgraceycgracey Posts: 13,588
    edited 2018-10-17 02:18
    potatohead wrote: »
    Hey since we're on the topic, do any of those extra control functions mentioned and plan for do things like switch aspect ratio?

    I would think that monitors would figure it out, just like they do for VGA signals.
  • Aspect ratio can be notified/controlled using the HDMI data packets.
  • 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
  • rogloh wrote: »
    Aspect ratio can be notified/controlled using the HDMI data packets.

    Cool.

    Chip, is the color engine still in play,?
  • potatohead wrote: »
    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"?
  • cgraceycgracey Posts: 13,588
    edited 2018-10-17 02:58
    potatohead wrote: »
    rogloh wrote: »
    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?
  • cgraceycgracey Posts: 13,588
    Roy Eltham wrote: »
    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.
  • way, HDMI and VGA could both be put out simultaneously.

    Chip, you read my mind.
  • jmgjmg Posts: 14,666
    cgracey wrote: »
    Roy Eltham wrote: »
    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 ?
  • cgraceycgracey Posts: 13,588
    HDMI is a final translation of pin output states from the streamer. LUT happens earlier.
  • jmgjmg Posts: 14,666
    cgracey wrote: »
    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 ?
  • cgraceycgracey Posts: 13,588
    jmg wrote: »
    cgracey wrote: »
    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 ?

    Yes, all that would be possible.
  • Remark about HDMI.

    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.

  • Most HDMI displays will work fine without HDCP. HDCP is only required if the SOURCE demands it (like your bluray player does).
  • Ltech wrote: »
    Remark about HDMI.

    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.
  • 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 :flushed:
    "Star Trek: The Wrath of Ken" in 3, 2, 1... :wink:
  • cgraceycgracey Posts: 13,588
    edited 2018-10-17 12:17
    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 :flushed:
    "Star Trek: The Wrath of Ken" in 3, 2, 1... :wink:

    Ken knows and he's happy about it. Otherwise, I wouldn't have told him.
  • RaymanRayman Posts: 11,996
    So I guess 250 MHz is going to be the usual clock frequency...
    That seems fairly close to the 300 MHz where things go haywire, right?
  • 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.
  • cgraceycgracey Posts: 13,588
    edited 2018-10-17 13:15
    If we could later move to a smaller process, 1GHz, or even 2GHz, would be possible. I would love to think that 1,000 instructions take only 1us.
  • TonyB_TonyB_ Posts: 1,720
    edited 2018-10-30 01:33
    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.

    Jonathan
  • cgraceycgracey Posts: 13,588
    edited 2018-10-17 15:11
    lonesock wrote: »
    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.
  • tonyp12tonyp12 Posts: 1,950
    edited 2018-10-17 15:40
    As P2 seems to run at 250MHz, HDMI is great

    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?





  • potatoheadpotatohead Posts: 10,181
    edited 2018-10-17 15:52
    What is the time scale for sync / level losses?

    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.

  • lonesocklonesock Posts: 917
    edited 2018-10-17 16:02
    Here are the 8b values that map to balanced 10b encodings:
    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
  • kwinnkwinn Posts: 8,691
    cgracey wrote: »
    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 :flushed:
    "Star Trek: The Wrath of Ken" in 3, 2, 1... :wink:

    Ken knows and he's happy about it. Otherwise, I wouldn't have told him.

    ROFLOL ;-) Good one.
Sign In or Register to comment.