Easing design migration between 32-bit MCU platforms

Over the past few years, there has been a lot of talk about standardization on a single core platform to simplify the migration of designs from one MCU vendor to another.

The interesting thing is, in all of this talk there is no mention of the peripherals. But peripherals are at the heart of what it really takes to port an application from one MCU vendor to another.

It’s all about the peripherals

When an engineer starts a new design, he will begin by looking at its functional requirements. What is the system supposed to do? How does the user interact with it? So on and so forth.

Based on this, he will determine the circuitry needed and the on-chip MCU peripherals that are required to control these circuits. For example, an industrial HMI (Human Machine Interface) device will need to support a LCD, buttons and/or a touch screen, communication to the machine, LEDs, a speaker/buzzer, etc.

All of these functions will require some kind of peripheral on the MCU, e.g., a CAN controller for communication, an ADC for a touch screen, a PWM timer for a buzzer, etc.

The more functionality a peripheral has, the less external circuitry is needed, which, in some cases, reduces the amount of code that needs to be written. For example, utilizing a special buzzer mode is easier than having to set up a PWM for the same purpose.

The core requirements are usually straightforward. While very important, the designer is quite abstracted from the core itself. The core really must meet two basic criteria.

Is it fast enough to perform all of the software tasks that are required to create the best user experience? And, does it perform all of these tasks efficiently? The type of core is irrelevant beyond this, as long as it meets these two performance requirements.

Of course, there is also a firmware/software side to the core. Legacy code is something the engineer has to consider. How much work can he save by using existing code? This question is not linked to the core directly, but rather to the peripherals, as most 32-bit MCU code is written in C and as such can be recompiled to any core.

Each MCU manufacturer will have peripheral features and programming models that are unique to its own products, regardless of the core that is being employed, which is what really makes the code hard to port.

Firmware libraries

To help the engineer, each MCU manufacturer supplies a firmware library that contains code to set up and use the various on-chip MCU peripherals. Because these peripherals are implemented in different ways by each manufacturer, and even have different features, porting an application from one MCU to another is not trivial.

ARM has been trying to ease porting efforts by defining a firmware abstraction layer standard called the Cortex Microcontroller Software Interface Standard (CMSIS), and the MCU manufacturers that use the Cortex-M series of cores have adopted it in their firmware libraries.

Unfortunately, this standard does not address the difficulty of porting peripherals, nor does it have a standard naming convention on variables or functions. As a result, there is no easy way to move from one firmware library to another without significant work.

In fact, this standard makes almost no improvement in the effort it takes to port an application among ARM MCU vendors. After all, there is no benefit to the MCU manufacturers in making it too easy to move to another vendor’s product.

Design for portability

Since the MCU manufacturer will not simplify portability to another vendor’s product, it is up to the design engineer to make the design portable. This can be achieved by implementing an abstraction layer that creates a standard programming interface between the hardware (i.e., MCU peripherals) and the application code. There are at least two ways to approach this:

1) Develop a shim layer or wrapper to translate between the MCU manufacturer’s peripheral library and your code. This is probably the most time-efficient solution, but it will add more code in the command and data paths.

2) Define a standard function and variable naming scheme, and apply it to each peripheral library. This avoids adding code, but can be very time consuming, depending on how complex your peripheral usage is.

Portability is not trivial and has to be part of the development process from day one. On top of the firmware/software side, there is the question of pin-to-pin compatibility, which almost always means re-layout of the PCB when moving from one MCU vendor to another. And, there might also be requirements for different external parts, such as capacitors and regulators.

Bottom line

Portability between 32-bit MCU vendors is equally difficult, regardless of the core being used. It is all about the peripherals and related firmware libraries. Each MCU manufacturer will do his best to make the design process as easy as possible by supplying firmware libraries and application notes.

They will also try to make their parts such that you can move between their own families with minimal effort. But portability to a competing solution is something they will not be interested in making too simple.

This is something the design engineer will have to own, and thus should evaluate the cost/benefits of doing so at the beginning of each project.

Information is shared by www.irvs.info

Architecting the smart grid for security

The smart grid is an important, emerging source of embedded systems with critical security requirements. One obvious concern is financial: for example, attackers could manipulate metering information and subvert control commands to redirect consumer power rebates to false accounts. However, smart grids imply the addition of remote connectivity, from millions of homes, to the back end systems that control power generation and distribution. The ability to impact power distribution has obvious safety ramifications, and the potential to impact a large population increases the attractiveness of the target.

These back end systems are protected by the same security technologies (firewalls, network access authentication, intrusion detection and protection systems) that today defend banks and governments against Internet-borne attacks. Successful intrusions into these systems are a daily occurrence. The smart grid, if not architected properly for security, may provide hostile nation states and cyber terrorists with an attack path from the comfort of their living rooms. Every embedded system on this path – from the smart appliance to the smart meter to the network concentrators – must be secure.

The good news is that utilities and their suppliers are still early in the development of security strategy and network architectures for smart grids; a golden opportunity now exists to build security in from the start.

