miniSpartan3 HDMI Input

Home Forums miniSpartan3 miniSpartan3 HDMI Input

This topic contains 2 replies, has 2 voices, and was last updated by  colin 3 years, 7 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #1839

    DogP
    Participant

    Hey,

    I was hoping to do a project on the miniSpartan3 with HDMI (DVI) input, but quickly realized that the HDMI circuit on the miniSpartan3 is really only usable as an output (no termination, I2C shifter, etc). I thought about trying to hack them in, but instead decided to create a dedicated input circuit. I was a little unsure whether the high speed signals would work across the 0.1″ header and traces (presumably) not routed as 100 ohm differential pairs. But I remembered seeing Hamsterworks’ HDMI input board he made for the Papilio Pro, which worked, and figured it was worth a shot. I got the boards and assembled one today, and it seems to work!

    To clarify… currently, the code just instantiates IBUFDS buffers and outputs the signals directly to OBUFDS buffers. So, the signal is physically routing through the FPGA, but I don’t have the FPGA actually decoding and re-encoding the signals yet. There are differences between the input structure of the Spartan-3A and the Spartan-6, which means I can’t use the S6 code from the miniSpartan6+ directly (for example, the S6 uses IODELAY and SERDES functionality, while the S3 will need to use DDR inputs, phase shifting in the DCMs, and deserialize in logic). Hopefully I’ll get that code written in the not-so-distant future.

    This board connects to the PORTC area of the header, using I/Os C0-C9 (and the GND/3.3V pins between them). The 4 TMDS pairs are routed to 4 differential pair inputs on Bank 3 of the FPGA, and the I2C level shifter is going to the other two pins. The FPGA is emulating the EDID ROM, so the outputs detect that there’s a monitor attached. This will only be usable as an HDMI input, not output, since TMDS outputs are only supported on Banks 0 and 2 on the Spartan-3A.

    Anyway, there’s not much to show as far as code yet, but I’ll be sure to post it once I get it up and running. And if anyone would like to make their own board, I’d be glad to send you the Gerber files (the boards were only a few dollars from OSH Park, and another few for the parts from Digikey). The board is pretty small (0402 components, etc.), so it’s not for a soldering novice… but it’s not absurdly difficult to assemble either.

    DogP

    Attachments:
    You must be logged in to view attached files.
    #1844

    DogP
    Participant

    I had a couple hours to work on this tonight, and decided to simply try getting the XAPP460 code running so I could confirm that the decoding and re-encoding can work, and to have a working example to refer to. I’m not very fluent in Verilog, but I can read it and make simple modifications, and luckily that was all it really took. :)

    It has two DVI demos… a Tx only, and a pass-through video overlay. The Tx only demo creates color bars and an overlay that moves around the screen. For that one, I modified the code to add an additional DCM to create the pixel clock from the 32 MHz oscillator (theirs brought the pixel clock in directly from an oscillator), and then modified the video timing for 800×600 (theirs was set up for 720P or 1080i, which is beyond the spec of the -4 speed grade part, and the pixel clock isn’t easily obtained from the 32 MHz clock). I didn’t modify any of the video generation, so the color bars and overlay aren’t properly scaled, centered, etc… but those details don’t really matter for what I’m doing (and I’ve already got a Tx working… so this was just for fun).

    The pass-through demo didn’t really need any major changes, since the pixel clock and video timing is created by the video source. It did complain about clock routing, which I ignored, and it still worked (I didn’t dig into it, since in the end I don’t plan to actually use this code). Oh, and I’m pretty sure this will only work on the XC3S200A part, not the XC3S50A part, since it uses 3 DCMs for the individual channel phase alignments (the XC3S50A only has 2). In practice, you may be able to get away with sharing a DCM for two channels, since odds are pretty good that two of the open eyes will at least be partially aligned, though it wouldn’t be optimal, and would take some changes to make it work. The transmitter only requires two DCMs, so it should work fine.

    Unfortunately, I don’t think the license allows me to post the project here, but if you want to try this, you can download the code from Xilinx, and I’d be glad to help you with the few changes I made. It doesn’t have the EDID ROM stuff implemented, so it’s not exactly a complete system… but it’s a good technical example. I plan to write my own VHDL implementation anyway, which I’ll integrate with the Tx code I posted a while back (based on Hamsterworks’ code)… which I will post once it’s done.

    DogP

    • This reply was modified 3 years, 9 months ago by  DogP.
    Attachments:
    You must be logged in to view attached files.
    #1901

    colin
    Participant

    Hey,

    This is exactly what I planned to do next! I was hoping to put some pull-up resistors and an EDID chip on the output port to use the board as a cheap Ambilight clone. I’d love to take a look at your VHDL when you’re done! Please don’t mistake the silence in this forum for a lack of interest!

    Colin

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.