Two questions.
I have a Xilinx Spartan 6 FPGA which only has HDMI ins and outs. Is there some sort of guide or pre-written code that I can use to start sending images to the screen? I have no idea how to begin and I have not been able to find resources.
Second, the reason I'm doing this is because I want to use and modify Atari 2600 code a guy implemented on a Spartan 3E with VGA. Is it even possible to easily adapt the video aspect of my project?
Any help, resources, or advice would be greatly appreciated!
Best Answer
The Atlys board uses TDMS inputs, so you'll need a HDMI decoder which takes those inputs and produces VSYNC, HSYNC, DE, and DATA. Xilinx details the DVI encoding and decoding process in a couple of application notes. These each come with example code, xilinx login required:
The example code is in verilog, although converting the top level to VHDL if you prefer is a relatively trivial exercise.
Here's a figure taken from the first application note showing the basic premise of the receiver:
Since the Spartan 6 has got built-in SERDES hardware, these can be used as part of the deserialisation process. There is a synchronisation process which recovers the clock and ensures that the channels are all in-sync. Finally, 8b/10b decoding is applied to produce the RGB channel data.
Once the video signals have been recovered, You can then forward theses signals on to whatever processing you want to do, or on to a encoder which will send them out of the HDMI ports again.
If you have the TFTMOD display, then forwarding the data out to the display is as simple as connecting the DE and DATA signals to the appropriate FPGA pins. The TFT board reference manual is useful for timing info about the display, although I found that the deserialiser output timing was fine.
You can use the UCF file from the this project, for the constraints for the HDMI, and this project for the MODTFT constraints if you're using that board.
The only thing to note is that the Xilinx example doesn't handle EDID info. If you're just using the board to forward data, then you can route the EDID lines right through and call it a day. Other scenarios may require handling the EDID data on the FPGA. Basically it's just I2C. The opencores I2C interface is pretty solid, or you can code your own. As far as I know, the wikipedia table about the data format for EDID 1.3 is accurate.