“Transformers” in the embedded world

By Viren Ranjan, Applications Engineer, Cypress Semiconductor Corporation

Executive Summary
The market has recently experienced an explosion in the number of embedded devices pervading everyday life, from iPods and PDAs that people carry to wireless presentation tools and digital organizers that help one organize oneself better to wireless sensor networks deployed for environment monitoring. As the world continues to go embedded, devices continue to grow smaller in size with an increasing number of battery-powered embedded devices also entering the market. Manufacturers are constantly driven to find new ways of decreasing the component count on an embedded device in order to reduce its size, reduce power budget to increase battery life and to reduce cost of manufacturer to be competitive in a crowded market. These requirements of embedded systems have forced semiconductor manufacturers to develop new technologies and tools to achieve these objectives. Following Moore’s law, the density of transistors in an integrated circuit has been increasing exponentially, reducing the form factor of ICs and thereby driving costs lower. Semiconductors are also exhibiting new operational modes with reduced power requirements thereby reducing average power consumption and increased battery life. Technology and tool advancements have enabled increased number of PCB layers possible in products, again reducing form factor. Technology continues to mature resulting in the increased abundance of embedded devices around us.

Dynamic Reconfiguration
A more recent technological development that further aids in the achievement of these objectives of embedded devices is “Dynamic Reconfiguration”. In the software domain, Dynamic Reconfiguration is commonly used to refer to software mechanisms that logically attach and detach system resources from an operating environment without incurring downtime. In Wireless Sensor Networks (WSNs), Dynamic Reconfiguration is the ability of deployed nodes to organize and reorganize themselves when some nodes are lost, to achieve 2 objectives; retrieve information from the environment and transmit this information to a base station. In the embedded world, dynamic reconfiguration refers to the ability of a programmable System-On-Chip (SOC) to change its functionality at run-time, performing seemingly different functions at different instances in time. This ability to reconfigure hardware in real-time allows available resources to be shared between multiple functions and configurations. Reconfigurable hardware morphs to become new hardware in different applications. Since hardware can be re-allocatable, its usage can be greater than100%. To understand this concept better, let us revisit some basics of a Systems-On-Chip based design approach.

System-on-Chip
A System-On-Chip (SOC) refers to the integration of electronic peripheral components onto a single integrated circuit. SOCs place multiple function systems on a single silicon chip to cut development cycle time while increasing product functionality. Reconfigured functions could be digital, analog, mixed-signal, and radio-frequency functions. A typical SOC consists of the following components: • • • A microcontroller/ microprocessor as its core processor Memory blocks Digital and analog peripheral components like timers, counters, ADCs, and DACs
Page 1 of 6 September 2008

