Analog video output with FPGA ?

[Jaunedeau]

Hi,

  I'd like to output an RGB video signal on an old CRT TV. The resolution would be at least 160x200, 320x200 if possible. So I need to output three analog values, with value changing at approximately 5MHz but they need fast transitions (e.g. if I use PWM, I guess I need at least 4 PWM periods in one pixel).
  I could use dedicated video DAC, the problem is that they seems to be harder and harder to source and since this is for an open source project that I hope may live for a few years and the price is apparently higher than the fpga I need (probably a gw1n 1k)... Is there any interesting chip I missed ?

  I have seen several people using r-2r ladders for this, but they only use 3 to 5 bits per components, I need 8. Can I use an r/2r or r ladder with trimpots on the higher bit to adjust the DAC, or will other factors (such a temperature drift ?) make it a bad idea ? (I won't mass produce so calibrating each piece once is acceptable)
  Should I build a PWM or PDM DAC inside the FPGA ? (in PAL, with 52us per line, 320 columns, 256 possible values and 4 PWM cycles per pixel, that would mean  6gHz clock... probably cheaper to save on the FPGA and use a DAC, but maybe PDM would be doable ?)
  Another solution I can think of is a 10 bits r/2r ladder, and and hardcoded calibration table to compensate for the resistors variation... any better solution ?

Thanks,
J.

[BrianHG]

If you want 8 bits per channel, look for the cheapest RGB video DACs and be done with it.  I know it's overkill, at these thing can run at +200Mhz, but it's easy and regulated outputs, with 75ohm cable driver built in with static immune outputs.

Try this guy:

ADV7125xxxxxx are still available at $7 to $9 USD a piece.  (search for alternate suffix as the 330MHz version I listed may be overkill)

ADV7123xxxxx are available at $5.37 USD, but you will need to buy 10 of them.  These are the cheapest if you go to ~25 pieces at they drop to $4.40 USD.

ADV7120xxxxxx are still available too, only 24bit, but more expensive and harder to find compared to the 30bit version above.  They seem to be available at $10 USD for the slowest 50MHz version.

THS8136xxxxx are available at $5 USD.
THS8135xxxxx are available at $5 USD.

Why not just output DVI/HDMI from your FPGA?  It only requires 8 outputs and only requires a 1$ IC if your FPGA doesn't directly support the TMDS standard through a cable, though, at 240p, even a basic LVTTL 3.3v IO with a few resistors can suffice.  If you then want RGB analog, then buy a cheap HDMI/DVI to RGB dac box.  Now you will get support for digital and analog using 1/5th the IOs on your FPGA.

[BrianHG]

HDMI to VGA adapters, basically a dime a dozen....: (Some cost less than the above DACs plus the 1$ TMDS driver IC for the FPGA + a HDMI plug for your PCB)

https://www.amazon.com/HDMI-to-VGA-Adapters/b/ref=dp_bc_aui_C_5/137-1730865-9692944?ie=UTF8&node=14570285011

Some tested recommended adapters:
https://www.retrorgb.com/hdmi-to-vga-dac-analysis.html

[SiliconWizard]

I'd recommend one of those ADV chips BrianHG mentioned. Yes, overkill but easy to use and good.
For your use case though, if color accuracy is not really a concern and given the low bandwidth, you could just go for R-2R ladders. Apart from color accuracy, I don't see why this would cause any problem especially at those low resolutions. For better results though, I would recommend going via external buffers rather than straight from the FPGA IOs, at which point, the integrated DACs will end up only a tad more expensive.

[Jaunedeau]

Hdmi to vga would be an option, and probably what I will do in early stages since I will prototype on tang nano 4k board. One problem that sourcing one that introduce low lag might be a problem on the cheap ones (e.g. one could be good, then they can change the component in the same product). Also some seems to only support full hd, and might cut some cost saving possibilities when I aims only for CGA.

Dedicated DAC seems to be the way to go... I'll use one and hope it stays available in the futur

[Jaunedeau]

Just a random thought but : if I implement on an MCU instead of an FPGA (or use and FPGA that can implement an ADC), could a 9 or 10 bit (instead of the 8 required) bits ADC plus an autocalibration routine at boot be a good solution ?

[BrianHG]

Hdmi to vga would be an option, and probably what I will do in early stages since I will prototype on tang nano 4k board. One problem that sourcing one that introduce low lag might be a problem on the cheap ones (e.g. one could be good, then they can change the component in the same product). Also some seems to only support full hd, and might cut some cost saving possibilities when I aims only for CGA.

Dedicated DAC seems to be the way to go... I'll use one and hope it stays available in the futur

The cheap ones are the ones without any lag.
Do you honestly believe that such a $3-$6 device actually has a DDRx memory chip within to delay the picture by a frame or more, introducing lag?
The only lag in a 3$ device will be a few pixels as the HDMI gets de-serialized, then sent to the dac immediately.

If you are getting lag, it is most likely coming from somewhere else.  Maybe your source video device is attempting to scale the picture to a video mode listed in the converter's EDID?  Hence the delay is not the converter's fault.

Yes, for the supported video modes, a number of devices might not lock onto specific video clock frequencies, basically failing to function.  I listed a review site which tests the old 240p mode used by old gaming systems & CGA.

[BrianHG]

Just a random thought but : if I implement on an MCU instead of an FPGA (or use and FPGA that can implement an ADC), could a 9 or 10 bit (instead of the 8 required) bits ADC plus an autocalibration routine at boot be a good solution ?

Didn't you say DAC, not ADC?

[Jaunedeau]

Didn't you say DAC, not ADC?

The idea is to have both and ADC and a DAC, and use the ADC to calibrate the DAC and build a lookup table to correct the DAC errors. I've found a post about this idea ( https://www.eevblog.com/forum/projects/r-2r-ladder-dac-calibration-what-do-you-think/ ) and when you see the first oscilloscop capture, it seems possible to make a calibration table and get a good 14bit adc from this 16bit R2R adc after calibration.
My case is a bit different : I need 8bit not 16, but about 30Msps not 44ksps. Also since my input is discrete (e.g. the atari 2600 has a 128 colors palette), I could build a calibration table for the 128 RGB triplets instead of three calibration tables of 256 individual R, G and B and compensate for the crosstalk.

I am a software developer, only learning electronics as a hobby, I have no intuition of if this could be a good solution (to the problem of video ADCs eventually no longer be available in a few years, and cost reduction because cost reduced projects are more fun to me).

[gf]

Should I build a PWM or PDM DAC inside the FPGA ? (in PAL, with 52us per line, 320 columns, 256 possible values and 4 PWM cycles per pixel, that would mean  6gHz clock... probably cheaper to save on the FPGA and use a DAC, but maybe PDM would be doable ?)

Delta-sigma modulation does not need such a high oversampling ratio. A 2nd order modulator with 2-level (binary) output has a theoretical SQNR of ~65dB with 32x oversamling, or ~80dB with 64x oversampling. For 5 MHz bandwidth, this would be 320 MSa/s (32x) or 640 MSa/s (64x). Maybe a little more if you want some headroom, but not 6GSa/s.

See also https://classes.engr.oregonstate.edu/eecs/spring2021/ece627/Lecture%20Notes/2nd%20&%20Higher-Order2.pdf

Edit: How much SNR do you need for analog video? I guess hardly more than 50dB. So even 16x oversampling may suffice, but that's already borderline.

Btw, does the TV have RGB inputs, or do you need a composite video signal?

[SiliconWizard]

Well, are you sure you need 24-bit RGB to drive an old CRT TV anyway? I am not.

[Jaunedeau]

Delta-sigma modulation does not need such a high oversampling ratio. A 2nd order modulator with 2-level (binary) output has a theoretical SQNR of ~65dB with 32x oversampling, or ~80dB with 64x oversampling. For 5 MHz bandwidth, this would be 320 MSa/s (32x) or 640 MSa/s (64x). Maybe a little more if you want some headroom, but not 6GSa/s.

See also https://classes.engr.oregonstate.edu/eecs/spring2021/ece627/Lecture%20Notes/2nd%20&%20Higher-Order2.pdf

Thank you. My calculation was for PWM, I'm just trying to learn about PDM for my application and can't do the math yet. If 32MHz is enough, that might be done with SPI on a cheap STM32 or the PIO or an RP2040 and that would greatly reduce cost. But my understanding of PDM (and that would almost be the same problem with PWM) is that if I want to display a full 1/256 brightness line with a 16 oversampling, I would display first pixel as 1 followed by 15 zero, followed by 15 pixels all black (full zeros), making an average of 1/256, but meaning I would need a filter that averages the value over 16 pixel. I'd still get good micro adjustements if I output analog source or video from a camera (hence I don't need 256 oversampling for them), but in my case (pure digital source whed having a 1 pixel wide white ball on a black background is not uncommon) PDM won't be really better than PWM ? (and PWM would still need at least 2x oversampling, or alternance and black and white pixels would be hard to distinguish from continues line of mid-gray pixels) ?

