Is SDS a leap of faith for designers?

14 May 2008

A new class of programmable semiconductor architecture called SDS (software defined silicon) can deliver programmable flexibility using embedded software and IP

For many years, software has been playing an increasingly important role in embedded systems design. From the process of defining and describing the underlying hardware platform, to the user interface and application levels, code now accounts for a high proportion of the engineering value and differentiation of any product.

The result has been a complex interplay between the roles of hardware and software, and tension between hardware designers and software programmers. It seems that the days when every chip was a full-custom device that implemented all of its functions in hardware with its functionality set during manufacturing (fab-binding), are in the past.

At the other extreme, processor-based architectures with a device whose behaviour is determined via a conventional program written in a high-level language, have also metamorphosed into SoC devices with a programmable core, surrounded by hardware particular to the required function.

Straddling the gap between ‘programmable’ and ‘hardwired’ are configurable solutions (such as FPGAs). They deploy a set of general-purpose hardware resources that can be functionally configured, but not physically changed. A hardware description language is used to describe the required behaviour, and the functionality is set at power-up (field-binding).

Whichever approach is used, nearly all hardware today has some software component and this is because designers recognise that software is simpler to modify, update and maintain. These are key requirements in times that are characterised by cost pressures and narrow market windows.

SDS architecture
This duality makes it increasingly difficult to create consistency and integration in the design flow. Despite developments such as SystemC that attempt to span the hardware and software domains, each type of design largely retains its own set of design tools and methodologies. One solution to this problem is to take an evolutionary step forward to an SDS architectural approach that provides a largely software-driven design flow and which uses familiar software development paradigms.

The physical implementation of SDS is based on a multi-core array processor architecture. Conceptually, such a structure can be seen as implementing a large number of independently operating sequential processes. Communicating by message passing, the array can be configured to efficiently execute functions as a parallel composition of primitive processes, or as a sequential composition of sequential
operations.

An SDS architecture requires hardware resources for process scheduling, synchronisation, communication and inputoutput tasks. Although the instruction set of each core must provide facilities for the same concurrent processing, communications, and I/O functionality, the message-passing basis of communication maintains the independence of each primitive process and makes it possible to build efficient multi-core chips scaling to hundreds of processes. The cost of concurrency is effectively reduced to support for load, store, branch and arithmetic operations.

One of the advantages of an SDS approach is that it supports a variety of programming techniques, ranging from statically configured networks to dynamic reconfiguration and mobile processes. Concurrent programs are compiled directly to the processor instruction set with no need for an OS kernel or microcode in the processor.

Tiles versus FPGAs
Each XMOS processing unit (or tile) consists of a processor, local instruction and data memory, an I/O structure to handle physical interfacing, and a communications infrastructure that manages inter-thread and inter-core communications (figure 1). The result is an array of processors that communicate via a dynamic message routing network. Consider this approach in comparison to that commonly used in an FPGA which consists of an array of look-up tables communicating via a statically configured interconnect.

The I/O processing functions are particularly important in the SDS structure. It is these that allow entire systems to be translated into a software image running on ‘vanilla’ silicon, and it is in this area that the processing units used in SDS differ from traditional embedded processors. In order to implement I/O interfaces, the processors need to respond deterministically to hard real-time events occurring at the chip’s external pins. This has to be achieved despite other software that may be running.

In turn, this requires the I/O to contain enough intelligence so as to minimise the latency between the pins and the processor (figure 2). Implementation of multiple interfaces in software also raises the challenge of parallel programming. The software must be capable of switching context fast enough to allow multiple tasks to simultaneously run effectively.

Speaking the same language
Although the SDS approach clearly lends itself to the use of an embedded software design flow, it is important to realise that this does not mean discarding the considerable fund of knowledge and technology that has been built-up surrounding EDA tools and HDLs (hardware description languages). In particular, standard programming languages like C do not deal with events or timing in a meaningful way in the context of integrated circuitry with its inherent parallelism.

However, it is undoubtedly desirable that hardware design should become more like software compilation. This is true for several reasons. First, compiling a C program with a few hundred variables to a target processor with a few hundred op-codes is an inherently predictable process, with a limited number of ‘correct’ answers. In contrast, even a small 50k system-gate FPGA, which has half-a-million (mostly independent) configuration bits, offers an enormous range of possible combinations. Furthermore, a full custom ASIC has even more options.

Along with this ‘embarrassment of riches’ for the hardware designer comes the need to embed an understanding of the target device within the description of the design intent. This is used to constrain the tools to consider only the known best choices, and avoid known-bad implementations.

Complex steps
Software compilation is also a much shorter process than HDL processing. Working from an HDL requires synthesis, fitting, and P&R (placement and routing) before the first-pass target silicon is defined. Each of these steps is at least as complex as the entire software compilation process. As a result, many equivalent results can emerge.

Indeed, the software-based flow appears to have an advantage when it comes to making incremental modifications to the design. In the HDL approach, even if a module is fully isolated in terms of synthesis to a netlist, design changes can trigger a whole new set of trade-offs within the P&R process. These can include re-establishing timing and power closure after design changes.

In contrast, the programmable device paradigm replaces the P&R process with the temporal time-slicing effect of a processor engine and program counter. In this case, self-contained program modules have limited potential to impact other parts of the design, and there is no fundamental need for any manner of trade-offs.

It is more than 20 years since hardware engineers embraced logic synthesis and learned that design tools can be trusted to translate high-level definitions of functions into the low-level manufacturing details. Today’s embedded designers are preparing to take a similar leap of faith. SDS architectures can allow them to move closer to the software engineering paradigm of a straightforward, compiler-style translation of design intent into device instructions. However, simply using a software-based flow is not enough. The key will be the deployment of a combination of the right silicon architecture with a carefully designed instruction set and a flexible set of tools. Only vendors that can offer all three can expect success as hardware and software converge.

RICHARD TERRILL is executive vice president of marketing, XMOS Semiconductor


Contact Details and Archive...

Print this page | E-mail this page