Micaela Serra

Hardware/Software

Codesign

What is Hardware/Software Codesign?

I do not intend to give a whole course on this topic on a single Web page. However here are a few thoughts to get you started. A tutorial introduction will follow.

Hardware-software codesign is a recent research area growing mostly from hardware synthesis and mainly focused to facilitate the design of small embedded systems (now, what is meant by and "embedded system"? see below). Codesign methodologies, implemented as new "types" of CAD tools, are intended to give relief to designers struggling with provisional divisions of hardware and software components, and the attendant integration problems. Their purposes include:

Hardware/Software (HW/SW) co-design can be defined in many ways depending on which aspect is emphasized. The description includes all of the following:

Typically developers approach system design in two separate stages; software design and hardware design. As illustrated in the figure below, the specification is divided into hardware and software portions early in the design process.

This often leads to difficulties when integrating the entire system at the end of the process by finding incompatibilities across the boundaries. As a consequence, it can directly impact the product time-to-market delaying its deployment. Most of all, this design process restricts the ability to explore hardware and software trade-offs, such as the movement of functionality from hardware to software and vice-versa, and their respective implementation, from one domain to other and vice-versa.

Hardware/Software co-design attempts to integrate the hardware and software paths by envisioning a common platform, and by increasing the possibility of interaction between the hardware and software development. The interaction focuses on keeping the software and hardware spaces unified at all times as much as possible, as illustrated in the figure below, to avoid a sudden complete integration in the last phase.

Hardware/Software co-design attempts to integrate the hardware and software paths by envisioning a common platform, and by increasing the possibility of interaction between the hardware and software development. The interaction focuses on keeping the software and hardware spaces unified at all times as much as possible, as illustrated in the figure below, to avoid a sudden complete integration in the last phase.

The co-design of HW/SW systems may be viewed as composed of four main phases as illustrated in in the side diagram:

  1. Modeling
  2. Partitioning
  3. Co-Synthesis
  4. C-Simulation

Modeling involves specifying the concepts and the constraints of the system to obtain a refined specification. This phase of the design also specifies a software and hardware model. The first problem is to find a suitable specification methodology for a target system. Some researchers favour a formal language which can yield provably-correct code. But most prefer a hardware-type language (e.g., VHDL, Verilog), a software-type language (C, C++, Handel-C, SystemC), or other formalism lacking a hardware or software bias (such as Codesign Finite State Machines). There are three different paths the modeling process can take, considering its starting point:

  • An existing software implementation of the problem.
  • An existing hardware, for example a chip, is present.
  • None of the above is given, only specifications leaving an open choice for a model.

It is important for existing tools to support all three paths considering different efforts in development is required in each path. In the current EDA market, there is still a lack of tools that can support all three design starting points. It is still inexistent a model or a language that handles all possible implementations the design can have forcing the designer to acquire multiple tools.

Partitioning identifies the parts in the model which are best suited in hardware software given constraints such as time, size, cost and power. Recent reports indicate that automatic partitioning is currently making little headway, and that researchers are turning to semiautomatic "design space exploration," relying on tools for fast evaluation of user-directed partitions.

Co-synthesis uses the available tools to synthesize the software, hardware and interface implementation. This is done concurrently with as much interaction as possible between the three implementations. Hardware synthesis is built on existing CAD tools, typically via VHDL or Verilog. Software synthesis is usually in any high level language. Codesign tools should generate hardware/software interprocess communication automatically, and schedule software processes to meet timing constraints (see also the diagram at the top of the page). DSP software is a particular challenge, since few good compilers exist for these idiosyncratic architectures. Retargetable compilers for DSPs, ASIPs (application specific instruction processors), and processor cores are a special research problem.

Co-simulation executes all three components, functioning together in real time. This phase helps with the verification of the original design and implied constraints by verifying if input and output data are presented as expected.

Although this system flow is suited for co-design, it still shows some pitfalls in the process. If a new partition is necessary during iterations, then modification to the interface is required. This is very challenging and time consuming for developers, for example, changing details of a driver for a bus interface. This type of modifications is usually not supported by existing tools and is left to the competence and experience of the designers. One challenge that faces researchers is the difficulty of reasoning about codesign in an abstract sense; the range of application domains is simply too wide. Thus, a modeling language that was useful, say, for communication systems, might be unattractive for controllers. Similarly, the partitioning problem may require assumptions about the nature of available hardware options, and this would certainly vary widely among applications. This reality has been reflected in two steps taken by many strong researchers in codesign. They have chosen a particular application domain on which to focus their work, and they have forged links with industrial partners who design families of related products within that domain. Pursuing this strategy, one can focus on direct research into the realm of "data-dominated" or "control- dominated" areas, especially as applied to embedded system design.

What is an embedded system?

Any item including a programmable device, not intended to be general purpose, with many interface units to measure, control, manipulate the external environment.