# FPGAs or CPLDs for “Glue Logic” and Video/LCD Capabilities

Some of you may remember I posted a question in which it was suggested that I use CPLDs instead of a large number of multiplexers. Here is the question, for reference.

However, as I read and learn about CPLDs and FPGAs, I realized that FPGAs are also used for video capabilities. My project is going to need something like a 6" to 7" Color LCD in any case. Note, 24 bit color or such is not required. Even an 8-bit display is more than enough for this application. But I cannot help and wonder - would it not be better that I used an FPGA instead of CPLDs? This would mean less chips to work and it will get rid of a microcontroller, possibly.

With my limited knowledge, the reasons that FPGAs don't seem like a good solution are:

1. Are likely more expensive than CPLDs.
2. A mid-range FPGA might not be handle all the logic required for the application, along with video. This implies that I may need more than one chip. At this stage, a relatively powerful microcontroller and CPLDs become more attractive. The CPLDs can be configured for all the logic required and the controller can be the brains.
3. FPGAs will require a programmer onboard as they cannot retain their programming. In comparison, CPLDs are instant-on.

Why do they seem like a good option:

1. Can possibly replace several CPLDs and micro controller.
2. More support available for FPGAs than CPLDs.

Note that I cannot use a powerful FPGA for two reasons. They are very costly and secondly, they most probably come in BGA packages. The local manufactures are able to handle BGAs but its not recommended (I asked).

• you might look at the xmos.com xcore products as different approach – old_timer Sep 8 '11 at 0:25

## 3 Answers

1. FPGA's are more expensive than CPLD's, but they can do so much more too. I only use CPLD's where the "instant on" (i.e., no programming time) is required, or when I need something that costs less than US$5 per chip. For everything else, an FPGA is preferable over a CPLD-- in my opinion. 2. Rarely does it make sense to put a CPU INSIDE the FPGA. When it comes to bang for the buck, you just can't compete with an off the shelf ARM or something similar. The only times it makes sense is when you only need a tiny 8-bit micro (a.la. Xilinx Picoblaze), or you are using an FPGA that includes a hard core and space is more important than cost. For your application, you'll need a reasonable 32-bit CPU to render the graphics for the LCD. So, at the very least, you'll have a 2-chip solution (CPU + FPGA/CPLD). 3. Yes, FPGA's need to be programmed at power-up. This can be a good or bad thing. It's bad because it means that at the very least you need a small Flash EEPROM chip that they "boot" from. It is good because it means that you can easily do "in the field firmware upgrades". With a CPLD, you'd have to drag out the CPLD programmer hardware/software every time you need to do an upgrade. For most of the boards I've designed, I've always had a CPU that took care of programming the FPGA. That CPU has been Power-PC's, ARM's, and an Intel Atom. Since that CPU already had Flash, RAM, Ethernet, and Linux it was a piece of cake to implement the FPGA drivers and FPGA programming stuff. In your case, I would lean toward CPLD's rather than FPGA's. Here's why: 1. Implementing a video output circuitry in an FPGA is not trivial. If I were assigning that task to an engineer, I would not assign it to a Junior engineer. It would have to be a Sr. engineer with 10+ years of experience. A Jr engineer might be able to "make it work", but it wouldn't be very good. Since you need a 32-bit CPU anyway, you might as well get one with a video output-- like some T.I. ARM's have, as well as the Freescale iMX stuff. 2. For those big shift registers, you need very little logic and a lot of I/O pins. More specifically, you need about 4 Flip-Flops per I/O pin. A medium sized FPGA will have maybe 300 I/O pins, but 50,000+ Flip-Flops. So you are really paying money for things you will never use. In the end, I think that you will spend about double or triple for an FPGA solution than a CPLD solution. 3. For someone who is just starting out with programmable logic, CPLD's have a much easier learning curve. There is no sense in making things more complicated before you have to. And here is another bit of unsolicited advise: Stick with the big FPGA/CPLD people (Xilinx and Altera). Avoid the 2nd and 3rd tier manufacturers like Lattice, Actel, Quicklogic, etc. The big guys are no more expensive (or not significantly so), their tools and support are better (and free!), and the skills you learn will be easier to use on future projects. And most importantly, it will look better on a resume! • Thanks very much, David. As usual, your answers are full of useful information. I too thought that CPLDs were a better choice but I wanted to confirm with experienced people, like yourself. And yes, I'm sticking with the big names. I'm sticking with Altera for now. They have great support material on their site and I quite like Quartus II so far. Thanks again for such useful information. – Saad Sep 8 '11 at 3:04 Difficult to say exactly, without knowing a lot more about what you are trying to do and speeds/data involved etc, but I think there are some FPGA options that might suit you. Actel (now Microsemi) make flash based FPGAs which need no support chip to upload configuration, you just program as you would a microcontroller. They do some pretty powerful ones at reasonable prices (e.g. IIRC the 250k gate ProASIC3 is around$15) in QFP packages up to 1M gates, some with soft ARM Cortex M1 option. Here is the ProASIC3 range, I have used a few of them (not tried any above 250k gates) and been quite impressed overall.

• There isn't a lot of data. In short: the current circuit uses a 256 bit demux and a mux (made from cascaded muxes). Instead of mux, I'll use Shift Registers. All of this isn't too much logic, but the applicaiton requires a large number of IO. At least 256 inputs and outputs each. This will probably make it necessary to have a few chips instead of just one. – Saad Sep 7 '11 at 23:10
• Yes, I recall this from your last question now - seems like your main issue if you want to avoid BGAs/multiple chips. The highest IO count is 154 for the QFP in that range, you would have to use at least a 484 pin BGA to get the number of IOs you need. As only the >1M gates have that option it would be expensive and a bit of a waste of such a powerful chip. I think using a few of the smaller ones might be an idea, although then you probably need a uC (unless you do something clever like divide the firmware between small soft cores like e.g a GPU) – Oli Glaser Sep 7 '11 at 23:24
• Yes, its the IO thats the problem. And as you can guess from my question above, I too am leaning towards a multiple CPLD + uC to drive them. – Saad Sep 7 '11 at 23:34

Your simplest bet for a display is probably a chip-on-glass TFT LCD. Those can be fed data at whatever rate is convenient. A typical interface requires clocking in 16 bits of data per pixel even if all one wants to do is display text, but if you don't need instantaneous screen updates they're easier to work with than LCD's that require continuous refresh.