I have been working with MCU's since the 90's, and I've recently ventured into the FPGA scene with the Spartan6 series chips from Xilinx. Assuming a simple factory automation design with sensors and motors, and some intelligence to link everything up, on which type of device could I finish the design faster and easier, MCUs or FPGAs? Small or "obvious" points are also appreciated because I'm new to FGPA's in general.
-
\$\begingroup\$ Even an FPGA solution would almost certainly also involve a processor, either next to the FPGA, implemented inside of it, or in a connected larger computer. Stored program structures are just far more readily targeted for implementing the complex parts of algorithms than specialized logic or state machines would be, so you save the later only for things which must be fast (or massively parallel) but simple. \$\endgroup\$– Chris StrattonOct 26, 2012 at 14:33
-
\$\begingroup\$ Great answers from richard & Martin below. It can be tempting to try to apply a newly-learned skill or technology to the next problem, but in this case (for reasons described by gentlemen above) I think an MCU is the way to go. \$\endgroup\$– RadianOct 31, 2012 at 17:56
2 Answers
There's no reason to use FPGAs unless you need to. Even two similarly talented engineers in the MCU and FPGA fields would use an MCU for a relatively simple automation task.
Pro MCU:
- MCUs usually have all the peripherals to the outside world ready to go
- Compiling takes seconds (FPGAs take minutes to hours)
- There are an order of magnitude (or two!) more engineers that can help, or pick up where you left off. (For a fun, not necessarily statistically valid, comparison - compare the number of Q&A on Stack Overflow for C vs VHDL or FPGA)
Use an FPGA if you have to because:
- The number-crunching required can't be met in the power, weight, size or cost budget with a microprocessor
- There are hard real-time deadlines which can't be guaranteed with software (response times in the microsecond realm for example)
- Using FPGA logic may make it easier to make robust assertions about response times
- You can make big savings in cost, power etc by using custom data-types (like a 12-bit floating-point for example)
Or:
- Your assignment tells you you have to :)
-
\$\begingroup\$ +1 For the 3rd bullet with "an order of magnitude (or two!) more engineers that can help". Last time I've used this criterion, it was for choosing programming language. \$\endgroup\$ Oct 25, 2012 at 18:32
A few reasons why I believe using a microcontroller (MCU) would be easier for you:
- You have experience with MCUs. Learning the ins and outs of any new chip takes time.
- MCUs have inbuilt peripherals which you would have to implement yourself (or buy) on an FPGA. For example, most MCUs have an I2C port which will come in useful if you read from an I2C sensor. Also, most MCUs have some sort of analogue to digital converter and pulse-width modulator, both of which will most likely be necessary for good motor control.
- Complex algorithms are easier to express in C than in VHDL (I have no experience of Verilog).
- Human-scale delays are easy in an MCU, but take significant resources in an FPGA.
- For simple factory automation the short, standard bit widths and slow speeds of MCUs are most likely sufficient.
It is necessary in either case to take care with the code you write, so that it works properly in all situations, especially dangerous conditions.