Edit: How much SNR do you need for analog video? I guess hardly more than 50dB. So even 16x oversampling may suffice, but that's already borderline.

I don't now how to answer that question. I want a "clean" rgb video output for a very arbitrary definition of clean ^^

Btw, does the TV have RGB inputs, or do you need a composite video signal?

I an targetting TVs (and maybe later computer CRT monitors) that have RGB input only

[Jaunedeau]

Well, are you sure you need 24-bit RGB to drive an old CRT TV anyway? I am not.

This is a good question. My idea was to start with 24bits on the prototype, then lower the bit-depth via software to see if I can reduce the cost and size (and soldering time/difficulty since the project might be open sourced if it works, and should be hobbyist friendly)

16bits RGB might be good enough, but at my current stage (just learning) prototyping with 24 bits won't cost more than prototyping with 16. Unless I go for and exernal DAC and can find a fast enough 6 bit one for cheaper (and with longer expected availability) than the dedicated 24bit video DACs.

[langwadt]

If you want 8 bits per channel, look for the cheapest RGB video DACs and be done with it.  I know it's overkill, at these thing can run at +200Mhz, but it's easy and regulated outputs, with 75ohm cable driver built in with static immune outputs.

Try this guy:

ADV7125xxxxxx are still available at $7 to $9 USD a piece.  (search for alternate suffix as the 330MHz version I listed may be overkill)

