There are a number of values of ESL design, such as increasing quality and reliability and producing optimal designs, but the greatest perceived value proposition is to reduce the time to market for a design. The single biggest impact on time to market that ESL offers is to start software development before hardware design has been finalized. This has the secondary positive effect of allowing early feedback to ensure that the hardware architecture matches the requirements of the software. But ESL, as has been seen, is a term that covers a range of activities, and thus is something that we have to define to be able to talk about it constructively. In this chapter, we discuss the requirements that each group of users places on ESL, and thus the needs that must be covered by any working definition.

Often, the expectation is that the users of ESL tools sit between and above the hardware and software teams, primarily looking at the system definition and defining the ways in which the two teams will interface with each other. One possible conceptualization of ESL is to view it as shaped like a bow tie.

Such a view places a high value on the potential influence of ESL tools as the results flow down into both the hardware and software design, and implementation and verification flows. The implication is that relatively few people will be directly involved in using these tools, but a much larger community will make use of the results. Normally, these will be in the form of models that can be used to drive software and hardware synthesis or verification flows (that may use other tools labeled ESL, but whose only real connection to ESL is that they take their input from an ESL model).

The reality today is that during the hardware design flow, models that are the primary output from ESL tools may be successively refined and in many cases become the verification components for the hardware and software implementations. Likewise, those same models may be significantly altered to better supply the needs of the software teams. Although the expectation is that these models will enable the software team to see the effects of their software running on the intended hardware, often the reality is that the utility of the model is as a means of exercising the software on a simulation of the broad spectrum of possible hardware implementations.

4.1 Tool and Model Landscape
    4.1.1 The Models
    4.1.2 The Companies Using ESL
4.2 System Designer Requirements
    4.2.1 Accuracy
        4.2.1.1 Peak and Mean Measures
        4.2.1.2 Other Measures—Heat, Power
    4.2.2 Time and Speed
        4.2.2.1 Traffic Generator Models
    4.2.3 Tool Cost and Value Proposition
4.3 Software Team Requirements
    4.3.1 Accuracy
        4.3.1.1 Register Accuracy
        4.3.1.2 Cycle Count Accuracy
        4.3.1.3 Concurrent and State Accuracy
    4.3.2 Model Creation Time
    4.3.3 Model Execution Performance
        4.3.3.1 Interpreted, Stand-Alone Models
        4.3.3.2 Interpreted Slave Models
        4.3.3.3 Cache Line Just-In-Time Model
        4.3.3.4 Cache Page JIT Models
        4.3.3.5 Host Compiled Models
    4.3.4 Tool Chain Cost
4.4 Hardware Team Requirements
    4.4.1 Model Refinement
    4.4.2 Verification Environment Provision
    4.4.3 Verification
    4.4.4 Verification Simulation
    4.4.5 Cost
4.5 Who Will Service These Diverse Requirements?
4.6 Free or Open-Source Software
    4.6.1 F/OSS Community and Quality Effects
    4.6.2 F/OSS Licenses
        4.6.2.1 Copyright Ownership
        4.6.2.2 License Terms
        4.6.2.3 OSCI’s License
        4.6.2.4 License Compatibility
    4.6.3 The Scope of F/OSS within ESL
    4.6.4 Direct Benefits
    4.6.5 Other Effects of F/OSS
    4.6.6 Enabling (Academic) Research
    4.6.7 Economics of F/OSS Business Models
4.7 Summary
4.8 The Prescription

Errata

Feedback