Sachin Gupta, Cypress Semiconductor
Electronic Design
Using run-time reconfigurable analog and digital logic can enable greater than 100% utilization of available hardware resources, resulting in a smaller footprint and lower system cost
When facing the challenge of having to design systems that do more, are smaller, and have higher power efficiency, the ability to achieve more than 100% with available resources through dynamic reconfiguration becomes compelling. Consider a vending machine that needs to accept money and dispense items as its primary function with an occasional need to communicate to a host CPU. Using dynamic reconfiguration, the same set of digital resources that are configured as the timer/counter at the time of vending can be configured as a UART block and pulse-width modulators (PWMs) for baud rate generation while talking to the host.
Dynamic reconfiguration can be realized in nearly every application that performs different tasks at different times. Since a walkie-talkie transmits data only in one direction, dynamic reconfiguration enables the design of a smaller device. A handheld ticket-dispensing machine could use the logic that operates the thermal printer to serve as the battery-charging circuit. Similarly, an LED-based lantern charges the battery when power is available and uses those resources to control the white LEDs when wall power is not available. Effectively, battery charging is time-multiplexed with other system functionalities. The result is that a system can fit within a smaller footprint than if separate logic is required for each function.
Dynamic Reconfiguration
Dynamic reconfiguration is a well-known capability of digital architectures like FPGAs. It is achieved by having a new configuration stored in non-volatile memory and later read written to the appropriate configuration registers. Each of the various configurations is stored in non-volatile memory/flash at the time of device programming.
Programmability is no longer limited solely to the digital domain. Today, analog resources can be dynamically reconfigured and not just to change the specifications of a particular peripheral. Using dynamic reconfiguration, the same analog resource can serve as an analog-to-digital converter (ADC), amplifier, or capacitive touch sensor at runtime based on the application requirements.
To understand how analog resources can be dynamically reconfigured, consider a continuous time programmable analog block (Fig. 1). At first look, this circuit appears quite complicated. In fact, it is a relatively simple circuit that provides the ability to connect various signals at any given input/output to realize different circuits.
 |
|
| Figure 1. | The analog resources can be dynamically reconfigured into a continuous time programmable analog block. |
For example, this same block can be configured as an inverting or non-inverting amplifier based on the connections. A hysteresis-enabled comparator with the required gain/hysteresis can be achieved by selecting the appropriate resistor value within the resistor matrix. The required reference can be selected using a reference multiplexer. The output of the block can also be routed to some other block or an output pin.
All of these connections and resistor values are configured using configuration registers that can be written at run-time. Thus, a block can act like an attenuator, buffer, inverting or non-inverting amplifier, and even an instrumentation amplifier if combined with additional blocks. System designers can change the functionality of the block using firmware by writing new values to the configuration registers.
A switched capacitor block can emulate a capacitor as a resistor using a switched capacitor technique where the resistance (R) is implemented by controlling the flow of charge:
By controlling the switching frequency (fS), the capacitor values (C), and the way these capacitors are connected around the op amp, a variety of circuits can be implemented without requiring any additional hardware (Fig. 2). The same switched capacitor can also be used to implement a delta-sigma modulator, integrator, filter, or touch sensing block.
 |
