PRICES include / exclude VAT
Sponsored link
Released: 29.09.2006
IEEE 1647-2006 - IEEE Standard for the Functional Verification Language 'e'
IEEE Standard for the Functional Verification Language 'e'
Format
Availability
Price and currency
English PDF
Immediate download
130.25 EUR
Standard number: | IEEE 1647-2006 |
Released: | 29.09.2006 |
ISBN: | 978-0-7381-4941-7 |
Pages: | 390 |
Status: | Active |
Language: | English |
DESCRIPTION
IEEE 1647-2006
The scope of this standard is the definition of the e functional verification language. The e functional verification language is an application-specific programming language, aimed at automating the task of verifying electronic designs with respect to their specifications. This standard aims to serve as an authoritative source for the definition of the following: a) syntax and semantics of e language constructs b) the e language interaction with standard simulation languages c) e language librariesElectronic systems are integrated circuits (ICs), boards, or modules combining multiple ICs together, along with optional embedded processors and software components. Electronic systems are built to specifications that anticipate the environment in which such systems are expected to function and define the expected system functionality. Functional verification measures how well a system meets its specification. Even with moderately complex systems this question cannot be answered by inspection. For all modern electronic systems, a sophisticated verification process needs to accompany the design process to ensure compliance with the specification. Many electronic design automation (EDA) tools are used to carry out the functional verification process. The most prominent functional verification method, used to verify virtually all system designs, is called dynamic verification or simulation-based verification . Simulation-based verification makes use of a functional model of the system being designed. The functional model is simulated in the context of a mockup of the anticipated system environment. This mock-up is called the verification environment. There are many requirements a verification environment needs to fulfill. — It needs to create input stimulus and feed it into the system being verified. — It needs to collect the output from the system being verified, as well as the state of selected internal nodes. — It needs to check the output matches the expectations, based on the functional requirements, the state of the system being verified, and the inputs provided. — It needs to measure functional coverage : the extent to which functions of the system being verified have been exercised by the verification environment. — It needs to facilitate error identification, isolation, and debug. For that purpose, test environments contain combinational and temporal assertions, as well as various messaging and logging capabilities. — The verification environment needs to be able to mimic all possible variations and configurations the system being verified might face in practice. — The verification environment needs to be able to throw a wide variety of error conditions at the system being verified, in order to test error handling and error recovery. — The verification environment should be easily controllable, to allow steering by the verification engineers. The verification environment is a primary component in a simulation-based verification process. The environment needs to drive the system being verified through enough diverse scenarios to cover a statistically meaningful portion of the systems state space. Coverage data collected throughout the process should provide the foundation to an informed decision about the production readiness of the system being designed. Sophisticated verification environments are complex software systems, representing a significant investment. Reuse of verification components is a primary way of minimizing this investment. Reusability is typically an artifact of a well thought-out software architecture, but in the case of e , the language itself facilitates reuse through aspect-oriented programming (AOP) constructs and the semantics of generation. The purpose of the e functional verification language is to facilitate the creation of sophisticated verification environments. e features many constructs that automate and support common verification environment tasks. A standard definition of the e language should serve both practicing verification engineers and EDA tool developers. Engineers using e to build verification environments and reusable verification components need to ensure the valuable intellectual property (IP) they create can be interpreted by others. Tool developers need to agree on consistent syntax and semantics to ensure interoperability between tools. These goals are best facilitated by means of an open standard.
New IEEE Standard - Superseded. The e functional verification language is an application-specific programming language, aimed at automating the task of verifying an electronic design with respect to its specification. Verification environments written in e provide a model of the environment in which the design is expected to function, including the kinds of erroneous conditions the design needs to withstand. A typical verification environment is capable of generating user-controlled test inputs with statistically interesting characteristics. Such an environment can check the validity of the design responses. Functional coverage metrics are used to control the verification effort and gauge the quality of the design. e verification environments can be used throughout the design cycle, from a high-level architectural model to a fully realized system. This standard contains a definition of the e language syntax and semantics, and how tool developers and verification engineers should use them.