Spread-spectrum clocking reduces EMI in embedded systems

For years now, government institutions have been regulating the amount of EMI (electromagnetic interference) an electronic device or system can emit. Their efforts primarily target lowering dissipated power and eliminating any interference to the function of other surrounding devices as a result of EMI. Spread-spectrum clocking is a popular implementation for reducing EMI in synchronous systems.

Spread-spectrum-clocking benefits

EMI is the energy resulting from a periodic source in which most of the energy becomes a single fundamental frequency. The influence of these unwanted signals can manifest itself in the limited operation of other devices and systems. In some cases, the EMI-generated disturbance can make it impossible for these devices or systems to operate. Because an electromagnetic signal must have a source, synchronous systems are ideal candidates for generating excessive EMI. Within a system, the coupling paths in PCBs (printed-circuit boards) transmit the generated EMI that affects other system components. However, EMI can occur even in the absence of a conductive medium, such as an electric conductor or dielectric. In most cases, EMI results from a combination of conduction and radiation.

The primary PCIe (PCI Express) model implements a synchronous-clocking scheme. That is, the same 100-MHz clock source generates the reference clock for PCIe devices. Furthermore, in the case of a motherboard, the traces on the PCB can act as coupling paths to facilitate the transmission of EMI to the surrounding devices. The disturbance that occurs can affect not only the system but also other surrounding systems when EMI travels through the atmosphere in the form of radiation.

One method of minimizing the EMI that a device generates is to keep the disturbing signals below a certain level. You accomplish this goal by modulating the disturbing signals across a wider frequency range, thus spreading the energy across a range of frequencies rather than concentrating it at one frequency. In PCIe systems, the modulation of the reference clock is spread-spectrum clocking.

The most common modulation techniques are center-spread and down-spread. The center-spread approach applies the modulated signal in such a way that the nominal frequency sits in the center of the modulated frequency range. That is, half of the modulated signals deviate above the nominal frequency, and the other half deviate below it. A down-spread approach also results in a range of deviated frequencies. However, in the down-spread approach, the modulated signals deviate below the nominal frequency.

Spread-spectrum clocking reduces EMI in embedded systems figure 1Many PCIe systems implement EMI-minimizing spread-spectrum clocking by spreading the spectral energy of the clock signal over a wide frequency band. In spread-spectrum-clocking systems, PCIe components generally must use a reference clock from the same source. This approach allows a transmitter PLL (phase-locked-loop) and a receiver-clock-recovery function, or clock-data-recovery circuit, to track the modulation frequency and remain synchronous with each other. If only one side of the link uses a spread-spectrum-clocking reference clock, the transmitter and receiver circuits cannot properly track one another. For example, if a PCIe add-in card interfaces to a spread-spectrum-clocking system and also implements a cable connection to a downstream card that is using a constant-frequency-clock source, the downstream interface will be unable to connect.

The PCIe base specification provides guidelines for modulating the reference-clock input to PCIe devices. At a high level, the PCIe specification uses the down-spread approach when using a 30- to 33-kHz-wave signal as the modulating frequency to the 100-MHz clock, resulting in a frequency range of 99.5 to 100 MHz (Figure 1).



Information is shared by www.irvs.info

Open Embedded: An alternative way to build embedded Linux distributions

As embedded processors have grown more powerful and feature-rich, the popularity of the Linux operating system in embedded applications has grown in leaps and bounds. Although the fact that Linux is open source and free of licensing fees is one major driver of its popularity, another key driver is the wealth of application software and drivers available as a result of Linux’s widespread usage in the desktop and server arenas.

However, embedded developers cannot simply pick up desktop Linux distributions or applications for use in their systems. Broadly speaking, embedded Linux developers face three main challenges:

1. assembling a compatible combination of bootloader, kernel, library, application, and development tool components for the processor and peripherals used in their hardware;

2. correctly cross-building a multi-megabyte image; and

3. optimizing the various kernel and user-space components to reduce the footprint and associated memory cost.

Solutions to these challenges are far from straightforward and for a development team to achieve them requires significant effort and experience. Commercial embedded Linux vendors offer pre-tested solutions for particular embedded processors, but for developers who prefer a ‘roll your own’ approach to Linux, the Open Embedded (OE) build environment provides a methodology to reliably build customized Linux distributions for many embedded devices. A number of companies have been using OE to build embedded Linux kernel ports along with complete distributions, resulting in an increasing level of support to maintain and enhance key elements of the OE infrastructure.

In addition, a growing number of embedded Linux distributions (such as Angstrom) utilize OE. Although these distributions are not formally part of OE, they add to the attraction of using OE by providing ready-to-run starting points for developers. A final attraction is that some of the newer commercial distributions from companies such as MontaVista and Mentor Graphics are now based on OE. These provide additional tooling and commercially supported distributions.

In this article we present an overview of the key elements of the OE build environment and illustrate how these elements can be applied to build and customize Linux distributions. The Texas Instruments Arago distribution, which is based on the Angstrom distribution, will be used as example of how to create a new distribution based on OE and the distributions that already use it.

Most of the Arago- or Angstrom-based example scripts shown here have been modified slightly to more concisely demonstrate key concepts of OE. Developers should access the original scripts at the websites listed at the end of the article to view complete real-world implementations.

An Overview of Open Embedded

OE is based on BitBake, a cross-compilation and build tool developed for embedded applications. Developers use BitBake by creating various configuration and recipe files that instruct BitBake on which sources to build and how to build them. OE is essentially a database of these recipe (.bb) and configuration (.conf) files that developers can draw on to cross-compile combinations of components for a variety of embedded platforms.

OE has thousands of recipes to build both individual packages and complete images. A package can be anything from a bootloader through a kernel to a user-space application or set of development tools. The recipe knows where to access the source for a package, how to build it for a particular target, and ensures that a package’s dependencies are all built as well, relieving developers of the need to understand every piece of software required to add a particular capability to their application. OE can create packages in a variety of package formats (tar, rpm, deb, ipk) and can create package feeds for a distribution.

Most OE users will typically begin by selecting a particular distribution rather than building individual packages. The advantage of using an existing distribution is that it will often be necessary to select certain package versions to get a working combination. Distributions address this key function. They often provide a ‘stable’ build in addition to a ‘latest’ build to avoid the inherent instabilities that come from trying to combine the latest versions of everything.

A key benefit of OE is that it allows software development kit (SDK) generation. While some development teams may prefer to build their complete applications in OE, others may have a dedicated team that builds Linux platforms for application development teams to use. In these circumstances, the Linux platform team can generate a Linux distribution as a SDK that is easily incorporated into the build flow preferred by an application team. As a result, there is no need for application development teams to be OE experts.

A critical aspect of the OE database is that much of it is maintained by developers employed by parties with an interest in ensuring successful Linux distribution builds on embedded devices. This maintenance effort is critical given the amount of change occurring in the Linux kernel and application space.

A Quick Look at BitBake

The build tool developers are typically most familiar with is ‘make’, which is designed to build a single project based on a set of interdependent makefiles. This approach does not scale well to the task of creating a variety of Linux distributions each containing an arbitrary collection of packages (often hundreds of them), many of which are largely independent of each other, for an arbitrary set of platforms.

These limitations have led to the creation of a number of build tools for Linux distributions, such as Buildroot and BitBake. BitBake’s hierarchical recipes enable individual package build instructions to be maintained independently, but the packages themselves are easily aggregated and built in proper order to create large images. Thus it can build an individual package for later incorporation in a binary feed as well as complete images.

One important aspect of BitBake is that it does not dictate the way an individual package is built. The recipe (or associated class) for a package can specify any build tool, such as the GNU autotools, making it relatively straightforward to import packages into OE.

To address the need to select specific versions of packages that are known to work together and to specify the different embedded targets, BitBake uses configuration files.

