Generating colour bars with minimal resources

[Terry]

You had me confused, too - but it is obvious when you think about it!

[ppppenguin]

Looked at the multiplier problem again. In VHDL you can just say PRODUCT <= A * B; and it will synthesise a mutliplier. No guarantees that it will be the best possible multiplier structure for the device or for your application. In a FPGA type device with dedicated multiplier hardware this usually works well, in a CPLD it completely blew the macrocell etc budget for reasons that are unknown and probably unknowable. The Coregen system that allows you to make mutlipliers and much else with good control over implementation isn't available for CPLDs. So it's DIY time. A bit like the old days in the 1990s when I desgined efficient multipliers from scratch to use in ancient FPGA families.

Mutliply is just a row of gated adders and simple shifts. This is 8 bit signed by 6 bit unsigned with only the top 8 output bits used. It took 57 macrocells which is affordable. Probably full of errors but it proves the concept will work. On this basis the whole design for a colour bar generator llooks feasible.

Code:

----------------------------------------------------------------------------------
-- Invotron router controller
-- Running on PLDkit XM2C2 module. Coolrunner-II XC2C384-7FT256

-- Multiplier for colour bars.
-- A is up to 8 bit signed multiplicand, B is up to 8 bit unsigned multiplier
-- Product is only 8 bit. Lower bits are truncated
-- 8x6 piped multiplier without B delay compensation uses 57 macrocells. Another 15 needed for B delays

-- 16/7/16: Ideas
----------------------------------------------------------------------------------

----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

-- Allows use of Xilinx primitives
library UNISIM; use UNISIM.VComponents.all;
use USEFUL_FUNCTIONS.all;    -- Useful functions such as "to_std_logic" (boolean to std_logic)

----------------------------------------------------------------------------------------------------------------------
--                             START OF ENTITY        
----------------------------------------------------------------------------------------------------------------------    
entity multiplier is Port (
        CK : in std_logic;
        iMULTIPLICAND, iMULTIPLIER : in  std_logic_vector(7 downto 0);
        oPRODUCT : out std_logic_vector(7 downto 0));
end multiplier;
--===================================================================================================================

----------------------------------------------------------------------------------------------------------------------
--                             START OF ARCHITECTURE        
----------------------------------------------------------------------------------------------------------------------        
architecture rtl of multiplier is

--------------------------------- Internal signals -------------------------------------------------------------------
signal PARTIAL0, PARTIAL1, PARTIAL2, PARTIAL3, PARTIAL4, PARTIAL5 : signed(7 downto 0);
signal A: signed(7 downto 0);
signal B: unsigned(5 downto 0);
--===================================================================================================================

--A is mutliplicand. 8 bit, 2's comp. Use SIGNED
--B is multiplier    6 bit, +ve Use UNSIGNED or SLV
-- Set of 6 conditional adders
-- B needs pipeline delays if stages are registered
-- Since low order products are not used there's no need for pipelines there
-- Can use mixture of registered and unregistered stages. Possibly 2 or 3 stages before register

-- Need to sort out shifts
begin

-- Assign inputs
A <= signed(iMULTIPLICAND);
B <= unsigned(iMULTIPLIER(5 downto 0));

process (CK) begin
    if rising_edge(CK) then


-- First stage is just a set of AND gates
        if  B(0) = '1' then PARTIAL0 <= A;
             else            PARTIAL0 <= X"00";
        end if;

-- Shift with sign extension
        if  B(1) = '1' then PARTIAL1 <= (PARTIAL0(7) & PARTIAL0(7 downto 1)) + A;
             else            PARTIAL1 <= (PARTIAL0(7) & PARTIAL0(7 downto 1));
        end if;

        if  B(2) = '1' then PARTIAL2 <= (PARTIAL1(7) & PARTIAL1(7 downto 1)) + A;
             else            PARTIAL2 <= (PARTIAL1(7) & PARTIAL1(7 downto 1));
        end if;

        if  B(3) = '1' then PARTIAL3 <= (PARTIAL2(7) & PARTIAL2(7 downto 1)) + A;
             else            PARTIAL3 <= (PARTIAL2(7) & PARTIAL2(7 downto 1));
        end if;

        if  B(4) = '1' then PARTIAL4 <= (PARTIAL3(7) & PARTIAL3(7 downto 1)) + A;
             else            PARTIAL4 <= (PARTIAL3(7) & PARTIAL3(7 downto 1));
        end if;

        if  B(5) = '1' then PARTIAL5 <= (PARTIAL4(7) & PARTIAL4(7 downto 1)) + A;
             else            PARTIAL5 <= (PARTIAL4(7) & PARTIAL4(7 downto 1));
        end if;

    end if; -- CK
end process;

-- Assign output
oPRODUCT <= std_logic_vector(PARTIAL5);  
--===================================================================================================================

end rtl;

[ppppenguin]

I've roughed out the rest of the design and it's looking good. Using 322 macrocells out of 384 available.

Macrocells                              
322/384  (84%)                    

Used Pterms
978/1344  (73%)

Used Registers
277/384  (73%)  

There will be stuff I've overlooked, notably some re-timing delays in a few places but with 62 macrocells in hand I'm pretty confident. Looks like it will be worth actually building the ladder DAC and trying it.

Timing is no problem, I'm running at 25MHz while the analysis tools say it will run at over 40MHz. I'll remove some pipelining in the multiplier and see how it looks. That will save quite a few re-timing delays.

