E&F Module 30 - EDA Industry Working Groups

Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service Requirements and Specification Modeling (RSM) RASSP Education & Facilitation Program Module 30 Version 3.00 Copyright  1995-1999 SCRA All rights reserved. This information is copyrighted by the SCRA, through its Advanced Technology Institute (ATI), and may only be used for non-commercial educational purposes. Any other use of this information without the express written permission of the ATI is prohibited. Certain parts of this work belong to other copyright holders and are used with their permission. All information contained, may be duplicated for non-commercial educational use only provided this copyright notice and the copyright acknowledgements herein are included. No warranty of any kind is provided or implied, nor is any liability accepted regardless of use. The United States Government holds "Unlimited Rights" in all data contained herein under Contract F33615-94-C-1457. Such data may be liberally reproduced and disseminated by the Government, in whole or in part, without restriction except as follows: Certain parts of this work to other copyright holders and are used with their permission; This information contained herein may be duplicated only for non-commercial educational use. Any vehicle, in which part or all of this data is incorporated into, shall carry this notice . Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Rapid Prototyping Design Process DARPA Tri-Service RASSP DESIGN LIBRARIES AND DATABASE Primarily software HW DESIGN SYSTEM DEF. FUNCTION DESIGN HW & SW CODESIGN Primarily hardware VIRTUAL PROTOTYPE HW FAB HW & SW PART. INTEG. & TEST SW DESIGN SW CODE RSM Copyright  1995-1999 SCRA 2 Methodology RASSP Reinventing Electronic Design Architecture Goals Infrastructure DARPA Tri-Service l l l l To Investigate the State-of-the-Art in Requirement and Specification Modeling Methodologies To Show How RSM Is an Important Part of the Top-Down Design Methodology To Describe a Unified Evaluation Framework for Specification Modeling Methodologies To Describe an Existing RSM Methodology and Apply various evaluation criteria to It Copyright  1995-1999 SCRA 3 Methodology RASSP Reinventing RSM Outline Electronic Design Architecture Infrastructure DARPA Tri-Service l The Motivation for RSM m m m m m m Copyright  1995-1999 SCRA Where RSM fits in the RASSP Roadmap Goals of the Module Requirements & Specifications Defined Test Bench Development Where RSM fits in the Product Life-Cycle The System Definition Process 4 Methodology RASSP Reinventing RSM Outline (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l Requirements Engineering and Requirements Analysis m m m l Requirements Engineering Goals Requirements Analysis Requirements Validation Specification Modeling Methodologies (SMM) m m Copyright  1995-1999 SCRA SMM Applied to Reactive Systems Methodology Attributes 5 Methodology RASSP Reinventing RSM Outline (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l Methodology Survey Survey Content m Review of Evaluative Parameters m Ward and Mellor's Methodology (SDRTS or RTSA) m Jackson System Development (JSD) m Software Requirements Engineering Methodology (SREM) m Object Oriented Analysis (OOA) m Specification and Design Language (SDL) m Embedded Computer Systems (ECS) m Vienna Development Method (VDM) m Language of Temporal Ordering Specification (LOTOS) m Electronic Systems Design Methodology (MCSE) m Integrated Specification and Performance Modeling Environment (ISPME) Copyright  1995-1999 SCRA m 6 Methodology RASSP Reinventing RSM Outline (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l CASE Tools m m m m m m Copyright  1995-1999 SCRA RDD-100 DOORS SLATE Requirements and Traceability Management (RTM) Statemate ADEPT 7 Methodology RASSP Reinventing RSM Outline (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l RASSP Requirement Capture and Test Planning m m m l Review of the problem and the approach to solution Examples q FFT q SAR Use of the virtual prototype Summary Copyright  1995-1999 SCRA 8 Methodology RASSP Reinventing RSM Outline Electronic Design Architecture Infrastructure DARPA Tri-Service l The Motivation for RSM m m m m m m l l l l l l Goals Requirement defined Specification defined Executable Requirements and Specifications Test Bench Planning and Development Where RSM fits in the Product Life-Cycle Requirements Engineering and Requirements Analysis Specification Modeling Methodology (SMM) SMM Survey CASE Tools RASSP Requirement Capture and Test Planning Summary Copyright  1995-1999 SCRA 9 Methodology RASSP Reinventing Customer Expectations Electronic Design Architecture Infrastructure DARPA Tri-Service l Customers expect: m m m m Copyright  1995-1999 SCRA A system that accomplishes the desired overall functionality An accurate implementation of each function A system with products that will be operational and useful in its natural and induced environments Conformance to constraints on funding, schedule, physical characteristics, technology, external interfaces etc., during design and manufacture and after delivery 1 Methodology RASSP Reinventing Electronic Design Architecture Requirements Defined Infrastructure DARPA Tri-Service A requirement is: l A statement identifying a capability, physical characteristic, or quality factor that bounds a product or process need for which a solution is to be pursued l A clear documentation of the customer's expression of need so as to be directly usable in the design process Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Requirements : Usual Approach DARPA Tri-Service l Traditional: paper documents in a natural language m m m m m m Copyright  1995-1999 SCRA Subject to omissions, ambiguities, and errors Interpretation needs to be manual: subjective errors Natural language documents: reader and writer give different meanings to the same words Extraction of requirements from original document to a requirements tracking tool adds to ambiguity and chances of errors Need for manual mapping of written requirements into diverse design tools No underlying formalisms to ensure consistency among the various elements comprising the requirements document 1 Methodology RASSP Reinventing Electronic Design Architecture Executable Requirements Infrastructure DARPA Tri-Service l l l l l l A requirement modeled in a simulatable language is known as an executable requirement Overcomes the problems associated with traditional ways of documenting requirements Written in a machine-executable language Presents an external view of the system Especially well-suited for hardware and hardware/software systems, e.g. embedded systems A simulatable requirement evolves to a executable specification Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Specifications Defined Infrastructure DARPA Tri-Service l l l A specification is a complete but purely external description of a system to be designed. A completed specification involves modeling the environment in which the system is expected to function, and describing relations between the environment and the system in terms of a functional description. ( Requirements + Constraints + Behavior + Design criteria ) = Specifications Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing The Specification Document Electronic Design Architecture Infrastructure DARPA Tri-Service l The Specification Document is structured in the following manner: m m m m m m m Copyright  1995-1999 SCRA Problem presentation Characteristics and modeling of the environment System I/O specifications Functional specifications- system function description Operational specifications- Operation sequence, accuracy Technological specifications- implementation constraints Additional information such as document source, and explanations 1 Methodology RASSP Reinventing Executable Specification Electronic Design Architecture Infrastructure DARPA Tri-Service l An executable specification m A simulatable description of a component or system object q q q q Represents an arbitrarily high level of abstraction í e.g. DSP system, architecture, or HW/SW component level Reflects function and timing Incorporates a description of the object's interface Provides the proper data transformations m May also describe electrical or physical aspects including m Power, cost, size, fit, and weight Includes defined test requirements which leads to a test bench q l Denotational items (e.g. power) are m m Copyright  1995-1999 SCRA Considered factual (derived) items to be checked Not executed 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure The Role of the Executable Requirement/Specification DARPA Tri-Service l Executable Specification features: m m m l Executable Specification contents: m m m l A description of a system or component to reflect function, timing, and other aspects of the intended design Operational features of the intended design Abstract while retaining necessary detail Fiscal and non-functional constraints Behavioral description Test bench Executable Specification Applications: m m m m Copyright  1995-1999 SCRA At each level of design abstraction in a top-down design methodology Decomposition of constraints into subsystems Checking of systems and subsystems against testbenches Deriving requirements for lower levels 1 Methodology RASSP Reinventing Electronic Design Architecture Need for Test Bench Infrastructure DARPA Tri-Service Test bench simulates the environment of a model l Tests model functionality and timing l Compares model output with expected output l Provides a framework for the development of executable requirements l Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Test Planning Infrastructure DARPA Tri-Service l l l l A test bench is an executable VHDL model which instantiates the Model Under Test (MUT) The MUT output is compared against the expected response as generated by the test bench. Uses automatic test generation techniques Test planning is necessary for model validation Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Goals in Test Planning Electronic Design Architecture Infrastructure DARPA Tri-Service l l Goals can be evaluation or search goals Evaluation goals: m m m l Evaluate correctness of the MUT for all values within a range of the adjustable requirement space. Choose a set of samples from the evaluation space Form a test case by a sample value-constrained requirements pair Trade-off between testing time and degree of confidence of the test group Search goals: m m Copyright  1995-1999 SCRA Search for extremes that may be attained by the adjustable requirements taken into consideration Adjustable requirement needs to exhibit monotonic behavior in the search range 2 Methodology RASSP Reinventing A Typical Testbench Electronic Design Architecture Infrastructure DARPA Tri-Service Adaptive Testing Model State Stimulus Generator Test Vectors Model Under Test Response Comparator Go/No Go Or Noise Expected Response Copyright  1995-1999 SCRA 2 Methodology RSM Within the Product Life-Cycle RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service Technologies of interest upgrade data Use Set Requirements (simulatable) Acquisition data to multiple vendors Product Test System Test Fabricate/ Compile (HW Develop Specification R S M Verify Design Test (System) Validate (SW &HW) Verify / Test Implement/Code (HW/SW) SW) HW/SW Verification Copyright  1995-1999 SCRA 2 Methodology RASSP Reinventing Electronic Design Architecture Detailed view of the RSM Infrastructure DARPA Tri-Service DETERMINE SYSTEM REQUIREMENTS AND CONSTRAINTS REQUIREMENTS STAGE DEVELOP FORMAL (EXECUTABLE) REQUIREMENTS ADAPT A SUITABLE SPECIFICATION METHODOLOGY SPECIFICATION STAGE ENVIRONMENT SPECIFICATION SYSTEM SPECIFICATION PLAN AND DEVELOP TEST BENCH TEST BENCH STAGE TO SYSTEM IMPLEMENTATION Copyright  1995-1999 SCRA 2 Methodology The System Definition Process RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service Production Rqmts - cost/schedule - methodology Operational Description - environment, user, signal Algorithm Choice 4-6 mo - operational scenarios - Algorithm - Risk area/mitigation - Development plan System Requirements Definition Requirements "db" Analysis Report - Completeness report - Cost - Traceability 1-3 mo Overall Architectural Definition HW Requirements Copyright  1995-1999 SCRA Performance model Architecture HW/SW Requirements documents Traceability matrix Development plan Simulation, test/stimulus response Sizing 1-3 mo B-2 Specifications Interface Control Documents (ICD) Tradeoff Studies Tools Editors Spreadsheets RDD-100 RTM F2D2 Tools VHDL Simulators RDD-100 BONeS Technology Assessment (packaging...) Alternative approaches COTS vs. Custom Bottlenecks and degradation Scalability, fault tolerances,... SW Requirements B-5 Specifications Interface Control Documents (ICD) 2 Methodology RASSP Reinventing Methodology Comparison Electronic Design Architecture Infrastructure DARPA Tri-Service Re-specify Re-specify Specify Specify Re-design Design Traditional Executable Requirements Specifications Design I&T I&T Done Done RASSP/CEENS Re-engineer Re-engineer Start Over Systematic & Predictable Change = Complexity = Risk Copyright  1995-1999 SCRA 2 Methodology RASSP Reinventing Electronic Design Architecture Methodology Costs & Benefits Infrastructure DARPA Tri-Service PHASE Rqmt Elicitation Rqmt Specification Rqmt Modeling Rqmt Analysis Behavioral Modeling Simulation (Design) Integration & Test … Re-engineering COST added effort added effort added phase added effort BENEFIT availability of Rqmt Model reduces effort significantly reduced effort & cost; improved product significantly reduced effort & cost; improved product Benefits outweigh costs 9/29/98 Copyright  1995-1999 SCRA 2 Methodology RASSP Reinventing RSM Outline Electronic Design Architecture Infrastructure DARPA Tri-Service l The Motivation for RSM l Requirements Engineering and Requirements Analysis m m m l l l l l Requirements Engineering Goals Requirements Analysis Requirements Validation Specification Modeling Methodologies (SMM) SMM Survey CASE Tools RASSP Requirement Capture and Test Planning Summary Copyright  1995-1999 SCRA 2 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Requirements Engineering Goals DARPA Tri-Service l Requirements engineering is the description of m m m l A proposed system's intended behavior and Its associated constraints By a disciplined application of proven principles, methods, tools and notations. The following are the chief aims of this activity: m m m m Copyright  1995-1999 SCRA Identification and documentation of customer and user needs Documentation of external behavior and associated constraints Ensuring consistency, completeness and feasibility of the required document by analysis and validation Sensitivity to the evolution of needs 2 Methodology RASSP Reinventing Requirements Analysis Electronic Design Architecture Infrastructure DARPA Tri-Service l Requirements Analysis Models: m Functional Model: Analysis of the system by considering its functional aspects m Structural Model: Analysis of the components or objects which form the system m Mixed Level Model: Structural analysis and decomposition of both the system and the functionality of the system iteratively m Communication Model: Description of message exchange between the system components m Behavioral Model: Description of the internal behavior of the components based on FSMs Copyright  1995-1999 SCRA 2 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure The Requirements Analysis Process DARPA Tri-Service From: - Validation - Functional Verification - Physical Verification. Customer Expectations Project & Enterprise Constraints Operational Scenarios System Boundaries Interfaces Functional Requirements Modes of Operations From: - Functional Analysis - Control Requirements Analysis Technical Performance External Constraints Measures of Effectiveness Utilization Environments Performance Requirements Physical Characteristics Establish Requirements Baseline Operational Functional Physical Copyright  1995-1999 SCRA Life-cycle Process Concepts To: Systems Analysis Human Factors To Validation 3 Methodology RASSP Reinventing Electronic Design Architecture Requirements Validation Infrastructure DARPA Tri-Service From Requirements Analysis Validation Customer Expectations? Enterprise & Project Constraints? Variances & Conflicts External Constraints? To Req. Analysis Validated Req. Baseline To: - Control - Functional Analysis Copyright  1995-1999 SCRA 3 Methodology RASSP Reinventing RSM Outline Electronic Design Architecture Infrastructure DARPA Tri-Service l The Motivation for RSM Requirements Engineering and Requirements Analysis l Specification Modeling Methodologies l l l l l m Definition and Application to reactive systems m Methodology Attributes SMM Survey CASE Tools RASSP Requirement Capture and Test Planning Summary Copyright  1995-1999 SCRA 3 Methodology RASSP Reinventing Phases of the Design Process Electronic Design Architecture Infrastructure DARPA Tri-Service l Specification Phase m m l Design Phase m l Formulation of system requirements Documentation as a specification Alternative implementation strategies q Considered q Evaluated Implementation Phase m Copyright  1995-1999 SCRA Realization as a product 3 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure What is Specification Modeling? DARPA Tri-Service l l Forms part of the Specification Phase of the Design Process A Specification Model of a system incorporates its m m m l l Behavior Design, and Requirements A Specification Model helps in making predictions about the system characteristics Enhances understanding of the system design and behavior Copyright  1995-1999 SCRA 3 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Defining a Specification Modeling Methodology (SMM) DARPA Tri-Service l A specification modeling methodology is a coherent set of methods and tools to develop, maintain and analyze the specification of a given system Copyright  1995-1999 SCRA 3 Methodology RASSP Reinventing Electronic Design Architecture Definition of Reactive Systems Infrastructure DARPA Tri-Service A reactive system is one that is in continual interaction with its environment l Reactive systems are typically control dominated l Control-related activities form a major part of the reactive system's behavior l A reactive system typically responds or reacts by changing its own state and generating further stimuli l A reactive system executes at a pace determined by its environment l Copyright  1995-1999 SCRA 3 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Application of Reactive Systems DARPA Tri-Service Reactive systems are prevalent in military as well as in commercial applications l Such systems represent a very large and ubiquitous class of high technology products l Such systems are often employed in highly critical applications l Examples of reactive systems l m m m m m Copyright  1995-1999 SCRA Network protocols Air-traffic control systems Industrial-process control systems Fire-power systems Guided missiles 3 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Characterizing Reactive Systems DARPA Tri-Service l Important behavioral characteristics of reactive systems m m m m m l State-transition oriented Concurrent Timing sensitive Exception-oriented Environment-sensitive Nonfunctional characteristics Copyright  1995-1999 SCRA 3 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l l l Why Apply Specification Modeling to Reactive Systems? Designing reactive systems poses one of the greatest challenges in the field of system design and development Many reactive systems are employed in highlycritical applications Reactive nature is extremely difficult to specify and implement Reliability and safety issues must be considered too Copyright  1995-1999 SCRA 3 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Attributes of Reactive System Specification Methodologies DARPA Tri-Service l Three major attributes of a reactive system specification modeling methodology: m Language q m Complexity control q m To cope with the complex nature of the reactive system Model continuity q Copyright  1995-1999 SCRA To support ability to provide conceptual models To focus on development and maintenance of a specification model instead of a proposed implementation 4 Methodology Components of a System Specification Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l Underlying model m l Set of languages m l Used to conceptualize and comprehend the system requirements Provides notations to express system requirements Set of techniques, range m From q m To q Copyright  1995-1999 SCRA Loosely specified guidelines for proceeding with the specification process Detailed algorithms needed to develop a complete specification from preliminary requirements and concepts 4 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Attributes of a Reactive System SMM DARPA Tri-Service reactive systems specification modeling methodology specification language complexity control model continuity model integration conceptual models Copyright  1995-1999 SCRA representational complexity analysis developmental techniques complexity implementation assistance implementation independence 4 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Attribute 1-Specification Language DARPA Tri-Service reactive systems specification modeling methodology specification language complexity control model continuity model integration implementation assistance representational complexity implementation conceptual analysis developmental independence techniques models complexity Copyright  1995-1999 SCRA 4 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Language-Conceptual Models System Views DARPA Tri-Service l Three complementary views m m m Copyright  1995-1999 SCRA Activity q Specification represents the activities that occur in the system q Activity in a system closely tied to the flow of data in a system Behavior q Specification represents ordering and interaction of activities q Often represented in terms of states and transitions, or the flow of control Entity view q Entities in the system, are identified q Entities represent the system components that are responsible for the activities and behavior in the system q Often represented as the data-items present in a system 4 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Language-Conceptual Models Specification Style DARPA Tri-Service l Two primary styles of specification m m l l Model-oriented q System is specified in terms of state-machines, processes, or set theory Property-oriented q System is viewed as a black-box q Properties of the system specified in terms of the directly observable behavior at the interface q No assumption is made about the internal structure or contents of the system. Model-oriented specifications considered easier to understand than property-oriented specifications Property-oriented specifications considered less implementation dependent than model-oriented specifications Copyright  1995-1999 SCRA 4 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Language-Conceptual Models Concurrency DARPA Tri-Service l l Concurrent behaviors cooperate with each other to achieve the desired functionality Concurrency is further characterized by the ability to express communication and synchronization among concurrent behaviors. Copyright  1995-1999 SCRA 4 Language-Conceptual Models Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l Information exchange usually conceptualized in terms of m m l Communication Among Concurrent Behaviors Shared-memory models Message-passing models Both shared-memory and message-passing models are interchangeable Copyright  1995-1999 SCRA 4 Language-Conceptual Models Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l Synchronization needed to m m l Synchronization Among Concurrent Behaviors Coordinate the activities of the components Permit each component to wait for other components to reach certain states or generate certain data or events Synchronization may be achieved using m m Copyright  1995-1999 SCRA Control constructs Communication techniques 4 Language-Conceptual Models Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l Nondeterminism Among Concurrent Behaviors Nondeterminism is an attribute for complexity control Nondeterminism allows the specifier to: m m Copyright  1995-1999 SCRA Focus on allowable alternative behaviors Not commit to any specific alternative 4 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Language-Conceptual Models Timing Constraints DARPA Tri-Service l Direct specification of timing constraints m m m m l Inter-event delays Data rates Execution time constraints for executing behaviors Temporal logic Indirect specification of timing constraints m Copyright  1995-1999 SCRA Implied through a collection of specification language constructs 5 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Language-Conceptual Models Modeling Time DARPA Tri-Service l l Reactive system behavior often specified in terms of a time metric Time is considered in a separately modeled entity rather than referred to indirectly, in order to increase the ease of specifying timing behavior Copyright  1995-1999 SCRA 5 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Language-Conceptual Models Exception Handling DARPA Tri-Service l l Exception handling needed when certain events require instantaneous response from the system Exception handling can be provided through explicit specification language constructs Copyright  1995-1999 SCRA 5 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Language-Conceptual Models Environment Characterization DARPA Tri-Service l l l The reactive system expected to be in continual interaction with its environment The environment itself is reactive in nature A reactive system's operational environment can be specified as m m Copyright  1995-1999 SCRA An explicit model A set of properties providing hints about various operational conditions, such as sleep, active, reset, modes, etc. 5 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Language-Conceptual Models Nonfunctional Characterization DARPA Tri-Service l Support for expression of nonfunctional characteristics is required, e.g. m m m m m m m l Reliability Availability Maintainability Safety Power Size Footprint Mechanisms must be provided to represent m m m Copyright  1995-1999 SCRA Hints Properties External constraints 5 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Language Analysis Techniques DARPA Tri-Service l l l Based on sound mathematical formalisms Enables automatic checking for specification inconsistencies Formalisms available m m m m m m Copyright  1995-1999 SCRA Petri-nets Finite state machines State diagram Temporal logic Process algebras Abstract data types 5 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Language Analysis Techniques (Cont.) DARPA Tri-Service l Language Support for model executability m m Copyright  1995-1999 SCRA Motivation- nontrivial complexity of the systems being designed today Executability of the specification q Helps to improve the comprehensibility and robustness of the specification q Offers the ability to experiment with preliminary prototypes which are useful to validate the specification against the requirements of the system 5 Methodology RASSP Reinventing Electronic Design Architecture Attribute 2- Model Continuity Infrastructure DARPA Tri-Service reactive systems specification modeling methodology specification language complexity control model continuity model integration implementation assistance representational complexity implementation conceptual analysis developmental independence techniques models complexity Copyright  1995-1999 SCRA 5 Methodology RASSP Reinventing Model Continuity Electronic Design Architecture Infrastructure DARPA Tri-Service l The maintenance of relationships between models created in different model spaces m m l The models must be able to interact in a controlled manner The models may be utilized concurrently throughout the design process Maintaining model continuity for a specification can be divided into three sub-problems: m m m Copyright  1995-1999 SCRA Model integration Implementation assistance Implementation independence 5 Methodology RASSP Reinventing Electronic Design Architecture Features and Benefits Infrastructure DARPA Tri-Service l l l Supports transcending levels of abstractions for testbench and functional representations Functional model evolves from functional requirement, through specification, implementation, detailed design, to fabrication Testbench evolves from executable specification, through implementation to fabrication to provide verification and validation at each level Copyright  1995-1999 SCRA 5 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Model Continuity Model Integration DARPA Tri-Service l l The flow of information must occur in both directions across model boundaries A methodology must support bidirectional information flow across model boundaries Copyright  1995-1999 SCRA 6 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l The methodology should provide support for checking conformance between the models at various levels of abstraction or in different domains Conformance checking may be viewed along two dimensions: m m l Model Continuity Model Integration Conformance Vertical - involves validating conformance between models representing different levels of abstraction Horizontal - involves validating conformance between models representing different modeling domains The need may exist for checking both horizontally and vertically Copyright  1995-1999 SCRA 6 Model Continuity Model Integration Model Interaction Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l Requirements of performing integrated modeling across different levels of abstraction and modeling domains: m m l A high degree of model interaction Information flow among the models Model interaction involves identification of how a methodology addresses the following: m m Implementation assistance q Maintaining visibility of the specification model during the implementation phase Implementation independence q Copyright  1995-1999 SCRA Incorporating relevant details obtained from the implementation phase back into the specification model 6 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l l Model Continuity Model Integration Complexity Control Required: a means to control complexity during the development and analysis of models throughout the design stages Support for this attribute is necessary for effective implementation of the conformance and interaction attributes Complexity control achieved by supporting a hierarchy of representations Copyright  1995-1999 SCRA 6 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l A hierarchical approach allows incremental expansion of design without expanding the rest of the system Model complexity can be divided into two dimensions: m m l Model Continuity Model Integration Complexity (Cont.) Vertical - abstraction of a lower-level model into a higher-level is an example of managing vertical complexity Horizontal - combining models from different modeling domains an example of managing horizontal complexity The hierarchical representation must possess capability to manage both horizontal and vertical complexity Copyright  1995-1999 SCRA 6 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Model Continuity Implementation Assistance DARPA Tri-Service l Two prime motivations for implementation assistance: m m l Reduction of designer effort Increase in implementation accuracy Synthesis of efficient implementations from system-level specifications m m Copyright  1995-1999 SCRA Generally based on the structure of the specification Design space is limited 6 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Model Continuity Implementation Independence DARPA Tri-Service l l A specification is considered implementation independent if it lacks implementation bias Two key advantages of an implementation independent specification m m Copyright  1995-1999 SCRA The specifier can focus on describing the behavior of the system, rather than how it is implemented Unnecessary restrictions are not placed on designer freedom 6 Methodology RASSP Reinventing Electronic Design Architecture Attribute 3: Complexity Control Infrastructure DARPA Tri-Service reactive systems specification modeling methodology specification language complexity control model continuity model integration implementation assistance representational complexity implementation conceptual analysis developmental independence techniques models complexity Copyright  1995-1999 SCRA 6 Methodology RASSP Reinventing Complexity Control Electronic Design Architecture Infrastructure DARPA Tri-Service l Complexity control exists along two dimensions m m Copyright  1995-1999 SCRA Representational complexity control makes the specification concise, understandable and decomposable Developmental complexity control supports incremental development and step-wise refinement 6 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Complexity Control Dimensions DARPA Tri-Service l Representational complexity m m m l Hierarchy Orthogonality Representation scheme Developmental complexity m m m Copyright  1995-1999 SCRA Nondeterminism Perfect synchrony hypothesis Developmental guidance 6 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l An important tool in controlling complexity Group similar elements together to create a new element m l Complexity Control Representational Complexity Hierarchy The new element represents the group of similar elements Result m m Copyright  1995-1999 SCRA Introduction of common behavior Support for multiple levels of abstraction 7 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l Complexity Control Representational Complexity Orthogonality Decomposition of a reactive behavior into a set of orthogonal behaviors Result, significant improvement in: m m Copyright  1995-1999 SCRA Clarity of intent Understandability of function 7 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l Complexity Control Representational Complexity Representation Scheme Plays an important role in understandability of a specification Two types of representation schemes m m Copyright  1995-1999 SCRA Graphical Textual 7 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l l Complexity Control Developmental Complexity Nondeterminism Nondeterminism supports an evolutionary approach to specification development Details of design are avoided till later stages of implementation Mechanisms to detect and resolve nondeterminism are required Copyright  1995-1999 SCRA 7 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l Complexity Control Developmental Complexity Perfect Synchrony Hypothesis Perfect-synchrony hypothesis implies that a reactive system produces it outputs synchronously with its inputs This assumption is supported in systems where the inputs change at rates slower than the system can react Copyright  1995-1999 SCRA 7 Complexity Control Developmental Complexity Developmental Guidance Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l Guidance for model development m Helpful in identifying the next step in the specification process q Bottom up approach í q A top-down approach í q Decomposing a specification into smaller and more detailed components Middle-out approach í Copyright  1995-1999 SCRA The primitives are first identified and then combined Combines both top-down and bottom-up approaches 7 Methodology RASSP Reinventing RSM Outline Electronic Design Architecture Infrastructure DARPA Tri-Service l The Motivation for RSM Requirements Engineering and Requirements Analysis Specification Modeling Methodology (SMM) l SMM Survey l l m l l l Survey of ten representative methodologies CASE Tools RASSP Requirement Capture and Test Planning Summary Copyright  1995-1999 SCRA 7 Methodology RASSP Reinventing Methodology Survey Electronic Design Architecture Infrastructure DARPA Tri-Service l Ten representative methodologies chosen: m m m m m m m m m m Copyright  1995-1999 SCRA Ward and Mellor's Methodology (SDRTS or RTSA) Jackson System Development (JSD) Software Requirements Engineering Methodology (SREM) Object Oriented Analysis (OOA) Specification and Design Language (SDL) Embedded Computer Systems (ECS) Vienna Development Method (VDM) Language of Temporal Ordering Specification (LOTOS) Electronic Systems Design Methodology (MCSE) Integrated Specification and Performance Modeling Environment (ISPME) 7 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Review of Evaluative Parameters DARPA Tri-Service l Specification Language m m l Complexity Control m m l Conceptual models Analysis techniques Representational complexity Developmental complexity Model Continuity m m m Copyright  1995-1999 SCRA Model integration Implementation Independence Implementation Assistance 7 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure 1. Ward and Mellor's Methodology (SDRTS or RTSA) DARPA Tri-Service SDRTS: Structured Development for Real-Time Systems l RTSA: Real-Time Structured Analysis l Reason for development: Specification and design of real-time applications l System Views Data Flow Diagrams Control Flow Diagrams Used to model activities of the system Used to express the sequencing of the system activities Copyright  1995-1999 SCRA 7 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Ward and Mellor's Methodology (Cont.) DARPA Tri-Service Methodology basis: Structured analysis to express system requirements graphically, concisely, and with minimal redundancy System Spec. Environment Model • Operational context • Stimulus Copyright  1995-1999 SCRA System Model • System behavior • Development through successive iterations 8 Methodology RASSP Reinventing Ward and Mellor's (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l Language aspect not supported well m l Lack of Formal Method support m l Less useful in the specification and design of critical systems Lack of orthogonality m l No direct support for specifying timing constraints or for handling exceptions Complicated systems more difficult to represent Model continuity attribute not well supported Copyright  1995-1999 SCRA 8 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure 2. Jackson System Development (JSD) DARPA Tri-Service l l l l Originally developed for program design Considered suitable for design of information systems and real-time systems Covers specification, design and implementation stages Supports complexity control in development and representation Copyright  1995-1999 SCRA 8 Methodology RASSP Reinventing Electronic Design Architecture JSD (Cont.) Infrastructure DARPA Tri-Service Basis: "Structure of a system to be designed can be determined from the structure and evolution of the data it should manage" l Representation of system requirements as Jackson's diagram for entities l System specification diagram- a network of processes that model the real world l Explicit time modeling by introducing delays l Copyright  1995-1999 SCRA 8 Methodology RASSP Reinventing Electronic Design Architecture JSD (Cont.) Infrastructure DARPA Tri-Service Two phases Specification •Environment described in terms of entities and actions •Actions are ordered by the expected sequence of events •Actions and entities represented as a process network using system specification diagrams Copyright  1995-1999 SCRA Design •Identify processes needed to execute the actions of each entity •Thus expand process network •Map completed process network to a set of hardware/software components 8 Methodology RASSP Reinventing Electronic Design Architecture JSD (Cont.) Infrastructure DARPA Tri-Service l l l l Timing considerations come very late, nearly after the design phase Specification is implementation-dependent, thus reducing designer freedom Lacks support for expressing reactive system characteristics such as exception handling Does not support formal analysis Copyright  1995-1999 SCRA 8 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service 3. Software Requirements Engineering Methodology (SREM) Developed for data processing applications of Specifications l Makes use of structured finite-state automata called requirement nets (r-nets) l Express the evolution of outputs and final state starting from inputs and current state, using rnets. I/O - message sets l Behavior of a reactive system well-represented by this methodology l Performance and timing constraints can be added l Supports the attribute of model continuity l Copyright  1995-1999 SCRA 8 Methodology RASSP Reinventing Electronic Design Architecture SREM (Cont.) Infrastructure DARPA Tri-Service l l l l l l l Specification development steps in SREM: Specification of interface between the system and the environment Data processing requirements Produce initial description using r-nets Add functional details, timing and performance constraints Perform validation and coherency tests on the specification Conduct final feasibility test Copyright  1995-1999 SCRA 8 Methodology RASSP Reinventing SREM (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l Does not support hierarchical decomposition of the specification m l Task of specification requires too much detail Specification and implementation are tied too close to one another, thus limiting model continuity support Copyright  1995-1999 SCRA 8 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure 4. Object Oriented Analysis (OOA) DARPA Tri-Service l l l l Based on object-oriented paradigm of modeling Classes and objects used to express the problem domain Extension of data or information modeling approaches, and concerns data transformations Complexity control attribute well-supported Copyright  1995-1999 SCRA 8 Methodology RASSP Reinventing OOA (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l Major steps in OOA are: m m m Copyright  1995-1999 SCRA Identify objects, their attributes and the structure of their interrelationships Entire specification developed as a hierarchy of modules Refinement of modules take place vertically and horizontally 9 Methodology RASSP Reinventing Electronic Design Architecture OOA (Cont.) Infrastructure DARPA Tri-Service l l Must be combined with languages that support expression of reactive system characteristics Languages must have both formal and operational semantics Copyright  1995-1999 SCRA 9 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure 5. Specification and Description Language (SDL) DARPA Tri-Service l l l l Used for specifying and describing many types of systems Standardized, semiformal Can be used graphically or textually Supports perfect synchrony hypothesis and has an associated formal semantics Copyright  1995-1999 SCRA 9 Methodology RASSP Reinventing Electronic Design Architecture SDL (Cont.) Infrastructure DARPA Tri-Service System Views Structural (recursive decomposition of hierarchical blocks) Copyright  1995-1999 SCRA Behavioral Data (specifies reactive (modeled as an nature of system) abstract data type) 9 Methodology RASSP Reinventing SDL (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service Topmost level Channels System Block Channels Environment Behavioral Model Signals Signals Process 1 Copyright  1995-1999 SCRA Process 2 Process 3 ... 9 Methodology RASSP Reinventing SDL (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l Does not support all reactive system characteristics m m l Exception handling not directly supported Inputs are processed only when receiving process is ready to process them Model continuity not well-supported Copyright  1995-1999 SCRA 9 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure 6. Embedded Computer Systems (ECS) DARPA Tri-Service l l l l l Based on the three views of system modeling: activities, control and implementation Supports both behavioral and functional decomposition of the system's specification Used by the CAD Tool Express VHDL that utilizes the visual formalism of Statecharts Conceptual model of concurrency, hierarchy and reactive transitions supported by Statecharts Supports both language and complexity control attributes Copyright  1995-1999 SCRA 9 Methodology RASSP Reinventing Electronic Design Architecture ECS (Cont.) Infrastructure DARPA Tri-Service l l l System is functionally decomposed into a number of subsystems using activity charts Viewed as a collection of interconnected functions organized in a hierarchy Top-down and iterative analysis used to gradually express all the requirements of the system Copyright  1995-1999 SCRA 9 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure 7. Vienna Development Method (VDM) DARPA Tri-Service l l l l Abstract model-oriented formal specification and design method Based on discrete mathematics Specification is written as a specification of an abstract data type which is defined by a class of objects and a set of operations acting on these objects Supports model continuity very well Copyright  1995-1999 SCRA 9 Methodology RASSP Reinventing VDM (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l Specification in that of an of an abstract data type m l l A program is an abstract data type specified in terms of variables and the operations allowed on them The design and specification processes are closely tied Specification methodology: m m m m m Copyright  1995-1999 SCRA Use META-IV to develop a formal specification Check specification for consistency using formal analysis Refine and further decompose specification to get a realization Check realization against specification for conformance Do iterative step-wise refinement until realization and implementation coincide 9 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l l Internationally standardized formal description technique Originally developed for formal specification of OSI protocols and services Based on process algebra and abstract data types m m l 8. Language of Temporal Ordering Specification (LOTOS) Process algebra: description of process behaviors and interactions Abstract data type: deals with description of data structures and value expressions Unambiguous precise and implementation independent Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture LOTOS (Cont.) Infrastructure DARPA Tri-Service Specify system by defining the temporal relationships among its externally observable interactions as interactions between process black boxes l Specify processes using process algebra techniques l Achieve process interactions using events l Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture LOTOS (Cont.) Infrastructure DARPA Tri-Service Property-oriented: therefore supports implementation independence l Specification does not restrict structure of implementation l Hard to conceptualize the internal states of reactive system l Concept of time not directly supported l Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure 9. Electronic Systems Design Methodology (MCSE) DARPA Tri-Service Methodology for specification, design and implementation of industrial computing systems l Structured approach to system design l Approaches design of real-time systems in a topdown style l Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing MCSE (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l Specification process consists of two parts m m l Environment modeling System modeling Specification processes produces three kinds of specifications: m m m Copyright  1995-1999 SCRA Functional specifications Operational specifications Technological specifications 1 Methodology RASSP Reinventing MCSE (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l Pros m m l Provides a well defined methodology for developing a specification Allows multiple system views and modeling approaches Cons m m Copyright  1995-1999 SCRA Lack of support for formal techniques Does not support a coherent integration of modeling approaches 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure 10. Integrated Specification and Performance Modeling Environment (IPSME) DARPA Tri-Service l Supports strong interaction between the specification, design and implementation phases m l l l l Better communication of design intent among phases Based on Statecharts: supports behavioral view of the system Also supports complementary modeling: modeling using Statecharts and modeling performance Performance model developed using ADEPT Supports activity view for a system Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture IPSME (Cont.) Infrastructure DARPA Tri-Service Development in an incremental manner from specification to implementation l Increments correspond to implementation of a Statecharts component l Performance model verified against Statecharts specification l Refinement of Statecharts and ADEPT models simultaneously l Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing IPSME (Cont.) Electronic Design Architecture Infrastructure DARPA Tri-Service l Supports the three reactive system attributes m m l Language and complexity approaches: Statecharts Model interaction component of model continuity: ADEPT Performance model developed independent of structure: implementation independence Implementation assistance supported by synthesizing Statecharts model itself Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Overall Comparison Electronic Design Architecture Infrastructure DARPA Tri-Service Specification Modeling Methodologies Language Complexity Control Model Continuity SDRTS JSD limited limited limited limited supported limited SREM supported limited limited OOA limited supported limited SDL supported supported limited ECS supported supported limited VDM supported limited limited LOTOS supported limited limited MCSE supported supported limited ISPME supported supported supported Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Support for Language Attributes DARPA Tri-Service Specification Model Methodologie s SDRTS JSD Available Conceptual Models activity+behavior entity Specification Style model model Environment Characterization model model SREM behavior model property OOA entity+behavior model limited SDL entity+behavior model limited ECS activity+behavior model model VDM entity model limited LOTOS entity+behavior property property MCSE activity+behavior model, property model ISPME activity+behavior model model Copyright  1995-1999 SCRA System Views 1 Methodology Support for Language Attribute RASSP Reinventing Electronic Design Architecture (Cont.) Infrastructure DARPA Tri-Service Specification Model Methodologies Available Conceptual Models SDRTS JSD Timing Constraints indirect direct Modeling Time limited supported Exception Handling limited limited SREM direct supported limited OOA indirect limited limited SDL indirect supported limited ECS indirect supported supported VDM indirect limited supported LOTOS indirect limited supported MCSE direct supported limited ISPME indirect supported supported Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Support for Language Attribute (Cont.) Infrastructure DARPA Tri-Service Copyright  1995-1999 SCRA Specification Modeling Methodologies Analysis Techniques Formal Analysis Model Executability SDRTS limited limited JSD limited limited SREM semiformal supported OOA limited limited SDL supported supported ECS supported supported VDM supported supported LOTOS formal limited MCSE semiformal limited ISPME formal supported 1 Methodology Support for Complexity Control RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service Specification Modeling Methodologies Hierarchy Orthogonality Representation Scheme SDRTS JSD supported supported limited supported graphical graphical SREM limited limited graphical OOA supported supported textual SDL supported supported graphical ECS supported supported graphical VDM supported supported textual LOTOS supported supported textual MCSE supported supported graphical ISPME supported supported graphical Copyright  1995-1999 SCRA Representational Complexity 1 Methodology Support for Complexity Control (Cont.) RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service Specification Modeling Methodologies Copyright  1995-1999 SCRA Developmental Complexity Nondeterminism SDRTS limited Perfect Synchrony Assumption asynch Developmental Guidance JSD limited asynch top down SREM limited asynch bottom up OOA limited asynch top down SDL supported synch top down ECS supported synch top down VDM supported synch top down LOTOS supported synch top down MCSE limited synch top down ISPME supported synch/ asynch top down / bottom up top down 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Support for Model-Continuity Attribute DARPA Tri-Service Specification Modeling Methodologies SDRTS JSD Copyright  1995-1999 SCRA Model Integration Conformance Interaction Complexity limited limited vertical vertical vertical vertical SREM limited vertical vertical OOA limited limited vertical SDL limited limited vertical ECS limited limited vertical VDM supported vertical vertical LOTOS limited vertical limited MCSE limited limited supported ISPME supported supported supported 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Support for Model-Continuity Attribute (Cont.) DARPA Tri-Service Specification Modeling Methodologies SDRTS JSD Copyright  1995-1999 SCRA Implementation Implementation Assistance limited limited Independence limited supported SREM supported limited OOA limited supported SDL supported supported ECS supported supported VDM supported limited LOTOS limited supported MCSE limited supported ISPME supported supported 1 Methodology RASSP Reinventing RSM Outline Electronic Design Architecture Infrastructure DARPA Tri-Service l The Motivation for RSM Requirements Engineering and Requirements Analysis Specification Modeling Methodologies SMM Survey l CASE Tools l l l m m m m m m l l RDD-100 DOORS SLATE Requirements and Traceability Management (RTM) Statemate ADEPT RASSP Requirement Capture and Test Planning Summary Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure RDD-100 Requirements Manager DARPA Tri-Service l l l l l l Functional Flow Block Diagrams, N-Squared Charts and Hierarchy Views are used in graphical display Configuration management done using a Multi-user Merge feature Can run on a superior or subordinate capacity Technical extraction and text editing from external source documents into the system design data; data can be navigated and edited Equipped with a behavior modeling tool that allows for the modeling of predicted or anticipated operational scenarios Coordination of work between all team members made possible by the allocation of superior or subordinate capacity Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure RDD-100 Requirements Manager DARPA Tri-Service l Core Features of Automated tools for Requirements Management: m m m m m Copyright  1995-1999 SCRA Requirements Capture Requirements Specification production Requirements Specification Management Text-oriented or model-oriented view of Requirements Management Provide links between requirements and other elements of the System Engineering Process 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l l l l l Dynamic Object-Oriented Requirements System (DOORS) Generate, parse existing and link to external requirements documents Assign attributes to requirements and restructure requirements into documents, tree structures, matrices and back-to-back trees Create views of requirements by interactive sorting and filtering Provides for requirements traceability by creating links between the tool and various other external documents and tools Includes modifiable routines for cost-benefit analysis, bottom-up weight calculation, impact analysis and test results Creation and customization of new document templates Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Systems Level Automation Tool for Engineers (SLATE) DARPA Tri-Service l l l l l l l l Integrates requirements, design alternatives and technical performance measures Use of textual outline, graphic block diagram and a functional, control or data flow diagram Translate requirements into a system architecture and display it as a hierarchical block diagram/ functional flow diagram Maps a requirements audit trial across system levels Evaluation of alternative designs and implementation decisions before implementation Multiple-perspective display of a conceptual design Functional decomposition and requirements flowdown and traceability Measures for technical performance Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Requirements and Traceability Management (RTM) DARPA Tri-Service l l l l l l l l Implementation independent Requirements gathered in a central repository and apparent inconsistencies refined Provides functionality, user interfaces, and hardware platform support relevant for each of the disciplines associated within a project's development All project info stored in a central on-line database Graphical tool to represent the chosen information flow Standard template that can be reused and redesigned for each project Manages information objects and relationships between them Specifies user-defined attributes to be defined for each information class Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Requirements and Traceability Management (RTM)- (Cont.) DARPA Tri-Service l l l l l l l l Captures the contents of requirements documents into a project database Identifies requirements by selecting the style or component type in the document corresponding to an information class Requirements can be extracted from an ASCII document and stored in the database as information objects Edit, merge or expand information to show information which is implied Combine different documents in a number of different views Assign attribute values to characterize each requirement Select, view and edit individual records Track dynamically, individual requirements through the project life-cycle Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Statemate Requirements Tracer DARPA Tri-Service l l l l l l l l l Parsing of requirements from original, imported or locally created documents Linkages between original and derived requirements, and between system models and requirements Checks for ensuring completeness and correctness of allocation Access, modify or link requirements while editing or modifying model element Link derived requirements to originals, and original requirements to design elements Process development using multiple requirements files Back-reference model elements to requirements Impact assessment on requirements due to modification of design elements Identification of requirements and design elements that have not been updated on changing original requirements Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Advanced Design Environment Prototyping Tool (ADEPT) DARPA Tri-Service l l l l l l l Developed by The Center for Semicustom Integrated Systems (CSIS) at The University of Virginia Employs both simulation-based and mathematical approaches for analysis Supports the integrated performance and dependability analysis of system level models Extended version supports operational specification modeling and hardware / software codesign Capable of simulating both interpreted and uninterpreted models in a common simulation environment using hybrid modeling Founded on VHDL descriptions and Petri Net Representations of models Spans numerous design phases, enabling the possibility of a common simulation environment Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing RSM Outline Electronic Design Architecture Infrastructure DARPA Tri-Service l The Motivation for RSM Requirements Engineering and Requirements Analysis Specification Modeling Methodology SMM Survey CASE Tools l RASSP Requirement Capture and Test Planning l l l l m Review of the problem and the approach to solution m Examples q FFT q SAR Use of the virtual prototype m l Summary Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture The Problem Infrastructure DARPA Tri-Service l l l l A written set of requirements for the design must be converted to executable requirements A methodology must be identified to proceed from the written to the executable, and then to the specifications, ultimately leading to synthesis of hardware The design specifications would be driven by the requirements thus captured The specifications are tested and validated against a test bench Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Requirements vs. Specifications DARPA Tri-Service l l l A Requirement describes a set of constraints which must be satisfied by the design, while a Specification describes the characteristics of the system developed to meet those constraints Requirement denotes input to the overall design cycle; Specification denotes the detailed design data produced at the output of the design cycle Requirements defines what needs to be done, while specifications outline how to do it Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture CEENSS-supported System Design Process Infrastructure DARPA Tri-Service Requirements Capture (product, systems, etc.) DOORS Functional Architecture (high-level behavioral VHDL specification) Renoir Architecture Definition (hw-sw partitioning) Software Simulatable Specification (e.g, SDL) Copyright  1995-1999 SCRA Requirements Modeling and Analysis VSPEC Hardware Architecture and Partitioning (Technology Independent) Hardware Simulatable Specification (Behavioral or RTL) Hardware Synthesis Monet, Visual Architect Analog/RF Models Technology Specific (VHDL-AMS) Autocode Generation or SW Reuse Software Compilation Digital Models Technology Specific (VHDL) Hardware/Software Codesign, Cosimulation 1 Methodology Example1: FFT Description RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service Buffered I and Q data arrays 2 at 512 words X 16 bits FILE I/O Buffer 32 bit data word 32 bit data word @ 5 MW/s Input Buf. Full Sensor read_data FFT Processor Latency delay of 200 us and noise specification of X dB @ rising_edge of 20 MHz 2 phase clock FILE I/O Buffer 32 bit data word Integer Valued Output Buf. Full write_data @ rising_edge of 20 MHz 2 phase clock Known Golden Results Clock @ 20 MHz Clock @ 5 MHz 31:16 16 bit in phase data samples from A/D converter Sink 15:00 16 bit quadrature-phase (Q) data samples from A/D converter Requirements for an FFT Processor System Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Example1: Requirement to Executable Requirement DARPA Tri-Service l l Requirement: " The system clock will operate with 2 phases and at a certain given frequency" VHDL Code Fragment: Begin -- architecture … internal_signals: phase1 <= NOT phase1 AFTER period; phase2 <= phase1 AFTER phase_delay; generated_signals: ph1 <= phase1 AND NOT phase2; ph2 <= NOT phase1 AND phase2; End; Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l Example 1:Requirement to Executable Requirement(Cont.) Requirement: "The processor shall buffer input data into 512 element buffers and process the data with max. latency of 20 us" VHDL code: … IF counter = 512 THEN stop_read_data <= '1', '0' after 5 ns; -- do Signal Processing here start_write_data <= '1' after 20 ns; -- start writing data to the output counter := 0; -- reset the counter so that more data can be read END IF; ... Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Example1: Scope of Executable Requirements DARPA Tri-Service Item Data I/O ports Control port Modes of operation Accuracy Latency Physical constraints Testability Scalability Environment Assumed quantity Copyright  1995-1999 SCRA Requirement Represented by executable requirement Data format specified a Protocol specified a Timing & data rate specified a Physical Commands and behavior specified a Data format specified a Protocol specified a Timing & data rate specified a Physical A 512 point FFT algorithm a Max. error to be specified a 20 us a Size, weight, power Best practice TBD Air cooled TBD 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l l l l l Example2: Executable Requirement to Executable Specification Compute the linear prediction model for a segment of speech samples Frame size is 240 samples with 12 bit resolution minimum Frame rate is 30ms Speech sampled at 8 KHz Use hamming weighted window on input data Copyright  1995-1999 SCRA Signal Processor Model Speech Data Control • Window Data • Compute prediction coefficients Linear Prediction Coefficients Test Bench Model • Read speech data from file • Send to processor every 30 ms in correct format • Read results from processor • Compare results with expected data 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Executable Requirements Signal Processor Entity DARPA Tri-Service ENTITY SignalProcessor IS GENERIC (LP_ORDER : INTEGER := 10); PORT ( --- SpeechType can be an array of 240 integers -- or an array of 240-12 bit data values. Integer is -- more efficient for simulation. lp_coeffType is an array -- of real numbers. Data -data : IN SpeechType; lpCoef : OUT lp_coeffType; --- "start_processor" is the control line from the test bench Control -- telling the processor when to begin computing Information -start_processor : IN OnOffType; start_read : OUT OnOffType ); END SignalProcessor; Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Executable Requirements Signal Processor Architecture DARPA Tri-Service ARCHITECTURE behavior OF SignalProcessor IS TYPE window_array_type IS ARRAY (0 to data'LENGTH -1); CONSTANT window_size_real : REAL := real (data'LENGTH); BEGIN Compute: PROCESS (start_processor) VARIABLE first_time : BOOLEAN := FALSE; VARIABLE window_coeff : window_array_type; VARIABLE windowed_data : window_array_type; VARIABLE gamma, lp_coeff : lp_coeffType; VARIABLE autocorr : corr_lags_type; BEGIN IF (start _processor= ON) THEN if (first_time = FALSE) THEN -- Calculate the window coefficients for hamming window in "double" precision hamming_wgts (window_size_real, window_coeff); first_time := TRUE; END IF; -- Window the data using the coefficients calculated window_data (window_coeff, data, windowed_data); -- Do the autocorrelation of this data set corr ( windowed_data, autocorr); -- Do L-D Recursion to finds all the prediction coefficients excluding lp_coeff(0) = 1 levinson_durbin (autocorr, gamma, lp_coeff, LP_ORDER-1); lpCoef <= lp_coeff AFTER 30 ms; start_read <= ON AFTER 30 ms, OFF AFTER 30 ms + default_delay; wait for 0 ns; END IF; END PROCESS Compute; END behavior; Copyright  1995-1999 SCRA Sensitivity List Find Autocorrelations LevinsonDurbin Recursion Window Data Write Data to Testbench 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Executable Requirements Test Bench Entity DARPA Tri-Service ENTITY TestBench IS PORT ( --- SpeechType can be an array of integers -- or an array of 12 bit data array. Integer is -- more efficient. lp_coeffType is an array -- of real numbers. Data -data : OUT SpeechType; lpCoef : IN lp_coeffType; --- "start_processor" is the control line from the test bench Control -- telling the processor when to begin computing Information -start_processor : OUT OnOffType; start_read : IN OnOffType ); END TestBench; Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Executable Requirements Test Bench Architecture DARPA Tri-Service ARCHITECTURE behavior OF TestBench IS TYPE window_array_type IS ARRAY (0 to data'LENGTH -1); SIGNAL start_data : OnOffType := OFF; BEGIN Start: PROCESS VARIABLE start : OnOfdType := ON; BEGIN IF (start = ON ) THEN start_data <= ON, OFF AFTER default_delay; start := OFF; Sensitivity END IF; END PROCESS Start; List Test_bench: PROCESS (start_read, start_data) VARIABLE data_in : window_array_type; VARIABLE in_line : LINE; FILE input_data : text is in "DATAFILE.in"; FILE output_data : text is out "DATAFILE.out"; BEGIN IF (start_data = ON or start_read = ON) THEN -- Load a block of data of data'HIGH samples i := 0; while ((NOT ENDFILE (input_data)) and (i <= data'HIGH)) loop Read data readline (input_data, in_line); from file read (in_line, data_in(i)); i := i+1; end loop; Send to processor data <= data_in; Copyright  1995-1999 SCRA start_processor <= ON, OFF AFTER default_delay; IF (start _read = ON) THEN -- Write the results to a file for -- later processing for i in lpCoef'RANGE loop write (in_line, lpCoef(i)); writeline (output_data, in_line); end loop; END IF; wait for 0 ns; END IF; END PROCESS Test_bench; END behavior; Write results to file 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Elements in Executable Specification of System Model DARPA Tri-Service System Timing and Performance Data • Signal processing I/O data –I/O timing constraints –I/O interface structures –I/O protocols –Signal levels –Message types • Signal processing latency –Data acceptance rate • Signal processing stimuli/response Copyright  1995-1999 SCRA System Functionality Data Physical Constraint Data • Algorithm descriptions • Control strategies • Task execution order • Synchronization primitives • Inter-process communication (IPC) • BIT and fault diagnosis • Size • Weight • Power • Cost • Reliability • Maintainability • Testability (fault coverage), diagnosis, and BIST goals) • Repairability • Scalability • Environment constraints –Temperature –Vibration –Pressure –Stress and Strain –Humidity –EMI/EMF/EMP [LMC-Meth] 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Executable Specification Signal Processor Entity DARPA Tri-Service ENTITY SignalProcessor IS GENERIC ( LP_ORDER : INTEGER := 10; COST : CostType := 1; -- Dollars Physical WEIGHT : WeightType := 5); -- Kilograms Parameters PORT (--- SpeechType can be an array of 240 integers Data -- or an array of 240-12 bit data values. Integer is -- more efficient for simulation. lp_coeffType is an array -- of real numbers. -data : IN SpeechType; lpCoef : OUT lp_coeffType; Control -Information -- "start_processor" is the control line from the test bench -- telling the processor when to begin computing -start_processor : IN OnOffType; start_read : OUT OnOffType ); END SignalProcessor; Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Executable Specification Signal Processor Architecture DARPA Tri-Service ARCHITECTURE behavior OF SignalProcessor IS TYPE window_array_type IS ARRAY (0 to data'LENGTH -1); CONSTANT window_size_real : REAL := real (data'LENGTH); BEGIN Compute: PROCESS (start_processor) VARIABLE first_time : BOOLEAN := FALSE; VARIABLE window_coeff, windowed_data: window_array_type; VARIABLE gamma, lp_coeff : lp_coeffType; VARIABLE autocorr : corr_lags_type; BEGIN IF (start _processor= ON) THEN if (first_time = FALSE) THEN Perform -- Calculate the window coefficients for hamming window in "double" precision fixed/floating hamming_wgts (window_size_real, window_coeff); Add cost and Add_cost_info (COST, cost_global); point tradeoffs weight info to Add_weight_info (WEIGHT, weight_global); (16 bit arith) first_time := TRUE; global values END IF; window_data (window_coeff, data, windowed_data); -- Window data -- Do the autocorrelation of this data set corr ( windowed_data, autocorr); -- Do L-D Recursion to finds all the prediction coefficients excluding lp_coeff(0) = 1 levinson_durbin (autocorr, gamma, lp_coeff, LP_ORDER-1); lpCoef <= lp_coeff AFTER 30 ms; start_read <= ON AFTER 30 ms, OFF AFTER 30 ms + default_delay; wait for 0 ns; END IF; END PROCESS Compute; END behavior; Copyright  1995-1999 SCRA Define functional information and task breakdown Sensitivity List Task 2 Task 1 Task 3 Control flow information 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Executable Specification Algorithm Descriptions DARPA Tri-Service procedure hamming_wgts ( size_of_window : in REAL; window_weights : out WINDOW) is constant pi : REAL := 3.14159265358979323846; variable arg : REAL; variable inc : REAL; begin arg := 2.0*pi/(size_of_window-1.0); inc := 0.0; for i in window_weights'RANGE loop window_weights(i) := 0.54 - 0.46*cos(arg*inc); inc := inc+1.0; end loop; end hamming_wgts; procedure window_data ( window_coeff : in WINDOW; data_in : in WINDOW; window_data : out WINDOW) is begin for i in window_coeff'RANGE loop window_data(i) := window_coeff(i) * data_in(i); end loop; end window_data; Copyright  1995-1999 SCRA procedure corr ( window_data : in WINDOW; autocorr : inout CORR_LAGS) is begin for i in autocorr'RANGE loop autocorr(i) := 0.0; for k in i to window_data'HIGH loop autocorr(i) := autocorr(i) + window_data(k)*window_data(k-i); end loop; end loop; end corr; • Algorithms chosen to perform necessary functions • Perform bit width trade-offs • Implement hamming weights using look-up tables 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Executable Specification Algorithms Descriptions (Cont.) DARPA Tri-Service procedure levinson_durbin ( autocorr : in CORR_LAGS; gamma : inout LP_COEFFS; lp_coeff : inout LP_COEFFS; size : in INTEGER) is variable alpha : REAL; variable beta : REAL; variable tmp : LP_COEFFS; • Determine from possible candidate algorithms the best to compute the prediction coefficients • Find the minimum bit widths causing the least amount of degradation Copyright  1995-1999 SCRA begin -- Initialization alpha := autocorr(0); beta := autocorr(1); lp_coeff(0) := -beta / alpha; gamma(0) := lp_coeff(0); -- Recursion for i in 1 to size loop alpha := alpha + beta * gamma(i-1); beta := autocorr(i+1); for j in 0 to i-1 loop beta := beta + autocorr(j+1)*lp_coeff(i-j-1); end loop; gamma(i) := -beta/alpha; for j in 0 to i-1 loop tmp(j) := gamma(i) * lp_coeff(i-j-1); end loop; for j in 0 to i-1 loop lp_coeff(j) := lp_coeff(j) + tmp(j); end loop; lp_coeff(i) := gamma(i); end loop; end levinson_durbin; 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service Example3: A Test Planning System used for the SAR model General Requirements Design Tool (Code Generator) VHDL Primitives Primitives Library Specific Requirements Test Plan Specification Repository Default Specification Requirements Goal Tree System Model Selection MUT & Stimulus Generator Specific Requirements Requirements Interface Copyright  1995-1999 SCRA Derived Requirements (Generic Values) Simulatable Test Bench 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Example3: An Example Test Bench Requirement DARPA Tri-Service l l The SAR processor test bench must generate a sequence of samples for the returned 'linear FM pulses' at a fixed sampling rate (general requirement) Specific requirements specify the values of the system parameters m Copyright  1995-1999 SCRA Linear FM pulses is a system parameter that implies several system parameters including bandwidth, pulse width, carrier frequency and the pulse repetition rate, whose values form specific requirements 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Example3: Storing System Requirements DARPA Tri-Service l Specification Repository m m l Associate primary requirements with physical system components Provide mechanism for changing the default requirements values used in the test plan Extract the requirements values and feed them to the test plan and the goal tree system using a parser Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service l Example3: Linking Using the Requirements Interface for SAR Link the test plan to the test bench using the Requirements Interface m The RI takes primary specific requirements from the test plan and produces the derived requirements as output Primary Derived Target sizes &ranges carrier freq. pulse repetition freq. b/w of signal transmitted noise std. Deviation pulse width of signal trans nominal range swath width Copyright  1995-1999 SCRA SAR Requirements Interface decimation factor sampling freq. Pulse width of recv signal b/w of recv signal no. of samples 1 Methodology RASSP Reinventing Example3: Test Generation Electronic Design Architecture Infrastructure DARPA Tri-Service l Two approaches to test vector generation m m Copyright  1995-1999 SCRA Model-based: q Specific implementation used in generating tests q State-based or path-based Environment-based: q Uses environment surrounding model under test to develop the test vectors q Tester not concerned about internal behavior of the MUT 1 Methodology RASSP Reinventing Electronic Design Architecture RSM Outline Infrastructure DARPA Tri-Service l The Motivation for RSM Requirements in the Systems Definition Phase Requirements Engineering and Requirements Analysis Specification Modeling Methodologies SMM Survey CASE Tools RASSP Requirement Capture and Test Planning l Summary l l l l l l Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Infrastructure Challenges of the Requirements Process DARPA Tri-Service l l l l l Requirements, especially for automated processes, are difficult to uncover Because of the dynamic nature of requirements, it is often difficult to establish baselines as well as to justify cost investment based upon them Design might begin prematurely if inappropriate requirements techniques are used A over-reliance of CASE ( Computer-Aided Systems Engineering ) tools may result in compromises in m Comprehension of requirements and m In the establishment of requirements engineering processes, techniques and principles Lack of confidence in requirements engineering often results due to lack of convincing evidence that works Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture RSM Proven Useful Infrastructure DARPA Tri-Service l l l l Applied throughout major industries Many practical methodologies Many useful tools Evaluation techniques exist Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture References Infrastructure DARPA Tri-Service l l l l l l l l l l [ARMSTRONG94] Armstrong, James R., Frank, Geoffrey. "Test Bench Development for RASSP DSP Models", 1st Annual RASSP Conference Proceedings, August 15-18, 1994. [CY90] Coad P., Yourdon E. Object-Oriented Analysis. Prentice-Hall, 1990. [Pnu86] Pnueli A. "Application of temporal logic to the specification and verification of reactive systems." Current Trends in Concurrency. Lecture Notes in Computer Science. Eds: de Bakker et al. Vol. 224, No. 9. Sep 1992. [Sarkar94] A., Waxman, R. and Cohoon, J.P.,“Specification Modeling Methodologies for Reactive System Design,” University of Virginia, Departmental Report. [SM88] Schlaer S., Mellor S.J. Object-Oriented Systems Analysis. Yourdon Press, 1988. [IEEE] All referenced IEEE material is used with permission. [IEEE1220] IEEE Standard 1220-1994 Trial-Use Standard for Application and Management of the Systems Engineering Process [Lincoln3] "Executable Requirements: Opportunities and Impediments," MIT-LL RASSP Program, Anderson A.H. [LMC-Meth] RASSP Methodology Version 2.0, Lochkeed Martin ATL [Hsia] "Status Report- Requirements Engineering", Hsia, Davis and Kung Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Additional Reading Infrastructure DARPA Tri-Service l l l l l Alford M.W., Ansart J.P., Hommel G., Lamport L., Liskov B., Mullery G.P., Schneider F.B. Distributed Systems. Methods and Tools for Specification. Lecture Notes in Computer Science, Springer-Verlag 1982. Aylor J. H. and Waxman R. and Johnson B.W. and Williams R.D. The Integration of Performance and Functional Modeling in VHDL. In Performance and Fault Modeling with VHDL. Schoen, J. M., Prentice Hall, Englewood Cliffs, NJ 07632, 1992, pages 22145. Aylor J. H., Williams R. D., Waxman R., Johnson B. W., and Blackburn R. L. A Fundamental Approach to Uninterpreted/Interpreted Modeling of Digital Systems in a Common Simulation Environment. UVA Technical Report TR # 900724.0, University of Virginia, Charlottesville, USA, July 24, 1990. Budkowski S. and Dembinski P. An Introduction to Estelle: A Specification Language for Distributed Systems. Computer Networks and ISDN Systems. North-Holland, Vol. 14, 1987. Belina F., Hogrefe D., and Sarma A. SDL with Applications from Protocol Specifications. Prentice Hall, 1991. Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Additional Reading Infrastructure DARPA Tri-Service l l l l l l l Bjorner D., Jones C.B. The Vienna Development Method: The Meta-Language. Lecture Notes in Computer Science. No. 61. Springer-Verlag. 1978. Blackburn R. L., and Thomas D. E. Linking the Behavioral and Structural Domains of Representation in a Synthesis System. DAC 85:374-380. Calvez J.P. Embedded Real-Time Systems: A Specification and Design Methodology. Wiley Series in Software Engineering Practice. 1993. Cameron J.R. "An overview of JSD". IEEE Transactions on Software Engineering. Vol SE-12. No. 2. February 1986. CCITT. Recommendation Z.100: Specification and Description language (SDL). Volume X, Fascicle X.1, Blue Book, October 1988. Coleman D. "Introducing Objectcharts or How to Use Statecharts in Object-Oriented Design". IEEE Transactions on Software Engineering. Vol. 18, No. 1. Jan 1992. Chu C. M., Potkonjak M., Thaler M., and Rabaey J. HYPER: An Interactive Synthesis Environment for High Performance Real Time Applications. Proceeding of the International Conference on Computer Design, pages 432-435, 1989. Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Additional Reading Infrastructure DARPA Tri-Service l l l l l l l l l Davis A. " A Comparison of Techniques for the Specification of External System Behavior". Communications of the ACM. Vol 31, No. 9. 1988. DeMarco T. Structured Analysis and System Specification. Yourdon Computing Series, Yourdon Press, Prentice Hall, 1979. Dutt N. D. and Gajski D. D. Designer Controlled Behavioral Synthesis Proceedings of the 26th Design Automation Conference, pages 754-757, 1989. Drusinsky D. and Harel D. Using Statecharts for hardware description and synthesis. In IEEE Transactions on Computer-Aided Design, 1989. Dijkstra E.W. "Guarded commands, nondeterminacy, and formal derivation of programs". Communications of the ACM, Vol 18, No. 8. 1975. Ehrig H. and Mahr B. Fundamentals of Algebraic Specification - 1. EATCS Monographs on Theoretical Computer Science 6. Springer-Verlag. 1985. Feijs L.M.G. and Jonkers H.B.M. Specification and Design with COLD-K. LNCS 490, pp. 277-301. Fraser M.D., Kumar K., Vaishnavi V.K. "Strategies for Incorporating Formal Specifications in Software Development". Communications of the ACM. Vol. 37, No. 10. Oct 1994 p 74-86. Færgemand O. and Olsen A. New Features in SDL-92. Tutorial, Telecommunications Research Laboratory, TFL, Denmark. 1992. Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Additional Reading Infrastructure DARPA Tri-Service l l l l l l l l Gajski D.D., Vahid F., and Narayan S. A system-design methodology: Executablespecification refinement. In Proceedings of the European Conference on Design Automation (EDAC), 1994. Halbwachs N. Synchronous Programming of reactive Systems. Kluwer Academic Publishers, 1993. Harel D. "Biting the Silver Bullet: Toward a Brighter Future for System Development". IEEE Computer. Vol. 25, No. 1. Jan 1992, pages 8-24. Harel D. "On Visual Formalisms". Communications of the ACM. Vol. 31, No. 5. 1988 p 514-530. Harel D. "Statecharts: A Visual Formalism For reactive Systems". Science of Computer Programming, Vol 8. 1987, pages 231-274. Hu D.C. and DeMicheli G. HardwareC - a language for hardware design. Stanford University, Technical Report CSL-TR-90-419, 1988. Harel D., Lachover H., Naamad A., Pnueli A., Politi M., Sherman R., Shtull-Trauring A., Trakhtenbrot M. "Statemate: A working environment for the development of reactive systems". Proceedings of 10th International Conference on Software Engineering. Singapore, 11-15 April 1988, p 122-129. Hatley D.J. and Pirbhai I.A. Strategies for Real-time System Specification. Dorset House Publishing, New York, 1987. Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Additional Reading Infrastructure DARPA Tri-Service l l l l l l l l IEEE Standard VHDL Language Reference Manual. IEEE Inc., NY, 1988. i-Logix Inc. ExpressVHDL Documentation, Version 3.0. 1992. ISO/IS 8807. Information Processing Systems - Open Systems Interconnection: LOTOS - A Formal Description Technique. 1989. Jackson M.A. System Development. Prentice-Hall, 1983. Jackson M.A. Principles of Program Design. Academic Press, 1975. Lor K. E. and Berry D. M. Automatic Synthesis of SARA Design Models from System Requirements. IEEE Transactions on Software Engineering 17(12):1229-1240 December 1991. Lavi J.Z. and Winokur M. "Embedded computer systems: requirements analysis and specification: An industrial course". Proceedings of SEI Conference, Virginia April 1988. Lecture Notes in Computer Science: Software Engineering Education, No. 327. Ed. G. A. Ford, Springer-Verlag p 81-105. Maraninchi F. Argos: A graphical synchronous language for the description of reactive systems. Report RT-C29, Univeriste Joseph Fourier, 1991. Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Additional Reading Infrastructure DARPA Tri-Service l l l l l l l Monarchi D.E. and Puhr G.I. "A Research Typology for Object-Oriented Ananlysis and Design". Communications of the ACM. Vol. 35, No. 9. Sep 1992. Manna A. and Pnueli A. The temporal logic of reactive and concurrent systems: specification. Berlin Heidelberg New York: Springer. 1991. Peterson "Role of Executable Specifications", Capt.Greg Peterson, Wright Lab Saracco R., Smith J., Reed R. Telecommunication Systems Engineering using SDL. Elsevier Science Publishers. 1989. Sarkar A. An Integrated Specification and Performance Modeling Approach for Digital System Design. Ph.D. Thesis. University of Virginia. Charlottesville, U.S.A. 1995. Sarkar A., Waxman, R. and Cohoon, J.P.,“Specification Modeling Methodologies for Reactive System Design,”, which appears in the book: High-Level System Modeling: Specification Languages, Edited by Berge, Levia, & Rouillard, Kluwer, 1995, pp 1-34. Sarkar A., Waxman R., and Cohoon J.P. "System Design Utilizing Integrated Specification and Performance Models". Proceedings, VHDL International Users Forum, Oakland, California, May 1-4, 1994, pp 90-100. l Spivey J.M. Understanding Z: A specification Language and its Formal Semantics. Cambridge University Press. 1988. Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Additional Reading Infrastructure DARPA Tri-Service l l l l l Thomas D.E. and Moorby P. The Verilog Hardware Description Language. Kluwer Academic Publishers, 1991. Wing J.M. "A specifier's introduction to formal methods". IEEE Computer, Vol 23, No. 9. 1990. pp 8-24. Woo N., Wolf W., and Dunlop A. Compilation of a single specification into hardware and software. AT&T Bell Labs, 1992. Ward P.T., Mellor S.J. Structured Development for Real-time Systems, Vols 1 & 2. Yourdon Computing Series, Yourdon Press, Prentice Hall 1985. Zave P. and Shell W. Salient features of an executable specification language and its environment. IEEE Transactions on Software Engineering 12(2):312-325 Feb, 1986. Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Additional Reading Infrastructure DARPA Tri-Service l l l l l l l EIA Standard 632 for Systems Engineering A Systems Engineering Process Model: Conceptual Approach Systems Engineering-Capability Maturity Model, Software Engineering Institute, Carnegie Mellon University, url http://www.sei.cmu.edu/publications/documents/95.reports/95.mm.003.html Dept. of Air Force Acquisition Risk Management Guide High-Level System Modeling Specification & Design Methodologies, Edited by Waxman, Berge, Levia, & Rouillard, Kluwer, 1996 "Embedded Real-Time Systems - A Specification and Design Methodology", Jean Paul Calvez, John Wiley & Sons, 1993 "Method Integration- Concepts and Case Studies", Edited by Klaus Kronlof, John Wiley&Sons, 1993 Copyright  1995-1999 SCRA 1 Methodology RASSP Reinventing Electronic Design Architecture Additional Reading Infrastructure DARPA Tri-Service l l l l l l l l "Benchmark I Requirements", Alan H Anderson, MIT Lincoln Lab "Executable Requirements Benchmarking," Alan H Anderson, MIT Lincoln Lab EIA-IS 632 Standard "Rapid Digital System Prototyping-Current practice, Future Challenges", V K Madisetti, IEEE D&T, Fall '96, pp18 Richards M., Gadient A., Frank G., eds. Rapid Prototyping of Application Specific Signal Processors, Kluwer Academic Publishers, Norwell, MA, 1997 Advanced Design Environment Prototyping Tool Tutorial, University of Virginia "Role of Executable Specifications", Capt. Greg Peterson, Wright Labs "Final Review", TRW, September 29, 1998. Copyright  1995-1999 SCRA 1

E&F Module 30 - EDA Industry Working Groups

Related documents

Products

Support

E&F Module 30 - EDA Industry Working Groups

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib