Programmable pulse generator

Kolja Sulimma wrote:
> Ray Andraka wrote:
> 
>>John_H wrote:
> 
> 
>>A DDS can be used to get a programmable rate that is not an integer
>>multiple of the clock frequency and that has a linear relationship
>>between the program value and the output frequency.  The DDS is
>>basically just an accumulator to which a fixed increment is added on
>>each clock cycle. The square-wave output is taken from the MSB of the
>>accumulator. (It will have jitter of up to a clock cycle depending on
>>the increment value).
> 
> 
> I prefer Bresenhams algorithm for frequency generation.
> The N-bit accumulator has a frequency error of up to 1/2^N.
> Bresenhams algorithm is exact for the question "generate N pulses in M
> clock cycles". I also has minimum jitter (up to half a clock cycle).
> The hardware implementation is simple and small.
> 
> Kolja Sulimma

Hmm,  Hadn't thought of that.  I've used Bresenham's algorithm for other 
things, but not for frequency generation.  Should work quite well 
though.  A DDS also solves the N pulses in M clock cycles, but only for 
the case M=2^k where k is the number of bits in the accumulator.  I.e. 
the DDS produces N pulses in 2^k clocks where k is the width of the 
accumulator and N is the increment value.  In the end, I think for M a 
power of two, the math reduces to the same thing whether you use 
Bresenham's or a DDS.

jimwalsh142@hotmail.com wrote:
> Kolja Sulimma wrote:
> I have't heard of that... could you post some links?

Bresenham invented famous algorithms for efficiently drawing lines and circles on bitmaps.
The point here is to realized that the line drawing algorithm can be used for any kind of scaling with factors less than one.
Bresenhams algorithm computes when you need to go up when drawing a line X pixels to the right and Y pixels up.
This is the same problem as producing Y pulses in X clock cycles. Or scaling a bitmap by a factor Y/X. Or....

The algorithm is really simple:
eps = X;
while(true) {
   wait_for_clock_edge();
   eps -= Y;
   if (eps < 0) {
	generate_pulse();
	eps += X;
   }
}

Kolja Sulimma

"Ray Andraka" <ray@andraka.com> wrote in message 
news:xu3Ag.84846$ZW3.49952@dukeread04...
<snip>
> A DDS also solves the N pulses in M clock cycles, but only for the case 
> M=2^k where k is the number of bits in the accumulator.  I.e. the DDS 
> produces N pulses in 2^k clocks where k is the width of the accumulator 
> and N is the increment value.  In the end, I think for M a power of two, 
> the math reduces to the same thing whether you use Bresenham's or a DDS.

This is getting a little off topic but it's such fun:

I like to change the nature of the DDS and perform an N pulses in M clocks 
without the 2^k restriction by normally adding N in a k-bit accumulator but 
adding N-M in the one cycle when the accumulator overflows.  The N or N-M 
value selection can be programmed as two constants and easily selected 
between the two within the accumulator.  The result is typically much better 
available resolution.  Most fractional values have an N/M solution using k 
values much lower than 32 bits that give accuracy significantly better than 
1/4 ppb.  Beyond finding the near perfect ratios (which is algoritmically 
straight-forward but extra software) not all N/M values have a better 
solution than N/2^k such that large values of k are sill desired for generic 
solutions.

The accumulator output range is [N-M,+N) for an accumulator that selects 
between the two add constants.  If the range [-M,0) is preferred, Acc+N and 
Acc+N-M adders can be muxed to the accumulator registers based on the +N 
add's carry output making things like lookup tables easier to deal with.  In 
both cases, one of the strong uses of a DDS - indexing into a lookup table 
with the DDS MSbits - is twisted by a range that's no longer [0,2^k).  In 
those cases the lookup table could be adjusted to the desired range or the 
modified DDS range multiplied by 2^p/M for a p-bit lookup.

Because of some of the extra hardware or reduced lookup resolution, this 
approach is most desireable when lower jitter solutions are desired for a 
PLL-filtered output, keeping the jitter at the higher frequencies where they 
can be filtered out.  There are still a few frequency values that will be 
problematic so it's not a complete fix.

- John_H 

Hi Jim,


This is really simple stuff to do in programmable logic. You can do it
with an adder, plus a comparator if your duty cycles is not 50/50.
Simple in uC too, maybe even cheaper, but 10ns is probably a little too
fast for a uC.



While they can be much more complex and are not working at the same
frequency range, you can steal some ideas from music synthesizers and
such.
- For a simple solution, check out this link:
http://www.fpga4fun.com/MusicBox.html.
- A more complex one is the implementation of the SID chip (MOS-6852?)
[see jester_sid_voice.vhd.], found in the classic C-64 computers:
http://www.fpga.nl/index.html?jester.html


Now, If that's too much for you, I am sure someone in the NG can
provide you some working code if you ask politely :)



ok, I have two other things to say:
 1. Instead of paying 99 USD for a CPLD, you could pay 99-150 USD and
get a very nice FPGA board, maybe even one with a *hint* PLL *hint*!
Play with it, and use it in future projects.
 2. Ignore that BS you read in sci.elec.design, Altera Quartus rocks.
And no, it has no difficulties inferring tri-state buffers :)


and wellcome to the wonderful world of FPGAs!
 -Burns

jimwalsh142@hotmail.com wrote:
> Hi All,
>
> I'm trying to develop a programmable pulse generator, essentially a
> single pulse of variable width repeated at a given rate. I posted a
> similar question a few weeks ago on sci.elec.design and someone
> suggested that this would make a nice CPLD project. As I'm keen to
> learn about programmable logic devices I decided to buy a development
> kit (Altera 7000 series) and try implementing the pulse generator.
>
> My ideal specification would be pulse widths from 10ns to 10us
> incremented in 10ns steps at repetition rates between 1 to 10 kHz. The
> evaluation board has a 25MHz clock so I'm limited to 40ns increments
> but that's ok for now.
>
> I've been playing around with various counters etc but am struggling
> to create anything useful, would be great if someone more experienced
> could give me a few hints!?
> 
> Thanks,
> 
> Jim W