Generating colour bars with minimal resources

[ppppenguin]

In this thread I speculated about generating colour bars using the PLD in the switch panel controller at the Vintage Wireless Museum: http://golbornevintageradio.co.uk/forum/...p?tid=4829&pid=59768#pid59768

The controller is a PLDkit XM2C2 module with Xilinx Coolrunner-II XC2S384FG256. This device has 384 macrocells and is currently just over half full.
http://pldkit.com/xm2c2

So what's needed? I've designed full spec PAL coders in larger Xilinx devices and am very familiar with the methods. But I don't have the luxury of plentiful digits. RGB colour bars are trivial, it's PAL coding that isn't.

Need a better DAC for a start.  The crude current setup with 3 bits plus sync isn't going to make composite PAL. A conventiional 8 bit R-2R ladder DAC should do the job. Might need a video opamp to get the level and impedance right. I've got enough pins available on the module so this is no problem.

Then there's the tricky set of questions about quality. Obviously needs to be good enough to line up a colour TV. Should also look adequate on a vectorscope. So the following aspects, which would need more digital resource than I've got, have to be abandoned:

1: Correct subcarrier to H frequency relationship. Many commercially available generators have skimped on this. So fully acceptable.

2: Bruch blanking sequence. A luxury as far as I'm concerened though it doesn't use much resource.

3: Chroma bandwidth shaping. Simple in analogue, far too resource hungry in digits.

Standard digital PAL coder has an adder/accumulator to make subcarrier phase, a pair of lookup tables to make sine and cosine waves, pair of multipliers to modulate U and V. Then there are filters to shape chroma bandwidth, burst gate and PAL switch generation and a matrix to turn RGB into YUV. Multipleirs, matrix, sin/cos tables and filters will blow the budget completely so some trickery needed.

Adder accumulator cut back to the minimum number of bits I can get away with. Don't know little yet. Can't afford modulators so for each bar use an adder to impose the correct phase offset. Then the smallest sine table I can get away with without completely evil looking results. Experiment needed. Big problem is amplitude modulation of the subcarrier. Yes, it's a multiplier which I can't afford so it'll have to be cut back to minimum number of bits. The rest is pretty routine stuff. I think.

At the moment this is just idle musing. i may or may not actually try it.

[ppppenguin]

I've some sums on subcarrier generation. This is done with an adder/accumulator, sometimes called a numerically controlled oscillator(NCO) or discrete time oscillator (DTO). https://en.wikipedia.org/wiki/Numericall...oscillator

In this case the available clock is 25MHz and the required frequency is 4.43361875MHz. Hence the amount to be added on each clock cycle is 4.433../25 = 0.1773.... I ran a spreadsheet for different numbers of bits in the accumulator. Since the computed coefficient isn't an integer and the actual coefft is integer there will be an error so I worked it out for all accumulator sizes from 8 to 32 bits. In parts per million it's horrible up to 16 bits. At 17 bits it's -3ppm which is acceptable for this application.

To give an idea of how to get it exactly right for my professional designs I use 32 or 36 bit accumulators. These give negligible errors but the relationship must be exact. In PAL the subcarrier and H timing recur over an 8 field sequence so I reset the accumulator every 8 fields. This also has the merit of lokcing phase as well as frequency which matters in the professional world. The phase jump is a tiny fraction of a degree for the big accumulators I use.

There is way of using a DTO to give exact ratios where the denominator isn't a binary power. I believe that the method is by John Chambers who worked at BBC Research labs many years ago. This involves changing the coefft when the accumulator overflows. It's not too hard to do and may allow a smaller accumulator. Though as it increases complexity elsewhere it may not give an overall saving. I can't find an online reference at the moment, can't even find my own notes.

[ppppenguin]

There's another way of tweaking ashort DTO to give better accuracy. For example in this application a 9 bit DTO needs a coefft of a fraction over 90.8. So if the coefft was 91 but 1 time in 5 it was reduced to 90 the resulting subcarrier frequency error would be 5.6ppm. Easy to implement using a 3 bit counter. Whether this gives any useful resource saving over a 17 bit DTO is another question. Only 12 registers as against 17 but the adder logic may get more complex with a changing coefft.

[Nick]

Is the John Chambers approach similar to the Bresenham line drawing algorithm? Certainly sounds like it...

[ppppenguin]

I looked up the Bresenham line drawing algorithm and it isn't very similar.

I use Chambers' method here to make 88.2kHz from a 49.152MHz clock. Explaining how this works isn't all that easy. At least I don't find it easy to explain but I've implemented it several times.

-- 17 bit DTO with extra bit for carry
-- 88.2kHz = 49.152MHz * 147/81920. 147 = 00093h. 147+131072-81920=49299=C093h
if WORD_CLOCK44_DTO(17)='1' then WORD_CLOCK44_DTO <= ("00" & X"C093") + ('0' & WORD_CLOCK44_DTO(16 downto 0)); -- Except when overflow
else WORD_CLOCK44_DTO <= ("00" & X"0093") + ('0' & WORD_CLOCK44_DTO(16 downto 0)); -- Add 147 most of the time
end if;

I've roughed out some VHDL for the colour bar generator and it's clear there are 2 big lumps: The sine table and the multiplier. The mutliplier may not be too bad. Assuming that an 8 bit adder can be done in 8 macrocells, an 8x8 multiply should take no more than 64. That's a lot in a device with only 384 to its name and with half already used but may be affordable.

I don't have a feel for the sine table. If it's 8 bit phase and 8 bit out that would be a 256 bit lookup table but the sum-of-products architecture might implement it in much less. In the very minimum case where the logic function for each output bit can be done with SOP terms in a single macrocell it reduces to something trivial. I don't think using symmetry will help. With a LUT implementation it's common to use 2 fold or 4 fold symmetry to reduce the LUT size but this isn't a LUT style of implementation. The only answer is suck it and see. The Xilinx software won't allow me to use a pre-generated trig core so I'll have to build the sine table in a spreadsheet and implement it as a case statement. Easy enough.

[ppppenguin]

I've been mucking around with some of the deisgn and seeing how much resource it uses. Quite encouraging. About 40 macrocells for a 17 bit DTO and all the phase shifting logic to give the different vector angles. Then the really nice result. Unless I've overlooked something an 8 bit input, 8 bit output sine function is only using 16 macrocells. Tempts me to try 10 in, 10 out.

[ppppenguin]

The bad news is the mutliplier, where for reasons that I don't fully understand it's refusing to fit an 8x8 multiplier into the device. I probably only need 8x6 but even so it looks nasty. I suspect the mutliplier it's trying to synthesise is not ideal for what I'm trying to do. I may have to make a multiplier by hand, using a row of gated adders.

There's another little nasty creeping up too. If I get a lot of pipeline delay in the chroma path I'll have to delay the luminance to match. That could be expensive on resources though I have an idea. I'll delay 3 bit RGB rather than 8 bit luminance. That should keep it under control.

[Amrad]

Hello Jeffrey,

There's another little nasty creeping up too. If I get a lot of pipeline delay in the chroma path I'll have to delay the luminance to match. That could be expensive on resources though I have an idea. I'll delay 3 bit RGB rather than 8 bit luminance. That should keep it under control.

I don't see how delaying the RGB is going to help. Surely that will only make the delay longer?

Regards,

Dave.

[ppppenguin]

The RGB is split into 2 paths, one for Y, the other for C. I can delay the RGB on the Y path separately.

[Amrad]

Hello Jeffrey,

Ah, I see! Thanks for the explanation.

Regards,

Dave.