Is an FPGA viable for such a project?

Question

I am currently working on Super OSD - an on screen display project. http://code.google.com/p/super-osd has all the details.

At the moment I'm using a dsPIC MCU to do the job. This is a very powerful DSP (40 MIPS @ 80 MHz, three-register single-cycle operations and a MAC unit) and, importantly, it comes in a DIP package (because I'm using a breadboard to prototype it.) I'm really getting every last bit of performance out of it running the OSD - the chip has about 200ns or 10 cycles per pixel on the output stage so the code has to be very optimised in this part (for this reason it will always be written in assembly.)

Now I was considering using an FPGA for this because due to the parallel architecture of such a chip it is possible to have a simple logic program running the OSD. Things like drawing lines and algorithmic code would be handled by an MCU, but the actual output would be done with an FPGA. And some simple things like setting pixels or drawing horizontal and vertical lines I would like to integrate onto the FPGA, to improve speed.

I have some questions:

1. Will it cost significantly more? The cheapest FPGA's I found were ~£5 each and the dsPIC is £3 each. So it will cost more, but by how much?
2. The dsPIC fits in a SO28 package. I would not like to go bigger than SO28 or TQFP44. Most FPGA's I've seen come in BGA or TQFP>100 packages, which aren't an option at the moment, due to the shear size, and the difficulty of soldering them myself.
3. How much current is used by an FPGA? The dsPIC solution currently consumes about 55mA +/- 10mA, which is okay at the moment. Would an FPGA consume more or less? Is it variable, or is it pretty much static, like the dsPIC?
4. I need at least 12KB of graphics memory to store the OSD graphics. Do FPGA's have this kind of memory available on the chip or is this only available with external chips?

Answer 1

In principle this is good candidate for FPGA based design. Regarding your requirements:

ad 1. The FPGA most likely will be more expensive, by how much that depends on the device you choose. At first glance smallest Spartan 3 from Xilinx (XC3S50AN) will be more then enough for this task (~10£ from Farnell). I think you can assume this is upper boundary for the cost (it has 56kB RAM inside, so it is more then you need). You may find cheaper device either from Xilinx offering or their competitors Altera and Lattice.

ad 2. The package is the tough issue, I did not saw FPGA with smaller footprint either. However maybe you can use CPLD device (for sake of argument the CPLDs are small FPGAs) which may be in smaller package (PLCC or QFN). On plus side they will be cheaper (even single $) on negative side most likely will not have RAM inside. With CPLD probably you would need external SRAM chip.

ad 3. FPGAs and CPLD current consumption is highly dependent on the programmed design. However there is good chance that FPGA and especially CPLD design would consume less than your current solution.

ad 4. FPGA do have that kind of memory inside, CPLD most certainly not. This may be solved by external sram chip (or two). For example:

|SRAM 1| <--> |CPLD| <--> |uC|
|SRAM 2| <-->

In such arrangement while the uC is writing to SRAM 1, the CPLD will be displaying data from SRAM 2. The CPLD should be able to handle both task simultaneously.

Of course you can solve this in other ways too:
1) use faster uController (ARM for example)
2) use device with some programmable fabric and uC inside (for example FPSLIC from Atmel, however I have never used such devices and I know very little about those)

Standard disclaimer -> as designs are open problems, with many constrains and possible solutions whatever I wrote above may not be true for your case. I believe it is worth checking those option, though.

Answer 2

You could use a CPLD rather than an FPGA, such as one of the Altera MAX II parts. They are available in QFP44 packages, unlike FPGAs. They are actually small FPGAs, but Altera plays down that aspect. CPLDs have an advantage over most FPGAs in that they have on-chip configuration memory, FPGAs generally require an external flash chip. There are other CPLDs, of course, but I like the MAX II.

It's impossible to say what the current consumption will be, as it depends on clock speeds and the amount of logic that is actually in use.

FPGAs usually have a limited amount of on-chip memory you can use, but you will need external memory with a CPLD.

Another option would be an XMOS chip, but the smallest one (the XS1-L1) is in a QFP64 package. It has plenty of on-chip RAM - 64k.

Answer 3

1) Yes, the FPGA will be more expensive. Not only is the chip itself more expensive, but you will also need Flash memory to store the programming. FPGA + Flash is probably 3x the cost of just the dsPIC...about $10 for a small FPGA and $3 for small Flash.

2) They may exist, but I'm not really aware of any FPGA that's not surface mount. Most of them are probably QFP or BGA.

3) The FPGA will probably pull about 3x the current that the dsPIC does, but that can go up or down depending on what features you use. FPGAs have many features that can increase power draw. But expect at least 150 mA.

4) FPGAs usually have block RAM inside them. All but the smallest FPGAs should have that much memory.

Others mention CPLDs. If you carefully partition your design, you could probably move some small but expensive operations into the CPLD. It would be like a mini co-processor.

Answer 4

Cheapest solution with the lowest learning curve would be to move to a higher powered processor, ARM most likely.

Programming a FPGA/CPLD in VHDL/Verilog is a pretty steep learning curve coming from C for many people. They also aren't overly cheap parts.

Using a decently capable ARM maybe a LPC1769? (cortex-M3) you would also likely be able to replace the PIC18 in your design.

As for the through hole issue, as long as you can get the SoC in an exposed pin QFP type package, just grab some of these adapters for the needed pin out for your prototyping.

Answer 5

My inclination would be to use something to buffer the timing between the processor and the display. Having hardware that can show an entire frame of video without processor intervention may be nice, but perhaps overkill. I would suggest that the best compromise between hardware and software complexity would probably be to make something with two or three independent 1024-bit shift registers (two bits per pixel, to allow for black, white, gray, or transparent), and a means of switching between them. Have the PIC load up a shift register, and then have the hardware start shifting that one out while it sets a flag so the PIC can load the next one. With two shift registers, the PIC would have have 64us between the time it is told a shift register is available and the time all the data has to be shifted. With three shift registers, the PIC would have to average one line every 64us, but it could tolerate a delay of up to 64us.

Note that while a 1024-bit FIFO would be just as good as two 1024-bit shift registers, and in a CPLD a FIFO only costs one macrocell per bit, plus some control logic, in most other types of logic two bits of shift register will be cheaper than one bit of FIFO.

An alternative approach would be to connect a CPLD to an SRAM, and make a simple video subsystem with that. Aesthetically, I like the on-the-fly video generation, and if somebody made nice cheap 1024-bit shift-register chips it's the approach I'd favor, but using an external SRAM may be cheaper than using an FPGA with enough resources to make multiple 1024-bit shift registers. For your output resolution it will be necessary to clock out data at 12M pixels/sec, or 3MBytes/sec. It should be possible to arrange things to allow for data to be clocked in at a rate of up to 10mbps without too much difficulty by interleaving memory cycles; the biggest trick would be preventing data corruption if a sync pulse doesn't come at the precise moment expected.