ASM vs. MCU for IoT, portable & wearable applications
I must admit that I was quite excited when I heard about Silego's latest family of GPAK devices around the beginning of this year (see New GPAK5 Tiny Mixed-Signal FPGA Features ASM & I2C). I've long been interested in the concept of asynchronous (un-clocked) logic, so one of the more interesting aspects of this device to me was the inclusion of a no-code asynchronous state machine (ASM).
The folks at Silego say that the GPAK5's ASM can off-load (sometimes replace) the system's MCU. However, it can be difficult to compare and contrast the two approaches, so I emailed the folks at Silego asking them for more details, and the guys and gals in Silego's application team just responded as follows:
When designing portable battery-powered systems, size and battery life constraints are often the most severe challenges to overcome. One traditional way to pack a lot of functionality into a small size and power budget is to use a low-power microcontroller such as TI's popular MSP430. These types of ultra-low power microcontrollers offer high levels of flexibility and are available in small packages, allowing a system to run for days, months, even years on a single battery cell.
At Silego Technology, we've taken a different approach to attack this issue by adding a user-programmable Asynchronous State Machine (ASM) macrocell to our fifth generation GreenPAK (GPAK5) product family. The following discussions include comparisons, design tradeoffs, and tips that users may consider when choosing between a variety of microcontroller options or performing the same tasks using the ASM inside the GPAK5.
How much equivalent MCU code can a GPAK5 handle?
The GPAK5's ASM supports eight states and 24 possible decisions. The following example may help users to quickly grasp the overall ASM concept:
- STATE(X): If Signal One is high, then go to STATE(A). This is a decision statement to determine the next state; each state is allowed to be the resultant state only three times.
State A is a configuration that causes an output to blink an LED. This is the actual result. In order to move to the next state (result), another decision must be made.
-- If Signal Two is high, then go to STATE(B).
-- If Signal Three is high, then go to STATE(D).
-- If Signal Four is high, then go to STATE(F).
- STATE(B) might cause an LED to blink faster.
- STATE(D) might wait 500 ms before moving on to another STATE.
- STATE(F) might check the POR or a Power Good signal.
So, one way to think about this is that the ASM in a GPAK5 represents an MCU program with up to 24 IF...THEN statements. When the 8-State ASM capabilities are considered together with hardware input and output circuits, the GPAK5 may be represented as being roughly equivalent to about 100 lines of standard C code written for common 8- and 16-bit MCUs.
As the name implies, ASMs have no clock. Silego's GPAK5 ASM is event-driven and does not operate with a clock. As such, when there are no events the ASM stays in one state where it consumes virtually no power. As a result, applications with limited input cycles can operate at leakage current power consumption levels well into the single digit nanoamps at room temperature. Applications such as resets, power sequencing, various sensor interfaces, and long-term data logging may all benefit from a real ASM.
What types of embedded control problems are addressed by the GPAK5's ASM?
Typical embedded control problems usually involve a system that is transitioning through a set of discrete states based on asynchronous external inputs. Thus, ASMs are the natural problem solver for many embedded control problems. Unfortunately, most designers have typically opted for traditional MCUs, thereby resulting in ASMs being pushed to the edges of engineering. However, due to the inherent power and speed advantages offered by ASMs, the on-going low-power portable-consumer-wearable-IoT revolution has renewed interest in these implementations. This is why Silego has revived and modernized the ASM, mitigating the well-known hazard/race conditions and programming/configuration headaches, while retaining all the inherent low-power, low-latency benefits for simple (up to eight states) embedded control problems that would require less than 100 lines of code.
The types of embedded control problems that can be solved by the GPAK5 ASM are limited only by the following:
- The number of inputs: 18
- The combinatorial logic blocks processing the 18 inputs: 17
- The number of total states: 8
- The number of decisions: 24
- Resolving basic true / false decisions from combinatorial logic
-- Is the voltage higher or lower than X volts?
-- Is Signal A XOR Signal B = 0 or 1?
-- Has timer Z finished?
- Four analog comparators
- 1.8 to 5.5V VDD
- ~25 MHz digital signals
An easy-to-understand example of how the GPAK5 ASM can be used is provided by an intelligent flashlight. This flashlight might have an OFF state, a High-Brightness state, a Low-Brightness battery-saving State, a flashing state, and a Battery Status state. The GPAK5's ASM can easily be set up to cycle between these states using multiple buttons and/or sequences of button pushes. The output drive MOSFET can be controlled by the GPAK5 to achieve high steady current through the White LED or lower current or flashing current depending on the configuration of the combinatorial logic as activated by the ASM's eight output bits.
Input/Output (I/O) port expansion is another easy-to-understand application example where a GPAK5 can be found useful. The GPAK5 comes with an I2C port that can be used to directly drive outputs, the ASM, or combinatorial logic. This means the I2C could write directly to a pin; however, the ASM can also be configured such that a bit from the I2C bus can move an ASM state, which -- in turn -- outputs a parallel 8-bit pattern. Each state can have its own parallel 8-bit output. Even a single pin periodically transitioning between high and low can be used to move the ASM between states, thereby allowing up to eight pins to have state-dependent pre-configured outputs.
Overkill MCUs vs. GPAK5's ASM value
An MCU contains a processor, program code, stack memory, and various peripherals. Such a device can easily perform the application examples described above, but it will be inefficient in terms of size and power. In is quite common to find MCUs designed into applications where less than 1% of the MCU horsepower will ever be used.
The GPAK5's ASM is well-suited to simple embedded control applications, especially ultra-lower power applications. In fact, most MCUs are computational-power and cost overkill for these simple embedded control applications, thereby making the low-cost GPAK5 ASM, a no code, no static power, ultra-small, easy-to-use obvious option.
Interrupt Latency: ns vs, µs
When implementing a state machine design on a MCU, this is achieved in software running on the microcontroller core. In this case, the states are implemented as points in the software instruction execution, while state transitions are implemented with conditional software branching. MCU's also have the ability to process asynchronous inputs; they do this via dedicated interrupt controller hardware and through interrupt service routines (ISRs). The ISR is software that is run after a hardware interrupt has been activated.
An important benchmark for a MCU is how short is the so-called interrupt latency -- that is, the time from the arrival of an external interrupt signal until the core is executing the first instruction of the ISR. MCU interrupt latency includes a variety of tasks that must be performed before the MCU can execute this first instruction. These tasks include latching the external signal, finishing execution on the instruction currently in progress, and saving the current state (pushing registers) to facilitate a return to exactly the same state following the ISR. Depending on the particular MCU in question, the latency can be as small as 10 to 20 cycles. Multiplying these cycles by the clock speed yields the interrupt latency. There is also an impact from running a high level language (such as C), as this usually increases the number of cycles for the interrupt latency. Similarly, if the user is running an operating system, this can also add extra cycles to the interrupt latency. The end result is that MCU interrupt latency in general-purpose devices is usually measured in fast examples at around 5 to 10µs.
By comparison, the GPAK5's ASM equivalent of interrupt latency is equivalent to the un-clocked time-of-flight through the few gates between an external pin and the internal ASM input, and is therefore measured in nanoseconds. Of course the ASM does have latency from one state to the next. If the GPAK5 is operating with a 5V power supply, the maximum latency is only 50ns, so in addition to being extremely low power, ASMs are also extremely fast.
There is a tradeoff that MCU users must make if power and fast interrupt response are both required in the system. The faster the clock speed is set, the lower the interrupt latency will be, but a faster clock speed will also drive up the power consumption. Some microcontrollers allow the system clock speed to change over time; it can be set low when the system is waiting on an asynchronous input and increased when the interrupt is requested. This can be an advantageous technique to save power and decrease interrupt latency, but there is a limit to how useful this is as there is also latency involved in changing the clock speed. No such tradeoff is necessary with an ASM.
MCUs, on the other hand, are clocked with signals that are not correlated well with VDD. As the VDD changes, the MCU propagation delays change and since the timing doesn't change, the timing margins are soon compromised. Chip designers react to these design hazards by putting the MCU under a voltage regulator or requiring still more performance to be lost by slowing the clock speed. However, the voltage regulator consumes power, while the slower clock speed increases interrupt latency.
Crash vs no crash
There are design and system flaws that can cause an MCU to crash. Poor software design, timing issues, miscalculations of interrupt latency, running out of stack memory, memory leakages, and accidental writes to program memory are some common pitfalls that may cause an MCU to crash.
The GPAK5’s ASM is configured in hardware with NVM bits, has no timing issues, latency measured in nanoseconds, no stack memory, no ability for memory leakage, and no ability to unintentionally overwrite program memory, and is therefore inherently more robust with regard to VDD noise and brownouts.For all these reasons, it is common to Silego's GPAK ICs and GPAK5's ASMs being deployed as crash monitors for large MCUs, SoCs, and ASICs. GPAKs may also be used to operate failure mode notifications, control error LEDs, and handle other functions that must remain operational while the main processor is malfunctioning.
No-code GUI-based tools vs. typical MCU tools
The GPAK5's ASM is configured using the GreenPAK Designer development environment. This GUI is presented in the form of a schematic editor as opposed to a software coding tool. Using this graphical interface, the typical multi-month learning curve required to gain expertise with a MCU tool can be reduced to few days for GreenPAK Designer, and the majority of state machine designs can be implemented in a matter of minutes.
In the case of an ASM design, GreenPAK Designer provides a special bubble state diagram tool that allows the designer to select and name the various states in the system, and point-and-click to add state transition arrows in the same manner that an engineer would draw a state diagram on a whiteboard.
After configuring the state machine, the designer returns to the schematic capture editor to graphically connect hardware signals to each of the state transition decision points. It is common for a design engineer to be able to complete their first prototype in just one day.
GPAK5 size vs. low-power MCUs
Even when compared to low-pin count, ultra-low power MCUs, the 1.8 to 5V tolerant GPAK5 is usually smaller because it doesn’t have to support all of the complexity of an MCU architecture. If a GPAK5 is able to perform the required control function, then -- in its 2 x 3 mm 20-pin STQFN package -- it is usually the smallest programmable option on the market. For applications that require even less control, previous GPAK family members are offered in 12-pin STQFN packages as small as 1.6 x 1.6 mm.
In summary, the tiny GPAK5 with its 8-state ASM can take on a variety of embedded control applications that would formerly have been the exclusive domain of MCUs. The easily-configured ASM brings key advantages of ultra-fast state transitions, ultra-low power consumption, and reliable and robust design, all combined with the supply voltage tolerance that is so important in IoT, portable, mobile, and wearable applications.