“Transformers” in the embedded world Published in Embedded.com (http://www.embedded.com)

[+] Feedback

• • • •

Timing sources like oscillators External communication interfaces like USB and SPI Voltage Regulator Power Management Unit

The SOC consists of all the above functions on a single chip and provides the user software control of these resources. The user has the flexibility to use the available resources and make changes to a hardware design, in software, during run-time. Figure 1 shows the block diagram of a typical microcontroller-based System-On-Chip.

Figure 1: A typical microcontroller-based System-on-Chip

However, when an application does not need to use all the available resources, a general purpose System-on-Chip could prove to be over-kill for many applications and therefore more expensive than necessary. For example, an embedded design might use the SPI interface on the SOC, but have no use for the Ethernet, USB, or CAN communication interfaces available. This results in less than 100% utilization of a chip’s resources, resulting in increased costs for that embedded design.

“Transformers” in the embedded world Published in Embedded.com (http://www.embedded.com)

Page 2 of 6 September 2008

[+] Feedback

A new approach to the System-on-Chip design is the use of Programmable Systems-on-Chip. A Programmable System-onChip also consists of a microcontroller as its core processor. More specialized functionality is implemented using universal analog and digital blocks that can be configured to perform the functions of the peripheral components shown above. The number of digital and analog blocks used for the emulation of a particular component varies, based on the component. Configuration of these components is done in software by writing to the relevant registers. Thus, a given application could configure the available blocks/resources to emulate only those functions that are required in its design. Given that hardware components can be configured by writing to registers in software, it is it also possible to reuse these universal blocks to perform the functions of other peripherals by rewriting the registers during run-time; i.e., Dynamic Reconfiguration. In order to understand this concept, let us look at an example application. Consider the design of a taximeter for a cab. The primary function of this device is to monitor distance traveled by the cab and reporting the fare accordingly. Other features that could be a part of this device are: • • • • • • • Interfacing to a thermistor to monitor ambient temperature and display the same Manage buttons to provide a user interface to functions such as changing displays, switching modes, turning on a backlight for the LCD, etc. Interfacing to a GPS receiver to obtain positional data Interfacing to a Real-Time-Clock to keep track and display time of day. Interfacing to a seat pressure sensor to sense the presence of a passenger Radio transmitter to transmit trip details to a base station Radio receiver to receive acknowledgements and other information from the base station.

A high level block diagram for such an application is shown in Figure 2.

Figure 2: Block diagram of a typical taximeter

“Transformers” in the embedded world Published in Embedded.com (http://www.embedded.com)

Page 3 of 6 September 2008

[+] Feedback

Apart from the core microcontroller which does all the processing, the taximeter consists of a number of different blocks performing different functions. Each of these functional blocks uses varying numbers of peripheral components like ADCs, filters, amplifiers, and timers. These functional blocks can be categorized as follows: • • • • • • • • • • • • • • GPS receiver LCD controller and LCD panel Flash/ EEPROM interface and memory block RTC Power Management Unit (PMU) Tachometer interface Thermistor interface Capacitive sensing buttons and interface Pressure Transducer interface System Timers Speaker interface LED interface Transmitter Receiver

If a traditional design approach was undertaken for this product, circuitry would be required for each function and the real estate space on the board required, and its corresponding cost, would be fairly high. However, we can take advantage of the fact that not all these functional blocks are operational simultaneously. This design can be divided into the following independent configurations. I. Common Configuration This configuration is enabled all the time. This would include the GPS receiver and its communication interface, the LCD controller, RTC, PMU and the Memory interface Passenger Present configuration This configuration is loaded only when a passenger is in the cab. Otherwise, it can remain unloaded or asleep. This configuration would include the Tachometer interface, Pressure Transducer interface, System Timers, and LED interface. Housekeeping configuration This configuration takes care of housekeeping chores like temperature sensing. thermistor interface. Transmission configuration This configuration is responsible for transmission of data and will include the transmitter. Reception configuration This configuration is responsible for reception of information from the base station and will include the receiver. This would include the

II.

III.

IV. V.

The Common configuration will always be loaded since that information would need to be kept track of at all times. However, the other configurations can be loaded only when required as follows: The taximeter could keep track of whether a passenger is in the cab or not by monitoring the pressure transducer. If a commuter is present, it would load the Passenger Present configuration to compute trip details. • The Housekeeping configuration could be timer driven, and loaded either when the processor is not busy handling some other function or at regular intervals of time. • Since transmission and reception do not take place simultaneously, the same hardware can be reused for both tasks. The system can take advantage of this fact by loading the Transmission configuration when it needs to transmit data. As soon as the transmission is done, the system would unload the transmitter configuration and load the receiver configuration to receive information from the base station. Each of these configurations utilizes a given number of hardware resources. Using Dynamic reconfiguration, configurations can be loaded and unloaded as and when required. Multiple configurations can be loaded simultaneously, as long as the combined resources required do not exceed the total resources available. Every time a configuration is changed, the same universal digital and analog blocks will be reconfigured to perform the function of a different peripheral device. Software
“Transformers” in the embedded world Published in Embedded.com (http://www.embedded.com) Page 4 of 6 September 2008

[+] Feedback

exercises control over the hardware resource usage. This enables the entire functional block diagram shown above to be “integrated” into a single Programmable System-on-Chip. Since the available hardware resources are reused based on dynamic operational requirements, Dynamic Reconfiguration allows the device to use more than 100% of the available resources.

Advantages of using Dynamic Reconfiguration
Apart from the advantages of reduced cost due to reduction in BOM cost and board real estate space, dynamic reconfiguration functionality also provides other advantages, including: • Allowing last minute changes in a hardware design through software changes • Improved power management as only those peripherals required at a given instance are active • Facilitating the addition of new product features easily An important element to adopting dynamic reconfigurability in an embedded design is the ease of implementation. For example, “PSoC Designer” from Cypress Semiconductor is an IDE which enables each configuration to be set up in an independent configuration window. Switching between configurations during run-time is matter of an API call, which is also generated automatically when the project is generated. In this way, the available hardware can be used in multiple configurations. Development tools must also support debug and trace options to ensure proper operation of each configuration. The time taken to switch between configurations depends on the number of registers to be written into. For Cypress’ PSoC, dynamic reconfiguration can be as fast as 40 microseconds for a processor running at 24 MHz with all of the available resources in the largest PSoC part to be reconfigured. The time is also sufficient for analog components like ADCs to settle and be usable. Dynamic Reconfiguration gives an embedded device the unique ability to “transform” itself to perform seemingly different functions at different instances of time. Dynamic Reconfiguration, along with its related developmental tools provides another valuable weapon in the arsenal of an embedded designer to producing smaller, better, more energy efficient embedded products.

“Transformers” in the embedded world Published in Embedded.com (http://www.embedded.com)

Page 5 of 6 September 2008

[+] Feedback

Cypress Semiconductor 198 Champion Court San Jose, CA 95134-1709 Phone: 408-943-2600 Fax: 408-943-4730 http://www.cypress.com
© Cypress Semiconductor Corporation, 2007. The information contained herein is subject to change without notice. Cypress Semiconductor Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. PSoC Designer™, Programmable System-on-Chip™, and PSoC Express™ are trademarks and PSoC® is a registered trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are property of the respective corporations. This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source Code except as specified above is prohibited without the express written permission of Cypress. Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. Use may be limited by and subject to the applicable Cypress software license agreement.

“Transformers” in the embedded world Published in Embedded.com (http://www.embedded.com)

Page 6 of 6 September 2008

[+] Feedback

Sign up to vote on this title
UsefulNot useful