If the only tool you have is a hammer . . .

[DJPhil]

Hello everyone, I tried to keep it short this time.

I'm mentally hammering out a project and I'm trying to decide the best way to implement it. I've got no firm concept yet of what it must do, so naturally that makes it a bit difficult to proceed. It's definitely going to involve some computation, and I haven't worked much with digital design myself. I wanted to get some impressions of what you guys would reach for in different situations. I mean, you can't solve every problem with a uC . . right?

I've read up on the basics, and these are the impressions I was left with:

Discrete logic
  A bunch of seven series chips holding hands!
  Simple tasks only, takes up the most space (usually), low power consumption, inflexible, non-volatile, fast
  These days used primarily to interface, buffer, and drive more than compute. You never know though . .

CPLD 
  Basically a mini fpga, or a small pile of discreet logic, though the distinction grows fuzzy on the FPGA side.
  Simple-ish tasks (not math friendly), standalone chip (usually), lowish power consumption, reprogrammable, non-volatile, pretty fast
  Probably what's in that pedometer they handed out at the fundraiser. Used in addressing, interface, and consolidating those dozen discreet logic chips into one chip to save space (and make them programmable).

FPGA
  Like a huge discreet logic orgy! But when the power goes off, what happened in the FPGA doesn't stay in the FPGA.
  Complex paralell computation (loves math), chip + (p)rom (usually), lowish power consumption, reprogramtastic, volatile memory, wicked fast
  Used for . . everything. If you need high performance and efficiency, optimize it on an FPGA and you win.

Microcontroller
  Sort of like a generalized FPGA, but that's not how it works. Not really. It gets complicated so you don't have to.
  Complex serial computation (interrupt driven), standalone chip (usually), medium power consumption, reprogrammable, non-volatile, wicked fast
  Used for . . everything. More 'noob friendly' than an FPGA. Not as efficient as an FPGA.

I know these are massive generalizations, but am I close on these? Did I miss anything big?

[EEVblog]

Not a bad stab at it.
FPGA's can be non-volatile too, and CPLD's can be wickedly fast and FPGA wickedly slow depending on how you look at it.

Microcontrollers are actually extremely low power consumption, FPGA's are the power hogs of the industry. Micros are generally incredibly more efficient than an equivalent soft processor in an FPGA.
FPGA's only really come into their own in processing when you have to do stuff in parallel, lots of stuff. That's why the big FPGA's only come in packages with thousands of pins. Micros don't work in parallel, they are sequential processing machines. If you are simply using an FPGA as a replacement soft processor for a regular micro, then you have likely made a horrible choice indeed. There is a reason why some FPGA's now have "hard silicon" micros embedded in them.

FPGA's are orders of magnitude more difficult to develop for than micros, many many more traps for young players. You often spend more time fighting the complex tools than doing the job.

FPGA's are basically a "brute force" approach, it's like having hundreds of thousands of discrete logic gates at your disposal. That has pros and cons.

Micro have tons of cool peripherals like ADC's, RTCC's, watchdog timers, etc that you don't get with FPGA's.

That pedometer almost certainly uses a micro.

For most tasks a micro is going to do the job and would be your first choice for most apps that need computation. I'd generally only reach for an FPGA when I know a "hard silicon" seuqnetial processing solution like a micro is not going to do the job, or some specific reason I need the re-configurability of the FPGA.

The processing power of modern 32 bit micros that cost a few dollars and run on an oily rag is just incredible.

As always, horses for courses, and YMMV.

Dave.

[TheDirty]

It's nice to play with FPGA's, but you have to be doing something seriously off the wall to require them.  They can also be pretty expensive.  There has been a flurry of 32bit high MIPS uC cores out there lately, even with DSP if your "calculations" require it.

I've been playing with Cortex M3's lately.  Luminary Micro and the new LPC13xx and LPC11xx.  From a price performance standpoint they are pretty tough to beat.  $3 in singles for a 32k FLASH, 8k RAM, 72Mhz, 32bit, super low power Cortex-M0 with no more supporting hardware requirements than a regular PIC or AVR.  I'll be tossing all the other chips I've been using for these things.  They aren't any harder to work with than a PIC or AVR, but probably not for starters just because they are so new there's not a lot of help or sample code.

http://www.higginstribe.com/lpc1xxx/lpc1114-sbb/20100308-lpc1114-breadboard-002.jpg
http://www.higginstribe.com/lpc1xxx/lpc1114-sbb/20100308-lpc1114-breadboard-001.jpg