Sophisticated attackers

The increasing reliance of embedded systems in commerce, critical infrastructure, and life-critical function makes them attractive to attackers. Embedded industrial control systems managing nuclear reactors, oil refineries, and other critical infrastructure present opportunity for widespread damage. To get an idea of the kinds of sophisticated attacks we can expect on the smart grid, look no further than the recent Stuxnet attack on nuclear power infrastructure.

Stuxnet infiltrated Siemens process control systems at nuclear power plants by first subverting the Microsoft Windows workstations operators use to configure and monitor the embedded control electronics (Figure 1). The Stuxnet worm is likely the first malware to directly target embedded process control systems and illustrates the incredible damage potential in modern smart grid security attacks.



Figure 1 - Stuxnet infiltration of critical power control system via operator PC

information is shared by www.irvs.info

Facilitating at-speed test at RTL

Production testing for complex chips usually involves multiple test methods. Scan-based automatic test pattern generation (ATPG) for the stuck-at defect model has been the standard for many years, but experience as well as a number of theoretical analyses have shown that the stuck-at fault model is incomplete. Many devices pass high coverage stuck-at tests and still fail to operate in system mode.

Analysis of the defective chips often reveals that speed or timing problems are the culprits. At 90nm and smaller processes, the percentage of timing related defects is so high that static testing is no longer considered sufficient. Functional tests have been used to check (cheque for banks) for at-speed operation. But generating functional at-speed test patterns is difficult and running this volume of tests on the automatic test equipment (ATE) is expensive. As an alternative, scan test has been adapted to detect timing-related defects. Like standard stuck-at scan tests, high coverage at-speed scan test vectors can be automatically generated by ATPG tools. Manufacturing testing of deep subµm designs now routinely includes "at-speed" tests along with stuck-at tests.

Little has been done so far to make front end designers aware of at-speed test solutions at the register transfer language (RTL) level of abstraction. This document is intended to present basic concepts and issues for at-speed testing, as well as demonstrate the at-speed coverage estimation and diagnosis capability built-in to the SpyGlass-DFT DSM product for RTL designers and test engineers.

Information is shared by www.irvs.info

Mobile WiMAX system operation

This chapter provides a detailed description of the operation of IEEE 802.16m entities (i.e., mobile station, base station, femto base station, and relay station) through use of state diagrams and call flows. An attempt has been made to characterize the behavior of IEEE 802.16m systems in various operating conditions such as system entry/re-entry, cell selection/reselection, intra/inter-radio access network handover, power management, and inactivity intervals.

This chapter describes how the IEEE 802.16m system entities operate and what procedures or protocols are involved, without going through the implementation details of each function or protocol. The detailed algorithmic description of each function and protocol will be provided in following chapters. Several scattered call flows and state diagrams were used in reference [1] to demonstrate the behavior of the legacy mobile and base stations, making it difficult to coherently understand the system behavior.

The IEEE 802.16 standards have not generally been developed with a system-minded view; rather, they specify components and building blocks that can be integrated to build a working and performing system. An example is the mobile WiMAX profiles where a specific set of IEEE 802.16-2009 standard features (one out of many possible configurations) were selected to form a mobile broadband wireless access system.

Detailed IEEE 802.16m entities' state transition diagrams comprising states, constituent functions, and protocols within each state, and inter-state transition paths conditioned to certain events would help the understanding and implementation of the standards specification [2–5]. It further helps to understand the behavior of the system without struggling with the distracting details of each constituent function.

State diagrams are used to describe the behavior of a system. They can describe possible states of a system and transitions between them as certain events occur. The system described by a state diagram must be composed of a finite number of states. However, in some cases, the state diagram may represent a reasonable abstraction of the system.

There are many forms of state diagrams which differ slightly and have different semantics. State diagrams can be used to graphically represent finite state machines (i.e., a model of behavior composed of a finite number of states, transitions between those states, and actions). A state is defined as a finite set of procedures or functions that are executed in a unique order. In the state diagram, each state may have some inputs and outputs, where deterministic transitions to other states or the same state happen based on certain conditions.

In this chapter, the notion of mode is used to describe a sub-state or a collection of procedures/protocols that are associated with a certain state. The unique definition of states and their corresponding modes and protocols, and internal and external transitions, is imperative to the unambiguous behavior of the system. Also, it is important to show the reaction of the system to an unsuccessful execution of a certain procedure. The state diagrams described in the succeeding sections are used to characterize the behavior of IEEE 802.16m system entities.

This chapter provides a top-down systematic description of IEEE 802.16m entities' state transition models and corresponding procedures, starting at the most general level and working toward the details or specifics of the protocols and transition paths. An overview of 3GPP LTE/LTE-Advanced states and user equipment state transitions is further provided to enable readers to contrast the corresponding terminal and base station behaviors, protocols, and functionalities. Such contrast is crucial in the design of inter-system interworking functions.

information is shared by www.irvs.info