FPGA video format conversion

[BrianHG]

Without an entire frame buffer, the video input and video output frame must have an exactly timed matched V-sync, though, you can have a fixed delay from video input to output.  If you don't you will need to skip lines or pixels which will mess up the PLL locking mechanism in your VGA LCD screen, or, you will crap out you video vertical output.

This shouldn't be a problem, taking the video input and it H-Sync and run a perfect 2x, or 2.25x or 2.5x or 2.75x or 3x output with a H-sync running the same pixel/line count as the TVP, but, at the PLL multiplied rate.  If you are attempting H-locking, instead of V-locking delayed by an extra line or 2, you might get horizontal alignment jitter as this locking may mess up, but, this shouldn't be necessary as all you need to do is wait 1 additional source line delay before beginning video output.

You only need a 4-5 line buffer to make this work, so, you have plenty of memory to over-sample the source video so that your output will look like an analog VGA signal with additional shades and you only need to worry about the Y stretching linear filtering.

[MattHollands]

You only need a 4-5 line buffer to make this work, so, you have plenty of memory to over-sample the source video so that your output will look like an analog VGA signal with additional shades and you only need to worry about the Y stretching linear filtering.

Where do you get 4-5 from? If the input and output frames start at the same time there is a 26 line difference between the two frames at the end of the input frame. Therefore I need 26-lines in memory.

[BrianHG]

You only need a 4-5 line buffer to make this work, so, you have plenty of memory to over-sample the source video so that your output will look like an analog VGA signal with additional shades and you only need to worry about the Y stretching linear filtering.

Where do you get 4-5 from? If the input and output frames start at the same time there is a 26 line difference between the two frames at the end of the input frame. Therefore I need 26-lines in memory.

Ohh, are you doing some weird vertical scaling multiplication?
26 lines difference from top to bottom from what kind of vertical multiple?
2x? 2.5x?  The exact numbers are a blur going back somewhere around 5 pages on this thread...
What's the different usable Y res of the LCD and what's the Y res of the scope output?

[MattHollands]

The input resolution is 576x378 lines and the output resolution is 1024x600 lines.

The frame time of the input is 16.685ms and the output is not 16.9ish, off the top of my head. Will have to play around with removing lines etc to make 16.9 closer to 16.685.

Pixel rate input is 20MHz. Output is 48.875MHz

[MattHollands]

Ok so I have managed to synchronise the two video signals.

The first thing I did was change the pixel rate of the output from 48.875MHz to 48.928MHz which is only a 0.1% change and gives me an output frame rate much closer to the frame rate of the input. However they would still drift out of phase as this was not exactly correct.

Then I made the input assert a flag each time it started receiving line zero. The output then simply restarted the output frame whenever it saw this flag and it reached the end of an output line.This means that we are basically inserting/removing lines into the VSYNC as necessary to keep roughly in sync to within a line.

However, I found that this caused the LCD to flicker. Luckily, I found however that if I add/remove the lines in the front porch then it does not flicker!

So this is my solution. I will now try to reduce the frame buffer to the minimum necessary.

[BrianHG]

You should be resampling the vertical by 51:32.  (ie, your vertical scaler requires a 6 bit counter, 378 will be stretched to 602 lines)  With this, you will loose a fraction of a line at the top and bottom of the display.  1/2 of a visible line on top and bottom to be very close.  It should still be a visible line, however, you need to make sure you also count your source's total scan lines into that ratio to make sure you end up with a whole number of lines to make a steady scaled output.  3:2 would be much easier, but your source 378 will end up as 567 leaving a black bar or 16 lines on the LCD above and below the centered image, however, your chance of making a perfect source to destination scaled image is far more likely to succeed.

Once again, your rendered output should be parallel to your input, since the input is 60hz and your output is 60hz.  Your output hsync should be a perfect 51:32, or 3:2 multiple of you input source and the video output should fit in with just a few line delay from the source.  No slipping, no line dropping in the front porch.

Occasionally removing lines in the video, I find it funny that this actually worked for you.

[MattHollands]

It makes sense that the LCD doesn’t care how many lines I put in the front porch. During the front porch it is just waiting for the vsync. Pixel clock is derived from the hsync pulse which is still constant.

[simmconn]

You should be resampling the vertical by 51:32.  (ie, your vertical scaler requires a 6 bit counter, 378 will be stretched to 602 lines)  With this, you will loose a fraction of a line at the top and bottom of the display.  1/2 of a visible line on top and bottom to be very close.  It should still be a visible line, however, you need to make sure you also count your source's total scan lines into that ratio to make sure you end up with a whole number of lines to make a steady scaled output.  3:2 would be much easier, but your source 378 will end up as 567 leaving a black bar or 16 lines on the LCD above and below the centered image, however, your chance of making a perfect source to destination scaled image is far more likely to succeed.

