Post by thread:[EE] Low pin count CPLD-like device.

I have an application where I need to end up with effectively a 24 bit divide by-n counter, where n is going to be fixed at design time - probably on the order of 10 million or so. I also need to do a compare on the 24 bit value to output a single bit based on the current value of the divide-by-n counter. Seems like an application for a FPGA, or perhaps the correct CPLD (if I can find one which has enough flip/flops and/or logic)..... but all I really need are three i/o pins, count, reset, and "comparator output" - and it seems almost impossble to find a low pin count device which has enough logic inside to do a 24 bit counter without also having a huge number of pins. About the only thing I've found so far are some of the Atmel ATF family, which are available in 40 or 44 pin packages, which is a bit big, and perhaps the Cypress PSoC which might just do the trick. The problem I'm finding with the CPLD's in particular is that there seems to be some sort of unwritten rule that the flip-flop must connect directly to the output pin, and you can't have extra flip-flops floating around not associated with a pin. As a result, a CPLD which implements a 24 bit counter, plus an additional output must have at least 25 output pins, plus 2 input pins. Unfortunately, these seem to be few and far between. The FPGA's are just big, and most need config flash as well. I really would like to find something which is like a simple 16v8, but has quite a few extra macrocells which are internal to the part which are tied into the and array and not dedicated to a pin. That way you could implement a counter or similar which is much wider than the device's I/O, and which doesn't require some horrific quantity of pins simply to get the amount of logic needed. So, have I missed any parts? -forrest

Depending on the speed have you looked at something like a 10F pic? Forrest Christian wrote: {Quote hidden}> I have an application where I need to end up with effectively a 24 bit > divide by-n counter, where n is going to be fixed at design time - > probably on the order of 10 million or so. I also need to do a compare > on the 24 bit value to output a single bit based on the current value of > the divide-by-n counter. > > Seems like an application for a FPGA, or perhaps the correct CPLD (if I > can find one which has enough flip/flops and/or logic)..... but all I > really need are three i/o pins, count, reset, and "comparator output" - > and it seems almost impossble to find a low pin count device which has > enough logic inside to do a 24 bit counter without also having a huge > number of pins. > > About the only thing I've found so far are some of the Atmel ATF family, > which are available in 40 or 44 pin packages, which is a bit big, and > perhaps the Cypress PSoC which might just do the trick. The problem > I'm finding with the CPLD's in particular is that there seems to be some > sort of unwritten rule that the flip-flop must connect directly to the > output pin, and you can't have extra flip-flops floating around not > associated with a pin. As a result, a CPLD which implements a 24 bit > counter, plus an additional output must have at least 25 output pins, > plus 2 input pins. Unfortunately, these seem to be few and far between. > > The FPGA's are just big, and most need config flash as well. > > I really would like to find something which is like a simple 16v8, but > has quite a few extra macrocells which are internal to the part which > are tied into the and array and not dedicated to a pin. That way you > could implement a counter or similar which is much wider than the > device's I/O, and which doesn't require some horrific quantity of pins > simply to get the amount of logic needed. > > So, have I missed any parts? > > -forrest > -- Vapour Forge Jake Anderson Project Manager Mobile: 0412 897 125 Email: spam_OUTjakeTakeThisOuTvapourforge.com Web Page: http://www.vapourforge.com Your source for custom IT services

Just to clarify my application slightly - in essence what I am building is a 24 bit "resettable" PWM... that is, a resettable divide by n counter attached to a magnitude comparator.. And both the value of "n" and the value the comparator compares to can be set at synthesis-time. Forrest Christian wrote: {Quote hidden}> I have an application where I need to end up with effectively a 24 bit > divide by-n counter, where n is going to be fixed at design time - > probably on the order of 10 million or so. I also need to do a compare > on the 24 bit value to output a single bit based on the current value of > the divide-by-n counter. > > Seems like an application for a FPGA, or perhaps the correct CPLD (if I > can find one which has enough flip/flops and/or logic)..... but all I > really need are three i/o pins, count, reset, and "comparator output" - > and it seems almost impossble to find a low pin count device which has > enough logic inside to do a 24 bit counter without also having a huge > number of pins. > > About the only thing I've found so far are some of the Atmel ATF family, > which are available in 40 or 44 pin packages, which is a bit big, and > perhaps the Cypress PSoC which might just do the trick. The problem > I'm finding with the CPLD's in particular is that there seems to be some > sort of unwritten rule that the flip-flop must connect directly to the > output pin, and you can't have extra flip-flops floating around not > associated with a pin. As a result, a CPLD which implements a 24 bit > counter, plus an additional output must have at least 25 output pins, > plus 2 input pins. Unfortunately, these seem to be few and far between. > > The FPGA's are just big, and most need config flash as well. > > I really would like to find something which is like a simple 16v8, but > has quite a few extra macrocells which are internal to the part which > are tied into the and array and not dedicated to a pin. That way you > could implement a counter or similar which is much wider than the > device's I/O, and which doesn't require some horrific quantity of pins > simply to get the amount of logic needed. > > So, have I missed any parts? > > -forrest >

