With the ability to mix processors, complex peripherals, and custom hardware and software on a single chip, full-system design and analysis demands a new methodology and set of tools. The Felix initiative, headed by Cadence Design Systems' Alta Business Unit, has brought together a group of system, semiconductor and software vendors to develop that methodology.

Creating systems-on-silicon in a timely fashion will require design reuse-of both hardware and software-on a large scale. Clearly, there are many challenges in the implementation of these large chips. But at the system level, there are equal challenges in the definition of features and their cost-effective implementation on an architectural platform.

We believe that Behavior-Architecture codesign, which is the selection of features and of the architectural platform to implement them, is the right level of abstraction to begin system design. The task of partitioning the design into hardware and software, called Hardware-Software codesign, should be determined and guided by the decisions taken at the behavior-architecture codesign level.

This view of system design has brought together into Felix such systems companies as Ericsson, Magneti-Marelli, National and Motorola; semiconductor companies like Motorola, National Semiconductor, ARM, and SGS-Thompson; and software companies like debis Systemhaus. The purpose of the initiative is to facilitate and apply the principles of Behavior-Architecture codesign.

Specifically, the initiative seeks to define a complete design methodology from this level of abstraction to implementation. It also aims to develop an environment consisting of design-entry mechanisms, design languages, synthesis and analysis tools including simulation, various forms of formal verification, and hardware and software synthesis. Further, it seeks to create a set of modeling principles to guide the development of models at the appropriate levels of abstraction, with precise accuracy and execution-speed tradeoffs.

The role of Ericsson, Magneti-Marelli, National Semiconductor, and Motorola is to help define and tune the system-design paradigm, and the role of ARM, debis, National Semiconductor, Motorola Semiconductor and STMicroelectronics (formerly SGS-Thomson Microelectronics) is to create intellectual-property (IP) blocks and their models for system design.

Meanwhile, the role of the Alta Business Unit of Cadence is to firm up the design methodology, based on the inputs of the Felix initiative partners, and to develop the environment and the tools that support the methodology. The Business Unit is backed by Cadence Laboratory scientist and Politecnico di Torino Professor Luciano Lavagno, and by UC Berkeley Professors Alberto Sangiovanni-Vincentelli and Jan Rabaey.

