Forums

Clock Divider in a 22V10

Started by sam February 11, 2005
Hello all:


I have a 6.144Mhz crystal and I am trying to 
generate the 9600*16 ~ 154k clock needed by the
8251 UART and the ~ 1Mhz system clock.

I dont want to use the 74ls* series ripple
counters and I have a bunch of 22v10 PAL chips
lying around.

I have been thinking about how best to do this,
using what I have.

Basically I need to divide the 6.144Mhz by 40.
First by 5 to realize the system clock, then by
8 to realize the UART baud clock.

With the 22v10 I could set aside two 3 bit 
"registered" outputs for a GLITCH FREE 
synchronous counter ... But I would need the
output of one to drive the other ... and I
dont see how I can do this when they all 
share a common CLK input.

By the way I also have a bunch of 74ls112 dual
J/K flip flops lying around (about 25). I 
thought I might use that along with the 22v10'
to realize my clock divider.

Any ideas?

On Fri, 11 Feb 2005 17:12:36 GMT, sam <sam@here.com> wrote:

>Hello all: > > >I have a 6.144Mhz crystal and I am trying to >generate the 9600*16 ~ 154k clock needed by the >8251 UART and the ~ 1Mhz system clock. > >I dont want to use the 74ls* series ripple >counters and I have a bunch of 22v10 PAL chips >lying around. > >I have been thinking about how best to do this, >using what I have. > >Basically I need to divide the 6.144Mhz by 40. >First by 5 to realize the system clock, then by >8 to realize the UART baud clock. > >With the 22v10 I could set aside two 3 bit >"registered" outputs for a GLITCH FREE >synchronous counter ... But I would need the >output of one to drive the other ... and I >dont see how I can do this when they all >share a common CLK input. >
Clock all the flops at the same rate (you have to, anyhow) and decode a single state of the faster counter and use that as a clock enable on the slower counter, effectively a "carry in." John
In article <pssp01940r9trdauq7epc8l4fsee71c8ti@4ax.com>,
John Larkin  <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:
[...]
>Clock all the flops at the same rate (you have to, anyhow) and decode >a single state of the faster counter and use that as a clock enable on >the slower counter, effectively a "carry in."
I think John meant this but it isn't clear so: If you make the decoded output from the fast section registered. you get the combined logic without adding a lot of delay. The whole thing is well withing the 22V10s reach. -- -- kensmith@rahul.net forging knowledge
On Fri, 11 Feb 2005 19:33:52 +0000 (UTC), kensmith@green.rahul.net
(Ken Smith) wrote:

>In article <pssp01940r9trdauq7epc8l4fsee71c8ti@4ax.com>, >John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote: >[...] >>Clock all the flops at the same rate (you have to, anyhow) and decode >>a single state of the faster counter and use that as a clock enable on >>the slower counter, effectively a "carry in." > >I think John meant this but it isn't clear so: > >If you make the decoded output from the fast section registered. you get >the combined logic without adding a lot of delay. >
Actually, no; it can just be a static decode of one fast counter state that enables the slower counter. It's no different from any other carry. If you have a pin to spare, the carry state can be explicitly decoded and then used in the counter below; if not, you have to include all the decode terms in every flop of the lower counter, which is a nuisance.
>The whole thing is well withing the 22V10s reach.
Right; it's only 6 MHz. Counters *are* a pain in a 22V10; there's no XOR available, so as the counters get longer the number of logic terms explodes. It's tedious to do by hand. John
Back in 1988, I had to make a large counter in a CPLD.  I used Altera's
EP610, which is similar to the 22V10's.  Altera's flops could be
switched between "D" and "T" type flops, so making a synchronous ripple
counter was a simple task.  I don't know if the 22V10's have that
option to switch flops to "T"-type.  If they don't you could always
configure them as "T"-type in the feedback terms and that would make
the counter logic easier, anyway.  I don't see a problem running at 6
MHz to generate a 154 kHz clock -- that's only a 6-bit counter.