BitBake fetches the package sources from the internet via wget (or any other Software Configuration Management tool such as Git or svn) using the location information in the recipe (Figure 1 below). It then applies any patches that are specified in the package description, which is a common requirement when cross-compiling packages for an embedded processor. The package collection is specified in the higher-level recipes such as those for images and tasks.



Since many developers will want to use an existing distribution, BitBake enables a developer to override distribution defaults by placing customized recipes or configuration files earlier in the BBPATH search path. This enables developers to tweak a distribution for their own needs without having to directly modify (and then subsequently maintain custom copies of) the existing distribution files. This approach in OE is called ‘layering’ and each collection of recipes is called an ‘overlay’.

We’ll now examine some of the different recipe and configuration files to shed a more detailed light on how OE and BitBake work. We will start by looking at the recipe types.

Information is shared by www.irvs.info

Fleet data loggers tackle real-world testing

In order to simulate real situations for the communication networks in a vehicle it is necessary to perform extensive test drives in a real environment. Large amounts of data need to be acquired, recorded, and, afterwards, accessed.

Shortly before production maturity, in-depth testing in vehicles is typically conducted in the context of test drives. To achieve the greatest possible test coverage, some of these tests are performed under extreme environmental conditions. Whether they are winter tests in Finland at -30C, hot weather tests in Death Valley at over 50C, or week-long drives through the Brazilian rainforest at high humidity and on rough roads, in the end the vehicle and all of its components must operate smoothly. Iinstalled data loggers must be able to withstand these harsh conditions as well. This means that they must be mechanically rugged and operate reliably over a broad range of temperatures.

At first glance, it would seem reasonable to use a notebook-based solution for in-vehicle data logging. Together with a suitable network interface the notebook should be able to offer all required capabilities, because functionality can be implemented in software. However, commercially available notebooks cannot handle the required temperature range. Furthermore, the system must first be booted, which takes some time—even with fast notebooks. This implies another requirement for data loggers: Short startup times. Data must be acquired quickly enough for the first message on the bus to be logged.

Information is shared by www.irvs.info

Making your application code multicore ready

Many silicon vendors rely on multicore architectures to improve performance. However, some engineers might say that those vendors have not been able to deliver compilation tools that have kept pace with the architecture improvements. The tools that are available require both a good understanding of the application and a deep understanding of the target platform.

However, an alternative approach is possible. This article will highlight a way to parallelize complex applications in a short time span, without the need to understand neither the application nor the target platform.

This can be achieved with interactive mapping and partitioning design flow. The flow visualizes the application behavior and allows the user to interactively explore feasible multithreaded versions. The program semantics are guaranteed to be preserved under the proposed transformations.

In many cases the design of an embedded system starts with a software collection that has not yet been partitioned to match the multicore structure of the target hardware.

As a result, the software does not meet its performance requirements and hardware resources are left idle. To resolve this, an expert (or a team of experts) comes in to change the software so that it fits the target multicore structure.

Current multicore design flow practice



Figure 1 Traditional multicore design practice involves an iterative process of analysis, partitioning, loop parallelization, incorporation of semaphores, analysis, testing and retuning of code.

A typical approach, illustrated in Figure 1 above, would include the following steps:

1. Analyze the application. Find the bottlenecks.

2. Partition the software over the available cores. This requires a good understanding of data access patterns and data communication inside the application to match this with the cache architecture and available bandwidth of buses and channels on the target platform. Optimize some of the software kernels for the target instruction set (e.g. Intel SSE, ARM Neon).

3. Identify the loops that can be parallelized. This requires a good understanding of the application: find the data dependencies, find the anti- and output dependencies, and find the shared variables. The dependencies can be hidden very deeply, and to find them often requires complex pointer analysis.

4. Predict the speedup. Predict the overhead of synchronizing, the cost of creating and joining threads. Predict the impact of additional cache overhead introduced by distributing workload over multiple CPUs. If parallelizing a loop still seems worth it, go to the next step.

5. Change the software to introduce semaphores, FIFOs and other communication and synchronization means. Add thread calls to create and join threads. This requires a good understanding of the API’s available on the target platform. In this stage subtle bugs are often introduced, related to data races, deadlock or livelock that may only manifest themselves much later, e.g. after the product has been shipped to the customer.

6. Test. Does it seem to function correctly? Measure. Does the system achieve the required performance level? If not: observe and probe the system. Tooling exists to observe the system; The experts need to interpret these low-level observations in the context of their expert system knowledge, then draw conclusions.

7. Try again to improve performance or handle data races and deadlocks. This involves repeating the above from Step 1.

Close analysis of Figure 1 clearly shows there are many problems with this design flow. Experts that can successfully complete this flow are a rare-breed. Even if you can find them, at the start of a project it is hard to predict how many improvement and bug fix iterations the experts need to go through until the system stabilizes.

Multicore platforms are quickly becoming a very attractive option in terms of their cost-performance ratio. But they also become more complex every year, making it harder for developers to exploit their benefits. Therefore we need a new design flow that enables any software developer to program multicore platforms. This flow is depicted in Figure 2 below.



Figure 2 Multicore design flow that enables any software developer

In this alternative flow, a tool analyzes the program before it is partitioned. It finds the loops that can be parallelized and devises a synchronization strategy for these loops. The tool also has detailed knowledge of the target platform and it can estimate the cost of different partitioning and synchronization strategies.

Information is shared by www.irvs.info

Touch-screen technologies enable greater user/device interaction

Introduction

Touch screens are not a new concept. Since the arrival of the iPhone® multimedia device, touch technology has become extremely popular and has benefited from a flood of innovations. Where previously touch screens were merely designed to replace keyboards and mice, today they convey a completely new operating experience. Featuring greater interaction between the user and device, this new “touch” experience has been achieved by a combination of different technologies. This article provides an overview of recent advances in touch-screen technology.

Resistive technology

Touch screens with resistive technology have been in common use for many years. They are inexpensive to manufacture and easy to interface.

In resistive-technology sensing, electrodes are connected to two opposite sides of a glass plate with a transparent, conductive coating. When a voltage is applied to the electrodes, the plate acts like a potentiometer, enabling the measurement of a voltage which depends on the position of the contact point, Figure 1.

Once a similar, second plate is arranged in close proximity to the first with electrodes offset by 90°, and with the coatings facing each other, a 4-wire touch screen is achieved. If the top plate, which can also consist of transparent plastic, is deflected by a finger or pen so that the plates touch at the contact point, the x- and y-position of the pressure mark can be determined by comparing the voltages.



Figure 1: Functionality of a resistive touch screen.

because resistive touch screens are pressure sensitive, they can be operated using any pen or a finger. In contrast to most capacitive technologies, they can also be operated if the user is wearing gloves. Due to the mechanical contact system and the DC operation, they have a high electromagnetic interference (EMI) tolerance. However, only one contact pressure point can be registered at a time, and no multitouch systems are possible.

Modern controllers like the Maxim MAX11800 autonomously calculate the X/Y coordinates, thus relieving the host CPU of this task. This facilitates rapid scanning which, for example, enables a clear and legible signature to be captured.

Capacitive styles

Another technology, termed “projected capacitive,” is gaining in popularity. The premise for this technology is straightforward: transparent conductor paths made of indium tin oxide (ITO) are applied to a transparent carrier plate mounted behind a glass plate. A finger touching the glass plate affects the electrical capacitor field and enables the contact to be detected and measured. Two fundamentally different approaches are used to implement a projected capacitive design.

Self-capacitance

With this design, a clearly defined charge is applied to a conductor path. An approaching finger conducts part of the charge to ground. The changing voltage at the conductor path is analyzed by the touch controller. The ITO conductor paths are arranged in X and Y directions in a diamond pattern (Figure 2).



Figure 2: Functionality and design of a self-capacitance touch screen.

The exact position of the finger on the glass plate is determined by the controller chip through interpolation. Only one finger position can be recorded at a time, so real multitouch functionality is not possible.

The MAX11855 is a controller for a self-capacitive touch screen. It can control up to 31 ITO paths. Its superior sensitivity enables touch detection from gloved hands, and its noise immunity allows for thin and simple ITO constructions without the need for special shielding or a safety gap between it and the LCD display.