Many concepts in the Felix initiative were pioneered by the Polis research project, which was started in 1988 by UC Berkeley, and supported by Magneti-Marelli. The Politecnico di Torino, Cadence Berkeley and European Labs (http://www.cad.eecs.berkeley.edu/Respep/Research/hsc/abstract.html) joined later. Using automotive electronics as the design driver, the Polis project developed a formal behavioral model based on a network of communicating entities called Codesign Finite State Machines (CFSMs) that are independent of hardware and software.

The user can map each CFSM to an implementation in either hardware or software, estimating the performance to evaluate that particular mapping. Finally, a hardware or software implementation, including the RTOS, can be synthesized. The Polis hardware architecture was limited to a single microprocessor. These concepts have been embraced by the members of the Felix initiative, who have extended them to cover a wider set of applications, including communications and consumer electronics, with more emphasis on design reuse, and with richer sets of architectures such as multiprocessor systems, including DSPs.

In 1997, COSY — an Esprit Project of the European Community — was funded, with the participation of the Cadence European Labs, the Cadence Alta Business Unit, Philips, and Siemens. The goal of the COSY research project is to apply the design methodology to a class of new, advanced designs in the consumer electronics and industrial electronics domains, and to assess its benefits. The basic tenets of the design methodology were presented and discussed at a System Design Workshop held in Rome in November 1997.

The designer of the complete system must focus on the behavior of the system, and then find or establish an architecture. Short product life cycles and customization to niche markets force the system designer to reuse not just building blocks, but architectures as well. These reused architectures, or platforms, are the basis for a cluster of products that may differ in software features, regulatory standards, or language specialization. New features for the target architecture must be analyzed to ensure that they have the right timing and still work correctly and with existing features.

The semiconductor designer focuses on efficient implementation of a reusable component or of a complete architecture, and then analyzes its appropriateness and efficiency for different applications or behaviors. Here manufacturing cost is often paramount. The prime directive is to achieve the right combination of processors, memory, and logic for efficient manufacturing. The analysis of how a new device can be used for a variety of end applications determines its market size.

In both cases, there is a need to bring the behavior from a system designer and an architecture from a supplier together so that the efficiency, cost, power, and responsiveness of the combination can be analyzed. For large blocks and software, we need a characterization method similar in effect to the way in which ASIC companies provide gate-level models and timing shells.

Each gate has a logic description, useful for both simulation and synthesis, and a timing description, useful for timing optimization and static verification. The Felix initiative is working on a way to describe the logical behavior of a large block separately from the timing or power architecture, so that we can map the behavior onto an architecture and then proceed with evaluation.

Today, behavior is described using a variety of techniques, including dataflow, C/C++, SDL, Esterel, and HDL. Basically, behavioral design is the capture of the executable-functional specification with the minimum of implementation artifacts possible. Behavioral design is inherently heterogeneous — no single specification meets the needs of all application areas. Most of the higher-level behavior-capture mechanisms describe the system at a transaction — or token-passing level, which is very appropriate for feature/behavior/algorithm design, but not so great for implementation.

Verification is a must at the pure behavioral level to verify such high-level questions as algorithmic appropriateness, which involves filtering out enough noise or correctness, for example, and handling a cell-handoff correctly with your protocol. Reliability issues — like deadlocking when you distribute your algorithm — are also important.

Today, architecture is usually mixed into the behavioral design, sometimes in an implicit way, as in the size of a queue or a shared bus. A separate description of an architecture is not necessarily executable, but is a definition of the important architectural artifacts: computational, communication, and organizational.

Computational artifacts include processors, complex hardware IP, and complex software IP. Communication artifacts are buses, memories, queues, and mailboxes in an RTOS. Organizational artifacts are purely for partitioning purposes, including software tasks and custom-hardware groupings that share a bus interface.

To analyze a specific behavior/architecture combination, we need to describe how the behavior will be implemented using the facilities available in the architecture. We call this process "mapping the behavior onto the architecture." Some behaviors are mapped to hardware, either to be synthesized or selected as a specific IP implementation. Some behaviors are mapped to software by assigning them to a software task or interrupt-service routine.

Communication between behaviors must also be assigned an implementation, perhaps using a hardware bus, an interrupt, polling, mailboxes, shared memory with semaphores, or other mechanism. It will almost certainly be necessary to refine the large tokens/transactions from the behavior-level design down into bite-sized pieces that can be carried by the lower-level architectural communication resources.

Once a behavior has been mapped onto an architecture, then a new set of verification and analysis tasks must be performed. Initially for our behavioral simulation, we use an abstract notion of time, assuming an infinitely fast reaction to events. When we map onto an architecture, our behaviors will be annotated with real or estimated delays, based on how they will be implemented. A behavior mapped to software will have two different types of delays: its own (estimated) computation time and the delays caused by sharing a processor with other behaviors and an RTOS.

Similar architectural delays occur in hardware and are the result of mapping large tokens onto narrow buses. This is similar to the computation time of software. They also occur in getting access to a shared bus, like the delays caused by sharing a processor.

Meeting throughput, reaction time, and latency requirements call for a verification step using the mapped behavior annotated with architectural delays. At this behavioral level we will have estimates rather than cycle-accurate delays. These estimates are not good enough to write test programs, but can be extremely useful in making the high-level choices of what is in hardware as opposed to what is in software; how to architect the software in terms of number of threads; and which RTOS to choose.

Analysis using parameter sweeps is an excellent way to understand how sensitive the behavior and/or architecture is to changes, and how much slack is available for adding features in derivative products.

After the designer is happy with the mapping of behavior onto architecture, it is time to start producing the final implementation. Much of the hardware implementation can be reused from previous designs, including processors, bus interfaces and protocols, and large blocks such as MPEG decoders. Similarly, on the software side the RTOS, device drivers and large blocks of code — like protocol stacks — can be reused. The glue between these blocks is what needs to be created.

Quite a bit of glue is created during the mapping from behavior onto architecture. In many cases, the larger transactions used in behavioral design have already been refined into a protocol of smaller transactions appropriate to our architecture. This type of communication refinement can be done using, for instance, the CFSM concept from Polis, allowing us to synthesize either a hardware or software implementation.

Creating an implementation for a system requires extra information that was not needed in our original mapping. Detailed memory maps and exact interrupt vectors are important for implementation, but are not necessary for performance analysis.

Once the extra information has been added to our mapping, we can start to generate hardware and software implementations. The results of the implementation will be in four major groups:

• The main program for each processor, including RTOS setup and hardware initialization.

• The code for each task and interrupt routing, with the correct device driver and communication code inserted.

• The top-level hardware netlist, expanded from the architecture diagram to include all bus wires, bus-interface logic, and instantiations of all complex blocks.

• The HDL code for each block generated with both references to reused blocks and the synthesized implementation of glue logic.

By separating the behavior and architecture, we enable their co-evolution. Unique requirements of the behavior will require changes in the architecture. Cost considerations within the architecture may imply behavioral modifications. Keeping implementation neutral and allowing the independent mapping of behavior onto architecture is essential to good system design and is the essence of what has been termed Hardware-Software codesign. Behavior-Architecture codesign is perhaps a better term, since the hardware and software should not be created until all the important decisions have been made.

Companies in the Felix Initiative have embarked on several pilot design projects to help drive new methodologies and tools. Initial projects include designs for automotive applications, high-performance video decompression, single-chip computers, and wireless applications. Specific architectural components being modeled are simple and complex buses, microcontrollers, and DSP processors.