Generating colour bars with minimal resources

[ppppenguin]

Monitor in PAL-D. Hasn't even got a PAL-S switch as some pro monitors have. I think what you can see is the camera interacting with interlace. The green magenta transition is really horrible for 2 reasons. One is the uncontrolled sharp transitions, the other is that Y/C timing is slightly out, probably 120ns or 160ns.

[ppppenguin]

Should add that the vectors and transitions between them are better and cleaner than I've seen on a lot of PAL signals. "Rabbit ears" is the colloquial and self explanatory name for the loopy transitions seen on many PAL signals that come from analogue coders. Notably the burst. Over the years I've spent a lot of effort on getting accurate analogue PAL/NTSC coding in my designs. With digits, provided the DAC is OK and the numbers are right it just works.

[ppppenguin]

I've been going on about sin(x)/x correction forgetting that some of you won't have any idea of what this is about. The theory is quite heavy on maths and is explained pretty well in this application note: https://www.maximintegrated.com/en/app-n...vp/id/3853

In practice it means that the frequency response of any DAC inherently falls off as the frequency rises. What matters is the ratio of the highest output frequency of interest to the sampling clock. The higher this ratio the less correction you need. For a 5.5MHz bandwidth video signal and 54MHz sampling (I use this in some of my professional designs) the correction is only 0.1dB or so. For this project I want colour subcarrier of 4.43MHz to come out right with a clock of 25MHz. It works out at a little over 0.4dB.

The classic method of doing sin(x)/x correction was in the analogue filter (reconstruction filter) that follows the DAC. In the video world these were available with the necessary correction. And a hefty price tag. With oversampling, such as the 54MHz mentioned above, the analogue filter is much simplified and the small correction can also be done easily enough in analogue. It's also easier to do it in digits before the DAC. A simple high pass transversal filter is needed. In my 54MHz example it was a 3 tap filter which was trivial in the FPGA I was using. It's not trivial in the CPLD of this project.

So I'm looking for a quick and dirty solution. I don't need nice flat frequency response, just equal gain at 4.43MHz and DC. So I'll just increase the chroma amplitude as necessary by tweaking the gain numbers for each colour bar. Need to watch out that the maximum ampltude of luminance + chrominance doesn't go over 255 and wrap around to zero. That would look very ugly. I just need to take care and possibly tweak the amount of signal I give to each LSB. At the moment it's 4mV, may have to raise it by a few percent.

sin(x)/x correction matters for all DACs where the fequency response is important. For audio the DACs are usually so heavily oversampled that the correction is truly negligible and can be ignored.

One further point is that the correction needs to be linear phase (or constant group delay to express it another way). The drop in frequency response is unlike a normal simple low pass filter where the phase varies with frequency. Hence the correction should also be linear phase, such as a transversal filter.

[ppppenguin]

Had another look at the multiplier today. I've now built a simple 8 bit (signed) x 6 bit (unsigned) multiplier that is 6 gated adders. I've put 2 registers in there to improve speed. Perhaps surprisingly this also improves denisty. It may be that the fitting tools tie themselves in knots when presented with a huge great lump of combinational logic, giving a poor result. I can't be bothered to see if an extra pipeline stage gives any improvement in density. I don't need it t go any faster. More pipelining means more registers used for both the pipeline and elsewhere as matching delays.

Haven't done anything about the low chroma yet but when I wind up the gain on the vectorscope I can get all the vectors in their correct boxes. Vectorscope previously checked with very accurate colour bars from my main SPG so I know it's spot on.

Don't know if I'll take this project any further but it's been quite interesting. If I wanted to do a more ambitious pattern generator with this CPLD the answer would be an interface to a SD card. With many GB of memory available one could store lots of single frames and even moving sequences as literal data. For PAL, this would mean storing 8 fields of data, even for a still picture, to avoid jumps in subcarrier phase. This is conceptually similar to the Richard Russell and ImoGen test ard generators which both stored literal data, albeit at a lower pixel clock rate and using standard flash chips.

[Mike Watterson]

I'm impressed.

Back in 1982 to set-up cheap screens for school computers we simply bought a Sinclair spectrum and I wrote text patterns in BASIC, yes horrible but cheap then compared to test gear.

I'm still trying to give away some Xilinx gear, (FPGA boards with CLPD too) but Jeffrey says they are too obsolete now to make the postage worth while.