Intelligent control also makes pseudo-multitouch possible, e.g., zooming through the spread of two fingers. The integrated microcontroller enables the device to be used flexibly for touch screens of different dimensions as well as for buttons or slider controls.

Mutual capacitance

With this technology, an activating finger changes the coupling capacity of two crossing conductor paths. The controller monitors each line, one after another, and analyzes the voltage curves at the columns (Figure 3). This technology is capable of multitouch; several finger contacts can be detected simultaneously.



Figure 3. Functionality of a mutual-capacitance touch screen.

The geometry of the conductor paths is optimized for several applications. The MAX11871 touch-screen controller is designed for this technology and is the first controller on the market to allow a capacitive touch screen to be operated with gloved hands or pens. Another advantage is that the screen can be mounted behind a thick glass plate, so very robust systems can be built.

Haptics rising quickly as a driving force

A user’s operating experience is changing significantly because of the emerging use of haptics. Haptic feedback enables the operator to “feel” a device execute a function.

Currently, cell phones use a very rudimentary method for this tactile feedback. An integrated vibration motor, which is primarily used to signal an incoming call when the device is in silent mode, is activated for a short moment with every touch contact, and the whole cell phone briefly vibrates.

Future haptic systems will further refine this experience. In the newest designs, the touch-screen glass plate is moved by special actuators that operate magnetically, e.g., the new linear-resonant-actuators (LRA), or are piezo-based. Piezo devices are available in single-layer versions. which require a high voltage (up to 300V) or in a more-elaborate multilayer technology which can reduce the required voltage.

The MAX11835 haptic driver has been designed for single-layer, high-voltage piezo actuation. It is controlled directly by a touch-screen controller like any of the devices mentioned above. It enables a nearly latency-free operation, which is very important for the touch experience. Its waveform memory allows for individual movement patterns, which can further optimize the operating experience.

As an example, buttons can be sensed by fingertips moving over the display. Pressing the button then executes a function and creates a different waveform, which is detected differently by the finger. In this way touch-screen devices can be operated safely without the operator having to constantly look at the display to verify an action. This significantly increases personal safety for navigational systems or medical devices.



Figure 4; The function generator built into the MAX11835 reduces the delay for a fast and individual haptic experience

Information is shared by wwww.irvs.info

Ultra-Low-Power RF

Even though the chips ship in their tens of millions each week, the market for short-range, low power RF technologies operating in the globally popular 2.4GHz ISM band - such as Wi-Fi, Bluetooth, ZigBee and a slew of proprietary solutions - is far from maturity. In the next few years, many impressive developments will emerge and wireless connectivity will pervade every aspect of our lives.

In particular, ultra low power (ULP) wireless applications – using tiny RF transceivers powered by coin cell batteries, waking up to send rapid “bursts” of data and then returning to nanoamp “sleep” states – are set to increase dramatically. For example, according to analysts ABI Research, the wireless sensor network (WSN) chips market grew by 300 percent in 2010. And the same company forecasts that no less than 467 million healthcare and personal fitness devices using Bluetooth low energy chips will ship in 2016.

ULP wireless connectivity can be added to any portable electronic product or equipment featuring embedded electronics, from tiny medical and fitness sensors, to cell phones, PCs, machine tools, cars and virtually everything in between. Tiny ULP transceivers can bestow the ability to communicate with thousands of other devices directly or as part of a network – dramatically increasing a product’s usefulness.

Yet, for the majority of engineers, RF design remains a black art. But while RF design is not trivial - with some assistance from the chip supplier and a decent development kit - it’s not beyond the design skills of a competent engineer. So, in this article I’ll lift the veil from ULP wireless technology, describe the chips, and take a look at how and where they’re used.

Inside ULP wireless
ULP wireless technology differs from so-called low power, short-range radios such as Bluetooth technology (now called Classic Bluetooth to differentiate it from the recently released Bluetooth v4.0 which includes ultra low power Bluetooth low energy technology) in that it requires significantly less power to operate. This dramatically increases the opportunity to add a wireless link to even the most compact portable electronic device.

The relatively high power demand of Classic Bluetooth - even for transmission of modest volumes of user data – dictates an almost exclusive use of rechargeable batteries. This power requirement means that Classic Bluetooth is not a good wireless solution for ‘low bandwidth - long lifetime’ applications and it’s typically used for periods of intense activity when frequent battery charging is not too inconvenient.

Classic Bluetooth technology, for example, finds use for wirelessly connecting a mobile phone to a headset or the transfer of stored digital images from a camera to a Bluetooth-enabled printer. Battery life in a Classic Bluetooth-powered wireless device is therefore typically measured in days, or weeks at most. (Note: There are some highly specialized Classic Bluetooth applications that can run on lower capacity primary batteries.)

In comparison, ULP RF transceivers can run from coin cell batteries (such as a CR2032 or CR2025) for periods of months or even years (depending on application duty cycle). These coin cell batteries are compact and inexpensive, but have limited energy capacity, typically in the range of 90 to 240mAh (compared to, for example, an AA cell which has 10 to 12x that capacity) - assuming a nominal average current drain of just 200µA.

This modest capacity significantly restricts the active duty cycle of a ULP wireless link. For example, a 220mAh CR2032 coin cell can sustain a maximum nominal current (or discharge rate) of just 25µA if it’s to last for at least a year (220mAh/(24hr x 365days)).

ULP silicon radios featuring peak currents of tens of milliamps - for example, current consumption of Nordic Semiconductor’s nRF24LE1 2.4GHz transceiver is 11.1mA (at 0dBm output power) when transmitting and 13.3mA (at 2Mbps) when receiving. If the average current over an extended period is to be restricted to tens of microamps, the duty cycle has to be very low (around 0.25 percent) with the chip quickly reverting to a sleep mode, drawing just nanoamps, for most of the time.

Information is shared by www.irvs.info

Scalable SoC drives 'hybrid' cluster displays

With increased electronics content, increasingly connected cars, and computers taking more and more control in vehicles, it is only logical that instrument clusters massively change their appearance and functions.

Traditional instrument clusters are a key element of cars that are undergoing substantial changes. The time has arrived for an evolution in traditional main vehicle instrument cluster units. Between the group of mechanical instrument clusters and the growing group of free programmable clusters there is actually the huge area of hybrid dashboards, which combines traditional meters and at least one graphical display for driver information.

With the increasing number of electronic systems in cars, such as driver assistance systems, the number of information and status signals offered to the driver is increasing in parallel. Undoubtedly pictures and graphics can be grasped more easily and quickly by humans than written or digital information. The consequence is a strong trend towards displays within easy view of the driver, mostly as part of a hybrid cluster, but also—as a logical step—implemented as head-up displays (HUDs).

For the automotive industry the design of the driver's environment is a major differentiator from competitors, especially considering the difficult conditions for implementing advanced electronic systems in the car. Quality, robustness, functional safety, data security, low power consumption, etc, are the main criteria. From the cost perspective this means that display and semiconductor technologies have to be available at reasonable prices and have to offer the right amount of scalability in several key areas, such as LCD and TFT, graphics processors and controller units, sensors and LED modules.

New features and applications, with obvious possibilities for integration into instrument clusters, are being introduced into cars via entertainment, navigation, advanced driver assist systems (ADAS), and diagnostic systems. Although multi-purpose head units will still have the main display capability, clusters will be able to offer an auxiliary screen to the driver—especially for multimedia content, even if it were only to access main vehicle information and safety data from ADAS.

Information is shared by www.irvs.info

Exposing the hidden costs of using off-the-shelf analog ICs

An ASIC does not necessarily have to be a custom integrated circuit. There are many standard analog chips in the market that are simply priced too high. It may make good economic sense to consider using an analog ASIC company developed a chip that mimics a standard product.