Once again, your rendered output should be parallel to your input, since the input is 60hz and your output is 60hz.  Your output hsync should be a perfect 51:32, or 3:2 multiple of you input source and the video output should fit in with just a few line delay from the source.  No slipping, no line dropping in the front porch.

Occasionally removing lines in the video, I find it funny that this actually worked for you.

Actually the scaling ratio doesn't have to be integer to integer (the last line from the source doesn't have to fall exactly on the last line in the destination). Scaling ratio is also affected by the usable area in the LCD panel, when the panel is a bit too large for the viewing window and margins should be reserved for best result.

The minimum amount of line buffer required is determined by the active to total line count ratio in source vs in destination, if the frame rate is the same. Say the source takes 70% of a frame time to display all active lines, and the destination takes 80% due to their different frame structures, line buffers will be needed for 10% of the source line count, plus overhead by the scaler and whatnot.

Linear interpolation is simple but the image is not sharp enough to my taste. In a commercial design I ended up with windowed sinc interpolation with 4 taps and up to 32 phases. Linear interpolation use a 2 tap filter, so the line buffer structure is different.

Having a variable frame structure may work, but I wouldn't count on it for use in a product. Some LCD panels have explicit requirement for a stable frame structure, some are implied, others may not care. It may work on one panel, but may not work on 100s or 1000s of them, even for the same part number.

I'd say lack of upfront planning would cost the OP more time and effort to get to where he needs to be, but he seems to enjoy the journey. So please keep on. 

[MattHollands]

I have been working on the schematic for the final board. Settled on TVP7002->iCE40HX8K-BG121->ADV7125.

Currently the FPGA drives the HSYNC and VSYNC lines of the output VGA. How could I check that this will be ok? I could add a buffer if necessary.

[BrianHG]

Not all monitors will work with a 3.3v coming out of the FPGA, and, if they do, it might be potentially on the edge of functionality that temperature could throw things off.  (I ran into this a few times, for real, but, I was testing with multiple completely different LCD screens... Some worked great at 3.3v.  Others seem to, however, mysteriously would go haywire at times.  The HS was sitting on the threshold of functionality for those screen and the FPGA output buffer moves slightly with it's temperature and that digital IO trying to feed a monitor cable and resistive load to GND at the other end.)

To be safe, I would use 74ACT04, or HCT04, 3 gates in parallel, powered from 5v, to drive that potential 75ohm load on HS&VS that some monitors have on the HS & VS inputs.  Others may have a 1k load, but, still, a nice low impedance 5v drive to spec is good and you will protect your FPGA from ESD and any other unpredictable surge from that VGA connector.

Between the FPGA output and the 74ACT04 inputs, I would have a 470 ohm pullup to 3.3v strengthening that crucial weaker high drive of the FPGA output to match it's larger low drive current and to pass that CMOS/TTL emulated threshold of a 5v powered HCT04/ACT04.

EG
                           -> T04 ->
FPGA OUT VS -> T04 -> VGA connector VS pin
                           -> T04 ->

                           -> T04 ->
FPGA OUT HS -> T04 -> VGA connector HS pin
                           -> T04 ->

In your FPGA code, just invert the HS & VS out.

[simmconn]

Depending on whether the VGA output is for an in-chassis VGA monitor or a DB-15 VGA connector and 6ft+ cable to the monitor. The sync driver may not be needed in the former case. Even if the sync driver is needed I would be careful with 74ACTs. They are fast and strong drivers, often too fast and too strong that create nasty reflections and ground bounce. Especially for the un-terminated sync lines. I have no idea why VESA specified a high load impedance for the sync signals but still use low-impedance coaxial cables for them. In that case proper clamping circuit at the source is probably more important than driving the full 5V voltage. The sync spec is in TTL levels so theoretically compatible with LVCMOS.

[Yansi]

Isn't clamping already present, within the final stage of the '04 inverters? I mean, that complementary pair of mosfets has to have the substrate diodes connected somewhere, likely to a VDD and VSS. So clamping is already well present.

[simmconn]

Well, it depends on what you want to get hit when the spike comes, the parasitic, un-characterized body diode in your multi-pin chip, or a more robust standalone diode right at the IO connector. Engineers may make different decisions base on many factors such as the cost structure and the usage environment of the product, etc.