AD9984A
Production
The AD9984A is a complete 10-bit, 170 MSPS, monolithic analog interface optimized for capturing YPbPr video and RGB graphics signals. Its 170 MSPS encode...
Datasheet
AD9984A on Analog.com
ADV7513
Recommended for New Designs
The ADV7513 is a 165 MHz, High-Definition Multimedia Interface (HDMI®) transmitter that is ideal for DVD players/ recorders, digital set-top boxes, A...
Datasheet
ADV7513 on Analog.com
AD9985A
Obsolete
The AD9985A is a complete 8-bit, 140 MSPS, monolithic analog interface optimized for capturing RGB graphics signals from personal computers and workstations...
Datasheet
AD9985A on Analog.com
The design I am working on has to take a CGA type (640 X 240) video input and output it to a monitor using HDMI at VGA type (640 X 480) resolution. Previously, I was using an FPGA to capture the video from a AD9985A and line double it and send it to a ADV75125 DAC for output. Unfortunately, for this new HDMI based design, the video source did not have a HSYNC frequency, that when doubled (at 2X the original HSYNC), did not meet a CEA861 standard and so the monitor did not display anything using the ADV7513 HDMI transmitter.
I am now planning on using a RAM frame buffer so that the output can be "spot on" to a standard frequency and displayed properly. There will be at least two buffers. One gets filled with input while the other is being output with the correct HYNC and VSYNC timings. When the input buffer is ready, the buffers switch roles. Some frames will be dropped, but the video is "almost" static so that should not be an issue. A FPGA will take care of all of the timing and buffer fill and switchover issues. While we currently use a AD9985A ADC in our product, I am thinking about changing to a AD9984A ADC which is recommended for new designs, unlike the AD9985A, which is not.
If anyone has had experience using a frame buffer solution similar to what I propose, I would appreciate any feedback.
Thanks.
Mike
Just some quick comments:
1) The AD9984A and ADV7513 are probably the best parts to use for this application.
2) The frame buffer only needs to be sized to store 640 x 200 x 24 bits of active video area. If you could work in YCbCr 422 color space domain, memory requirements drop by 33%
3) Since the data rates are so slow you might be able to get away with only one frame buffer shared between the receiver side and the transmitter side.
4) You will have 2 different clock domains that need to be treated correctly in the FPGA
I have no specific reference to point to for this solution.