The waveform will still be pretty nasty, with unlimited chroma bandwidth. I wonder if I could soften the chroma edges slightly without using too many resources. There's no problem doing it in theory, with pre-computed transition values for amplitude and phase. Whether it would use too much resource is unknown without trying it.

[ppppenguin]

Did the sums for the DAC yesterday. Conventional R-2R ladder design. Theory is well explained here: http://www.tek.com/blog/tutorial-digital...3-r-2r-dac As explained the DAC can be modelled as a voltage source and resistor. This is the Thevenin equivalent. For an bit bit DAC the voltage source is (255/256) * V. V is 3.3V is my case as the PLD outputs swing pretty much all the way to the rail if they're not loaded too heavily.

This is a crude design so I just want to roughly match 75R and get over 1V swing. THus avoiding the need for an opamp buffer. I also want to use convenient resistor values. For R/2R this means 100R/200R, 120R/240R or 150R/300R. Looks like 120/240 will be about right. The thevenin resistance of the DAC is 120R. Putting 200R across the output will lower than to 75R (120R//200R = 75R) The thevenin voltage will be 3.3V * (255/256) * (200/(200+120)) = 2.054V. This is just over the 2V that I need to give 1Vp-p into a 75R load. A single LSB will be 4.03mV.

Obviously I can't do 100% colour bars with that DAC - I'd need over 1.2Vp-p for that - but EBU bars are fine and they don't go over 1V.

Might give it a go on the bench today. Solder up some resistors and program in a simple ramp to test the DAC.

A crude low pass filter wouldn't come amiss. I could probably program a frequency sweep to check that but it also doesn't want too much overshoot or ringing. It will be crude, though not as crude as the 470p hung across the output of my 3 bit DAC. It only really needs to get subcarrier and low frequencies at the same ampplitude while giving half decent looking edges.

[ppppenguin]

DAC is built and tested. Definitely glitchy at the MSB and MSB-1 transitions and not monotonic at the MSB transition. Didn't expect any better. Only getting 980mV out of it when loaded with 75R rather than 1027mV. Almost 5% low which is more than I'd hoped. I think it's mainly due to the 3.3V rail being a little low and the outputs drooping under load by more than I'd hoped. Not complaining too much. I can fine tune the 200R resistor on the output to get the amplitude spot on, albeit at the expense of accurate output impedance. 220R gives me 1020mV with a theoretical output impedance of 120R//220R = 77.6R. Probably a little higher as the output impedance of the logic will contribute something. Still more than good enough for the intended application.

Did I say this was rough and ready engineering

Fans of the Aurora SCRF may be interested to know that Darryl used a similar R-2R DAC but with a clever twist to get 10 bit conversion from a 7 bit DAC. I won't give away his trade secrets here but not only does it save components and pins on the FPGA but it also gives better accuracy. His basic ladder values are 1K and 2K which will give rather better results than my low values. He uses an emitter follower to give a 75R output.

[ppppenguin]

Generating subcarrier. Just the DTO and sine table so far.  One trace is from these tests, the other, drifting past slowly, is subcarrier from my lab SPG. By sheer luck they're only about 1ppm apart in frequency.

I've put a high quality low pass filter in the output of this test. Things look pretty grim with no filter so it will need a simple LPF. Probably just an L and 2 Cs. I'll calcualte it as a 10MHz 3 pole Butterworth initially, then cut and try to optimise transient performance while giving equal response at subcarrier and low frequencies.

Just remembered sin(x)/x correction will be needed. Not too bad for 4.43MHz sampled at 25MHz but will need a slight boost somewhere. Hope I've got enough range on the DAC to do it by upping the SC gain values. Could easily go over 255 and wrap around to 0.

If all goes well it shouldn't be too far from making colour bars. I've written almost all the VHDL, just got to try it out.

[ppppenguin]

Here's a photo so you can have a good laugh at my expense. First attempt at getting colour bars out of it. There are several problems.

No burst. I know from a test point that there's no burst gate either, so an ordinary logic problem. I also think that even if I am doing the burst gate right the burst will be deleted later by some overenthusiastic blanking. Again an ordinary logic problem. I think the PAL switch is working based on what I can see at a test point.

The chroma amplitudes are all over the place. No idea why yet. The yellow bar is huge! The chroma is at 4.43MHz as far as I can tell.

You can't really tell from this picture but I think the luminance amplitudes are largely wrong too. The syncs are correct as they're from the well tested monochrome pattern generator.

Once I have a burst, preferably a proper swinging PAL burst, the picture monitor and vectorscope will start showing me useful information.

[ppppenguin]

I've now got a burst in about the right place. The vectorscope actually locked to a very brain damaged signal, even if the picture monitor obstinately stayed in monochrome. There's a scattering of vectors. Some are dots, others are like no shape I've ever seen before. I've also managed to muck up something to do with signed integers so black level and blanking are close to peak white while peak white is near black.

I may pull stumps now and run the weekly full backup.

[ppppenguin]

Had 1 more go before switching off and bingo! We have bars. There are a few problems but nothing too bad.Tthe blue chroma amplitude is wrong and I've already found the typo that caused it. There will be some timing refinements to be done and I may be able to smooth off the sharp edges a little bit. I need to sort output filtering and sin(x)/x correction. Basically those bars are already just about good enough for telly mending.

Another question is will the design fit in the CPLD when I add back the logic that handles the control panel of the Museum's video/audio router. Seeing as test pattern generation is a secondary function it feels like the pattern generator tail is wagging the controller dog.

[Terry]

Hanover bars in the Magenta bar?

Is your monitor operating in simple PAL mode?