Andrew Piziali

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.

Use of ESL for Implementation Verification

This chapter introduces the notion of positive and negative verification. Positive verification demonstrates that a specified requirement is satisfied by the design under verification (DUV). Negative verification demonstrates that no flaws exist in a particular implementation of a requirement. This chapter also contrasts on the verification focus of implementation verification against post-partitioning verification, where implementation-level details like cycle timing and control register bit encodings find themselves the subject of checkers and coverage models. An emphasis on clear box verification is more important for implementation verification than for post-partitioning verification because the lowest-level design choices—generally unspecified in any formal manner—are decided at this time. Hence, it is required to examine the internals of both hardware and software components to expose flaws. The number of pins is a design decision attempting to balance the cost of the dedicated trace pins with the number of signals that need to be monitored at any time. To maximize use of those pins, several levels of multiplexers are built into the device so that different internal signals can be fed to the external pins.

Research, Emerging, and Future Prospects

This chapter examines some of the possible changes of direction that may be in store for the industry as it battles with issues such as Moores law, nanotechnology, and the like. In addition, it discusses some of the issues perceived as limitations to progress in this transition from a register-transfer level (RTL) methodology to an electronic system-level (ESL) flow, and from a hardware-centric to a software-centric design approach. Technology is not the only factor that can bring about change. This chapter discusses various process changes that are happening, such as the continued globalization of the industry and the increased adoption of IP. These factors affect teams and the way engineering operations are performed. Education also needs to evolve to meet the needs of industry. ESL tool development and adoption represents one of the biggest potential disruptions that have happened in this industry for the past two decades. It requires not only different tools and methodologies, but in many cases a different mindset. This is occurring at the same time as other, non-technical shifts are happening around the world, and together they are creating a powerful force for change.

Chapter 4 – What Are the Enablers of ESL?

This chapter establishes the importance of models as an integral part of the electronic system-level (ESL) flow, and that the models are primary deliverable from ESL tools. Models with many different and often competing attributes are needed by all the groups that are fed from the ESL flow—namely, hardware, software, and verification. Many of the models will be created by the system designers who will use them for a variety of sizing and selection functions. Todays complex systems have made it necessary to develop dynamic analysis tools because traditional spread sheet analysis is no longer capable of providing the required accuracy. Models do not always have to be faithful to the eventual design. Providing the means to inject errors or exhibit alternative behaviors can help in tracking down problems. Models need to communicate through interfaces, and it is important for the viability of the industry that these are based on standards.

Chapter 10 – Post-Partitioning Verification

This chapter discusses the verification of the hardware/software (HW/SW) components of the design that result from the earlier partitioning step. The chapter discusses the verification that can and should be performed on the post-partitioned models of the system. This includes the establishment of the types of verification that can be performed and the importance of separating issues, such as functional verification, performance verification, and implementation verification. Post-partitioning verification is introduced into the electronic system-level (ESL) design flow to discover design errors that are introduced before register-transfer level(RTL) and software implementation. Verification at this stage benefits from a reduced abstraction gap between specification and design under verification (DUV). The post-partitioned DUV has no cycle-level timing and the software will be operating on high-level data structures, such as transactions, rather than register-level data. Validation means making sure the specification is correct—that is, the specification captures the product design requirements. Verification means making sure the implementation is correct, ensuring that it conforms to the requirements recorded in the specification.

Chapter 7 – Pre-Partitioning Analysis

This chapter discusses the analysis of systems based on the specifications and models. It explores what is possible in the electronic system-level (ESL) design flow through pre partitioning analysis of specifications and partial specifications of new functionality. It is also seen that the greatest success of these techniques is in specific models of computation and associated tools, such as dataflow analysis for signal and image processing applications. Pre partitioning analysis refines the system specification models and defines additional or elaborated design constraints derived from the high-level requirements, before the main partitioning of the design into hardware and software; into hardware blocks and software functions; and, in the case of multiprocessor systems, into a specification of multiple processors and their interconnection. If specifications and models are not executable, then analysis must be based on static methods—usually informal—that will allow us to analyze the specifications and derive interesting properties or constraints of the resulting systems.

Specifications and Modeling

This chapter describes both the functional and nonfunctional requirements of electronic system-level (ESL) systems. Modern electronic systems are not trivial in functionality or implementation complexity. Systems are built out of subsystems with widely varying scope. ESL is also about hardware and software, each of which have traditionally been implemented by different groups within an organization and who use different sets of design techniques and tools to do their respective jobs. Because ESL design begins before there are clear distinctions between hardware and software, these organizational challenges have to be taken into account. Traditionally, hardware and software development occur in isolation from one another. Hardware designs need to be fairly mature before software development and integration with hardware can progress. Requirement setting is not independent of implementation architectures. Simply put, a requirement without concerns about implementation is irrelevant. Electronics original equipment manufacturers (OEMs) most often deal with hardware platforms, which are fairly well established.

Taxonomy and Definitions for the Electronic System Level

This chapter defines taxonomy for the electronic system-level (ESL). Taxonomy is a characterization of objects or concepts based on the relationships that exist among them. Taxonomy can be represented in a hierarchical graph or table of attributes, where each of the attributes identifies a particular element of the differentiation. The title of “Father of Taxonomy” is given to Carl Linnaeus, a Swedish scientist who provided the characterization of living things in 1735. His taxonomy concentrated on the reproductive organs of plants and animals, and although many modifications have been made to it since then, the core taxonomy of living things in use today remains true to his concepts. Creating taxonomy for ESL deals with somewhat of a moving target because the parameters change as the technology matures. This can introduce some controversy, but this chapter categorizes elements of the ESL design flow in a way that may be useful for defining and constructing design flows.