HDMI added to Prop2

2456720

Comments

  • 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...
    Prop Info and Apps: http://www.rayslogic.com/
  • 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.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • 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 ?
  • Maybe some way to do DDR ... that would lift the constraint on the bit rate enough to allow some flexibility with TDMS encoding.

    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • 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: 5,664
    edited October 16 Vote Up0Vote Down
    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"
    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • jmgjmg Posts: 12,446
    edited October 16 Vote Up0Vote Down
    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: 10,177
    edited October 16 Vote Up0Vote Down
    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.
  • Googling says 50 Ohm impedance on each line at receiver, so series resistor would probably work, if needed.
    Prop Info and Apps: http://www.rayslogic.com/
  • 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 :)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Yes, Cluso99, that's all there seems to be to it.
  • 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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • cgraceycgracey Posts: 10,177
    edited October 16 Vote Up0Vote Down
    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: 879
    edited October 16 Vote Up0Vote Down
    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.

    Formerly known as TonyB
  • 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: 855
    edited October 16 Vote Up0Vote Down
    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: 879
    edited October 19 Vote Up0Vote Down
    deleted
    Formerly known as TonyB
  • 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: 9,504
    edited October 16 Vote Up0Vote Down
    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.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • RaymanRayman Posts: 8,857
    edited October 16 Vote Up0Vote Down
    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...
    Prop Info and Apps: http://www.rayslogic.com/
  • cgraceycgracey Posts: 10,177
    edited October 16 Vote Up0Vote Down
    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: 879
    edited October 16 Vote Up0Vote Down
    deleted
    Formerly known as TonyB
  • TonyB_TonyB_ Posts: 879
    edited October 16 Vote Up0Vote Down
    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.
    Formerly known as TonyB
  • 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...
    Prop Info and Apps: http://www.rayslogic.com/
  • msrobotsmsrobots Posts: 2,089
    edited October 16 Vote Up0Vote Down
    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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • 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.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • It is easy to output HDMI, but inputting it would require LVDS receiver circuitry.
  • TonyB_TonyB_ Posts: 879
    edited October 17 Vote Up0Vote Down
    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.
    Formerly known as TonyB
Sign In or Register to comment.