Yes, I knew I forgot to mention something like that... I'm counting a signal on the order of 10Mhz.... and the comparator output has to be really fast - much faster than you could implement even in a very tight loop of assembly. -forrest Jake Anderson wrote: {Quote hidden}> Depending on the speed have you looked at something like a 10F pic? > > Forrest Christian wrote: > >> I have an application where I need to end up with effectively a 24 bit >> divide by-n counter, where n is going to be fixed at design time - >> probably on the order of 10 million or so. I also need to do a compare >> on the 24 bit value to output a single bit based on the current value of >> the divide-by-n counter. >> >> Seems like an application for a FPGA, or perhaps the correct CPLD (if I >> can find one which has enough flip/flops and/or logic)..... but all I >> really need are three i/o pins, count, reset, and "comparator output" - >> and it seems almost impossble to find a low pin count device which has >> enough logic inside to do a 24 bit counter without also having a huge >> number of pins. >> >> About the only thing I've found so far are some of the Atmel ATF family, >> which are available in 40 or 44 pin packages, which is a bit big, and >> perhaps the Cypress PSoC which might just do the trick. The problem >> I'm finding with the CPLD's in particular is that there seems to be some >> sort of unwritten rule that the flip-flop must connect directly to the >> output pin, and you can't have extra flip-flops floating around not >> associated with a pin. As a result, a CPLD which implements a 24 bit >> counter, plus an additional output must have at least 25 output pins, >> plus 2 input pins. Unfortunately, these seem to be few and far between. >> >> The FPGA's are just big, and most need config flash as well. >> >> I really would like to find something which is like a simple 16v8, but >> has quite a few extra macrocells which are internal to the part which >> are tied into the and array and not dedicated to a pin. That way you >> could implement a counter or similar which is much wider than the >> device's I/O, and which doesn't require some horrific quantity of pins >> simply to get the amount of logic needed. >> >> So, have I missed any parts? >> >> -forrest >> >> > > >

On Aug 24, 2008, at 8:39 PM, Forrest Christian wrote: > The problem I'm finding with the CPLD's in particular is that there > seems to be some sort of unwritten rule that the flip-flop must > connect directly to the output pin, and you can't have extra flip- > flops floating around not associated with a pin. Yeah, I've noticed that as well, back when I was thinking about doing relatively complex state machines in PLDs, but didn't actually need the "state" on output pins. IIRC, there used to be some specialized "state machine" PLDs, but they went away in favor of more general purpose devices :-( If you're doing a PWM controller, you'll need even more flipflops to hold the end values, right? BillW