Analog ASICs are not for everyone. Like any component choice, they must offer the best economic value for the application. Any associated up-front NRE costs (non-recurring engineering) must be factored into the equation along with hard tooling (wafer fabrication masks, test hardware and software and more). In addition, there is the issue of time. Analog ASICs can take from six months up to a year or more to be ready to use in a production environment. And of course, there is a minimum quantity that must be consumed to assure the value is received. These must all align properly to justify development of an Analog ASIC

Why do Standard Analog ICs Cost So Much?

No one designs and tools production for ICs for free. The OEM pays for this one way or another. When you buy a standard analog IC, some portion of the price you pay is used to cover the development cost of that chip. The real question becomes, what portion of the price you pay is actually the cost to make the chip? A simplified analysis is derived by viewing a chip company’s financial statement. The critical metric is Gross Profit Margin (GPM).

Gross Profit = Company Annual Sales – Actual Cost to Build the Products Sold

When viewed in their annual report, reflecting sales over a 12 month period, GPM is an average, meaning half of the chip company’s sales during that year achieved more than the reported GPM and half were below the reported GPM.



Depending on the GPM of the products you selected for your new design, it may be cost advantageous to consider replacing them with an analog ASIC. For example, a circuit uses several off-the-shelf analog ICs, including a Linear Tech gain programmable precision instrumentation amplifier, a National micro power ultra low-dropout regulator, an Analog Devices 40 µA micropower instrumentation amplifier, and much more. The combined high volume bill of materials cost was $3.56 and was easy to integrate into an analog ASIC. By integrating the equivalent functions into an analog ASIC, it was possible to reduce the $3.56 cost to well under one dollar. The product lifetime is expected to be ten years, with monthly volumes averaging 15K units.

After amortizing in the NRE and tooling costs associated with the development of the ASIC, the following sensitivity analysis was developed. It is expected that during the lifetime of the ASIC that there may be some degradation to the prices of the standard analog ICs. The analysis projects lifetime savings based on not only under and over achievement of the lifetime volumes of the chip but also the fact the future cost savings may be less than today’s based standard product price changes.



While cost is a compelling reason to move to an analog ASIC because it is an easily measured metric, do not underestimate the value of IP protection and unique differentiation. Many times these critical aspects of an analog ASIC’s economic value are overlooked.

Information is shared by www.irvs.info

3D modeling integrates flexible PCB design

Over the last decade, electronic products have become increasingly complex and dense as they support more functions into dramatically reduced footprints. The need for flexible circuits has grown exponentially, since they are often the preferred solution to achieve package weight-reduction, compared to rigid planar boards.

They are also easier to manufacture, reducing total assembly time while driving down cost and errors. Through their proven suitability for handling more than 25 point to point wires connections, flexible PCBs also provide greater system reliability.

Additionally, their main advantage is their ability to bend in order to accommodate the most cramped environments, enabling denser component layouts within the specified mechanical constraints of consumer products.

This makes flexible PCBs suitable for use in almost all electronics-based equipment, from consumer products such as digital cameras, computers and hard drives, to internal medical devices and military equipment.

Several generations of notebooks, tablet computers and other devices have been able to slim down while increasing their functionalities thanks to flexible layouts and interconnects.

Reducing the design cycle

Looking at how some flexible PCBs are designed today, and considering their development cycles, it is clear that there is considerable room for improvement. When Dassault Systèmes started to work on this subject with a leading Japanese worldwide consumer electronics company, we soon realized that their design process was slow, extremely complex and time consuming.

The first steps of the development process were purely manual and involved placing the flexible PCB assembly within the product. Even today, some companies are still making paper PCBs by hand, and check the components’ positions manually throughout the product’s physical mock up stages.

Following this procedure, 2D drawings were generated and shared with the ECAD designer for component placement and routing.

Within this outdated methodology, mechanical and electronic design processes were conducted separately. Only late in the development cycle was it possible to exchange critical design data between MCAD and ECAD systems. The limitations in data exchange and the lack of co-design functionality resulted in the need for additional design iterations, driving up development times and costs.

Information is shared by www.irvs.info

Microcontroller provides an alternative to DDS

Audio and low-frequency circuit systems often require a signal source with a pure spectrum. DDS (direct-digital-synthesis) devices often perform the signal generation by using these specialized integrated circuits. A DDS device uses a DAC but often with no more than 16-bit resolution, limiting the SNR (signal-to-noise ratio).

You can perform the same task with a microcontroller programmed as a DDS and use an external high-resolution DAC. To achieve 18 to 24 bits of resolution requires a large memory table containing the cosine function for any values of phase progression.

An alternative approach lets you use a standard microcontroller with a small memory and still implement an effective synthesizer. You can design a circuit to produce a sine wave using a scalable digital oscillator built with adder and multiplier block functions in a simple structure.



Figure 1 shows a microcontroller driving an audio DAC. To develop your code to generate a sine wave, the circuit in Figure 2 comprises two integrators with an analog feedback loop equivalent to that of an ideal resonator.



Parameter F defines the frequency and ranges from 0 to –0.2, and Parameter A sets the amplitude of the output signal with a single initial pulse at start-up. The following equation derives the frequency of generated signals:


where T denotes the time for computing an entire sequence to obtain output data.

The firmware for implementing this system is relatively straightforward. It requires just a few additions and one multiplication. Thus, you can use a slow microcontroller. Remember, though, that the precision of every operation must be adequate to warrant a complete signal reconstruction. Processing data with 8 or 16 bits isn’t sufficient. You must write your firmware to emulate a greater number of bits, which requires accurate code implementation.

If you properly develop your code, then you should generate the DAC output codes that produce a sine wave (Figure 3). Remember that Parameter F is nonlinear with respect to the output frequency. If you need a directly proportional rate, you can square the value of F before applying it to the input. You’ll find it useful when you need to make an easy frequency setting.



You can use just about any microcontroller to implement the oscillator, together with a high-performance DAC. You can achieve an output SNR greater than 110 dB. Many audio DACs operating in monophonic mode have 20- to 24-bit resolution at a 192-kHz sampling rate. They also offer a dynamic range of 120 dB or more.

Information is shared by www.irvs.info

Creating video that mimics human visual perception

Recent significant breakthroughs in core video processing techniques have nurtured video technology into one that looks aptly placed to contest the capabilities of the human visual system. For one, the last couple of decades have witnessed a phenomenal increase in the number of pixels accommodated by display systems, enabling the transition from standard-definition (SD) video to high-definition (HD) video.

Another noteworthy evolution is the stark enhancement in pixel quality, characterized by high dynamic range (HDR) systems as they elegantly displace their low dynamic range (LDR) equivalents.

Moreover, the intuitive approaches developed in the understanding of images to replicate the perceptual abilities of the human brain have met with encouraging successes, as have 3D video systems in their drive toward a total eclipse of their 2D counterparts.

These advanced techniques coerce toward a common purpose—to ensure the disappearance of boundaries between the real and digital worlds, achieved through the capture of videos that mimic the various aspects of human visual perception. These aspects fundamentally relate to video processing research in the fields of video capture, display technologies, data compression as well as understanding video content.

Video capture in 3D, HD and HDR
The two distinct technologies used in the capture of digital videos are the charge-coupled devices (CCD) and complementary metal-oxide-semiconductor (CMOS) image sensors, both of which convert light intensities into appropriate values of electric charges to be later processed as electronic signals.

Leveraging on a remarkable half-century of continued development, these technologies enable the capture of HD videos of exceptional quality. Nevertheless, in terms of HDR videos, these technologies pale in comparison to the capabilities of a typical human eye, itself boasting a dynamic range (the ratio of the brightest to darkest parts visible) of about 10000:1.

Existing digital camcorders can either only capture the brighter portions of a scene using short exposure durations or the darker portions using longer exposure durations.

Practically, this shortcoming can be circumvented with the use of multiple camcorders with one or two beam splitters, in which several video sequences are captured concurrently under different exposure settings.

