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

HDMI added to Prop2

2456721

Comments

  • RaymanRayman Posts: 13,800
    You don't have to pay unless you use the word "HDMI" on the board or in manual or website...
    Easier to just use DVI or DisplayPort as signaling is the same for video only...
  • potatohead wrote:
    HDMI would be a very nice bullet point.
    Agreed, except that you can't call it that without being an official "HDMI Adopter" and paying royalty fees.

    -Phil

    That's OK. There are ways to manage all that.

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Does anyone know if the Clock+/- has any relative timing requirement in relation to the data? It cycles at 1/10th the Red/Green/Blue bit rate.

    It will have quite strict skew rules, as it has to phase lock x10 and then sample data-centred. At 240MHz half-data width is ~ 2ns
    If you take care to keep the path-delays the same, you should get sub 1ns skews ?
    cgracey wrote: »
    I worked it into the streamer. It takes the upper 3 bytes of the output long for R/G/B and the lower byte is used for command codes. In lieu of the normal 32 bits, it outputs {24'b0, r, !r, g, !g, b, !b, clk, !clk}. You have to pace your pixels at 1/10th the chip clock using 'SETXFRQ ##$0CCCCCCC'. To enable HDMI encoding: 'SETCMOD #$80'. It's maybe only good for 640x480 @60Hz, but gets us an HDMI output that will work with modern displays.

    Will that support Audio too, or just images ?

    All this supposes you can hit 250MHz with some sort of reliability ?
    You may need to constrain Vcore and Temp, in order to do that ?
  • evanhevanh Posts: 15,126
    Maybe some way to do DDR ... that would lift the constraint on the bit rate enough to allow some flexibility with TDMS encoding.

  • jmgjmg Posts: 15,140
    evanh wrote: »
    Maybe some way to do DDR ... that would lift the constraint on the bit rate enough to allow some flexibility with TDMS encoding.

    DDR is also common on faster FLASH memory, but I suspect that needs
    cgracey wrote: »
    ... In lieu of the normal 32 bits, it outputs {24'b0, r, !r, g, !g, b, !b, clk, !clk}. You have to pace your pixels at 1/10th the chip clock using 'SETXFRQ ##$0CCCCCCC'. To enable HDMI encoding: 'SETCMOD #$80'....

    How much extra logic is this adding ? Is this going to push P&R over the edge ?

    What is the status of clock gating ? - even coarse on/off, like disabled COG or disabled Smart Pin = No Clock branch drive.
  • evanhevanh Posts: 15,126
    edited 2018-10-16 20:11
    Chip,
    I note there is I/O library part of ALTLVDS_TX for the Cyclone V in Quartus. I'm guessing this means the Cyclone has special Serdes hardware that allows much higher bit rate than clock rate. So should be possible to easily do 250 mbps on the A9 part. May only be specific pins though.

    EDIT: OR maybe not - "Warning (14737): Warning: Current device family value (null) is invalid"
  • jmgjmg Posts: 15,140
    edited 2018-10-16 21:14
    cgracey wrote: »
    It seems to be working on the FPGA, but I now realize it's too slow to test, as the FPGA only goes to 80MHz.

    Maybe you can do a partial test, with a 25MHz clk, and lower data rate, for reduced colour range ?
    cgracey wrote: »
    It should route straight from the P2 pins to the female HDMI socket.

    Well, almost straight, as HDMI needs LVDS, and your swing is too large for that.

    This looks a useful doc :
    file:///C:/Users/Admin/Downloads/61W_17974_6_HR_Letter_0.pdf


    HDMI leverages on the successful transition minimized differential signaling (TMDS) technology. The differential signals
    are +3.3 Volts, terminated in 50 Ω with nominal amplitude transitions of 500 mV (+2.8 V to +3.3 V). The voltage swing
    can vary from 150 mV to 800 mV. The signals have rise times of the order of 100 ps.
    The data rates on a single link can range from 25 Mpps to 340 Mpps (Mpps = Mega pixel per second).
    b. Low level Output Voltage (VL)
    The VL test is performed to ensure signal voltage levels are within prescribed limits. The test checks for the DC voltage
    levels on the HDMI link for each TMDS signal. The CTS specifies that the voltage of the low-levels should fall within 2.7
    V and 2.9 V.

  • cgraceycgracey Posts: 14,133
    edited 2018-10-16 21:54
    jmg wrote: »
    cgracey wrote: »
    It seems to be working on the FPGA, but I now realize it's too slow to test, as the FPGA only goes to 80MHz.

    Maybe you can do a partial test, with a 25MHz clk, and lower data rate, for reduced colour range ?
    cgracey wrote: »
    It should route straight from the P2 pins to the female HDMI socket.

    Well, almost straight, as HDMI needs LVDS, and your swing is too large for that.

    This looks a useful doc :
    file:///C:/Users/Admin/Downloads/61W_17974_6_HR_Letter_0.pdf


    HDMI leverages on the successful transition minimized differential signaling (TMDS) technology. The differential signals
    are +3.3 Volts, terminated in 50 Ω with nominal amplitude transitions of 500 mV (+2.8 V to +3.3 V). The voltage swing
    can vary from 150 mV to 800 mV. The signals have rise times of the order of 100 ps.
    The data rates on a single link can range from 25 Mpps to 340 Mpps (Mpps = Mega pixel per second).
    b. Low level Output Voltage (VL)
    The VL test is performed to ensure signal voltage levels are within prescribed limits. The test checks for the DC voltage
    levels on the HDMI link for each TMDS signal. The CTS specifies that the voltage of the low-levels should fall within 2.7
    V and 2.9 V.

    HDMI added 130 flipflops per cog, 117 of which are in the three 8b/10b TMDS translators (39 flops each). So, that's +1,040 flops for the P2, out of a current ~88,000.

    It seems to have been demonstrated by many FPGA projects that full 3.3V swing is okay. If not, we could add series resistors. Or, maybe I could make a digital DAC mode that outputs $FF or some level using OUT as the driver.
  • RaymanRayman Posts: 13,800
    Googling says 50 Ohm impedance on each line at receiver, so series resistor would probably work, if needed.
  • Cluso99Cluso99 Posts: 18,066
    I had a quick read of the HDMI and DVI basics a few days ago. Seems it's just 3 differential serial data 10 bits and a clock 1/10th rate. The HDMI is a subset of DVI pins. There are passive HDMI to DVI and visa versa readily available.
    So I presume you just need to output a clock and 3 sets of 10 bit serial per clock.
    With the P2 seemingly able to reach 250MHz, HDMI/DVI is a nice asset to have :)
  • cgraceycgracey Posts: 14,133
    Yes, Cluso99, that's all there seems to be to it.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Chip,
    I note there is I/O library part of ALTLVDS_TX for the Cyclone V in Quartus. I'm guessing this means the Cyclone has special Serdes hardware that allows much higher bit rate than clock rate. So should be possible to easily do 250 mbps on the A9 part. May only be specific pins though.

    EDIT: OR maybe not - "Warning (14737): Warning: Current device family value (null) is invalid"

    I need to be sure that my TMDS encoder is working properly. I think what I will do is have the FPGA output the sequence, but have another cog's streamer record it to hub RAM. From there, I will make a communication link to send it over to the P2 silicon which will be able to stream it out at 250MHz.
  • So the streamer on the FPGA can read a slower HDMI signal, produced by a slower HDMI sending.

    That somehow implies that a real P2 can stream in HDMI or LVDS?

    curious,

    Mike
  • cgraceycgracey Posts: 14,133
    edited 2018-10-16 22:59
    msrobots wrote: »
    So the streamer on the FPGA can read a slower HDMI signal, produced by a slower HDMI sending.

    That somehow implies that a real P2 can stream in HDMI or LVDS?

    curious,

    Mike

    It can't create the data in real time right now. We'll have to have a respin for that. However, it can play bytes out of Hub RAM onto eight pins at 250MHz.

    I will probably use serial to send the data from the FPGA board over to the P2 silicon.
  • TonyB_TonyB_ Posts: 2,108
    edited 2018-10-16 23:01
    Is this really just DVI, without the extra data and audio that HDMI can do during the blanking?

    The DVI 1.0 specification can be downloaded from here and describes the TMDS encoding in detail.

  • cgraceycgracey Posts: 14,133
    TonyB_ wrote: »
    Is this really just DVI without the extra data and audio that HDMI can do during the blanking?

    The DVI 1.0 specification can be downloaded from here and describes the TMDS encoding in detail.

    HDMI is a subset of DVI, from what I gather. The high-speed 10-bit encoding is common across both formats.
  • roglohrogloh Posts: 5,122
    edited 2018-10-16 23:14
    cgracey wrote: »
    I worked it into the streamer. It takes the upper 3 bytes of the output long for R/G/B and the lower byte is used for command codes. In lieu of the normal 32 bits, it outputs {24'b0, r, !r, g, !g, b, !b, clk, !clk}. You have to pace your pixels at 1/10th the chip clock using 'SETXFRQ ##$0CCCCCCC'. To enable HDMI encoding: 'SETCMOD #$80'. It's maybe only good for 640x480 @60Hz, but gets us an HDMI output that will work with modern displays.

    This sounds great Chip. As part of the set of command codes you recognize, if you have included all the 16 TERC4 mapped 10bit codes as well as those used by the data / video guard bands and preamble patterns, then canned sequences of packets could potentially be streamed out to hopefully add some support for digital audio and other HDMI info packets in addition to the standard VGA resolution video at 250MHz, instead of being limited to just pure DVI only with 8b/10b. This gets trickier as you do need to encode and add some ECCs on data packets being sent but I suspect other COG(s) should be able to do that in parallel and deliver to hub RAM for transmission by the video COG which can remain data unaware apart from the overall framing needed.
  • TonyB_TonyB_ Posts: 2,108
    edited 2018-10-19 00:36
    deleted
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    It can't create the data in real time right now. We'll have to have a respin for that. However, it can play bytes out of Hub RAM onto eight pins at 250MHz.
    I will probably use serial to send the data from the FPGA board over to the P2 silicon.
    Sounds like a very good test.
    You can always just generate stripes or checker-board test patterns, which should be good enough to test PLL's etc on each end, and HW jitter/swings etc ?

  • potatoheadpotatohead Posts: 10,253
    edited 2018-10-16 23:10
    Looks like simple video only. Frankly, that is just fine with me.

    These are gonna add up. Respin to respin again could be on the table.

  • RaymanRayman Posts: 13,800
    edited 2018-10-16 23:20
    More like DVI is a subset of HDMI, I think.

    The physical connector doesn't matter, it's the protocol for 3D stereo, encryption, sound and stuff like that DVI doesn't have...

    You can connect a DVI signal to HDMI connector and it will work fine.
    Other way around will only work if it's pure video, unencrypted...

    At least, that's my take...
  • cgraceycgracey Posts: 14,133
    edited 2018-10-16 23:26
    In this 8-bit to 10-bit encoder, the TMDS state machine generates needed tokens from the input bytes. There are also four special control codes that can be sent which are different from the byte-data tokens. That is all that can be done. Something like audio would be at a higher level, where you would probably use control codes to signal the data. point is, I think we have all the hardware that would ever be needed.
  • TonyB_TonyB_ Posts: 2,108
    edited 2018-10-16 23:30
    deleted
  • TonyB_TonyB_ Posts: 2,108
    edited 2018-10-16 23:41
    cgracey wrote: »
    In this 8-bit to 10-bit encoder, the TMDS state machine generates needed tokens from the input bytes. There are also four special control codes that can be sent which are different from the byte-data tokens. That is all that can be done. Something like audio would be at a higher level, where you would probably use control codes to signal the data. point is, I think we have all the hardware that would ever be needed.

    As control data must fit in a byte and the 10-bit control codes are special and cannot be created by TMDS, we'd need more logic to translate the additional control bytes into tokens.

    Video without audio is fine, I think.
  • RaymanRayman Posts: 13,800
    I was reading something that made it sound like there were more possible control tokens defined...

    I think video only needs two bits though for hsync and vsync, or something like that...
  • msrobotsmsrobots Posts: 3,701
    edited 2018-10-16 23:57
    cgracey wrote: »
    msrobots wrote: »
    So the streamer on the FPGA can read a slower HDMI signal, produced by a slower HDMI sending.

    That somehow implies that a real P2 can stream in HDMI or LVDS?

    curious,

    Mike

    It can't create the data in real time right now. We'll have to have a respin for that. However, it can play bytes out of Hub RAM onto eight pins at 250MHz.

    I will probably use serial to send the data from the FPGA board over to the P2 silicon.

    OK, half the answer, so if we can stream out at 250MHz, can we stream in at 250MHz also? So maybe capture a HDMI signal to record it? Even if we reduce the resolution before saving that might be a interesting feature.

    The lacking point of the wonderful P1 video was that it is just one-directional but I recently stumbled about a post where someone uses the P1 video hardware to send a 3Mbaud serial signal to a PC-Host.

    And one thing what I am still looking for is a fast and easy to use P2 to P2 link. Some years ago I build a RAI(s)D with 4 SD cards and using @"Beau Schwabe"'s high speed serial as example wrote fast 2,3,4,5,8,9 wire transmit protocols to transfer from P1 to P1. It was quite challenging for me to do so.

    But using the streamer on both sides might get really fast transfers. Gosh I will need multiple P2 boards right from the beginning...

    Mike
  • Chip, so it really is like WAITVID for HDMI / DVI. Cool. Over time, people can push it to do what may eventually be done.

    I like it.
  • cgraceycgracey Posts: 14,133
    It is easy to output HDMI, but inputting it would require LVDS receiver circuitry.
  • TonyB_TonyB_ Posts: 2,108
    edited 2018-10-17 00:04
    Rayman wrote: »
    I was reading something that made it sound like there were more possible control tokens defined...

    I think video only needs two bits though for hsync and vsync, or something like that...

    More tokens than the four for the syncs would require more hardware. They couldn't be done in software.

    Bit 0 of the long for HSync and bit 1 for Vsync with other bits of the low byte zero seems the simplest scheme and I imagine Chip has done it that way.
Sign In or Register to comment.