Embedded system engineering magazine 2006.05,06

I/O and Interfaces

EMBEDDED SYSTEMS designers are constantly under pressure to boost the execution speed their applications. One common solution has been to ramp up the clock speed of the system processor, but this

usually results in increased power consumption. Additionally, memory performance has not kept pace with processor technology, and this mismatch limits any significant gains in system performance. Consequently the higher-frequency approach is leading to diminishing returns.

The execution pipeline of a traditional singlethreaded processor will stall for many reasons

The key to squeezing the maximum performance in such a design is controlling the way the threads are executed in the pipeline, and so the various threads are scheduled into the execution unit for maximum efficiency. When one thread stalls waiting for memory, the next thread is introduced to ensure that the processor's execution unit is as busy as possible.

Technology

The 34K core family uses a nine stage execution pipeline coupled with a small amount of hardware to handle the virtual processing elements (VPEs) and the thread contexts (TCs), as illustrated in figure 1.

Each thread has its own dedicated hardware, called the thread context (TC). Since the context of each thread is always available, the core can switch between threads on a clock-by-clock basis to keep the pipeline as full as possible. This approach eliminates the massively cycle-ineffi- cient overhead which would otherwise be caused by context switching between threads. Each TC has its own set of general-purpose registers, a PC (program counter) that allows a TC to run a thread from a complex operating system such as Linux. A TC also shares resources with other TCs, particularly the CP0 registers used by the privileged code in an OS kernel.

The set of shared CP0 registers and the TCs affiliated with them make up a VPE (Virtual Processing Element). A VPE running one thread (i.e. with one TC) looks exactly like an independent MIPS CPU, and is fully compliant with the MIPS32 architecture specification. This allows two OS's to run side by side on a single core with no loss of efficiency – Linux plus an RTOS for example.

All threads (in either VPE) share the same caches, so cache coherency is not an issue. This

Figure 2: A dual OS Example: Residential Gateway supporting multiple VoIP channels

MANY HIGH-VOLUME applications benefit from ASIC technology. By tailoring the silicon exactly to the application, size and cost can be kept to a min-

imum. The ASIC approach has contributed so much to the cost-effectiveness of some products that it has made the difference between commercial success and failure.

However, these benefits are usually gained at the cost of versatility. If the design needs to be changed, it is probable that the ASIC will need to be “re-spun”, resulting in massive extra costs and delays in time-to-market. Until now, that is. New 6-pin microcontrollers now coming onto the market can provide cost-effective “electronic glue” in a very small space – enabling an existing ASIC to be used in a changed circuit.

The design process for an ASIC is complex and the combination of design, simulation and verification can often take over a year. Non-recurring engineering (NRE) charges are usually very high, so it is important to be confident that the application will sell in large numbers, so that these costs can be amortised. Long processing times in the fab, from the submission of the design to finished silicon, can delay the product reaching the market, and therefore reduce profitability.

Changes

One of the biggest risks with an ASIC is that the system design changes after the design has been finalised but before the silicon is delivered, or that the design changes only a short time into the end-product’s design life. These changes could

be caused by market fluctuations, a change in surrounding elements of the overall system, or even a whim of the marketing department. There is also the risk that, during the in-system validation of the ASIC, it becomes clear that the specification for one or more of the other components in the system are far from accurate. Of course, it is possible to redesign, resimulate, and reverify the ASIC, send in another NRE check, and then wait for the new design to come out of the fab, or a small microcontroller can be added to the ASIC board to correct the problem (see Figure 1).

For example, a microcontroller with internal oscillator, program memory, I/Os, an 8-bit timer and an optional comparator can cost-effectively correct a multitude of timing or data format problems.

Interfacing

A number of opportunities can be opened up by including a 6-pin microcontroller from the initial concept stages of an ASIC-based design. For example, if there is any uncertainty about the interface to another device or part of the system, using a 6-pin microcontroller can allow the design of the ASIC to continue without the risk of it not working when silicon is received. The microcontroller can then quickly be programmed to implement whatever interface specifications are finally needed.

Programmable board serialisation and authentication, or programmable I/O for different system configurations, can easily be provided by an on-board 6-pin microcontroller. The microcontroller can be used with comparators to

read sensors and could provide calibration and linearisation, so sensors from multiple vendors could be used. This can allow the purchaser to choose the sensor that provides the best value when purchasing decisions are made.

Field reprogramability

A microcontroller can also be used to enable an ASIC-based design to be re-programmed in the field. The features of a single, ASIC-based board design can easily be enabled or disabled, eliminating the need to stock different variants. The robustness of a 6-pin microcontroller could allow it to be used as a system watchdog timer, where if a sophisticated health check communication between the ASIC and the microcontroller fails for any reason, the microcontroller could reset the system, or put it in a known failsafe state.

Microchip Technology’s PIC10F20X 8-bit flash family of 6-pin microcontrollers can also extend the life of an existing ASIC-based design by adding new functionality and features without the need for a full re-design. The use of a small microcontroller can allow the interface to the ASIC to be changed, for example changing a

T

straints.

of software merge the sors with ASIC. Both are described

sion instructions, enabling developers to design "hardware as software" and resulting in reduced design complexity and faster time-to-market. This is achieved by accelerating performance through increased data parallelism, sufficient data bandwidth, and temporal parallelism.

"Hardware to software" enables developers to work within a single development flow that keeps design in a software development environment that is both well-established and familiar to developers. Instead of improving performance by hand-coding assembly or partitioning algorithmic code to an FPGA, for example, developers identify "hot spots" within the application. This enables the compiler to create an optimized configuration to be implemented in a programmable fabric and then treat it as it would any other instruction.

This is critical for evolving applications. With coprocessor-based architectures, development of hardware acceleration logic cannot begin until the algorithm has been completely designed in software. In effect, this reverses the traditional "hardware first, then software" design model. The only way to hardware-accelerate performance without completely undermining time-to- market is through concurrent software and hardware development as is possible with a soft- ware-reconfigurable architecture.

Acceleration through software

Being able to process multiple data concurrently with a single instruction is an essential mechanism for improving performance without having to increase clock frequency and corresponding manufacturing cost and power consumption. Softwarereconfigurable architectures are able to further increase efficiency by defining data size and format on an instruction-by-instruction basis. In this way, extension instructions can match data exactly,

lize them. As a consequence, data bandwidth directly determines the degree of data parallelism that is possible.

Pipeline

Temporal (pipelined) parallelism is the ability of an architecture to make optimal use of the instruction pipeline while executing multiple instructions simultaneously. Efficient temporal parallelism is only possible when hardwareaccelerated instructions share the same instruction decode unit and pipeline as standard instructions. When extension instructions are executed in a separate pipeline, such as is the case when an ASIC, DSP, or FPGA is used as a coprocessor, managing dependencies between standard and extension instructions becomes extremely difficult. Mechanisms to manage these dependencies increase instruction latency and undermine deterministic processing performance; developers must assume worst-case latency to simplify operation. Given that context data (i.e., intermediate results) must also be transferred to a coprocessor with data, processing and bandwidth inefficiencies are also introduced.

With a shared pipeline, context can be passed with a pointer to shared memory or, for zero overhead, stored in state registers persistent from extension instruction to extension instruction. Dependencies can also be managed by the pipeline, minimizing latency. Because such latency is now deterministic, it can be accounted for optimally by the compiler.

Because the pipeline is shared in a softwarereconfigurable architecture, extension instructions implemented in programmable logic are described in the same high order language (i.e., C/C++) as unaccelerated application code in the same format. This is the foundation of the "hard-