[DJPhil]

Excellent, I see where I was off track.

Just to clarify my ambiguous requirements, I think I implied a lot more complexity in my needs than I meant. I have largely been working with small power and amplification circuits, and I will be attempting to do something that requires a bi-directional five or six bit counter. My reference to computation was just to assert that there was any at all, as opposed to the none at all that I'm used to working with. 

I figured out how to string together a half-dozen or so discrete logic chips to get where I need to be but it seems like a lot of board space and a mess of spaghetti when I look at it. I found the CPLD pages while looking for a way to consolidate parts. Speed is not a factor for this project as I'm looking at counting pulses that won't exceed 5hz in frequency. I was concerned that I would be wildly underutilizing even the most basic uC for such a simple task and that it might eat a lot of power twiddling it's thumbs. I did read through the datasheets for some of the PIC10 parts, and even after seeing the power consumption (not that I fully understand it all yet) and the 'wake on pin change' power saving bits I still wasn't quite sure where things stood.

I did actually pop open a freebie pedometer from a fundraiser and it contained a coin cell, a five digit lcd (100Km stroll anyone?), a few surface mount components, and a gob of that black epoxy I love to hate right on top of something all the traces went to. It's worth noting that the pedometer is several years old, has no regenerative mechanism, has no power switch (always on), and the LCD is still faintly readable. Not bad for sitting in a desk drawer for a few years!

The analog tasks in the device will be eating about 8-15mA during use (~2hrs/week) and nothing at all during power off if I have it figured right. Given that I've got about 250mAh to work with from a cheap coin cell, it looks like I might have more to worry about from the analog side than the digital side. I'm going to hit the data sheets on the uCs again and re-read about the power saving technology. I must say, I was a whole lot more excited about learning uC programming than trying to figure out CPLDs from the ground up!

Just reading the specs on that 32bit chip makes my head spin, I'll definitely have to wait until my training wheels are off. Those are really good looking boards too, did you simply do another toner transfer on the back to label the pins, or was it something else?

Thanks for steering me right guys, and if anyone has more insight on how they've used the different logic tools out there please add on.

[TheDirty]

Yes, I just use toner transfer for the silkscreen.  I've just recently been doing the silkscreen.  I used to just use marker or something.  I use photo paper for doing the toner transfer on the PCB, but I bought some commercial paper that I haven't had much success with, but it does the silkscreen really well, so I use it strictly for that.

I'm not the best with starter microcontroller advice, so I'll leave most of that to others.

It's not really a starter chip, but the defacto standard at the moment for low power is the MSP430 line from TI.  The chips are actually not too bad to start out with and there's a nice USB programmer/debugger that you can get for $30 that uses their spy-bi-wire interface.  Unfortunately only a select number of the chips support the spy-by-wire interface and some say they do, but aren't actually compatible with the starter programming tool.  Still you have a decent selection of chips to select from and they are fairly easy to program and there's a decent user group out there for them.  The nice development environments are all commercial, but CCS (the TI offered one) is free up to 16k limit and IAR kickstart is free up to 8k.  There's GCC port for it, but with no debugger it's painful to use.  I use these currently but am happy to ditch them for the new Cortex-M0 parts because of that 16k limit.  The big thing with the MSP430 is the new Chronos watch/kit that everyone is buying up.
http://wiki.msp430.com/index.php/EZ430-Chronos

If you want confusing, try out the ARM7's.  The peripherals are crazy.  Luckily these simpler Cortex-M3 parts all but replace them.

Anyway, I'm mostly rambling here.

[EEVblog]

CPLD's are pretty easy, just use a schematic compiler.
You can use schematic compilers for the FPGA's too, but in this case you wouldn't bother.

As for micro's, never worry about them being underutilised when they cost 10's of cents and can run from their own internal low power 32KHz oscillator, they would work a treat.

Dave.

[Neilm]

I have always found that there are more architecture constraints with CPLDs than with FPGAs. I got caught out by that on a project may years ago where the guy designing the board decided it would be a good idea to put all the data and address bus lines beside each other. The internals of the chip meant that it would either read the data bus or write to the data bus but not both - some of the logic terms for the data bus pins were a couple of hundred terms long.

As for what to program them with - I use VHDL. I have tried schematic capture and found the diagrams either became really horrible really quickly or had to be broken down into such small chunks it was hard to follow.

Neil