Electronic – PLD, FPGA or microcontroller for PWM decode

There's two criteria that you can use to evaluate a digital project that help you decide which part best matches your criteria. The first is design size/complexity - how much logic is involved. The second is the input and output requirements in terms of pin count. Speed can be factored in if you can estimate what your slowest function would be. The vendor tools (Altera Quartus II, Xilinx ISE, etc.) will help you once you get in the right ballpark.

• PAL/PLA/GAL: These are intended to replace a small to medium size circuits that you might normally implement as LSI logic chips (7400, 4000 series). These can offer better board layouts due to I/O remapping, and lots of simple logic functions. These chips contain non-volatile memory (or one time programmable fuses) and require no power-up configuration time. They may not contain data storage elements.

• CPLD: These are larger cousins of the PLA. The designs can be small state machines, or even a very simple microprocessor core. Most of the CPLD chips that I have seen do not have any on-chip SRAM, although the large Cypress CPLD you linked does. CPLDs are more likely to be re-programmable with flash memory, and they also do not require configuration time on power-up.

• FPGA: Unlike the CPLD, the logic blocks are based on SRAM instead of flash memory, resulting in faster logic operations. The major down-side with FPGAs is that since the configuration is stored in SRAM, every time the device is powered up the FPGA must load its programming into this SRAM. Depending on the size of your design and the speed of your non-volatile storage, this can cause a noticeable delay from power-on to fully functioning. Some FPGAs have on-chip flash for storing their data, but most use separate memory chips. FPGAs will often have hard-wired multipliers, PLLs, and other logic functions to improve computing speed. Large blocks of on-chip RAM is also available. You will also be able to use high-performance I/O specifications like LVDS, PCI, and PCI-Express.

• FPGA with Microprocessor Hard Core: I'm not familiar with these, but I would imagine that your design would center around the microcontroller programming, and the FPGA would augment the microcontroller. The parts you identified make it look like you would start your design with a microcontroller and a FPGA, and then combine the two into one chip/package.

How to decide which is right for you:

The best way is to have your code (Verilog/VHDL) finished, and then use the vendor's tools to try and fit it into the smallest part possible. I know Altera's tool lets you change programming targets fairly easily, so you could keep picking smaller FPGAs, and then smaller CPLDs until your design usage gets close to about 75%. If you require performance, then try to pick devices that have features (fast multipliers) that decrease the speed requirements of the logic. Again, the vendor tools will help you identify if you need to upgrade or if you can downgrade.

Another factor of which part to use is ease-of-use. Using PAL/PLA/GAL logic is probably more effort than constructing the function using discrete logic gates (74HC*, 4000, etc). CPLDs typically require only a single supply voltage, and don't require additional circuitry. They are effectively stand-alone. FPGAs begin to use multiple power supplies for I/O and the logic core, complex I/O standards, separate program memory, multi-layer (>2) PCBs, and BGA packages.

Steps to narrowing down your design requirements would include:

1. Identify all inputs and outputs for your FPGA/CPLD. This is usually an easy part of the design stage. This way you know what package you're looking at, and how close you can cut it to that margin.

2. Draw a block diagram of the internal logic. If your blocks look simple (each block would have a hand-full of logic gates and registers), then you probably can use a CPLD. If, however, your blocks have labels such as "Ethernet transciever", "PCI-Express x16 interface", "DDR2 Controller", or "h264 Encode/Decode", then you are almost certainly looking at a FPGA and using HDL.

3. Look and see if your interfaces have special I/O requirements, such as special voltages, LVDS, DDR, or high speed SERDES. It's easier to get a chip that supports it than to get an additional translator chip.

Example CPLD Applications:

• Multi-channel PWM with SPI interface
• I/O Expander
• CPU Address Space Decoding
• Clocks (Time keeping)
• Display Multiplexors
• Simple DSP
• Some simple programs can be converted into a CPLD design

Example Hobbyist FPGA Applications:

• Small System-on-Chip (SoC) designs
• Video
• Complex protocol bridges
• Signal processing
• Encryption/Decryption
• Legacy system emulation
• Logic Analyzer/Pattern Generator