|
| Figure 2. |
Switched capacitor analog blocks are made up of a set of switched capacitors |
Each capacitor has an associated configuration register that can be used to change the capacitor’s value. The switching frequency can be controlled using hardware dividers or a PWM that is implemented in a programmable digital block. Switches are available that can be controlled using registers to keep some capacitors in the circuit all the time or to remove them instead of keeping them in switched capacitor mode. For instance, an integrator needs a capacitor in the feedback path and does not require any switching. The analog blocks can implement a range of devices including an inverting amplifier, an integrator, or a differentiator.
Similar to the analog resources, digital blocks also can support various functions by writing the required configuration value to the configuration registers for the given digital block. Programmable input/output connections enable any pin to be connected to any peripheral with the processor so the same hardware block can be connected to different pins at different times. For example, a digital block being used as a PWM to drive an LED can be used as a UART transmitter at a different time using different output pins.
Feasibility Of Dynamic Reconfiguration
Depending upon the architecture of the programmable device, dynamic reconfiguration may be possible for many applications. However, the complexity of implementing dynamic reconfiguration may too costly if every register needs to be understood by the developer and its value set manually. To make dynamic reconfiguration practical, the development tools must provide an efficient way to set these values with minimal effort as well as provide a basic reconfiguration infrastructure for run-time implementation. Two features are essential:
- Automatic generation of configuration register values: Development tools must provide an easy way to define and manage multiple configurations. Defining a configuration refers to the selection of the peripherals to use and their internal interconnection. Based on the configuration definition, the tool must generate the required register values for each block used in that configuration (Fig. 3). As can be seen from this code, when the development tools can generate the required register values, this frees the development from manually generating these values. This also enables developers to make frequent changes to configurations without any penalty.
- Ease of switching configurations: If the developer has to manage switching between configurations, this will impose significant overhead as the developer creates code to read values from flash and write to the required registers, especially when frequent changes are made to configurations at the time of development. A single mistake can lead to a system malfunction that could be difficult to detect and locate. Therefore, development tools must abstract the low-level register write details and must provide a high-level application programming interface (API) to perform this task.
 |
|
| Figure 3. | The PSoC Designer IDE generates code for configuration registers based on a user’s design. |
Further complicating switching configurations is the need to “unload” the values that have been written since the previous configuration was loaded. Unloading may not be required in every situation but will be required in most of them. For example, consider an application with a base configuration and two loadable configurations.
The base configuration includes the resources that are required all the time and do not need to be loaded and unloaded at any point. This configuration is loaded before entering the main application code. In this example application, the base configuration needs to have a UART that talks to the host CPU. The first loadable configuration needs one ADC. The other configuration needs one PWM and a touch sensor.
Assume the UART needs two programmable digital resources and the PWM needs one while the ADC and touch sensor use the same number of resources. The processor handles switching between configurations (Fig. 4). Of course, the development tools must provide a way to load and unload these configurations easily without the need to understand low-level registers and where configuration values are stored in flash memory.
 |
|
| Figure 4. | It is possible to dynamically switch configuration while the system is running. |
Implementing Dynamic Reconfiguration
To implement dynamic reconfiguration in an application, the various hardware configurations allocating the digital and analog blocks need to be defined. This can be completed using an intuitive graphical user interface (GUI) to simplify the process. Developers can then dynamically switch between these configurations by calling an API within the application. The API calls code that will then set the required register values based on the peripherals and the settings that have been selected for the particular configuration.
To show how dynamic reconfiguration is implemented in applications, let’s look at a real-world system. A programmable system-on-chip (PSoC) from Cypress consists of various system resources, CPU core, digital subsystem, analog subsystem, and programmable interconnects. The digital subsystem comprises various programmable digital blocks that can each be configured independently for different functions. Similarly, the analog subsystem consists of various programmable analog blocks that can be similarly configured. These subsystems are shown graphically as independent blocks in the development tool (Fig. 5).
 |
|
| Figure 5. | The PSoC Designer Chip Editor view shows the connections to the digital and analog resources. |
To configure a programmable hardware block, developers drag a peripheral over and drop it on an empty block. It can then be connected to other peripherals or a pin. The development tool generates the required register values that are to be stored in flash at programming time. At power up or reset, before the device begins to execute the main application code, the device loads the initial configuration into the registers from flash.
Developers can define a new configuration by right clicking and then selecting a new loadable configuration in the workspace. For each configuration, developers can select different peripherals and connect them as required. Once all of the configurations are defined, the tool generates the required register values along with assembly code to move these values to their corresponding register as shown in Figure 4. Developers can also load configurations dynamically from the main application using a single line of code: “LoadConfig_[config_name]”.
One factor that may require attention from developers is the switching time between configurations. Although unloading and loading a configuration is primarily register writes, this process will take time directly proportional to the number of registers that need to be written for a particular configuration. The approximate switching time can be calculated based on the resources used, and the application can adjust for the latency as required.
Dynamic reconfiguration is a powerful feature that can be used in nearly every application where different peripherals can be used in a time-multiplexed manner to reduce system cost and footprint. By changing the functionality of programmable hardware resources at runtime to perform different tasks, system designers can achieve more that just 100% utilization of available hardware resources.
