Over the years, embedded systems designers have used different approaches to design systems in ways that optimize and customize hardware to fit the specific requirements of the application they're developing. Broadly speaking, these approaches fall into three categories:
• Processors , where the behavior of the device is defined using software programming languages, and the target is a processing engine that interprets and executes the instructions. Examples include microprocessors, microcontrollers, and DSPs.
• Configurable hardware , where the behavior of the device is defined using hardware description languages, and the target is a set of general-purpose functional resources that can be functionally configured but not physically changed. Examples include FPGAs and PLDs. The functionality is set at power-up (field-binding).
• User-specified hardware , where the engineering team creates custom physical silicon to implement the target device. This ranges from a minimal effort such as a gate array to a fully-customized device with handcrafted features. The functionality is set during manufacturing (fab-binding) and is immutable.
All three of these categories are well suited for different types of designs and all have evolved over time to take advantage of the capabilities available with new semiconductor technology. What hasn't always evolved so gracefully are the design methods and tools.
Among other things, each category has evolved its own unique set of design tools and design flows. Although there have been efforts to smooth the often significant differences between them–for example the development of C-language extensions such as Handel-C and SystemC in FPGAs–these domain-specific tools and methodologies often work at cross purposes in an integrated development environment.
This trend has accelerated as more gates have become available through programmable logic, and embedding processors into ASICs and SOCs has become straightforward. Thus it appears likely that the next generation of hardware will be increasingly programmable, blending processors and configurable hardware. It is also likely that it will become a dominant factor in custom ICs, much as programmable logic became pervasive starting 20 years ago.
The next step: software defined silicon
Given this trend, it may be the time to take the next evolutionary step in hardware design and in the tools to support them: a software-defined silicon (SDS) architectural approach that does more than just smooth over the discontinuities and provides a common design flow that is largely software driven and uses familiar software development paradigms.
Although SDS may initially sound too blue-sky and unrealistic, when you analyze existing designs what emerges is that nearly all “hardware” has some software components. Ranging from simple state machines to embedded software processors, an instruction-set type of control machine lives in most custom devices. Software has made these inroads into hardware because software is substantially simpler to modify, update, and maintain–key requirements in complex systems moving forward.
The SDS approach takes this software-oriented approach to the logical next step. It is based on a multicore array processor architecture built around the concept of communicating sequential processes.
The processors used in each element of the array are general purpose in the sense that they can execute conventional sequential programs. However, when used in concert, they form a general purpose concurrent architecture with hardware resources for scheduling a collection of concurrent processes and for performing synchronization, communication, and input-output tasks.
This approach allows the description of systems in terms of component processes that operate independently and interact with each other solely through message-passing communication. It allows component processes to be defined both as sequential processes and as the parallel composition of more primitive processes.
A software-defined silicon architecture based on communicating sequential processes makes it possible to build efficient multicore chips scaling to hundreds of processors. Concurrent processing, communications, and input-output are supported directly by the instruction set of the cores and by the protocol used in the on-chip interconnect.
Importantly for the embedded systems developer, this approach supports a variety of programming techniques, ranging from statically configured process networks to dynamic reconfiguration and mobile processes.
Concurrent programs are compiled directly to the processor instruction set; no kernel is needed and no microcode is used in the processor implementation. The cost of communications, synchronizations, inputs, and outputs is reduced to that of loads, stores, branches, and arithmetic.
Perhaps the most important aspect from the developer's point of view, this approach offers a new way to construct programmable and configurable systems based on software design.
In contrast to an FPGA, which has an array of look-up tables that communicate via a statically configured interconnect, such a multicore architecture has an array of processors that communicate via a dynamic message routing network.
In the SDS approach, each processing unit or tile needs just four key components; the processor, some local memory to hold the instructions and data, an I/O structure that can handle physical interfacing, and a communications infrastructure that handles interthread and intercore communications. (Figure 1.)
The I/O processing functions in particular are the last stronghold for custom logic. However, once a processor is capable of implementing interfaces, nothing stops entire systems being translated into a software image running on vanilla silicon.
It's in this area that the processing units used in SDS differ from traditional embedded processors. I/O interfaces require the processors to be capable of responding to hard real-time events occurring on pins. The designer needs to be able to guarantee that the software will service the I/O pins no matter what other software is running. For this to be achieved, intelligence needs to be added to I/O, as shown in Figure 2.
From an architectural perspective that means the design needs to ensure that latency between pins and processor is kept to an absolute minimum and that determinacy can be guaranteed. Implementation of multiple interfaces in software raises another challenge, that of parallel programming. The software must be capable of switching context fast enough to allow multiple tasks to run effectively simultaneously.
Translating source code into object code
This approach clearly will use an embedded software design flow. However, we shouldn't be too hasty to discard the collective knowledge surrounding hardware description languages (HDLs). HDLs have served our industry well and have evolved substantially from their origins. Perhaps most importantly, they have taught us that we can trust design tools to translate our high-level definition of functions into the low-level manufacturing details.
When logic synthesis first emerged it required a large leap of faith to go from trusted schematic symbols with their underlying transistors to the mysterious “netlist.” Those days are long past and designers have reasonably good faith that their design intent will migrate into the target device.
There is, however, a fundamental problem with describing hardware. To achieve reasonable results in a target device, it's often necessary to embed substantial “understanding” of the silicon details in the definition of the functions.
This embedding is required so the tools can be guided into the best choices amongst many, avoiding certain known-bad results. This handcrafting requires substantial expertise and means that the design object will be flavored with the characteristics of the presumed target. By this definition, HDLs are not really “description” languages per se ; they are used much more to guide the actual implementation.
Making HDL definition more like software compilation
Although software designers have been using the tools of their trade for as long as hardware engineers have used their own tools, these two sets of tools have evolved along different paths. Because the target of a software program is a well-understood and well-constrained machine, the process of translating the design intent (source code) into the device instructions (object code) is reasonably straightforward and well understood.
Another very interesting side effect of the differences between HDL processing and software compilation is that the HDL must pass through synthesis, fitting, placement, and routing before a target is formed.
Each of these steps is quite long compared with compilation, and myriad equivalent results can emerge, the selection depending on any number of random variables or events. Contrast this with software compilation that is typically a single-pass process that's extremely efficient in terms of computing resources and time. (Figure 3)
An interesting thought exercise is to consider how changes in a module can affect the rest of the design. The changes are especially important to understand because custom silicon is all about incremental (and often last-minute) modifications to merge reality with the marketing specification.
An HDL-based design that targets a sea-of-gates (FPGA, gate-array, ASIC) will be forced to make tradeoffs between device resources based on the changes in the design. Even if a module is fully isolated in terms of synthesis to a netlist, the placement and routing process will commence a series of tradeoffs that will affect the balance of the otherwise untouched design. The result is the well-known challenge of timing closure after minor design changes.
Now consider the programmable device that is based on a processor. Code modules are generally self-contained and well-behaved in terms of changes and impacts on the rest of the design. For example, changes in a code module cannot affect other code modules in terms of silicon utilization–that is because the essential nature of a processor is that the gates are intended for reuse by all of the opcodes.
There are no tradeoffs per se ; the entire design phase of “fitting or place & route” is replaced by the temporal time-slicing nature of a processor and a program counter, making a design based on a software-flow and a processor architecture more resilient to changes in the design.
It seems to be a universal rule that there will be changes, there will be unexpected results, and marketing will require changes mere moments before a product has to ship. These factors favor a software-based approach.
Verifying hardware design
Once the target netlist or object file is created, it's usually simulated with an appropriate set of stimuli and expected results so that an automation tool can “probe” the design to verify functionality.
In addition to simulating and debugging, it's standard practice to evaluate the design by putting it into the target device. In the case of an FPGA, that's a fairly simple process, supported by ample hardware. If the design is for a gate array or ASIC, there is an NRE and manufacturing-time price to pay. That means relatively little iteration is done with the HDL as it is expensive to evaluate accuracy in the actual target device. The goal of “first time right” silicon is imperative, but it's usually a “best attempt” constrained by time and budgets.
Compare that with the process of loading a software object file into the target processor and allowing it to execute the code. It may even be able to self-evaluate the code with other concurrent applications that act as stimulus and analysis engines.
Software-based designs that target a processor are inherently more stable than HDL-based designs that target gates for the following reason: the compiler has a few hundred opcodes and a few hundred variables to consider. A tiny 50K system-gate FPGA has half-a-million configuration bits. And those bits are not exclusive, so the possible combinations are exponential. And a custom ASIC has as many options as there are atoms.
Add to this the massively higher number of designs that go through software compilers and collectively add to the debugging process of the compiler. For these two factors alone, software compilers are inherently more stable and reliable than an HDL flow. This is no comment on the engineers who develop the EDA tools; they are some of the very best software authors and architects–it's just that they're pushing a much bigger rock up a much bigger hill.
Learning new tricks
Moving to a world where systems are constructed using software images running on vanilla silicon is feasible and should help speed up development cycles, reduce development costs, and improve the flexibility and maintainability of designs.
So, a software approach to system design is desirable on a number of levels. For some time, there have been efforts to adapt programming languages for use as hardware description languages, the “C to gates” flows.
Many designs originate as C-based descriptions for basic evaluation, so it's natural to want to migrate that model into the actual silicon through an automated process. The problem is that programming languages like C do not contemplate events or timing in a way that's meaningful to integrated circuitry with its inherent parallelism. It's a case of trying to use a well-bounded tool for an ill-suited job
Simply using a software-based flow is not sufficient to provide the efficiency and flexibility demanded by the engineers building electronic systems. It's also necessary to give the engineers an efficient instruction base and the correct silicon architecture. These will be the topics of future articles on Embedded.com.
Richard Terrill is the executive vice president of marketing at XMOS. Prior to XMOS, he was vice president of marketing at Velogix, and, at Xilinx, was responsible for worldwide strategic marketing. He has held senior management positions at Lightspeed, Cadence, and Altera. He was a founder of RAPID, the IP business advocacy organization and was a corporate representative to the VSI Alliance. Terrill has a BS degree in physics from Rensselaer Polytechnic Institute. He may be reached at .