Shop OBEX P1 Docs P2 Docs Learn Events
HDMI added to Prop2 - Page 11 — Parallax Forums

HDMI added to Prop2

18911131421

Comments

  • Fabulous! :)
  • Cluso99Cluso99 Posts: 18,066
    Fantastic!!!!!!!!!!!!!!!!!!!!!! :smiley:
  • RaymanRayman Posts: 13,797
    Someone should try with a white border to make sure all on screen
  • cgracey wrote: »
    It works!

    I've got the P2 generating the data in memory, then streaming out only three different lines:

    1) display line
    2) hidden line
    3) hidden line with VSYNC

    It's pumping out the 8-bit patterns of {R+, R-, G+, G-, B+, B-, CLK+, CLK-} at 250MHz and one of my desk displays is taking it in, without any special resistors or drive levels - just CMOS outputs.

    Excellent! Perhaps others with a P2 could try further tests, e.g.

    (a) Open-collector outputs with 270 ohm series resistors
    (b) 720 active pixels/line @ 270 MHz
    (c) HDMI mode with video and data islands, including audio!
  • roglohrogloh Posts: 5,122
    edited 2018-10-26 12:06
    cgracey wrote: »

    I think this HDMI thing is done. Now, I'm going to see about clock gating to get dynamic power consumption down.

    Such a great result Chip! It's always great to see DVI coming out with nice gradients for the first time and hopefully in the near future from your own custom Verilog in a P2 respin. Outstanding.

    I really like that it even worked right away without the resistors, that will really bode well for maker types who just want to hack things up quickly and don't care too much about proper signal stuff and will help to push its development faster. Further HDMI features can certainly come later in SW. Maybe I should add some pads for an HDMI connector on my board now!

    Hope the dynamic power effort next is just as successful. Good job.
  • cgraceycgracey Posts: 14,133
    edited 2018-10-26 15:21
    Thanks for all your help, Everyone.

    If I was working alone, I wouldn't have had the time and energy to make this happen, but you provided:

    1) The idea that it could be done
    2) Direction to resources online
    3) Specially-prepared test data for validation
    4) Electrical considerations
    5) Lots of valuable discussion

    This thread now contains unique information that would be quite helpful to anyone doing an implementation of their own. Test patterns couldn't even be found on the internet, but they exist in this thread now. That is great!
  • This thread demonstrates nicely the versatillity of the P2 and the incredible resources available on this forum.
  • jmgjmg Posts: 15,140
    rogloh wrote: »
    ....
    Maybe I should add some pads for an HDMI connector on my board now!

    Good idea, certainly the Parallax P2 Eval Board, needs to grow a HDMI connector now.. :)


  • RaymanRayman Posts: 13,797
    edited 2018-10-28 00:46
    It would be great if can do VGA+Audio over HDMI interface.
    That would seal the deal over analog VGA...

    I have no idea what is involved in the audio encoding.
    I think the bandwidth must be much less than the video though.
    Can this still be done at 250 MHz? Seems we need all of that for 60 Hz VGA...
    Maybe 275 MHz is enough?
  • Audio can be sent during the "data islands", which happen during blanking periods.
  • Looks like the audio is sent during the "back porch". Digging into that myself.
  • Rayman wrote: »
    It would be great if can do VGA+Audio over HDMI interface.
    That would seal the deal over analog VGA...

    I have no idea what is involved in the audio encoding.
    I think the bandwidth must be much less than the video though.
    Can this still be done at 250 MHz? Seems we need all of that for 60 Hz VGA...
    Maybe 275 MHz is enough?

    Yes audio can be done at 250MHz.
  • dMajodMajo Posts: 855
    edited 2018-10-28 02:36
    I have been around for a while and the forum has exploded with new threads/posts .... I have difficulties to synchronize myself :).

    Chip, congrats for the new feature.
    I hope that the gurus here that will put together the HDMI driver will include (I mean to share in the same cog) also CEC (it is only 400 bps one wire I2C ... similar) that could be used as remote input from a TV (eg for a set top box and/or home automation controller).
  • TonyB_TonyB_ Posts: 2,105
    edited 2018-10-28 12:42
    The HDMI spec explains how to divide the TMDS pixel clock to get an audio clock fs using two constants N and CTS, as follows:

    128 * fs = fTMDS_clock * N / CTS

    It has recommended values for various clocks but not for a pixel clock of exactly 25 MHz, so here they are:
    fTMDS_clock = 25.0 MHz
    fs kHz	  N	 CTS
     32.0	 4608	28125
     44.1	 7056	31250
     48.0	 6912	28125
     88.2	14112	31250
     96.0	13824	28125
    176.4	28224	31250
    192.0	27648	28125
    
  • TonyB_ wrote: »
    cgracey wrote: »

    Wow! Good eye. I never noticed that. It would have taken me a long time to figure that out. Thank you.

    How can it be explained that without maintaining the balance, I get proper results?

    Chip, is the routine working now, with the same outputs and disparities as the ascending and descending sequences?

    If you look at the sequences here or here, you can see a non-zero disparity is always followed by zero disparity. I think this is due to the consecutive inputs and doesn't apply when they are more random, e.g.
    0E,1FA, 0,+4
    0F,105,+4, 0
    10,1F0, 0, 0
    
    0E,1FA, 0,+4
    10,1F0,+4,+4
    

    10h is one of 52 byte values that encode to a single 10-bit value, no matter what the disparity input, which is output unchanged. The very regular nature of an up or down counter might explain in part why the erroneous routine had the correct outputs.

    Hmm this got me thinking... if we have 52 combinations per color component that it's basically invariant direct LUT type encoding, wouldn't that perhaps allow for a simplified encoding that could be tried out right now with the help of another cog or two?
    I mean, for example mapping 5:5:5 RGB, 32 levels over 52, plus the sync part?

    Also, a question for Chip: does the 250MHz rate require running the COGs at the same frequency? It is feasible to have, for example, most of the chip running 200/240MHz, and still generate the TDMS stream up to some 320/360MHz until we hit the silicon speed limit?
  • TonyB_TonyB_ Posts: 2,105
    edited 2018-10-28 14:12
    TonyB_ wrote: »
    10h is one of 52 byte values that encode to a single 10-bit value, no matter what the disparity input, which is output unchanged.

    Hmm this got me thinking... if we have 52 combinations per color component that it's basically invariant direct LUT type encoding, wouldn't that perhaps allow for a simplified encoding that could be tried out right now with the help of another cog or two?
    I mean, for example mapping 5:5:5 RGB, 32 levels over 52, plus the sync part?

    Here are the 52 byte values that always encode to a single 10-bit value that has five '1's and five '0's:
    #8b,10b
    10,1F0
    11,10F
    22,11E
    23,1E1
    26,1E2
    27,11D
    2C,1E4
    2D,11B
    36,247
    37,2B8
    38,1E8
    39,117
    44,13C
    45,1C3
    4A,1C6
    4B,139
    54,1CC
    55,133
    5A,263
    5B,29C
    68,1D8
    69,127
    6C,271
    6D,28E
    76,287
    77,278
    88,178
    89,187
    92,18E
    93,171
    96,227
    97,2D8
    A4,19C
    A5,163
    AA,233
    AB,2CC
    B4,239
    B5,2C6
    BA,2C3
    BB,23C
    C6,217
    C7,2E8
    C8,1B8
    C9,147
    D2,21B
    D3,2E4
    D8,21D
    D9,2E2
    DC,2E1
    DD,21E
    EE,20F
    EF,2F0
    

    Some of these codes have been used in a minimal FPGA implementation:
    http://hamsterworks.co.nz/mediawiki/index.php/Minimal_DVI-D

    Two possible sequences for 4:4:4 RGB are
    00*,11,22,36,44,55,68,77,88,97,AA,BB,C9,DD,EE,FF*
    or
    00*,11,22,36,45,55,68,77,88,97,AA,BB,C9,DC,EE,FF*
    

    EDIT:
    * Added 00 and FF to the above, however the 10-bit codes for these two vary depending whether the disparity input is positive, zero or negative as follows
    #8b,10b+,10b0,10b-
    00,100,100,3FF
    FF,200,200,0FF
    
  • The addition of HDMI is super useful. Being able to output via composite, VGA, and HDMI covers about every TV/monitor option that someone would want to use. This is really exciting!
  • The addition of HDMI is super useful. Being able to output via composite, VGA, and HDMI covers about every TV/monitor option that someone would want to use. This is really exciting!

    Yep, also for versatility if you use a DVI-I as the video connector you can get passive adapters/cables to allow all these formats to be supported by the same port which I think could be rather handy at times as it basically supports everything:

    - analog VGA
    - component
    - composite / s-video
    - DVI
    - HDMI (no CEC, but still potentially including audio)

  • rogloh wrote: »

    - HDMI (no CEC, but still potentially including audio)

    Uh, CEC is separate from the HDMI signalling, so you could implement that in a separate cog.

    From the Wikipedia page:

    CEC is a separate electrical signal from the other HDMI signals. This allows a device to disable its high-speed HDMI circuitry in sleep mode, but be woken up by CEC. It is a single shared bus, which is directly connected between all HDMI ports on a device, so it can flow through a device which is completely powered off (not just asleep).

    The bus is electrically identical to the AV.link protocol, but CEC adds a detailed higher-level message protocol.

    The bus is an open-collector line, somewhat like I²C, passively pulled up to +3.3 V, and driven low to transmit a bit.
  • What I meant above was that CEC is not possible using a DVI-I connector, as there is no pin for it. It could be done with a proper HDMI connector however.
  • roglohrogloh Posts: 5,122
    edited 2018-10-28 23:26
    Speaking of connectors, one of my concerns about the HDMI footprint is the pin order for P2 HDMI. I trust the order Chip puts out the 3 TMDS pairs DATA0, DATA1, DATA2 and CLOCK pairs on an 8 pin group lines up nicely with the HDMI connector order so all the lines don't have to be crossed with vias on PCBs etc - probably needs to be double-checked to ensure this is the case.

    UPDATE: just re-read first post. Looks like Chip thought about it already - cool!
  • cgraceycgracey Posts: 14,133
    I was just wondering if the monitor really cares about getting a "balanced" HDMI signal. I inserted an "RET" into the code where the balance compensation was computed and then ran the program. Monitor DOES NOT care!
  • RaymanRayman Posts: 13,797
    I wonder what the concern for balance is...
    Maybe with super long cables you can store a lot of charge in the capacitance of the cable that may cause EMI type event on disconnect?
  • Eventually, the need to ensure compatibility with DVI standards, at its minimum System Low Pixel Formal Requirement, forced they to don't push it too hard.

    cs.unc.edu/~stc/FAQs/Video/dvi_spec-V1_0.pdf

    (read at page 14, 2.2.4 Low Pixel Format Support)

    I'm trying to check if there are any other possibilities for other low frequency modes, e. g., interlaced @ 13.5 MHz and non-interlaced @ 27.0 MHz.
  • YanomaniYanomani Posts: 1,524
    edited 2018-10-29 19:49
    Eh eh eh, another gem! I love reading specs....

    page 18, 2.3.1, under Minimum frequency supported...

    "The DVI link can be considered inactive if the T.M.D.S clock transitions at less that 22.5 MHz for more than 1 second

    This is new, at least to me

    Does this means we could lower the clock frequency till @ 225 MHz, and the display SHOULD be kept operational, though the pixels would become a tad "longer", in the horizontal direction?

    Maybe I'm loosing something?
  • jmgjmg Posts: 15,140
    Yanomani wrote: »
    Eh eh eh, another gem! I love reading specs....

    page 18, 2.3.1, under Minimum frequency supported...

    "The DVI link can be considered inactive if the T.M.D.S clock transitions at less that 22.5 MHz for more than 1 second

    This is new, at least to me

    Does this means we could lower the clock frequency till @ 225 MHz, and the display SHOULD be kept operational, though the pixels would become a tad "longer", in the horizontal direction?

    Maybe I'm loosing something?

    That makes sense, it sounds like a margin on the nominal 25MHz - so they have to define some corner below that.

    Individual vendors may go even lower.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I was just wondering if the monitor really cares about getting a "balanced" HDMI signal. I inserted an "RET" into the code where the balance compensation was computed and then ran the program. Monitor DOES NOT care!

    It seems some use AC coupling to those 50 ohm pullups to 3v3 (mentioned in a post above), and with lower voltage FPGA/ASICs I can see that would save level shifters, and GHz level shifters are not going to be nice...

    So I'd say the balanced fixups are there to keep the eye diagrams best, when AC coupled, especially at the upper end of the scale.

    Another possible issue : Has anyone checked for phantom powering effects, from those 50 ohms to 3v3 in HDMI ?

    That may be another reason to select AC coupling ?
  • YanomaniYanomani Posts: 1,524
    edited 2018-10-29 20:26
    jmg wrote: »
    That makes sense, it sounds like a margin on the nominal 25MHz - so they have to define some corner below that.

    Individual vendors may go even lower.

    CTA (Consumer Technology Association) standard - CTA-861-G (November 2016) seems to enforce the acception of the following Video Timings, as a minimum:

    640x480p @ 59.94/60Hz;
    720x480p @ 59.94/60Hz;
    720x576p @ 50Hz.

    https://glenwing.github.io/docs/CTA-861-G.pdf

    (page 24, 3.1 General Video Requirements for Sources)

    It's a Huge reading (215 pages) but it seems that the low res formats are someway relaxed througout many standards, in order to ensure a baseline to easy adoption.

    At the end of the day, I believe that reality bytes bites, and a consumer is expected to be very angry if that new and fancy video wichever didn't show any image at all, at none of the resolutions the owner tryes to use it.

  • tonyp12tonyp12 Posts: 1,950
    edited 2018-10-29 20:33
    Make sure P2 pinouts does line up as to avoid via's and crossing of traces:


    744 x 549 - 52K
    1000 x 800 - 244K
  • cgraceycgracey Posts: 14,133
    tonyp12 wrote: »
    Make sure P2 pinouts does line up as to avoid via's and crossing of traces:


    I think I've got it:

    P7 = R+
    P6 = R-
    P5 = G+
    P4 = G-
    P3 = B+
    P2 = B-
    P1 = CLK+
    P0 = CLK-

    What do you think?
Sign In or Register to comment.