State Machine ‘v’ Micro in a FPGA

Paul J ClarkeApril 23, 2012

Designing a system and considering if to have a FPGA in the first place is something a engineer should always consider. However one thing that people look to do is designing a microcontroller on a FPGA and in this post I want to consider why we would do it at all and what would be the real consideration for doing this.


We first look at what's available in the microcontroller world. We have a vast range from tiny 8bit 6 pin devices right the way up to monster 32bit devices. These come with all sorts of features like I2C, SPI, UARTS, DMA, ADC’s, DAC’s and much much more. You could consider that there is little you can’t do with a microcontroller and never need a FPGA at all. These devices are low cost and have tons of support for them. So what's wrong with them? Well one argument is speed and flexibility. A microcontroller is fixed hardware that can’t be changed. You need to code your micro which means it takes clock cycles to do anything, and lots of them. You're also limited by the paths of data within a device. For certain you can flow data via DMAs but these need setting up first.

FPGAs however offer a open platform to design whatever you like. Designed correctly they will process data at very high speed, pipelining though the device. First FPGA I saw was processing gigbit ethernet packets at silly speeds, able to fill the gigabit connection with data when other devices on the market at the time could only get to 80%.

Because of the parallel feel to a FPGA and the logic can run lots of different blocks at the same time. Against a micro with the same clock speed you can see that they will outrun them for certain. However there are limits and FPGA are not all speed demons and they are not cheap either.

One of these limits comes with state machines. These are the little worker engines in FPGA when it comes to doing tasks. For example if your interfacing to a I2C interface and want all the features then a nice small state machine will look after the interface and keep it all running happy. State machines are great however there are limits with these also. Getting them to talk to each other can be tricky without some handshaking to keep stuff in sync. This will use up clock cycles and make them less efficient. Having said this, only this last week I have seen a post on improving this issue.

The size of a state machine is also an issue. The bigger and bigger it gets the more risk there is of it all falling apart on you. So if a CPU is nothing more than a state machine, why not use one of them?

Well this is where soft (and even hard) cores come in. These are CPU cores that can be build on your FPGA. There are small ones and big ones just like microcontrollers so what's the real attraction? Well its the openness of it all.

For some a small 8 bit soft core will just go that little extra mile than a state machine and run tasks. For the larger ones then we start talking about SoC (System on a Chip). These 32 bit monsters core just like the small ones come without fancy I2C interfaces for example. These can be added however either through your own code or via the suppliers IP library. These offer the fact you can decide what hardware interfaces will be on your board and how they then connect out or interface. They really do allow you to design your own system... but!

The but is that these big SoC are not easy and come with a cost. Lots of logic gate costs real hard cash and more than an off the peg microcontroller in some cases. Most are licensed to the manufacture of the device so an extra cost is there too. It all sounds far too much for me and this is my issue.

Personally I feel that people will all to quickly move to large cores either external or internal without thinking what they need. So when considering your design, consider if more state machines will be better, or use a small soft core micro. Or even consider using a separate microcontroller with a FPGA bolted to the side of it. As a engineer the decision is yours to make the right one for your project.

To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.

Please login (on the right) if you already have an account on this platform.

Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: