Since its inception in the early 1990s, ESL design and verification has evolved gradually into a patchwork of methodologies that support various aspects of the Hardware/Software (HW/SW) co-development of complex embedded systems, implemented as board-level products, SoC, or System-on-Field Programmable Gate Arrays (SoFPGA). This is not necessarily ESL design’s final destination, but it is the current status.

The patchwork currently consists largely of system modeling environments; formal system requirements capture, analysis, and traceability tools; architectural modeling, 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.

The patchwork has not—at the time of writing—evolved to the point at which it can be termed a methodology. However, the value-add of the patchwork has led to its application in the design of high-performance, software-intensive, multifunction systems and chips for advanced products. An example is a 3G cell phone/data terminal that is also a Global Positioning System (GPS) device, digital camera, video/MP3 entertainment center, web terminal and personal information management device, and is equipped with Wi-Fi or Bluetooth connectivity. This design complexity—both hardware and software—is the primary driver for the adoption of ESL development methodologies. As mainstream product development grows in complexity, so will the demand for ESL methodologies—provided that new “patches” are added to extend the patchwork’s utility.

System modeling and formal specification techniques preceded today’s 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, such as the telecommunications service providers, as well as the National Aeronautics and Space Administration (NASA). NASA used system-level modeling to perform— among other critical simulation tasks—system Failure Mode and Effects Analysis (FMEA) for the Apollo mission. Such simulation techniques were essential to putting a man on the Moon. A more recent example of system-level modeling for space applications is the life support systems in the NASA Lunar-Mars Life Support Test Project. Formal specification techniques were used in the development of commercial mainframe computer and telecommunications equipment in the 1970s and 1980s, but did not significantly proliferate beyond those application domains.

It is only gradually, over the last decade or so, that the design of smaller systems and SoCs has required high-level techniques, and these techniques must operate at the multiple levels of abstraction that span system modeling to chip implementation. The adoption imperative here is competitive advantage in the design of commercial network equipment—wired and wireless—and consumer electronics, especially wireless handsets. The design imperative is to integrate complex system functionality implemented in both hardware and software, within demanding performance and power consumption specifications. Not surprisingly, then, among the early adopters of modern ESL tools and methods are companies such as Conexant, Emulex, Fujitsu, IBM, Infineon, Intel, NEC, Nokia, Panasonic, Philips, Qualcomm, Rohm, Samsung, Sony, STMicroelectronics, TI, and Toshiba.

This chapter addresses the following questions: What is the motivation for adopting ESL development methodologies? Why are they being adopted now, and why not sooner? What are the methodologies that are gaining traction? What must be done to transform ESL development from an “early adopter” technology to a mainstream one? What is the future of ESL development? The chapter concludes with a few provocative thoughts.

3.1 Introduction
3.2 Motivation for ESL Design
3.3 Traditional System Design Effectiveness
3.4 System Design with ESL Methodology
3.5 Behavioral Modeling Methodology
    3.5.1 VSP: Potential Value
    3.5.2 VSP: Programmer’s View
    3.5.3 VSP: Programmer’s View Plus Timing
    3.5.4 VSP: Cycle-Accurate View
3.6 Behavioral Modeling Environments
    3.6.1 Commercial Tools
        3.6.1.1 The Trailblazer: VCC
        3.6.1.2 Latest-Generation Tools
     3.6.2 Behavioral Modeling: Open-Source and Academic Technology
        3.6.2.1 POLIS
        3.6.2.2 Ptolemy Simulator
        3.6.2.3 SpecC Language
       3.6.2.4 OSCI SystemC Reference Simulator
3.7 Historical Barriers to Adoption of Behavioral Modeling
    3.7.1 The Demand Side
    3.7.2 The Standards Barrier
        3.7.2.1 Open SystemC Initiative
        3.7.2.2 Open Core Protocol International Partnership
        3.7.2.3 SpecC Technology Open Consortium
        3.7.2.4 The System-Level Language War
    3.7.3 Automated Links to Chip Implementation
3.8 Automated Implementation of Fixed-Function Hardware
    3.8.1 Commercial Tools
        3.8.1.1 Mathematical Algorithm Development Tools
        3.8.1.2 Graphical Algorithm Development Tools
        3.8.1.3 The Trailblazer: Behavioral Compiler
        3.8.1.4 Latest Generation High-Level Synthesis Tools
    3.8.2 Open-Source and Academic Tools
        3.8.2.1 SPARK Parallelizing High-Level Synthesis (PHLS)
3.9 Automated Implementation of Programmable Hardware
    3.9.1 Processor Design Using EDA Tools
        3.9.1.1 Processor Designer and Chess/Checkers
        3.9.1.2 CriticalBlue Cascade Coprocessor Synthesis
    3.9.2 Processor Design Using IP-Based Methods
        3.9.2.1 Configurable IP: Tensilica Xtensa and ARC 600/700
        3.9.2.2 IP Assembly: ARM OptimoDE
3.10 Mainstreaming ESL Methodology
    3.10.1 Who Bears the Risk?
    3.10.2 Adoption by System Architects
    3.10.3 Acceptance by RTL Teams
3.11 Provocative Thoughts
    3.11.1 Behavioral Modeling IDEs
    3.11.2 ASIP Processor Design
    3.11.3 Effect of ESL on EDA Tool Seats
    3.11.4 ESL and the Big Three Companies
3.12 The Prescription

Errata

Feedback

P. 49, Figure 3.5: The oval labelled "BROAD LEVEL PROTOTYPING" should be labelled "BOARD LEVEL PROTOTYPING"

P. 59, section 3.8.1.3, para 2, line 2. “automated teller machine” should be “asynchronous transfer mode”

P. 65, bullet 1, last line should read "modified for its new purpose"