14-07-2016, 10:56 AM
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.
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.
www.borinsky.co.uk Jeffrey Borinsky www.becg.tv
