Can a FPGA work like a microprocessor ?

Some FPGA's like the Xilinx Virtex-4 (FX - PowerPC) come with a hard(always there) processor within the programmable fabric. There are also soft core microprocessors that use the general FPGA fabric for their implementation like MicroBlaze.

In both cases the microprocessor cores generally can do what their standalone equivalents can do. The difference comes in that unused FPGA fabric can be used to implement the any digitial function or interface you like within the bounds of the device size and speed. Some interfaces will need external buffering depending on the voltage levels e.g. a transceiver for CAN bus.

The one weak area is replacing a microcontroller that has analogue interfaces. Currently there is virtually no analogue support in FPGA's so any analogue functions like A to D tend to need add on devices.

John Adair Enterpo> Hi all, can a FPGA work like a microprocessor ? If yes upto what extent

Further,

The hard IBM 405 PowerPC in Virtex II Pro, and Virtex 4 is optimized for low power, not for high speed. Generally speaking, the FPGA will get hot from doing all of the other things it needs to do, that having a uP on the same die requires that uP to be low power, not super high speed.

The soft uP (PicoBlaze, MicroBlaze) which is a uP optimized to be built from the fabric of the Xilinx architectures is optimized for area, and speed. But the area may be reasonably small, the the performance is perhaps 4 or 5 times slower than the hard processor, and many times slower than a speed optimized uP in its own package.

Regardless, since the 405 PowerPC exisits as up to two cores in a single part, and you may stuff as many PicoBlazes, or MicroBlazes as will fit in a part, the need for performance or speed may be addressed by multiprocessing.

However, if there is something needed to be done fast, then use of the raw gates to implement a massively parallel logic solution is superior. For example, a uP DSP program may be able to execute 100 times faster in logic, as opposed to on the uP. Interfacing to the uP is done with the auxiliary processor unit interface (build your own coprocessor to do exactly what you need) on the Virtex 4 FX parts. In the earlier parts, the hardened functions can be added to the interface buses (but are not as fast as the APU bus).

Generally speaking, if a uP solves the problem, then it is unlikely you would consider a FPGA. The reason to use a uP in a FPGA must have some other justification. For example, an automotive electronics supplier decided that providing maintenance for a new uP every year (that is subsequently obsoleted in less than 5 years) was far more expensive thaqn using an entirely soft uP solution in a Spartan device. Speed is no issue, cost is no issue (in fact the Spartan device soft processor combined with other functions they required was similar in per socket cost). This way the design is in HDL and c code, and can be ported to any new FPGA. And we also maintain a supply for our components for much much longer than the merchant uP industry.

We have supplied components for 20 years before last time buy notices.

Austin

Aust> Some FPGA's like the Xilinx Virtex-4 (FX - PowerPC) come with a

Another weak area, wrt microcontrollers, is lack of on-chip FLASH code memory. Some small FPGA cores/tasks can run out of BRAMs, and those get quite closely equivalent to the smallest microcontroller CORES.

Then there are common uC peripherals (besides ADCs) like low power oscillators, calibrated RC oscillators, WDOGs, brown out detectors, DACs, and 5V compatible pins.... All this means you could find a FPGA used alongside a Microcontroller, with each doing what they are best at.

-jg

FPGA's do have some limitations, and are not appropriate in every case that requires a microcontroller, but they also have some important strengths for embedded processing applications. For example, if you need to interface with a device that has non-standard I/O, you can either do it in software, inefficiently, or write an interface that allows your software to interact with it in a standard way. IOW - you can push some of the difficult problems into hardware, making the software simpler.

TFT LCD's, for example, can be tricky to deal with. In the SoC design that I am working on, though, the interface logic allows software to simply write to an address in memory. No waiting, no funky I/O routines

- just a single STA in a simple memcpy routine.

That is why FPGA based SoC's can be very powerful.