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:
- 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?
- 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.
- 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?
- 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?
Best Answer
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.