On Sun, 24 Aug 2008 22:11:11 -0600, you wrote: >Yes, I knew I forgot to mention something like that... I'm counting a >signal on the order of 10Mhz.... and the comparator output has to be >really fast - much faster than you could implement even in a very tight >loop of assembly. You should be able to get very consistent timing by having the output set by a timer interrupt - instead of count/compare you start the timer with a value designed to give the output when you want. If a PIC isn't quite fast enough (or the /4 clock is an issue) then look at the smaller Atmel ATTiny devices. Can't remember offhand if these will take an external clock tough. Failing that, a CPLD like the Xilinx XC9536XL ought to do it - these are very cheap nowadays, about $1 in low qty. I assume there are other parts of this system - if so, then maybe do these in a Philips LPC2000 series ARM and use one of the 32 bit counters for the PWM thing- these have 32 bit PWM (single edge on LPC2101/2/3, double edge on LPC213x), An LPC2101 wouldn't be out of the question as a standalone solution, but a XC9536 or 72 would be a little cheaper and need fewer support parts. Unless you can do it in a PIC or ATTiny I don't think you'll find a low pin-count solution, but teh XIlinx solution will be pretty low-cost. {Quote hidden}>-forrest > >Jake Anderson wrote: >> Depending on the speed have you looked at something like a 10F pic? >> >> Forrest Christian wrote: >> >>> I have an application where I need to end up with effectively a 24 bit >>> divide by-n counter, where n is going to be fixed at design time - >>> probably on the order of 10 million or so. I also need to do a compare >>> on the 24 bit value to output a single bit based on the current value of >>> the divide-by-n counter. >>> >>> Seems like an application for a FPGA, or perhaps the correct CPLD (if I >>> can find one which has enough flip/flops and/or logic)..... but all I >>> really need are three i/o pins, count, reset, and "comparator output" - >>> and it seems almost impossble to find a low pin count device which has >>> enough logic inside to do a 24 bit counter without also having a huge >>> number of pins. >>> >>> About the only thing I've found so far are some of the Atmel ATF family, >>> which are available in 40 or 44 pin packages, which is a bit big, and >>> perhaps the Cypress PSoC which might just do the trick. The problem >>> I'm finding with the CPLD's in particular is that there seems to be some >>> sort of unwritten rule that the flip-flop must connect directly to the >>> output pin, and you can't have extra flip-flops floating around not >>> associated with a pin. As a result, a CPLD which implements a 24 bit >>> counter, plus an additional output must have at least 25 output pins, >>> plus 2 input pins. Unfortunately, these seem to be few and far between. >>> >>> The FPGA's are just big, and most need config flash as well. >>> >>> I really would like to find something which is like a simple 16v8, but >>> has quite a few extra macrocells which are internal to the part which >>> are tied into the and array and not dedicated to a pin. That way you >>> could implement a counter or similar which is much wider than the >>> device's I/O, and which doesn't require some horrific quantity of pins >>> simply to get the amount of logic needed. >>> >>> So, have I missed any parts? >>> >>> -forrest >>> >>> >> >> >>

Forrest Christian wrote: > Yes, I knew I forgot to mention something like that... I'm counting a > signal on the order of 10Mhz.... and the comparator output has to be > really fast - much faster than you could implement even in a very tight > loop of assembly. > > -forrest Trade code size for speed. Implement the counter as a state machine so that for any given point only a single bye needs to be checked. You know for example that after the MSbyte has crossed some threshold it will test the same the next time. Even to the extent that the last 64 or 128 cycles are a piece of straight line code that flips the output at the end and starts at some indexed location. It might be surprising what could be done. Walter..

Yours and other comments along the similar lines are having me re-think the "too fast for a PIC" thoughts. What I am considering is something along your approach, combined with a previous response. That is, clock the PIC with the high-accuracy clock, and then do some creative programming where the timing is based on instruction cycles. The idea of clocking the PIC with the timing source hadn't occured to me... I'll run with that for a bit and see how it goes. -forrest Walter Banks wrote: {Quote hidden}> Forrest Christian wrote: > > >> Yes, I knew I forgot to mention something like that... I'm counting a >> signal on the order of 10Mhz.... and the comparator output has to be >> really fast - much faster than you could implement even in a very tight >> loop of assembly. >> >> -forrest >> > > Trade code size for speed. Implement the counter as a state machine > so that for any given point only a single bye needs to be checked. > You know for example that after the MSbyte has crossed some > threshold it will test the same the next time. > > Even to the extent that the last 64 or 128 cycles are a piece of straight > line code that flips the output at the end and starts at some indexed > location. > > It might be surprising what could be done. > > Walter.. > > >

Where ever possible make decision earlier rather than later in the process. The last bit can be a jump into a NOP chain that switches an output at the end. The state machine approach of jumping from state to state tends to mean that cycle counting is for longer instruction sequences. w.. Forrest W Christian wrote: {Quote hidden}> Yours and other comments along the similar lines are having me re-think > the "too fast for a PIC" thoughts. > > What I am considering is something along your approach, combined with a > previous response. > > That is, clock the PIC with the high-accuracy clock, and then do some > creative programming where the timing is based on instruction cycles. > The idea of clocking the PIC with the timing source hadn't occured to > me... I'll run with that for a bit and see how it goes. > > -forrest > > Walter Banks wrote: > > Forrest Christian wrote: > > > > > >> Yes, I knew I forgot to mention something like that... I'm counting a > >> signal on the order of 10Mhz.... and the comparator output has to be > >> really fast - much faster than you could implement even in a very tight > >> loop of assembly. > >> > >> -forrest > >> > > > > Trade code size for speed. Implement the counter as a state machine > > so that for any given point only a single bye needs to be checked. > > You know for example that after the MSbyte has crossed some > > threshold it will test the same the next time. > > > > Even to the extent that the last 64 or 128 cycles are a piece of straight > > line code that flips the output at the end and starts at some indexed > > location. > > > > It might be surprising what could be done. > > > > Walter.. > > > > > > > > -