Beam splitters allow for the simultaneous capture of identical LDR scenes, the best portions of which are then used to synthesize HDR videos. From a research perspective, the challenge is to achieve this feat of a higher dynamic range with the use of a single camcorder, albeit with an unavoidable but reasonable reduction in quality that is insignificantly perceivable.

Moreover, it is envisioned that HDR camcorders equipped with advanced image sensors may serve this purpose in the near future.

3D capture technologies widely employ stereoscopic techniques of obtaining stereo pairs using a two-view setup. Cameras are mounted side by side, with a separation typically equal to the distance between a person's pupils.

Exploiting the idea that views from distant objects arrive at each eye along the same line of sight, while those from closer objects arrive at different angles, realistic 3D images can be obtained from the stereoscopic image pair.

Multi-view technology, an alternative to stereoscopy, captures 3D scenes by recording several independent video streams using an array of cameras. Additionally, plenoptic cameras, which capture the light field of a scene, can also be used for multiview capture with a single main lens. The resulting views can then either be shown on multiview displays or stored for further processing.

Information is shared by www.irvs.info

Meters evolve to bring the smart grid home

The arrival of the truly connected digital home is one of the most anticipated events of the coming decade, promising tremendous opportunities across multiple markets. With stakeholders as diverse as consumer electronics manufacturers, connectivity solution providers, governmental agencies, utility companies and semiconductor suppliers, it is not surprising that there is a diversity of views on which direction the digital home should take.

Current stakeholders are looking to maintain existing business models, while new entrants see the connected home as an opportunity to create new revenue streams with products and services. Expect the digital home to be a battleground for years to come.

Many essentials, elemental building blocks are required to achieve the connected digital home. In the smart energy realm, the shift from mechanical meters to electronic meters is well under way.

Adding remote communications and automated service applications is the popular view of smart energy. The next envisioned frontier is the implementation of time-of-use plans, based on existing infrastructure and generation facilities. That limited vision, however, misses the opportunity to revolutionize the entire system, from power generation and distribution to effective energy consumption management.

"Smart meters will allow you to actually monitor how much energy your family is using by the month, by the week, by the day, or even by the hour," President Obama said in October 2009 during a speech in support of Recovery Act funding for smart grid technology. "Coupled with other technologies, this is going to help you manage your electricity use and your budget at the same time, allowing you to converse electricity during times when prices are highest."

That's a good starting point, but it will have no real impact on efficiency or consumption rates. Without fundamental energy generation and distribution innovation, consumers' behavior is unlikely to change in any significant way. Standardization and dynamic pricing are required to make it worthwhile for energy providers and consumers to monitor usage at so granular level.

The current, monopoly-driven infrastructure, however, is so inefficient that energy measurement and monitoring provide little opportunity for savings.

To achieve the benefits envisioned for the smart grid, full standards-based deployment is required.

A fully deployed smart grid will create a competitive energy service environment, with multiple providers and dynamic pricing, much as the telecom revolution has broadened customers' options over the past 25 years. A standards-based approach to supplying consumers' energy needs will drive investment in next-generation technologies and business models oriented to demographic profiles that match the efficiency generation profiles.

For example, people who work from home and consume a majority of their energy during the day may be offered an attractive package from an energy distributor partnered with a solar power generation company.

Information is shared by www.irvs.info

Technological advances simplify personal healthcare and peak-performance training

Over the past few decades, medical electronics has played a key role in supporting personal disease management and simple and advanced diagnostics. Examples range from blood-glucose and blood-pressure monitoring devices to fever management with an electronic thermometer. Several innovations that focus on increasing quality of life for users are being made in this space. The considerable progress made in this area has prompted developers to look beyond personal healthcare for medical electronics applications.

A number of applications are emerging that use both conventional and new medical electronics in conjunction with advanced software intelligence known as biofeedback. Devices that incorporate this technology enable users to maintain health or to train for peak performance. Biofeedback already encompasses a diverse range of applications. Simple to complex biofeedback systems and modern semiconductor devices such as ultra-low-power microcontrollers (MCUs), high-end embedded processors, and high-performance analog front ends (AFEs) can contribute to unlimited innovations in the field of biofeedback.



Personal biofeedback device categories include neurofeedback with electroencephalogram (EEG) and hemoencephalogram (HEG), heart rate variability (HRV), stress and relaxation, electromyogram (EMG) muscle-activity feedback, skin temperature and core temperature measurement, and pulse oximetry. Notice that these are reuse and new-use versions of time-tested diagnostic technologies known to the healthcare industry. An increasing number of emerging fitness products are now geared toward enhancing performance as opposed to general-purpose fitness applications.

Information is shared by www.irvs.info

Debug a microcontroller-to-FPGA interface from the FPGA side

Microcontrollers and FPGAs often work together in embedded systems. As more functions move into the FPGA, however, debugging the interface between the two devices becomes more difficult. The traditional debugging approach comes from the microcontroller side, which relies on a serial-port printout. This approach adds overhead and may cause timing problems. Furthermore, this approach cannot guarantee uninterrupted and exclusive access to certain addresses because of operating-system multitasking. Thus, a serial-port printout doesn’t accurately describe the actions on the microcontroller/FPGA interface.

Instead, you can approach the problem from the FPGA side using a JTAG (Joint Test Action Group) interface as a communication port. This approach uses the internal logic of the FPGA to capture the read/write transactions on the microcontroller/FPGA interface. This method is nonintrusive because the circuit that captures transactions sits between the microcontroller and the FPGA’s functioning logic and monitors the data without interfering with it. It stores the captured transaction in the FPGA’s RAM resources in real time. You can transfer the data to a PC through the JTAG port’s download cable.

The debugging tool comprises the data-capture circuit, the JTAG communication circuit, and the GUI (graphical user interface). The data-capture circuit uses standard HDL (hardware-description language) and instantiates a FIFO (first-in/first-out) buffer in the FPGA. Whenever you read or write to a register, the debugging tool records the corresponding value of the address and data on the bus and stores it in the FIFO buffer. You can retrieve the data through the JTAG’s download cable to the PC (Listing 1 - all listings are provided on subsequent pages or as a downloadable doc file from the links below).

Because the FPGA has limited on-chip RAM resources, you must keep the FIFO buffer shallow. To efficiently use the FIFO buffer, the design includes filter and trigger circuits. With inclusive address filtering, the circuit monitors only several discontinuous spans of addresses instead of the whole address space. Exclusive-address filters can filter out several smaller address spans from the inclusive-address spans, enabling finer control of the filter settings (Listing 2).

With transaction triggering, the circuit starts when you read from or write to a certain address. You can add certain data values to the triggering condition (Listing 3). You can dynamically reconfigure the settings of address filters and transaction triggers through the JTAG’s vendor-supplied, customizable communication circuit without recompilation of the FPGA design (Figure 1). The circuit has two interfaces, one of which is written in HDL to form a customized JTAG chain. It communicates with the user logic (listing 1, listing 2, and listing 3). The circuit is accessible through specific programming interfaces on the PC and communicates with the user program or GUI (Listing 4).



The FPGA-based circuit facilitates writing and reading functions from PC to FPGA logic, and it promotes the JTAG interface to a general communication port attached to the FPGA. FPGA manufacturers, including Actel, Altera, Lattice Semiconductor, and Xilinx, respectively, call this circuit UJTAG (user JTAG), Virtual JTAG, ORCAstra, and BScan (references 1 through 4).

The GUI for this circuit uses Tcl/Tk (tool-command-language tool kit). FPGA manufacturers provide vendor-specific APIs (application-programming interfaces) in Tcl for the PC side of the JTAG-communication circuit. The APIs include basic functions, such as JTAG-chain initialization, selection, and data reading and writing. With the data-read function, you can check the capturing status and get the transaction data from the FIFO buffer. With the data-writing function, you can send the filter and trigger configuration data to the capturing circuit in the FPGA (Listing 4). The JTAG-based debugging method provides dynamic visibility and controllability into the microcontroller-to-FPGA interface and the FPGA’s internal logic without the need to recompile and download FPGA code.

