Brian Bailey

Codesign Experiences Based on a Virtual Platform

One of the key elements of an electronic system level (ESL) methodology is the concept of platform-based design. Platform-based design (PBD) allows extensive reuse of components, which reduces the time-to-market for the first release of a product, maintenance, and subsequent releases. When the platform is modeled at a high level of abstraction, we often call the model a “virtual platform” (see Chapters 5 and 8). By recreating – in a simulation model – the full architectural environment of a system as well as the algorithms that it implements, virtual platform-based design enables quick design space exploration through experimentation with different design possibilities, without having to first invest time and effort in the design of a physical prototype. The final, optimal, solution might be one that was not usually explored using past methods.

Virtual Prototypes and Mixed Abstraction Modeling

In the preceding chapters, we talked about models and the strengths and weaknesses that they posses. In this chapter, and the chapters that follow, we start to see how those models are combined and applied to solve some of the problems associated with ESL. Unsurprisingly, most ESL methodologies that have been constructed start with a model that is generally called a system-level virtual prototype (SLVP). This is the closest thing that the electronics industry has to an executable specification.

IP Meta-Models for SoC Assembly and HW/SW Interfaces

A functional model contains a lot of information, but it does not often contain the information about how it was meant to be used, what restrictions are placed on its usage or the way in which it is meant to be connected. This information is considered to be metadata about that block and was often the principal information that would have been found on a specification sheet for a device. Once that information is captured in a formalized manner it can be used by tools to help with things such as system construction, enable system consistency to be analyzed, or reduce the burden of things such as documentation.

Transaction-Level Platform Creation

Chapter 5 looked at the creation of a system-level virtual prototype that was used primarily for software and system-level functional verification. It addressed many of the issues associated with adding major architectural elements, such as processors, buses, and memories. Many of the issues associated with HW/SW partitioning were also dealt within Chapter 6 and 7. These chapters took a top-down approach to the problem. They started from the highest level of functional description and refined the models by adding information associated with the major architectural decisions. In this chapter we will introduce a flow in which the hardware is modeled incrementally and integrated into a system that may then be used for hardware verification, more detailed architectural exploration, and software integration. These platforms are created at the behavioral transaction level and often referred to as transaction-level platforms (TLPs).

Interface Based Design

In April 2000, the first version of the Virtual Socket Interface alliance (VSIA) specification entitled “System-Level Interface Behavioral Documentation Standard”[1][2] was published and received wide acclaim by academic, industrial and press people [3]. The specification, which outlines a methodology for the separation of behavior from interface, provides a mechanism for documenting the intent and implementation of interfaces for Virtual Components (VCs) as well as a mechanism for showing how the interfaces at various levels of abstraction relate to each other. This specification results in a number of advantages to all participants in the design process.

C/C++ Hardware Design for the Real World

In previous chapters we have seen how system-level virtual prototypes get created and how they are often partitioned into pieces intended to be implemented as either software or hardware. This partitioning was done to manage costs and performance and to optimize many other attributes of the system. For the parts of the system intended to be hardware, several choices still remain. It is possible that those functionalities can be implemented using off-the-shelf components, such as processors or DSPs, or as components that require small extensions in order to meet the necessary requirements, such as configurable and extensible processors. It is likely that there will be a few components for which dedicated custom hardware is required and we now need to refine those models in ways that make them more amenable to the transformation process that is often called behavioral synthesis or high-level synthesis.

Processor-Centric Design: Processors, Multi-Processors, and Software

Almost all embedded systems are a combination of software running on embedded processor cores, supporting hardware such as memories and processor buses, and other hardware elements including function accelerators and peripheral interface blocks. As a result, systems design increasingly is taking a processor-centric focus. High-level descriptions of systems functionality must be analyzed and partitioned across multiple elements, including processors, potentially more than one, and hardware components where needed.

Evolution of ESL Development

This chapter reveals that the patchwork consists largely of system modelling environments; formal system requirements capture, analysis, and traceability tools; architectural modelling, analysis, optimization, and verification environments; simulators and abstract processor models for software validation. High-level synthesis and configurable IP approaches to fixed-function hardware development; architectural development, synthesis, and configurable IP design approaches to programmable hardware development; and diverse design aids such as system-level model libraries and model generation tools are also discussed in the chapter. System modelling and formal specification techniques preceded todays electronic system-level (ESL) design and verification methodologies by several decades. They were—and are—used extensively in the design of systems in which very high levels of safety or quality of service (QoS) are mandatory. The early adopters of such techniques included large systems infrastructure design and deployment organizations. The primary driver of ESL methodology adoption is the increasing failure of traditional methodologies to cope with the burgeoning system algorithm content necessitated by the integration of so much functionality. The cell phone deploys complex algorithms for dynamic features such as long-, medium-,and short-range communications, location data, and video and audio processing, as well as for quasi-static features such as still image processing and organization applications for personal information management.

What Is ESL

This chapter reveals that the electronic system-level (ESL) design is a successor to the venerable and still-used term “system-level design” (SLD), are numerous and confusing. ESL design is an emerging electronic design methodology that focuses on the higher abstraction level concerns first and foremost. ESL is now an established approach at most of the worlds leading System-on-a-chip (SoC) designs companies, and is being used increasingly in system design. ESL can be accomplished through the use of SystemC as an abstract modelling language. The problem with ESL is manifested by both of these definitions. ESL seems to be a collection of many different activities and methodologies for designing “systems” of various types. These “systems” are electronic based, yet they involve both hardware and software. The move to ESL design and verification is a fundamental shift in design methodology. It offers measurable improvements in design productivity, design quality, and reduction of risk in product development. There are no other shifts in the design process that hold as much promise and demonstrated results in better meeting design objectives than ESL.

Post-Partitioning Analysis and Debug

This chapter presents a large array of models and modelling styles that can be used to perform post-partitioning verification and analysis. Perhaps the most important aspect of this is that the choice of model types and abstractions is a continuum between the pre-partitioning stage and the implementation stage. Models need to be planned and the intended applications for those models must be decided so that a coherent plan can be put in place to ensure that the maximum benefit is extracted from each and every model created. No model at a single level of abstraction is capable of meeting the requirements of all the necessary tasks, so it is necessary to bring together models of different levels of abstraction to make a full system hybrid model. The interfaces among models—and thus among system components—are places where things can very easily go wrong, and ownership and responsibility for these must be clearly defined. The interfaces also need to be modelled at different levels of abstraction.