For most hobbyist work, you'll be limited to relatively small FPGAs unless you want to solder BGA packages. I would choose between a large CPLD or a cheap FPGA, and the size/speed requirements would dictate which one I needed.

To answer the TLC5940 side of the question:

First of all, bear in mind that when using TLC5940 your intensity need not be 12-bit values (4096 values): you can use the TLC5940 using with intensities of any value 12 bits or less. For instance, 8-bit intensities (256 values) do provide a very satisfying result. More on this latter.

Assuming 12-bit intensities, here's how GSCLK and BLANK work: TLC5940 doesn't have its own clock. So GSCLK is used to figure out when to turn on and off each LED. At the beginning of a cycle, all LEDs are on. Each time positive-going edge on GSCLK is received an internal counter is incremented on TLC5940. Each LED whose intensity value is lower than the counter is turned off. So LEDs with intensity 1 are turned off after the first cycle, LEDs with intensity 2 are turned off after the second cycle, and LEDs with intensity 4096 are not turned off at all. At the end of the cycle the chip does not reset itself, rather it expects a positive-going edge on BLANK to reset it, and after this the cycle begins again.

Here's what this means for driving the TLC5940: you need two PWM outputs; one for GSCLK and one for BLANK, and the one for BLANK needs to happen every 4096 cycles of GSCLK. Now notice that we are talking about the frequncy here, and not the duty cycle, whereas it is the duty cycle that analogWrite() controls. To drive the TLC5940, you could use a library written for driving TLC5490, or you can do the lower-level driving of TLC5940 yourself, which can use one of the following approaches (assuming you are using an ATmega-based Arduino, and in scale of increasing difficulty):

• Program the two timers yourself such that they use different prescalers such that the BLANK line is driven at 1/4096th the frequency of the GSCLK
• Program the CKOUT fuse on the ATmega, causing it to output the clock signal on one of its output pins. Use this for GSCLK. Then use a timer to generate a BLANK pulse at 1/4096th of clock frequency.
• Clock the ATmega externally, and use the same clock for GSCLK. Have an ATmega timer generate the BLANK pulse at 1/4096th of clock frequency.

Now to the question of frequency relationship between the TLC5940 clocking and the PWM. The BLANK line will have a duty cycle of 1/4096 (or whatever the maximum intensity value you are using), so that probably will not work for your servos. The GSCLK is usually 50/50 duty cycle but need not be. Lets assume that you want your LEDs to appear to be steady, and lets take the flicker theshhold to be 50Hz. This would mean that you need your intensity 1 LED to be flickering at 50Hz or above, meaning that a 4096-clock long cycle should complete in 20 milliseconds, meaning that your GSCLK clock should be at least 204kHz. At 204kHz the clock pulses are about 5uS long. So while in theory you could use the same clock for your servos and the TLC5940 (I think that's what you are asking): if you maintain the clock frequency (at 204kHz) and change the duty cycle you could control your servos and clock the TLC5940. However, if you use 12-bit intensities, then the greyscale clock needed by TLC5940 is going to be too fast for the servos.

But, if 4096 intensity values is too much to handle, consider using 8-bit intensity values. You will still have to send them as 12-bit values (that's what the TLC5940 interface expects), however, the is no law that says that your BLANK pulse must occur every 4096 GSCLK clocks. If it occurs every 256 clocks, you have yourself 8-bit intensity. So your 8-bit intensities should be sent as valid 12-bit values (with the high four bits being zero), and you'll restart the clocking cycle every 256 clocks. You can use any other number of intensity bits, as long as it is 12 or less, in the same manner. If you are using 256 intensity (=greyscale) values, then your minimum clock is 12.8kHz, and the clock duration is 78uS. Closer the 2400uS +90 pulse, but still quite far away. If we assume that +90 pulse is 90/10 duty cycle, then we calculate the clock cycle length to be 2.6mS, which translates into 375Hz clock. At this clocking, the maximum intensity value that will yield no flickering is 8 values (3 bits) at 50Hz persistence theshhold, and 16 values (4 bits) at 25Hz. You can decide whether that is good enough for your purposes.