Blog

Blinded by the light.

At the end of blog post #3 I suggested that before deciding on a specific FPGA vendor I had to have a project in mind. One key difference between MakerLogic and my day job is that MakerLogic projects are based purely on what I or my kids – or you readers – deem to be fun and interesting.

What a concept!

I spent considerable time looking through Hackaday and Hackaday.io, Make and other sites devoted to makers and their projects. I also attended several Maker Faires and Mini Maker Faires to see what types of projects were popular. I wanted to settle on something quickly so that I didn’t spend too much time in the analysis stage and never get started (see blog post #2).

One area that had tremendous representation was blinky lights. Matrix LED panels, smart LED pixel strings, LED cubes, LEDs in clothing — blinky bling was everywhere.

I looked at the WS2812B pixel strings in more detail and determined that they would be an ideal application to showcase how FPGAs could simplify driving LED strings. An FPGA could be used very effectively to generate all the low level string signals with great accuracy. Furthermore, I thought a small, inexpensive FPGA could drive a LOT of pixels and strings.

It was settled. For a project name I picked ezPixel.

Here are some initial, broad goals:

SPI interface to host microcontroller so that any Arduino, Raspberry Pi, Beagle Bone or other boards with an SPI interface could connect to it and control pixel strings easily.

Ability to read and write to/from the pixel RAM in the FPGA. This could be handy for host controller boards that have little RAM of their own to hold pixel color values.

USB serial port for easy development and as another potential way to control strings.

High string count.

High pixel count.

High pixel refresh rate.

Small size.

Low cost relative to other solutions when comparing number of strings and pixels.

Not too much to ask for…

Time to start the decision process for which FPGA to use. I have experience using inexpensive FPGAs from both Xilinx (Spartan6 family) and Intel (Cyclone family). I was also interested in looking at the newer MAX10 part family from Intel. MAX10 parts are becoming more generally available now and I was attracted to some of their features. Spartan7 and Cyclone10 look very intriguing, but neither family is readily available as I write this post.

A quick scan of the FPGA families I was familiar with showed the following:

Prices are from Digi-Key or Mouser for 100 piece quantity at the time of this writing.
RAMs reflect the number of individual 1024 x 8 memories in the part.
(*) means the BGA package is different from the smaller devices.

I looked at Intel CycloneIV devices but they were not price-competitive with the newer Spartan6 and MAX10 devices. Similarly, I did not include CycloneV in the list as they only come in larger BGA packages that would not be a good fit for this low-cost design. Spartan7 and Cyclone10 would be potential candidates but neither was available at the time of this writing.

I ruled out the Lattice parts because the different sized parts can’t fit on the same footprint – no migration up or down in part size is possible for these packages. They also can’t drive as many pixels comparatively due to their small amount of internal RAM resources.

Another thing to note is that Spartan6 devices require two voltage regulators plus a serial boot prom whereas the MAX10 devices need only one regulator and no boot prom. Therefore, the price difference is more than just the cost of the FPGA.

An interesting thing I noticed is that the Spartan6 parts cost a bit less for the EQFP144 package compared to the cost of the BGA packages. MAX10 parts were just the opposite in that BGA parts were less expensive than the EQFP144 versions.

Each pixel has three color emitting LEDs – Red, Green and Blue. Each color is 8-bits so a simple metric is that each color gets a separate RAM inside the FPGA. Therefore pixel colors will be stored in three RAMs. Some quick math in the table above derives the maximum possible number of pixels by dividing the number of RAMs by three, rounding down, and multiplying the result by 1024.

Before I can make a final decision on which part family to work with, some circuit prototyping is in order. I don’t yet know how much logic is required to talk to one string let alone many strings so I need to get an estimate…