Information is shared by www.irvs.info

Use best practices to deploy IPv6 over broadband access

After more than a decade of forewarning, the IPv4 to IPv6 transition has finally reached critical mass. On Feb 1, 2011, the AINA allocated the last freely available block of IPv6 addresses. At the same time, the number of users and "endpoints" requiring Internet access - and thus a unique IP address--continues to explode. With exponential growth in global broadband deployments, next-gen wireless rollouts on the horizon, and fast-growing smart phones in the field, the industry is predicting an increase of 5 billion unique endpoints by 2015. In the meantime, service providers are struggling to prepare their networks for the influx of IPv6 addresses.

While the Internet is rich with IPv6 content and services- Google is already supporting IPv6 on its search, news, docs, maps and YouTube- IPv4 won't just "go away" as IPv6 comes on board. This creates a challenging situation for service providers that must upgrade their network infrastructure to handle IPv4 and IPv6 co-existence.

Network cores are well equipped for handling both IPv4 and IPv6, however broadband access networks are not. IPv4 and IPv6 co-existence puts tremendous stress on the underlying network systems, which can potentially introduce latency, degrade network responsiveness, and compromise service level agreements. The biggest transition concern is the impact on customers: will introducing IPv6 endpoints, forwarding tables, and services affect connectivity speed, service quality, and network reliability?

IPv6 Solutions for Broadband Access

An abrupt transition of the legacy IPv4 infrastructure to IPv6 is not practical because most Internet services are still based on IPv4 and many customers are still running operating systems that do not fully support IPv6. Service providers must support both IPv4 and IPv6 endpoints and service in order to guarantee the quality of service (QoS) defined in their service level agreements (SLA).

There are different methods that can be used to achieve this goal across broadband access networks including:
* Translation
* Tunneling
* Dual-Stack Network

Translation

The easiest way to conserve the depleting IPv4 address space is to use translation so that the outward facing interface uses a public interface while the private network uses IP addresses that are not routed on the Internet. However, the known performance and scalability issues compel most service providers to deploy either tunneling or dual-stack transition mechanisms in broadband access networks.

Information is shared by www.irvs.info

Bring big system features to small RTOS devices with downloadable app modules

The embedded systems used in consumer, medical and industrial applications often require real-time response to provide an effective user experience.

Whether a smartphone’s baseband radio communications, ultrasound image processing, or production line video inspection, all of these and many other such systems need to process inputs quickly and get some information or action back to the user whether human or another machine.

These systems run on low-power processors and often do all of their processing with relatively small amounts of memory—a combination of requirements that often leads developers to use a real-time operating system (RTOS). The RTOS manages application tasks or threads, handles interrupts, and provides a means of interthread communication and synchronization.

RTOSes come in all sizes and flavors, from the large, like Wind River’s VxWorks, to the super-compact, like Express Logic’s ThreadX. Robust RTOSes offer many features adapted from desktop systems that are typically not available in compact RTOSes because such features execute a larger amount of code that takes a larger memory footprint and causes a slower real-time response.

In contrast, the compact RTOS generally operates as a library of services, called by the application through direct function calls. Underlying these RTOS services is an infrastructure (Figure 1, below) of scheduling and communications facilities that support these functions.



Figure 1. The compact RTOS generally operates as a library of services, called by the application through direct function calls.

Most "small footprint" RTOSes employ an architecture in which the application code is directly linked with the RTOS services it uses, forming a single executable image (Figure 2 below).

The application explicitly references the services it needs, using function calls with an API defined by the RTOS. These service functions are linked with the application from the RTOS library. The result is a single executable image, usually in the .elf format.

For development, this image then is downloaded to target memory and run or, in production, it is flashed into ROM and run at device power-on.

This "monolithic" approach is efficient in both time and space, but it lacks flexibility. Any changes to the application or RTOS require re-linking and a new download/flash of the entire image. While this is routine during development, after production it can present some limitations.



Figure 2. Most "small footprint" RTOSes employ an architecture in which the application code is directly linked with the RTOS services it uses, forming a single executable image.

In contrast, desktop operating systems such as Windows and Linux, and larger RTOSes, such as VxWorks and QNX, have a two-piece "OS/Application" architecture.In this architecture, there is a resident kernel, containing all the OS services available to applications or that are needed by other services within the kernel, all linked into a distinct executable.

This kernel executable boots the system and runs continuously, providing a foundation for applications which dynamically load and run. Usually, virtual memory provides demand paging to and from mass storage on desktop systems or multi-user separation in embedded systems.

This approach is used in mobile devices such as Apple’s iPhone or iPad, where new "Apps" can be downloaded over the wireless network. The OS runs in the device and handles the user interface, which enables selection of any of the downloaded “Apps.”

The selected App then runs along with the OS on the CPU. Similarly, large RTOS-based systems segregate applications from the RTOS kernel, usually in distinct memory spaces, within a virtual memory environment.

A nice feature of the large RTOSes, shared by their desktop OS cousins, is the ability to dynamically download applications onto a running system. In such partitioned architectures, the kernel runs as an entity and the applications run independently, but makes use of OS services to access and use hardware resources.

Even within embedded systems, such downloading and the dynamic addition or change of applications is found where big RTOSes operate in telecommunications infrastructure and defense/aerospace applications. This capability enables a high degree of modularity and field update of running systems.

Information is shared by www.irvs.info

Software and hardware challenges due to the dynamic raw NAND market

NAND flash is the dominant type of non-volatile memory technology used today. Developers commonly face difficulties developing and maintaining firmware, middleware and hardware IP for interfacing with raw NAND devices. After reviewing the history and differentiated features of various memory devices, we’ll take a detailed look at common obstacles to NAND device development and maintenance, particularly for embedded and system-on-chip (SoC) developers, and provide some recommendations for handling these challenges.

Background on non-volatile memory technologies
There are many different non-volatile memory technologies in use today.

EEPROM
Electrically erasable programmable read-only memory, or EEPROM, is one of the oldest forms of technology still in use for user-modifiable, non-volatile memories. In modern usage, EEPROM means any non-volatile memory where individual bytes can be read, erased, or written independently of all other bytes in the memory device. This capability requires more chip area, as each memory cell requires its own read, write, and erase transistor. As a result, the size of EEPROM devices is small (64 Kbytes or less).

EEPROM devices are typically wrapped in a low-pin-count serial interface, such as I2C or SPI. Parallel interfaces are now uncommon due to required larger pin count, footprint, and layout costs. Like almost all available non-volatile memory types, EEPROMs use floating gate technology in a complementary metal-oxide-semiconductor (CMOS) process.

Flash
Flash memory is a modified form of EEPROM memory in which some operations happen on blocks of memory instead of on individual bytes. This allows higher densities to be achieved, as much of the circuitry surrounding each memory cell is removed and placed around entire blocks of memory cells.

There are two types of flash memory arrays in the marketplace — NOR flash and NAND flash. Though these names are derived from the internal organization and connection of the memory cells, the types have come to signify a particular external interface as well. Both types of memory use floating gates as the storage mechanism, though the operations used to erase and write the cells may be different.

NOR Flash
NOR flash was the first version of flash memory. Until about 2005, it was the most popular flash memory type (measured by market revenue).[1] In NOR flash, bytes of memory can be read or written individually, but erasures happen over a large block of bytes. Because of their ability to read and write individual bytes, NOR flash devices aren’t suitable for use with block error correction. Therefore, NOR memory must be robust to errors.

The capability to read individual bytes also means it can act as a random access memory (RAM), and NOR flash devices will typically employ an asynchronous parallel memory interface with separate address and data buses. This allows NOR flash devices to be used for storing code that can be directly executed by a processor. NOR flash can also be found wrapped in serial interfaces, where they act similar to SPI EEPROM implementations for reading and writing.