ADV7123xxxxx are available at $5.37 USD, but you will need to buy 10 of them.  These are the cheapest if you go to ~25 pieces at they drop to $4.40 USD.

you can also get a clone of the ADV7123, for ~$2

https://www.lcsc.com/product-detail/Digital-To-Analog-Converters-DACs_HTCSEMI-HT7123ARQZ_C2886392.html

[BrianHG]

Just for those who want a super small RGB DAC for their FPGA projects, this guy: ($1.81 for 1 piece)

https://www.nxp.com/docs/en/data-sheet/PTN3393.pdf

Runs on 2 lane display-port, so you need to be able to work with that, but only 6 wires between your FPGA and this DAC.  This DAC also has built in  TTL drivers for your VGA plug's HS and VS signals as well as 5v tolerant level translators for the DDC SDA&SCL lines.

[SiliconWizard]

Well, are you sure you need 24-bit RGB to drive an old CRT TV anyway? I am not.

This is a good question. My idea was to start with 24bits on the prototype, then lower the bit-depth via software to see if I can reduce the cost and size (and soldering time/difficulty since the project might be open sourced if it works, and should be hobbyist friendly)

16bits RGB might be good enough, but at my current stage (just learning) prototyping with 24 bits won't cost more than prototyping with 16. Unless I go for and exernal DAC and can find a fast enough 6 bit one for cheaper (and with longer expected availability) than the dedicated 24bit video DACs.

Well yes, going for a lower bit depth would just be a benefit if you used R-2R ladders. Something that could still be considered if cost is really a concern.

Since you mentioned using MCUs (I think?), note that generating RGB video at these resolutions would be plenty feasible with just a RP2040 and its PIO. But given its limited number of GPIOs, you'd probably have to limit the bit depth to something lower.

[Jaunedeau]

Since you mentioned using MCUs (I think?), note that generating RGB video at these resolutions would be plenty feasible with just a RP2040 and its PIO. But given its limited number of GPIOs, you'd probably have to limit the bit depth to something lower.

The PIO is plenty of fun and I'll try playing with PDM on the PIO, but with max overclocking and 4 bit depth per component, I would get only 3 samples per pixel with pwm and 160 px per line... still a bit low for my all grey / alternating black and white pixels problem. I even thought of a dual rp2040 solution with one acting as an SPI ADC, but the stm32g4 (170MHz, requires no external flash, $2.5 for one piece in 64pins package / 52 gpios and has an real datasheet ^^) seems a simpler solution if an R2R ladder + calibration can do the job.

[radiolistener]

The problem with R-2R DAC is that it has many parallel wires which length depends on PCB layout and soldering. As result, you will have phase error for different bits. At higher frequency it leads to worse error and it limits the real resolution of the DAC.

If some color distortions is not an issue for your needs, then you can try discrete R-2R DAC. This color distortion will depends on picture which is displayed. But its more easy to use DAC chip, because it can guarantee real DAC resolution.

I think 24-bit color resolution (8+8+8 for r+g+b) is just impossible with discrete R-2R DAC at 5-7 MHz bandwidth due to physical limitations.

I think the max real resolution you can get with discrete R-2R at these frequencies is about 4-5 bits. And it will require precise PCB layout and soldering.

If you're needs better, then you're needs to use IC.


For example I have Chinese FPGA board with VGA output which uses 4-bit discrete R-2R DAC, I tried to play with it and notice some minor color distortion and noise (moire) which can be noticed at some specific pictures.

Good CRT display is more sensitive to color resolution and noise in the video signal. With CRT display you can notice even very small distortions and small phase jitter for pixel in video signal. I remember there was a tricky hack which allowed to show picture with using different phase delay for INK and PAPER circuits path in ZX Spectrum. Technically video memory contained solid picture, but since it was painted with INK and PAPER colors in specific pattern and they have different phase delay (the difference was very small much less than one pixel), it allowed to see picture on CRT TV which should be invisible with equal phase delay for INK and PAPER... And it was pretty visible even on a cheap low quality CRT TV despite the fact that the pixel phase error was very small... 

[tszaboo]

I am a software developer, only learning electronics as a hobby, I have no intuition of if this could be a good solution (to the problem of video ADCs eventually no longer be available in a few years, and cost reduction because cost reduced projects are more fun to me).

Don't worry, we can tell!
Your FPGA probably doesn't even have the memory to make a full frame buffer, and the monitor doesn't have the color accuracy, yet you want to do auto calibration of some 8bit color info. Instead of buying a Digilent Pmod VGA and truying it first.