sam wrote:
> Hello all: > > > I have a 6.144Mhz crystal and I am trying to > generate the 9600*16 ~ 154k clock needed by the > 8251 UART and the ~ 1Mhz system clock. > > I dont want to use the 74ls* series ripple > counters and I have a bunch of 22v10 PAL chips > lying around. > > I have been thinking about how best to do this, > using what I have. > > Basically I need to divide the 6.144Mhz by 40. > First by 5 to realize the system clock, then by > 8 to realize the UART baud clock. > > With the 22v10 I could set aside two 3 bit > "registered" outputs for a GLITCH FREE > synchronous counter ... But I would need the > output of one to drive the other ... and I > dont see how I can do this when they all > share a common CLK input. > > By the way I also have a bunch of 74ls112 dual > J/K flip flops lying around (about 25). I > thought I might use that along with the 22v10' > to realize my clock divider.
No need to use any additional logic, the 22V10 can /40, but you will need a square wave on the clock. To do both MOD5 and MOD8, you need Mod8.CountEnable = (Mod5 == 0) so that Mod8 clocks at 6.MHz (common clock in the 22V10), but is only ENABLED to change one in 5 clocks. - the rest of the time, it holds value. With a 22V10, you have the resource to separate the BAUD and system clocks : use 6 bits for divide by 40, and the other 4 bits allows programmable divide by 2..16, which you can set on IP pins, and so vary the Sys clock. ( or, indeed the BAUD clock, should you want to try > 9600 bd ) To vary the BAUD clock, you would code the /5, and then have a /2../8, for 9600..- then you can get 9600 - 38.4Kbd If you want the 1MHz to be an average more precise value, you can even code a MOD6/MOD7 counter, and select that on a 6:40 basis, so mostly it divides by 6, but 15% of the time, it divides by 7. You then have 1MHz with 0.0009765625 error Good software for 22V10 code is Atmel's free WinCUPL. -jg
"John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote in
message news:0m5q01t63g4fmadvvtfu79aeu71plhfm1q@4ax.com...
> Counters *are* a pain in a 22V10;
Nah, I used to use Tango PLD. Below is an example of an up/down counter: module(in HOLD, CLK; reg io D7..0; io UP; out WR) { /* setup some stuff */ group D[D7..0]; D[].oe = HI; D[].ck = CLK; D[].aclr = 0; D[].pre = 0; UP.oe = 1; WR.oe = HI; if (HOLD==0) { if (UP.fb) D[]++; /* D is counter, count up */ else D[]--; /* or count down, voila... */ WR = CLK; } else { D[] = D[]; WR = HI; } Meindert
On Fri, 11 Feb 2005 22:51:37 +0100, "Meindert Sprang"
<mhsprang@NOcustomSPAMware.nl> wrote:

>"John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote in >message news:0m5q01t63g4fmadvvtfu79aeu71plhfm1q@4ax.com... >> Counters *are* a pain in a 22V10; > >Nah, I used to use Tango PLD. > >Below is an example of an up/down counter: > >module(in HOLD, CLK; reg io D7..0; io UP; out WR) >{ > /* setup some stuff */ > group D[D7..0]; > D[].oe = HI; > D[].ck = CLK; > D[].aclr = 0; > D[].pre = 0; > UP.oe = 1; > WR.oe = HI; > > if (HOLD==0) > { > if (UP.fb) D[]++; /* D is counter, count up */ > else D[]--; /* or count down, voila... */ > WR = CLK; > } > else > { > D[] = D[]; > WR = HI; > } > >Meindert >
Yeah, that's a lot easier than APEEL, where you have to grind out the product terms. " NOW DO THE COUNTER BITS... MA1 = /MA1 * /MAX MA2 = /MA2 * MA1 * /MAX + MA2 * /MA1 * /MAX MA3 = /MA3 * MA2 * MA1 * /MAX + MA3 * /MA2 * /MAX + MA3 * /MA1 * /MAX MA4 = /MA4 * MA3 * MA2 * MA1 * /MAX + MA4 * /MA3 * /MAX + MA4 * /MA2 * /MAX + MA4 * /MA1 * /MAX MA5 = /MA5 * MA4 * MA3 * MA2 * MA1 * /MAX + MA5 * /MA4 * /MAX + MA5 * /MA3 * /MAX + MA5 * /MA2 * /MAX + MA5 * /MA1 * /MAX etc... So in a 22V10 the product terms get burned up fast as the counter gets longer, no matter how you compile it. Luckily, we don't use simple PLDs much any more; now it's mostly Xilinx FPGAs and the occasional Coolrunner for dinky stuff. John
On Fri, 11 Feb 2005 12:40:41 -0800, John Larkin wrote:

> Counters *are* a pain in a 22V10; there's no XOR available, so as the > counters get longer the number of logic terms explodes. It's tedious > to do by hand. > > John
I found an *OLD* one of mine compiled with AMD's 'PLPL' logic compiler - which used to be free - and did give you an XOR operator - (%); Made counters pretty easy. Bob DEVICE ad2b (p22v10) " same as Redcor ad2.pld except master reset " PIN " Generates address bits 0 - 6 " "---- Output Pin Assignments ----" compare1 = 18 (output active_low combinatorial) compare2 = 19 (output active_low combinatorial) latch = 17 (output active_high combinatorial) a[6] = 14 (output active_high registered) a[5] = 15 (output active_high registered) a[4] = 16 (output active_high registered) a[3] = 20 (output active_high registered) a[2] = 21 (output active_high registered) a[1] = 22 (output active_high registered) a[0] = 23 (output active_high registered) busy2=1 (clk_input) "add_ctr_adv " d[6] = 2 (input combinatorial) d[5] = 3 (input combinatorial) d[4] = 4 (input combinatorial) d[3] = 5 (input combinatorial) d[2] = 6 (input combinatorial) d[1] = 7 (input combinatorial) d[0] = 8 (input combinatorial) master = 9 (input combinatorial) busy = 11 (input combinatorial) ; "Logic Equation Section" BEGIN enable(a[0:6]) = #b1111111; enable(compare1,compare2,latch)= #b111; reset(a[0:6]) = /master; "reset to 0" a[0]=/a[0]; a[1]=a[1]%a[0]; a[2]=a[2]%(a[1]*a[0]); a[3]=a[3]%(a[2]*a[1]*a[0]); a[4]=a[4]%(a[3]*a[2]*a[1]*a[0]); a[5]=a[5]%(a[4]*a[3]*a[2]*a[1]*a[0]); a[6]=a[6]%(a[5]*a[4]*a[3]*a[2]*a[1]*a[0]); compare1=(a[0]%d[0])*(a[1]%d[1])*(a[2]%d[2])*(a[3]%d[3]); compare2=(a[4]%d[4])*(a[5]%d[5])*(a[6]%d[6]); latch=/compare1*/compare2*/busy; END.
"John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote in
message news:1gbq015ibg617j0nrmnj227cllfkphlj5j@4ax.com...
> Yeah, that's a lot easier than APEEL, where you have to grind out the > product terms. > > > " NOW DO THE COUNTER BITS... > > MA1 = /MA1 * /MAX > > MA2 = /MA2 * MA1 * /MAX > + MA2 * /MA1 * /MAX > > MA3 = /MA3 * MA2 * MA1 * /MAX > + MA3 * /MA2 * /MAX > + MA3 * /MA1 * /MAX
<snip> Ha, and exactly that could be distilled from the output of TangoPLD
> > So in a 22V10 the product terms get burned up fast as the counter gets > longer, no matter how you compile it.
Correct, however my example *was* made for a 22V10. And it worked (8 bits wide). Meindert