NAND Flash
The organization and interface of the NOR flash devices places limitations on how they can scale with process shrinks. With a goal of replacing spinning hard disk drives, the inventor of NOR flash later created NAND flash. He aimed to sacrifice some of the speed offered by NOR flash to gain compactness and a lower cost per byte [2]. This goal has largely been met in recent years, with NAND sizes increasing to multiple gigabytes per die while NOR sizes have stagnated at around 128 MB. This has come at a cost, as will be discussed later.

Raw NAND memory is organized into blocks, where each block is further divided into pages.




Figure 1: MT29F2G08AACWP NAND memory organization (courtesy Micron Inc.)

In NAND memories, read and write operations happen on a per-page basis, but erase operations happen per block. The fact that read and write operations are done block-wise means that it’s suitable to employ block error correction algorithms on the data. As a result, NAND manufacturers have built in spare bytes of memory for each page to be used for holding this and other metadata. NOR flash doesn’t have such spare bytes.

Also in contrast to NOR flash, the NAND flash interface isn’t directly addressable, and code cannot be executed from it. The NAND flash has a single bus for sending command and address information as well as for sending and receiving memory contents. Therefore, reading a NAND device requires a software device driver.

NAND flash is the underlying memory type for USB memory sticks, memory cards (e.g. SD cards and compact flash cards) and solid state hard drives. In all cases, the raw NAND flash devices are coupled with a controller that translates between the defined interface (e.g. USB, SD and SATA) and the NAND’s own interface. In addition, these controllers are responsible for handling a number of important tasks for maintaining the reliability of the NAND memory array.

Raw NAND issues and requirements
Let’s take a detailed look at the issues and challenges presented by incorporating raw NAND devices into an embedded system or SoC.

Errors and error correction
Despite being based on the same underlying floating gate technology, NAND flash has scaled in size quickly since overtaking NOR flash. This has come at a cost of introducing errors into the memory array.

To increase density, NAND producers have resorted to two main techniques. One is the standard process node and lithography shrinks, making each memory cell and the associated circuitry smaller. The other has been to store more than one bit per cell. Early NAND devices could store one of two states in a memory cell, depending on the amount of charge stored on the floating gate. Now, raw NAND comes in three flavors: single-level cell (SLC), multi-level cell (MLC) and tri-level cell (TLC). These differ in the number of charge levels possibly used in each cell, which corresponds to the number of bits stored in each cell. SLC, the original 2 levels per cell, stores 1 bit of information per cell. MLC uses 4 levels and stores 2 bits, and TLC uses 8 levels and stores 3 bits.

While reducing silicon feature sizes and storing more bits per cell reduces the cost of the NAND flash and allows for higher density, it increases the bit error rate (BER). Overcoming the increasing noisiness of this storage medium requires larger and larger error correcting codes (ECCs). An ECC is redundant data added to the original data. For example, the latest SLC NANDs in the market require 4 or 8 bits ECC per 512 bytes, while MLC NAND requires more than 16 bits ECC per 512 bytes. But four years ago, SLC NANDs only required 1 bit of ECC, and the first MLC NANDs only required 4 bits of ECC. In the event of errors, the combined data allows the recovery of the original data. The number of errors that can be recovered depends on the algorithm used.




Figure 2: Device issues versus process node shrinks (courtesy Micron)

Ideally, any ECC algorithm can be used to implement ECC as long as the encoder and decoder match. The popular algorithms used for NAND ECC are:

* Hamming Code: For 1-bit correction [3]
* Reed Solomon: For up to 4 bits of correction. This is less common [4].
* BCH : For 4 or more bits of correction [5].


Extra memory (called the "spare memory area" or "spare bytes region") is provided at the end of each page in NAND to store ECC. This area is similar to the main page and is susceptible to the same errors. For the present explanation, assume that the page size is 2,048 bytes, the ECC requirements are 4 bits per 512 bytes and the ECC algorithm generates 16 bytes of redundant data per 512 bytes. For a 2,048-byte page, 64 bytes of redundant data will be generated. For example, in current Texas Instruments (TI) embedded processors, the ECC data is generated for every 512 bytes, and the spare bytes area will be filled with the ECC redundant data. As ECC requirements have gone up, the size of the spare regions provided by the NAND manufacturers have increased as well. 


The manufacturers of NAND devices specify the data retention and the write/erase endurance cycles under the assumption of the specified ECC requirements being met. When insufficient ECC is used, the device’s usable lifetime is likely to be severely reduced. If more errors are detected than can be corrected, data will be unrecoverable.

Geometry detection
Before raw NAND operations can begin, the first step is to determine the NAND geometry and parameters. The following list is the minimum set of NAND parameters needed by a bootloader or other software layer to determine NAND geometry:

* 8-bit or 16-bit data width
* Page size
* Number of pages per block (block size)
* Number of address cycles (usually five in current NANDs)


Raw NAND provides various methods for NAND manufacturers to determine its geometry at run time:
4th byte ID: All raw NANDs have a READ ID (0x90 at Address 0x00) operation which returns 5 bytes of identifier code. The first and second byte (if the starting byte number is 1 aka "one based") are the manufacturer and device IDs, respectively. The fourth byte (one-based) has information on the NAND parameters discussed above, which can be used by the ROM bootloader.

This 4th byte information can be used to determine raw NAND geometry, yet the interpretation of the 4th byte ID changes from raw NAND manufacturer to manufacturer and between generations of raw NANDs. There are two noteworthy interpretations. The first is a format used by Toshiba, Fujitsu, Renesas, Numonyx, STMicroelectronics, National and Hynix, with certain bits used to represent the page size, data bus size, spare bytes size and number of pages per block. The second is a format particular to the latest Samsung NANDs, holding similar information to the first representation, but with different bit combinations representing different possible values. Since the 4th ID byte format isn’t standardized in any way, its use for parameter detection isn’t reliable.

ONFI: Many NAND manufacturers, including Hynix, Micron, STMicroelectronics, Spansion and Intel, have joined hands to simplify NAND flash integration and offer Open NAND Flash Interface (ONFI)-compliant NANDs. ONFI offers a standard approach to reading NAND parameters.

Other concerns
The physical connection between the embedded processor and the raw NAND device is also of concern. NAND devices can operate at either 3.3V or 1.8V, so it’s important to purchase NANDs with compatible voltage levels. It should be pointed out that 1.8V NAND devices are often specified with worse performance than 3.3V equivalent parts.

Another aspect that must be considered is whether asynchronous or synchronous NANDs will be used. The synchronous interface was something introduced with the ONFI 2.0 specification. Historically, NAND interfaces were asynchronous. However, to reach higher performance levels for data movement, clock synchronized data movement with DDR signaling was provided as an interface option. This type of interfacing may be common in SSD drives but isn’t common in the typical embedded processor or SoC.

Information is shared by www.irvs.info

The 'internet of things' is driving demand for mixed signal MCUs

There is increased activity around the ‘internet of things’; the ability to create networks of small devices that monitor and control our surroundings to create a sort of ‘augmented reality’.

A recent development is NXP’s intention to open-source its JenNET IP protocol stack, which uses the IEEE 802.15.4 MAC and PHY as its underlying platform and employs the IPv6 protocol to extend the network’s addressable nodes to what is often termed as ‘effectively limitless’. It is this potential to give any electronic device its own IP-addressable profile that will lead to the ‘internet of things’ concept becoming reality.

However, in addition to uniquely identifying these ‘things’, it follows that the ‘things’ should do something useful and, increasingly, the application that is most often cited is monitoring and control. Consequently, data gathering using some form of ‘smart’ sensor is expected to constitute a large part of activity for the ‘internet of things’.

A market report by analyst IDC and cited by Intel states that by 2015 there could be 15 billion devices with an embedded internet connection, more than two for every single person on the planet today. In reality, as smart sensor applications flourish, the number of connections could grow beyond this figure rapidly, and that will be enabled in large part by the falling cost of developing and deploying connected devices. A major element of that cost will be the embedded intelligence and it is here that many IDMs are focusing their attention, in developing low power, low cost MCUs that meet the commercial and technical requirements of this emerging application space.

