On Wed, 13 May 2009 16:45:05 -0700 (PDT), -jg <[email protected]> wrote:

>On May 13, 10:23*pm, Mike Harrison <m...@whitewing.co.uk> wrote:
>> I'm looking at a possible application and trying to figure the relative costs of FPGA/CPLD versus
>> MCU.
>> I can do it with a microcontroller, but the only MCUs with the hardware I need (TFT LCD controller)
>> tend to come with lots of other stuff (ethernet, large flash, USB etc.) which I don't need.
>
>If you can find a chip that does the task, that's normally going to be
>cheaper than a FPGA.
>(even with unused bits )

In many cases I'd agree that this is true, but in this particular one, almost all the other parts of
the MCU, including most of the 512K of flash, ethernet,USB,CAN,SD etc. etc. and a lot of pins aren't
needed.

>Or, find a uC that is close, and add a smaller Prog Logic device to
>stretch the peripherals.
>Streaming SPI-CPLD can add quite smart 'external peripherals'.
>The uC have Code-flash built in, as well as Analog features.

Again in many cases this would be a good solution but probably not here.
What I'm looking at is the cheapest way to drive a large number (potentially hundreds) of
distributed TFT (PSP) displays with local SDRAM and/or NAND flash storage for a few tens to hundreds
of frames, with a relatively a low bandwidth network of some sort to update content in non-realtime,
and switch the display between stored frames realtime. The aim is to minimise the cost per node as
much as possible.
The NXP LPC2478's LCD controller is fine, but the memory bus will be a bit of a bottleneck,
especially with the NAND flash option, as data needs to pass over the bus 3 times. Unfortunately
for reasons I can't fathom, NXP forgot to put a SPI flash load option in the bootloader of the
flashless 2470 version - it would in principle to load it using the ISP interface at startup but
it's a bit messy. And it would still be more expensive than the Lattice EC1 option.
At some point I may look at the NXP ARM9 LCD part which can load from SPI but it's in a BGA package
and this project is still at a small-scale speculative proof-of-concept stage so prototyping costs
need to be minimised.

The problem for both NAND and SDRAM is getting a contiguous stream of data to the LCD between the
hsyncs- NAND's 25uS page read time, and the SDRAM page sizes are problems which can be solved easily
once you have enough RAM for a 1-line FIFO buffer in an FPGA. It also makes it more potentially
viable to drive 2 displays per controller, which would slash the per-node cost.
The FPGA also provides more flexibility on the interface between units - e.g. faster SPI or UART
rates than the MCU could handle. If there are enough spare pins to commit an IO bank, even fast
LVDS between nodes could be an option,

>> The Xilinx S3A/AN-50 is the cheapest I've found so far, but is a a bit over-specced.
>> CPLDs seem to get expensive above 72 cells and don't tend to have RAM
>
>The two choices do not really seem to overlap here ? - you have a
>quite small logic block, and no
>mention of any processor on the 2nd choice ?

This was more of a general comment than one specific to this app. there is a big cost jump above 72
MC's that makes them not much cheaper than FPGAs.
I did start looking at whether a CPLD solution would be viable, hiding flash read/SDRAM setup inside
the line syncs but the timings & addressing don't quite look like they would work, and you'd need
too many macrocells to add an external SRAM.

>100 macrocells is viable in CPLD (384/512 tend to not stack up), and a
>device like
>ATF1508RE (128MC 3.3V SingleSupply) is $3.90/100+ at Digikey.
>You may be able to add SPI RAM - 32Kx8 is $1.09/100+

Interesting - I'd not noticed that one - I've used Atmel CPLDs in the distant past but had sort of
forgotten that they still did them as they don't seem promote them very much these days..!