Co-Design for SOCs -> Executable models key to flexible design

"Concurrent engineering" and "design reuse" are the hot buzz words for embedded system design. To meet the time-to-market pressure, different sections of a system-on-chip must be designed by several teams working in parallel, and everything that can be reused efficiently should be. Those two objectives have important implications.

First, the top-level specification must be converted into an executable model that can be validated and refined. Also, intellectual property (IP) models must be linked to the executable model at the appropriate level of abstraction. In addition, the implementation model-including hardware, software and the interfaces between-must be derived from the executable model. In short, the goal of codesign is to generate a hardware/software architecture from a global specification.

On the system side, the top-level specification is usually a loose structural description involving abstract blocks. These may include a process defined using a programming language, an existing function or IP described at various levels of detail, or even a description of the environment itself, considered as a functional test bench.

It is unlikely such a structure can be described using a single language. Having multiple languages makes communication between blocks difficu lt to describe. One of the goals of the System Level Design Language (SLDL) initiative is to provide a method for describing communication among blocks described using different languages.

The top-level description is a "concept," usually very far from the final implementation. Furthermore, many implementations can be derived from the same concept to meet different types of constraints, such as speed, power and cost. Before any real implementation work may be done, the designers must refine the specification by adding more implementation guidelines, until the detailed architecture to be built is defined.

Allocating different functions to different processors is a multiple-choice exercise: Several processors may be used, possibly from different types or categories (DSPs, controllers). Then, communication among them must be defined, and finally the different functions must be coded according to the chosen implementation target.

Each piece of software is scheduled and tuned to the spec ific processor on which it will run. The outcome of that step is scheduled C code, ready for compilation. The software part of the interface and communication function is included in the code. For example, for a processor to be usable in the Arexsys environment, one must provide a simple library of drivers covering basic memory accesses, a VHDL macro describing the processor's external interface and a cycle-accurate C model for cosimulation. The different hardware processes can be reorganized-split or merged-to optimize their implementation. That results in pieces of RTL code, ready for synthesis, including the hardware part of the interface and communication function.

Experienced system designers have a good view of what an architecture should be to solve the main issues of a particular application. However, even with an architecture in mind, converting initial specs to a description that can be implemented is a tedious, time-consuming and error-prone task.

In most cases, the amount of wor k to be done prevents designers from evaluating variants or finding more innovative solutions when initial results are not far from expectations. The limiting factor is not imagination, but a lack of resources and time to explore and validate new, better ideas.

With a complete hardware/software codesign tool such as the Arexsys solution, designers select a specific partitioning and the tools generate a detailed architecture that can be evaluated against the constraints or compared with a previous solution. The result of an architecture-exploration loop is a "virtual prototype" made of C code for the software part and VHDL/RTL code for hardware.

Each prototype can be compiled for a particular processor, synthesized to gates and cosimulated. The optimization loop is re-executed either from the architecture exploration step, by playing with different partitioning or communication options, or from the original model itself-for example, by experimenting with the way an algorithm is implemented.< /P>

When selecting a hardware/ software codesign solution, look for a tool that accepts consistent descriptions, using standard languages, throughout the refinement process. Also, there are several other important considerations.

First, the specification environment must support the use of several languages for describing both the subsystem being designed and its environment (including, for example, IP that will be included in the final implementation when it is known). Typically, System Design Language (SDL) commands should be used to describe the subsystem to be designed, while C and VHDL are used for software and hardware IP, respectively. Some other languages (Cossap, Matlab, Saber) can be used to describe parts of the environment.

It is also useful to develop your application at a high level using a high-level design methodology appropriate to your market and application. For example, the SDL is an ITU standard, widely used in the telecommunication industry. It meets most of the req uirements of hardware systems: parallelism, distribution and high-level timing (synchronization), and is expressive enough to describe both continuous and discrete parts.

SDL has some restrictions, but in practice, all other languages that are candidates for system specification-C, C++ or proprietary languages- have even more.

Moreover, SDL provides formal semantics, enabling formal verification and test of system-level specifications. Also, the tools should allow you to perform extensive architecture exploration and intermodule communication synthesis. Architecture exploration is based on process splitting, process merging and process binding to hardware or to software. Communication synthesis is based on a user-extensible library of communication protocols.

Finally, the design options should make room for both C and VHDL in the generation of an architecture implementation. The C code is a result of the combination of the code delivered by the architecture-generation tool and the C code present in the initial system specification.

This resulting C code is low-level and completely scheduled, with no real-time operating system required. The VHDL code is clean and readable at the RT level, ready for logic synthesis.

The ability to do cosimulation of hardware and software subsections is important also. That is a way to functionally verify the hardware-software interface. And, verification is essential, especially since that interface is often at the origin of integration bugs and this can lead to considerable overruns in costs.