Mixed signal MCUs which also integrate wireless connectivity are already available, they will likely become more prolific in the future. However, for many applications, integrating the wireless connectivity may be less appealing than a two-chip solution, at least while the battle over which wireless protocol will prevail still rages. For this reason, perhaps, there is more activity around developing ultra-low power MCUs that focus on interfacing to ever smarter sensors.

Marking its entry into the MCU market, ON Semiconductor recently introduced its first mixed-signal MCU which focuses on applications that demand precision, as well as low power. ON Semiconductor recently acquired Sanyo Semiconductor and, with it, a portfolio of 8 and 16-bit MCUs. However, for its first in-house development, ON Semi chose the ARM Cortex-M3 32-bit core, which it has married with some mixed signal elements to create the Q32M210. It claims the device has been developed to target portable sensing applications that require high accuracy, predictable operation and the ever-present power efficiency.

ON Semi is more accustomed to developing custom ASICs rather than its own products, however through a number of other acquisitions it believes it has accrued the expertise necessary to address the needs of ‘niche’ applications, where precision is valued. It is the company’s experience in developing niche mixed signal products that forms its credentials, not least in the development of hearing aids that use highly accurate ADCs and a bespoke DSP technology.

The analogue front-end (AFE) used in the Q32M210 features dual 16bit ADCs and configurable op-amps, which result in a true ENOB of 16bits across the power supply range. This is enabled, in part, by an uncommitted charge pump that can be used to extend the operational lifetime of the battery supply. ON Semi claims the charge pump can be used to deliver a consistent 3.6V to the AFE, even when the battery supply has dropped to 1.8V. This could significantly extend the usable lifetime of any device empowered by the Q32M210.

The additional peripherals provide a USB interface, as well as LED/LCD drivers and push-button interfaces. Coupled with the programmable sensor interface, this positions the device as a system-on-chip solution for a range of applications and specifically portable medical devices, where its accuracy will be valued.

The AFE used in the Q32M210 is clearly intended to differentiate it from the competition, in terms of both accuracy and power consumption. However ON Semi isn’t the only device manufacturer to acknowledge the importance of mixed signal performance.

Information is shared by www.irvs.info

Piezoelectric fans and their application In electronics cooling

Piezoelectric fans seem to represent an example of research and development that has culminated in a product that is deceptively simple. Although piezoelectric technology is capable of producing rotary motion, the fans operate quite differently from rotary fans, as they generate airflow with vibrating cantilevers instead of spinning blades.

Piezoelectric, as derived from Greek root words, means pressure and electricity. There are certain substances, both naturally occurring and man-made, which will produce an electric charge from a change in dimension and vice-versa. Such a device is known as a piezoelectric transducer (PZT), which is the prime mover of a piezoelectric fan. When electric power, such as AC voltage at 60 Hz is applied, it causes the PZT to flex back and forth, also at 60 Hz.



The magnitude of this motion is very tiny, so to amplify it, a flexible shim or cantilever, such as a sheet of Mylar, is attached and tuned to resonate at the electrical input frequency. Since piezoelectric fans must vibrate, they must use a pulsating or alternating current (AC) power source. Standard 120 V, 60 Hz electricity, just as it is delivered from the power company, is ideal for this application, since it requires no conversion.

[If direct current (DC), such as in battery-operated devices, is the power source, then an inverter circuit must be employed to produce an AC output. An inverter may be embodied in a small circuit board and is commercially available with frequency ranges from 50 to 450Hz.]

Driving the fan at resonance minimizes the power consumption of the fan while providing maximum tip deflection. The cantilever is tuned to resonate at a particular frequency by adjusting its length or thickness. The PZT itself also has a resonant frequency, so the simplistic concept of adjusting only the cantilever dimensions to suit any frequency may still not yield optimum performance. (Conceivably, tuning the electrical input frequency to match existing cantilever dimensions may work, though with the same caveat, that the resonant frequencies of all the components must match, within reason.

Applications for piezoelectric fans are just in their infancy and could really thrive through the imagination of designers. This article, which originally appeared in the April 2011 issue of Qpedia (published by Advanced Thermal Solutions, Inc. and used with permission here) explores the principles, construction, implementation, and installation of piezoelectric fans.

Information is shared by www.irvs.info

Benchmark automotive network applications

After establishing the first hardware for MOST25 technology, the release recommendations were introduced. This method was used to investigate and validate new products according to the requirements for automotive applications. In order to have a common basis for this work an application recommendation was written and released. Nevertheless, this approach also realizes some of the principles of robustness validation. Within the MOST community this approach is well proven, and mandatory not only for the German car manufacturers but for others as well.

Benchmarking
After having some experience with different products coming from diverse manufacturers, the concept of benchmarking was introduced. The goal of this method is to compare products with functionality with the best performance. The definition of best performance is based on the requirements for the automotive application. The challenge of this approach is that all relevant aspects are taken into account. In the relationship between these different limits is shown below.



Information is shared by www.irvs.info

Combining FPGAs & Atom x86 CPUs for SBC design flexibility

Field Programmable Gate Array (FPGA) technology has been a useful design resource for quite some time and continues to be a mainstay because it delivers many of the same benefits of x86 processor architectures.

The various common advantages include multifunctionality, a healthy and broad-based ecosystem and a proven installed base of supported applications. Combining x86 processor boards with FPGA-controlled I/Os expands these benefits even further, allowing dedicated I/Os to support a wider range of application requirements.

Employing next-generation x86 processors with FPGAs onto a single hardware platform provides the ability to eliminate chipsets so that different areas of applications can be built on the same platform requiring only the exchange the IP cores.

New x86-based embedded computing platforms combined with FPGAs enable a new realm of applications – providing highly adaptable feature options for designs that have previously been restricted due to lack of interface or I/O support.

By understanding the collective advantages of this approach, designers can reduce Bill of Material (BOM) costs and maintain long-term availability with legacy interfaces and dedicated hardware-based I/O. Further, legacy systems now have a bridge to tap into the latest processor enhancements such as graphics media acceleration, hyperthreading and virtualization for greater success in matching exacting requirements.

This is a significant advancement in bridging newer technologies with older systems implemented in military, industrial automation and manufacturing environments.

Blending x86 and FPGAs for adaptable design options

Most x86 architecture designs are paired with a chipset, usually a two-piece component with a specific set of integrated features. Ethernet, memory control, audio, graphics, and a defined set of input/output interfaces such as PCI, PCI Express, SATA , and LPC are routinely integrated options.

However many of these chipsets are moving away from the legacy interconnects (e.g., IDE and PCI) commonly found in deeply established environments such as military, industrial automation or manufacturing systems for safety and operations.

As a result, these industries have not been able to take advantage of processor advancements and subsequent improvements in power and performance.

The availability of new x86 processors in combination with an FPGA presents an entirely new design approach that virtually take away embedded limitations from a predetermined feature set. These capabilities distinguish the Intel Atom E6x5C processor series as a milestone in x86 technologies, and a departure from using a chipset with a fixed definition.

Instead the Intel Atom E6x5 processor is combined with a flexible and programmable Altera FPGA on a single compact multi-chip module. By incorporating PCI Express rather than the Intel-specific Front Side Bus, the FPGA is connected directly to the processor rather than to a dedicated chipset, resulting in maximum flexibility and long-term design security.

Designers further have ready access to increased performance integrated into smaller form factors that offer very low thermal design power (TDP).

Because the FPGA can be programmed to support modern as well as legacy interfaces, OEMs now have a workable migration path from non-x86 to x86 architectures – enabling slower moving technology-based market applications to progress to next-generation processing technologies.

Cementing this approach as an appealing long-term design solution, Loring Wirbel of FPGA Gurus estimates that the CAGR for FPGAs will continue at a strong 8.6 percent which will put the FPGA market at US$7.5 billion worldwide by 2015.

Information is shared by www.irvs.info