Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright  1995-1999 SCRA 1 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Copyright  1995-1999 SCRA All.

Similar presentations


Presentation on theme: "Copyright  1995-1999 SCRA 1 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Copyright  1995-1999 SCRA All."— Presentation transcript:

1 Copyright  1995-1999 SCRA 1 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 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. Requirements and Specification Modeling (RSM) RASSP Education & Facilitation Program Module 30 Version 3.00

2 Copyright  1995-1999 SCRA 2 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Rapid Prototyping Design Process SYSTEM DEF. FUNCTION DESIGN HW & SW PART. HW DESIGN SW DESIGN HW FAB SW CODE INTEG. & TEST VIRTUAL PROTOTYPE RASSP DESIGN LIBRARIES AND DATABASE Primarily software Primarily hardware HW & SW CODESIGN RSM

3 Copyright  1995-1999 SCRA 3 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Goals l To Investigate the State-of-the-Art in Requirement and Specification Modeling Methodologies l To Show How RSM Is an Important Part of the Top-Down Design Methodology l To Describe a Unified Evaluation Framework for Specification Modeling Methodologies l To Describe an Existing RSM Methodology and Apply various evaluation criteria to It

4 Copyright  1995-1999 SCRA 4 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline l The Motivation for RSM m Where RSM fits in the RASSP Roadmap m Goals of the Module m Requirements & Specifications Defined m Test Bench Development m Where RSM fits in the Product Life-Cycle m The System Definition Process

5 Copyright  1995-1999 SCRA 5 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline (Cont.) l Requirements Engineering and Requirements Analysis m Requirements Engineering Goals m Requirements Analysis m Requirements Validation l Specification Modeling Methodologies (SMM) m SMM Applied to Reactive Systems m Methodology Attributes

6 Copyright  1995-1999 SCRA 6 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline (Cont.) l Methodology Survey m 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)

7 Copyright  1995-1999 SCRA 7 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline (Cont.) l CASE Tools m RDD-100 m DOORS m SLATE m Requirements and Traceability Management (RTM) m Statemate m ADEPT

8 Copyright  1995-1999 SCRA 8 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline (Cont.) l RASSP Requirement Capture and Test Planning m Review of the problem and the approach to solution m Examples q FFT q SAR m Use of the virtual prototype l Summary

9 Copyright  1995-1999 SCRA 9 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP l The Motivation for RSM m Goals m Requirement defined m Specification defined m Executable Requirements and Specifications m Test Bench Planning and Development m Where RSM fits in the Product Life-Cycle l Requirements Engineering and Requirements Analysis l Specification Modeling Methodology (SMM) l SMM Survey l CASE Tools l RASSP Requirement Capture and Test Planning l Summary RSM Outline

10 Copyright  1995-1999 SCRA 1010 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Customer Expectations l Customers expect: m A system that accomplishes the desired overall functionality m An accurate implementation of each function m A system with products that will be operational and useful in its natural and induced environments m Conformance to constraints on funding, schedule, physical characteristics, technology, external interfaces etc., during design and manufacture and after delivery

11 Copyright  1995-1999 SCRA1 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements Defined 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

12 Copyright  1995-1999 SCRA 1212 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements : Usual Approach l Traditional: paper documents in a natural language m Subject to omissions, ambiguities, and errors m Interpretation needs to be manual: subjective errors m Natural language documents: reader and writer give different meanings to the same words m Extraction of requirements from original document to a requirements tracking tool adds to ambiguity and chances of errors m Need for manual mapping of written requirements into diverse design tools m No underlying formalisms to ensure consistency among the various elements comprising the requirements document

13 Copyright  1995-1999 SCRA 1313 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Requirements l A requirement modeled in a simulatable language is known as an executable requirement l Overcomes the problems associated with traditional ways of documenting requirements l Written in a machine-executable language l Presents an external view of the system l Especially well-suited for hardware and hardware/software systems, e.g. embedded systems l A simulatable requirement evolves to a executable specification

14 Copyright  1995-1999 SCRA 1414 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Specifications Defined l A specification is a complete but purely external description of a system to be designed. l 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. l ( Requirements + Constraints + Behavior + Design criteria ) = Specifications

15 Copyright  1995-1999 SCRA 1515 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP The Specification Document l The Specification Document is structured in the following manner: m Problem presentation m Characteristics and modeling of the environment m System I/O specifications m Functional specifications- system function description m Operational specifications- Operation sequence, accuracy m Technological specifications- implementation constraints m Additional information such as document source, and explanations

16 Copyright  1995-1999 SCRA 1616 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Specification l An executable specification m A simulatable description of a component or system object q Represents an arbitrarily high level of abstraction í e.g. DSP system, architecture, or HW/SW component level q Reflects function and timing q Incorporates a description of the object's interface q Provides the proper data transformations m May also describe electrical or physical aspects including q Power, cost, size, fit, and weight m Includes defined test requirements which leads to a test bench l Denotational items (e.g. power) are m Considered factual (derived) items to be checked m Not executed

17 Copyright  1995-1999 SCRA 1717 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP The Role of the Executable Requirement/Specification l Executable Specification features: m A description of a system or component to reflect function, timing, and other aspects of the intended design m Operational features of the intended design m Abstract while retaining necessary detail l Executable Specification contents : m Fiscal and non-functional constraints m Behavioral description m Test bench l Executable Specification Applications: m At each level of design abstraction in a top-down design methodology m Decomposition of constraints into subsystems m Checking of systems and subsystems against testbenches m Deriving requirements for lower levels

18 Copyright  1995-1999 SCRA 1818 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Need for Test Bench l 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

19 Copyright  1995-1999 SCRA 1919 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Test Planning l A test bench is an executable VHDL model which instantiates the Model Under Test (MUT) l The MUT output is compared against the expected response as generated by the test bench. l Uses automatic test generation techniques l Test planning is necessary for model validation

20 Copyright  1995-1999 SCRA 2020 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Goals in Test Planning l Goals can be evaluation or search goals l Evaluation goals: m 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 m Form a test case by a sample value-constrained requirements pair m Trade-off between testing time and degree of confidence of the test group l Search goals: m Search for extremes that may be attained by the adjustable requirements taken into consideration m Adjustable requirement needs to exhibit monotonic behavior in the search range

21 Copyright  1995-1999 SCRA 2121 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP A Typical Testbench Or Noise

22 Copyright  1995-1999 SCRA2 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Within the Product Life-Cycle Develop Specification Fabricate/ Compile HW/SW Verification Set Requirements Test Use Design Implement/Code Validate Verify Technologies of interest data (SW &HW) (simulatable) Product Test (HW/SW) (System) RSMRSM upgrade System Test (HW SW) Verify / Test Acquisition data to multiple vendors

23 Copyright  1995-1999 SCRA 2323 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Detailed view of the RSM DETERMINE SYSTEM REQUIREMENTS AND CONSTRAINTS DEVELOP FORMAL (EXECUTABLE) REQUIREMENTS ENVIRONMENT SPECIFICATION SYSTEM SPECIFICATION ADAPT A SUITABLE SPECIFICATION METHODOLOGY PLAN AND DEVELOP TEST BENCH TO SYSTEM IMPLEMENTATION REQUIREMENTS STAGE SPECIFICATION STAGE TEST BENCH STAGE

24 Copyright  1995-1999 SCRA 2424 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP The System Definition Process System Requirements Definition Overall Architectural Definition HW Requirements SW Requirements Production Rqmts - cost/schedule - methodology Operational Description - environment, user, signal Tools Editors Spreadsheets RDD-100 RTM F2D2 B-2 Specifications Interface Control Documents (ICD) B-5 Specifications Interface Control Documents (ICD) 4-6 mo Algorithm Choice - operational scenarios - Algorithm - Risk area/mitigation - Development plan Performance model Architecture HW/SW Requirements documents Traceability matrix Development plan Simulation, test/stimulus response Sizing Technology Assessment (packaging...) Alternative approaches COTS vs. Custom Bottlenecks and degradation Scalability, fault tolerances,... 1-3 mo Requirements "db" Analysis Report - Completeness report - Cost - Traceability Tools VHDL Simulators RDD-100 BONeS 1-3 mo Tradeoff Studies

25 Copyright  1995-1999 SCRA 2525 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Methodology Comparison Traditional Re-specify Specify Design I & T Done Re-engineer Start Over Re-specify Re-design RASSP/CEENS Change = Complexity = Risk Systematic & Predictable Specify Design I & T Done Re-engineer Formalism Executable Requirements Specifications

26 Copyright  1995-1999 SCRA 2626 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 9/29/98 Methodology Costs & Benefits Benefits outweigh costs

27 Copyright  1995-1999 SCRA 2727 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline l The Motivation for RSM l Requirements Engineering and Requirements Analysis m Requirements Engineering Goals m Requirements Analysis m Requirements Validation l Specification Modeling Methodologies (SMM) l SMM Survey l CASE Tools l RASSP Requirement Capture and Test Planning l Summary

28 Copyright  1995-1999 SCRA 2828 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements Engineering Goals l Requirements engineering is the description of m A proposed system's intended behavior and m Its associated constraints m By a disciplined application of proven principles, methods, tools and notations. l The following are the chief aims of this activity: m Identification and documentation of customer and user needs m Documentation of external behavior and associated constraints m Ensuring consistency, completeness and feasibility of the required document by analysis and validation m Sensitivity to the evolution of needs

29 Copyright  1995-1999 SCRA 2929 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements Analysis 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

30 Copyright  1995-1999 SCRA 3030 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP The Requirements Analysis Process Requirements Analysis From: - Functional Analysis - Control Customer Expectations Project & Enterprise Constraints External Constraints Measures of Effectiveness Operational Scenarios System Boundaries Interfaces Utilization Environments Life-cycle Process Concepts Functional Requirements Performance Requirements To: Systems Analysis Technical Performance Physical Characteristics Human Factors Modes of Operations Establish Requirements Baseline Operational Functional Physical To Validation From: - Validation - Functional Verification - Physical Verification.

31 Copyright  1995-1999 SCRA 3131 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements Validation From Requirements Analysis Validation Customer Expectations? Enterprise & Project Constraints? External Constraints? Variances & Conflicts To Req. Analysis Validated Req. Baseline To: - Control - Functional Analysis

32 Copyright  1995-1999 SCRA 3232 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline l The Motivation for RSM l Requirements Engineering and Requirements Analysis l Specification Modeling Methodologies m Definition and Application to reactive systems m Methodology Attributes l SMM Survey l CASE Tools l RASSP Requirement Capture and Test Planning l Summary

33 Copyright  1995-1999 SCRA3 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Phases of the Design Process l Specification Phase m Formulation of system requirements m Documentation as a specification l Design Phase m Alternative implementation strategies q Considered q Evaluated l Implementation Phase m Realization as a product

34 Copyright  1995-1999 SCRA 3434 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP What is Specification Modeling? l Forms part of the Specification Phase of the Design Process l A Specification Model of a system incorporates its m Behavior m Design, and m Requirements l A Specification Model helps in making predictions about the system characteristics l Enhances understanding of the system design and behavior

35 Copyright  1995-1999 SCRA 3535 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Defining a Specification Modeling Methodology (SMM) l A specification modeling methodology is a coherent set of methods and tools to develop, maintain and analyze the specification of a given system

36 Copyright  1995-1999 SCRA 3636 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Definition of Reactive Systems l 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

37 Copyright  1995-1999 SCRA 3737 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Application of Reactive Systems l 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 m Network protocols m Air-traffic control systems m Industrial-process control systems m Fire-power systems m Guided missiles

38 Copyright  1995-1999 SCRA 3838 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Characterizing Reactive Systems l Important behavioral characteristics of reactive systems m State-transition oriented m Concurrent m Timing sensitive m Exception-oriented m Environment-sensitive l Nonfunctional characteristics

39 Copyright  1995-1999 SCRA 3939 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Why Apply Specification Modeling to Reactive Systems? l Designing reactive systems poses one of the greatest challenges in the field of system design and development l Many reactive systems are employed in highly- critical applications l Reactive nature is extremely difficult to specify and implement l Reliability and safety issues must be considered too

40 Copyright  1995-1999 SCRA 4040 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Attributes of Reactive System Specification Methodologies l Three major attributes of a reactive system specification modeling methodology: m Language q To support ability to provide conceptual models m Complexity control q To cope with the complex nature of the reactive system m Model continuity q To focus on development and maintenance of a specification model instead of a proposed implementation

41 Copyright  1995-1999 SCRA 4141 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Components of a System Specification Methodology l Underlying model m Used to conceptualize and comprehend the system requirements l Set of languages m Provides notations to express system requirements l Set of techniques, range m From q Loosely specified guidelines for proceeding with the specification process m To q Detailed algorithms needed to develop a complete specification from preliminary requirements and concepts

42 Copyright  1995-1999 SCRA 4242 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Attributes of a Reactive System SMM reactive systems specification modeling methodology conceptual implementation independence specification language complexity controlmodel continuity analysis techniques representational complexity developmental complexity model integration implementation assistance models

43 Copyright  1995-1999 SCRA 4343 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Attribute 1-Specification Language reactive systems specification modeling methodology implementation conceptual implementation independence specification language complexity controlmodel continuity analysis techniques representational complexity developmental complexity model integration assistance models

44 Copyright  1995-1999 SCRA4 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models System Views l Three complementary views m 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 m Behavior q Specification represents ordering and interaction of activities q Often represented in terms of states and transitions, or the flow of control m 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

45 Copyright  1995-1999 SCRA 4545 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Specification Style l Two primary styles of specification m Model-oriented q System is specified in terms of state-machines, processes, or set theory m 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. l Model-oriented specifications considered easier to understand than property-oriented specifications l Property-oriented specifications considered less implementation dependent than model-oriented specifications

46 Copyright  1995-1999 SCRA 4646 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Concurrency l Concurrent behaviors cooperate with each other to achieve the desired functionality l Concurrency is further characterized by the ability to express communication and synchronization among concurrent behaviors.

47 Copyright  1995-1999 SCRA 4747 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Communication Among Concurrent Behaviors l Information exchange usually conceptualized in terms of m Shared-memory models m Message-passing models l Both shared-memory and message-passing models are interchangeable

48 Copyright  1995-1999 SCRA 4848 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Synchronization Among Concurrent Behaviors l Synchronization needed to m Coordinate the activities of the components m Permit each component to wait for other components to reach certain states or generate certain data or events l Synchronization may be achieved using m Control constructs m Communication techniques

49 Copyright  1995-1999 SCRA 4949 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Nondeterminism Among Concurrent Behaviors l Nondeterminism is an attribute for complexity control l Nondeterminism allows the specifier to: m Focus on allowable alternative behaviors m Not commit to any specific alternative

50 Copyright  1995-1999 SCRA 5050 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Timing Constraints l Direct specification of timing constraints m Inter-event delays m Data rates m Execution time constraints for executing behaviors m Temporal logic l Indirect specification of timing constraints m Implied through a collection of specification language constructs

51 Copyright  1995-1999 SCRA 5151 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Modeling Time l Reactive system behavior often specified in terms of a time metric l Time is considered in a separately modeled entity rather than referred to indirectly, in order to increase the ease of specifying timing behavior

52 Copyright  1995-1999 SCRA 5252 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Exception Handling l Exception handling needed when certain events require instantaneous response from the system l Exception handling can be provided through explicit specification language constructs

53 Copyright  1995-1999 SCRA 5353 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Environment Characterization l The reactive system expected to be in continual interaction with its environment l The environment itself is reactive in nature l A reactive system's operational environment can be specified as m An explicit model m A set of properties providing hints about various operational conditions, such as sleep, active, reset, modes, etc.

54 Copyright  1995-1999 SCRA 5454 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Nonfunctional Characterization l Support for expression of nonfunctional characteristics is required, e.g. m Reliability m Availability m Maintainability m Safety m Power m Size m Footprint l Mechanisms must be provided to represent m Hints m Properties m External constraints

55 Copyright  1995-1999 SCRA5 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language Analysis Techniques l Based on sound mathematical formalisms l Enables automatic checking for specification inconsistencies l Formalisms available m Petri-nets m Finite state machines m State diagram m Temporal logic m Process algebras m Abstract data types

56 Copyright  1995-1999 SCRA 5656 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language Analysis Techniques (Cont.) l Language Support for model executability m Motivation- nontrivial complexity of the systems being designed today m 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

57 Copyright  1995-1999 SCRA 5757 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Attribute 2- Model Continuity reactive systems specification modeling methodology implementation conceptual implementation independence specification language complexity controlmodel continuity analysis techniques representational complexity developmental complexity model integration assistance models

58 Copyright  1995-1999 SCRA 5858 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity l The maintenance of relationships between models created in different model spaces m The models must be able to interact in a controlled manner m The models may be utilized concurrently throughout the design process l Maintaining model continuity for a specification can be divided into three sub-problems: m Model integration m Implementation assistance m Implementation independence

59 Copyright  1995-1999 SCRA 5959 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Features and Benefits l Supports transcending levels of abstractions for testbench and functional representations l Functional model evolves from functional requirement, through specification, implementation, detailed design, to fabrication l Testbench evolves from executable specification, through implementation to fabrication to provide verification and validation at each level

60 Copyright  1995-1999 SCRA 6060 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Model Integration l The flow of information must occur in both directions across model boundaries l A methodology must support bidirectional information flow across model boundaries

61 Copyright  1995-1999 SCRA 6161 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Model Integration Conformance l The methodology should provide support for checking conformance between the models at various levels of abstraction or in different domains l Conformance checking may be viewed along two dimensions: m Vertical - involves validating conformance between models representing different levels of abstraction m Horizontal - involves validating conformance between models representing different modeling domains l The need may exist for checking both horizontally and vertically

62 Copyright  1995-1999 SCRA 6262 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Model Integration Model Interaction l Requirements of performing integrated modeling across different levels of abstraction and modeling domains: m A high degree of model interaction m Information flow among the models l Model interaction involves identification of how a methodology addresses the following: m Implementation assistance q Maintaining visibility of the specification model during the implementation phase m Implementation independence q Incorporating relevant details obtained from the implementation phase back into the specification model

63 Copyright  1995-1999 SCRA 6363 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Model Integration Complexity Control l Required: a means to control complexity during the development and analysis of models throughout the design stages l Support for this attribute is necessary for effective implementation of the conformance and interaction attributes l Complexity control achieved by supporting a hierarchy of representations

64 Copyright  1995-1999 SCRA 6464 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Model Integration Complexity (Cont.) l A hierarchical approach allows incremental expansion of design without expanding the rest of the system l Model complexity can be divided into two dimensions: m Vertical - abstraction of a lower-level model into a higher-level is an example of managing vertical complexity m Horizontal - combining models from different modeling domains an example of managing horizontal complexity l The hierarchical representation must possess capability to manage both horizontal and vertical complexity

65 Copyright  1995-1999 SCRA 6565 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Implementation Assistance l Two prime motivations for implementation assistance: m Reduction of designer effort m Increase in implementation accuracy l Synthesis of efficient implementations from system-level specifications m Generally based on the structure of the specification m Design space is limited

66 Copyright  1995-1999 SCRA6 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Implementation Independence l A specification is considered implementation independent if it lacks implementation bias l Two key advantages of an implementation independent specification m The specifier can focus on describing the behavior of the system, rather than how it is implemented m Unnecessary restrictions are not placed on designer freedom

67 Copyright  1995-1999 SCRA 6767 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Attribute 3: Complexity Control reactive systems specification modeling methodology implementation conceptual implementation independence specification language complexity controlmodel continuity analysis techniques representational complexity developmental complexity model integration assistance models

68 Copyright  1995-1999 SCRA 6868 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control l Complexity control exists along two dimensions m Representational complexity control makes the specification concise, understandable and decomposable m Developmental complexity control supports incremental development and step-wise refinement

69 Copyright  1995-1999 SCRA 6969 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Dimensions l Representational complexity m Hierarchy m Orthogonality m Representation scheme l Developmental complexity m Nondeterminism m Perfect synchrony hypothesis m Developmental guidance

70 Copyright  1995-1999 SCRA 7070 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Representational Complexity Hierarchy l An important tool in controlling complexity l Group similar elements together to create a new element m The new element represents the group of similar elements l Result m Introduction of common behavior m Support for multiple levels of abstraction

71 Copyright  1995-1999 SCRA 7171 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Representational Complexity Orthogonality l Decomposition of a reactive behavior into a set of orthogonal behaviors l Result, significant improvement in: m Clarity of intent m Understandability of function

72 Copyright  1995-1999 SCRA 7272 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Representational Complexity Representation Scheme l Plays an important role in understandability of a specification l Two types of representation schemes m Graphical m Textual

73 Copyright  1995-1999 SCRA 7373 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Developmental Complexity Nondeterminism l Nondeterminism supports an evolutionary approach to specification development l Details of design are avoided till later stages of implementation l Mechanisms to detect and resolve nondeterminism are required

74 Copyright  1995-1999 SCRA 7474 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Developmental Complexity Perfect Synchrony Hypothesis l Perfect-synchrony hypothesis implies that a reactive system produces it outputs synchronously with its inputs l This assumption is supported in systems where the inputs change at rates slower than the system can react

75 Copyright  1995-1999 SCRA 7575 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Developmental Complexity Developmental Guidance l Guidance for model development m Helpful in identifying the next step in the specification process q Bottom up approach í The primitives are first identified and then combined q A top-down approach í Decomposing a specification into smaller and more detailed components q Middle-out approach í Combines both top-down and bottom-up approaches

76 Copyright  1995-1999 SCRA 7676 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP l The Motivation for RSM l Requirements Engineering and Requirements Analysis l Specification Modeling Methodology (SMM) l SMM Survey m Survey of ten representative methodologies l CASE Tools l RASSP Requirement Capture and Test Planning l Summary RSM Outline

77 Copyright  1995-1999 SCRA7 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Methodology Survey l Ten representative methodologies chosen: 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)

78 Copyright  1995-1999 SCRA 7878 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Review of Evaluative Parameters l Specification Language m Conceptual models m Analysis techniques l Complexity Control m Representational complexity m Developmental complexity l Model Continuity m Model integration m Implementation Independence m Implementation Assistance

79 Copyright  1995-1999 SCRA 7979 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 1. Ward and Mellor's Methodology (SDRTS or RTSA) l SDRTS: Structured Development for Real-Time Systems l RTSA: Real-Time Structured Analysis l Reason for development: Specification and design of real-time applications System Views Data Flow Diagrams Used to model activities of the system Control Flow Diagrams Used to express the sequencing of the system activities

80 Copyright  1995-1999 SCRA 8080 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Ward and Mellor's Methodology (Cont.) Methodology basis: Structured analysis to express system requirements graphically, concisely, and with minimal redundancy System Spec. Environment Model Operational context Stimulus System Model System behavior Development through successive iterations

81 Copyright  1995-1999 SCRA 8181 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Ward and Mellor's (Cont.) l Language aspect not supported well m No direct support for specifying timing constraints or for handling exceptions l Lack of Formal Method support m Less useful in the specification and design of critical systems l Lack of orthogonality m Complicated systems more difficult to represent l Model continuity attribute not well supported

82 Copyright  1995-1999 SCRA 8282 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 2. Jackson System Development (JSD) l Originally developed for program design l Considered suitable for design of information systems and real-time systems l Covers specification, design and implementation stages l Supports complexity control in development and representation

83 Copyright  1995-1999 SCRA 8383 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP JSD (Cont.) l 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

84 Copyright  1995-1999 SCRA 8484 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP JSD (Cont.) 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 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

85 Copyright  1995-1999 SCRA 8585 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP JSD (Cont.) l Timing considerations come very late, nearly after the design phase l Specification is implementation-dependent, thus reducing designer freedom l Lacks support for expressing reactive system characteristics such as exception handling l Does not support formal analysis

86 Copyright  1995-1999 SCRA 8686 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 3. Software Requirements Engineering Methodology (SREM) l 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 r- nets. 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

87 Copyright  1995-1999 SCRA 8787 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP SREM (Cont.) l Specification development steps in SREM: l Specification of interface between the system and the environment l Data processing requirements l Produce initial description using r-nets l Add functional details, timing and performance constraints l Perform validation and coherency tests on the specification l Conduct final feasibility test

88 Copyright  1995-1999 SCRA8 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP SREM (Cont.) l Does not support hierarchical decomposition of the specification m Task of specification requires too much detail l Specification and implementation are tied too close to one another, thus limiting model continuity support

89 Copyright  1995-1999 SCRA 8989 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 4. Object Oriented Analysis (OOA) l Based on object-oriented paradigm of modeling l Classes and objects used to express the problem domain l Extension of data or information modeling approaches, and concerns data transformations l Complexity control attribute well-supported

90 Copyright  1995-1999 SCRA 9090 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP OOA (Cont.) l Major steps in OOA are: m Identify objects, their attributes and the structure of their interrelationships m Entire specification developed as a hierarchy of modules m Refinement of modules take place vertically and horizontally

91 Copyright  1995-1999 SCRA 9191 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP OOA (Cont.) l Must be combined with languages that support expression of reactive system characteristics l Languages must have both formal and operational semantics

92 Copyright  1995-1999 SCRA 9292 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 5. Specification and Description Language (SDL) l Used for specifying and describing many types of systems l Standardized, semiformal l Can be used graphically or textually l Supports perfect synchrony hypothesis and has an associated formal semantics

93 Copyright  1995-1999 SCRA 9393 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP SDL (Cont.) System Views Structural ( recursive decompo- sition of hierarchical blocks) Structural ( recursive decompo- sition of hierarchical blocks) Behavioral ( specifies reactive nature of system) Behavioral ( specifies reactive nature of system) Data ( modeled as an abstract data type) Data ( modeled as an abstract data type)

94 Copyright  1995-1999 SCRA 9494 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP SDL (Cont.) Environment System Block Channels Topmost level Behavioral Model Process 2Process 3... Process 1 Signals

95 Copyright  1995-1999 SCRA 9595 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP SDL (Cont.) l Does not support all reactive system characteristics m Exception handling not directly supported m Inputs are processed only when receiving process is ready to process them l Model continuity not well-supported

96 Copyright  1995-1999 SCRA 9696 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 6. Embedded Computer Systems (ECS) l Based on the three views of system modeling: activities, control and implementation l Supports both behavioral and functional decomposition of the system's specification l Used by the CAD Tool Express VHDL that utilizes the visual formalism of Statecharts l Conceptual model of concurrency, hierarchy and reactive transitions supported by Statecharts l Supports both language and complexity control attributes

97 Copyright  1995-1999 SCRA 9797 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP ECS (Cont.) l System is functionally decomposed into a number of subsystems using activity charts l Viewed as a collection of interconnected functions organized in a hierarchy l Top-down and iterative analysis used to gradually express all the requirements of the system

98 Copyright  1995-1999 SCRA 9898 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 7. Vienna Development Method (VDM) l Abstract model-oriented formal specification and design method l Based on discrete mathematics l 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 l Supports model continuity very well

99 Copyright  1995-1999 SCRA9 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP VDM (Cont.) l Specification in that of an of an abstract data type m A program is an abstract data type specified in terms of variables and the operations allowed on them l The design and specification processes are closely tied l Specification methodology: m Use META-IV to develop a formal specification m Check specification for consistency using formal analysis m Refine and further decompose specification to get a realization m Check realization against specification for conformance m Do iterative step-wise refinement until realization and implementation coincide

100 Copyright  1995-1999 SCRA 100100 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 8. Language of Temporal Ordering Specification (LOTOS) l Internationally standardized formal description technique l Originally developed for formal specification of OSI protocols and services l Based on process algebra and abstract data types m Process algebra: description of process behaviors and interactions m Abstract data type: deals with description of data structures and value expressions l Unambiguous precise and implementation independent

101 Copyright  1995-1999 SCRA 101101 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP LOTOS (Cont.) l 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

102 Copyright  1995-1999 SCRA 102102 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP LOTOS (Cont.) l 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

103 Copyright  1995-1999 SCRA 103103 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 9. Electronic Systems Design Methodology (MCSE) l 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 top- down style

104 Copyright  1995-1999 SCRA 104104 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP MCSE (Cont.) l Specification process consists of two parts m Environment modeling m System modeling l Specification processes produces three kinds of specifications: m Functional specifications m Operational specifications m Technological specifications

105 Copyright  1995-1999 SCRA 105105 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP MCSE (Cont.) l Pros m Provides a well defined methodology for developing a specification m Allows multiple system views and modeling approaches l Cons m Lack of support for formal techniques m Does not support a coherent integration of modeling approaches

106 Copyright  1995-1999 SCRA 106106 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 10. Integrated Specification and Performance Modeling Environment (IPSME) l Supports strong interaction between the specification, design and implementation phases m Better communication of design intent among phases l Based on Statecharts: supports behavioral view of the system l Also supports complementary modeling: modeling using Statecharts and modeling performance l Performance model developed using ADEPT l Supports activity view for a system

107 Copyright  1995-1999 SCRA 107107 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP IPSME (Cont.) l 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

108 Copyright  1995-1999 SCRA 108108 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP IPSME (Cont.) l Supports the three reactive system attributes m Language and complexity approaches: Statecharts m Model interaction component of model continuity: ADEPT l Performance model developed independent of structure: implementation independence Implementation assistance supported by synthesizing Statecharts model itself

109 Copyright  1995-1999 SCRA 109109 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Overall Comparison Specification Modeling Methodologies LanguageComplexity ControlModel Continuity SDRTS limited JSD limitedsupportedlimited SREM supportedlimited OOA limitedsupportedlimited SDL supported limited ECS supported limited VDM supportedlimited LOTOS supportedlimited MCSE supported limited ISPME supported

110 Copyright  1995-1999 SCRA 110110 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Language Attributes Methodologie s Available Conceptual ModelsSpecification Model System ViewsSpecification Style Environment Characterization activity+behaviormodel JSDentitymodel SREMbehaviormodelproperty OOAentity+behaviormodellimited SDLentity+behaviormodellimited ECSactivity+behaviormodel VDMentitymodellimited LOTOSentity+behaviorproperty MCSEactivity+behaviormodel, propertymodel ISPMEactivity+behaviormodel SDRTS

111 Copyright  1995-1999 SCRA 111111 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Language Attribute (Cont.) Available Conceptual ModelsSpecification Model Methodologies Timing Constraints Modeling Time Exception Handling indirectlimited JSDdirectsupportedlimited SREMdirectsupportedlimited OOAindirectlimited SDLindirectsupportedlimited ECSindirectsupported VDMindirectlimitedsupported LOTOSindirectlimitedsupported MCSEdirectsupportedlimited ISPMEindirectsupported SDRTS

112 Copyright  1995-1999 SCRA 112112 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Language Attribute (Cont.) Analysis TechniquesSpecification Modeling Methodologies Model Executability SDRTSlimited JSDlimited SREMsemiformalsupported OOAlimited SDLsupported ECSsupported VDMsupported LOTOSformallimited MCSEsemiformallimited ISPMEformalsupported Formal Analysis

113 Copyright  1995-1999 SCRA 113113 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Complexity Control Representational ComplexitySpecification Modeling Methodologies HierarchyOrthogonalityRepresentation Scheme JSDsupported graphical SREMlimited graphical OOAsupported textual SDLsupported graphical ECSsupported graphical VDMsupported textual LOTOSsupported textual MCSEsupported graphical ISPMEsupported graphical SDRTSsupportedlimitedgraphical

114 Copyright  1995-1999 SCRA 114114 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Specification Modeling Methodologies Support for Complexity Control (Cont.) Developmental Complexity NondeterminismPerfect Synchrony Assumption Developmental Guidance SDRTSlimitedasynchtop down JSDlimitedasynchtop down SREMlimitedasynchbottom up OOAlimitedasynchtop down SDLsupportedsynchtop down ECSsupportedsynchtop down VDMsupportedsynchtop down LOTOSsupportedsynchtop down MCSElimitedsynchtop down ISPMEsupportedsynch/ asynch top down / bottom up

115 Copyright  1995-1999 SCRA 115115 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Model-Continuity Attribute Model IntegrationSpecification Modeling Methodologies ConformanceInteractionComplexity JSDlimitedvertical SREMlimitedvertical OOAlimited vertical SDLlimited vertical ECSlimited vertical VDMsupportedvertical LOTOSlimitedverticallimited MCSElimited supported ISPMEsupported SDRTSlimitedvertical

116 Copyright  1995-1999 SCRA 116116 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Model-Continuity Attribute (Cont.) Specification Modeling Methodologies Implementation Assistance Implementation Independence JSDlimitedsupported SREMsupportedlimited OOAlimitedsupported SDLsupported ECSsupported VDMsupportedlimited LOTOSlimitedsupported MCSElimitedsupported ISPMEsupported SDRTSlimited

117 Copyright  1995-1999 SCRA 117117 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline l The Motivation for RSM l Requirements Engineering and Requirements Analysis l Specification Modeling Methodologies l SMM Survey l CASE Tools m RDD-100 m DOORS m SLATE m Requirements and Traceability Management (RTM) m Statemate m ADEPT l RASSP Requirement Capture and Test Planning l Summary

118 Copyright  1995-1999 SCRA 118118 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RDD-100 Requirements Manager l Functional Flow Block Diagrams, N-Squared Charts and Hierarchy Views are used in graphical display l Configuration management done using a Multi-user Merge feature l Can run on a superior or subordinate capacity l Technical extraction and text editing from external source documents into the system design data; data can be navigated and edited l Equipped with a behavior modeling tool that allows for the modeling of predicted or anticipated operational scenarios l Coordination of work between all team members made possible by the allocation of superior or subordinate capacity

119 Copyright  1995-1999 SCRA 119119 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RDD-100 Requirements Manager l Core Features of Automated tools for Requirements Management: m Requirements Capture m Requirements Specification production m Requirements Specification Management m Text-oriented or model-oriented view of Requirements Management m Provide links between requirements and other elements of the System Engineering Process

120 Copyright  1995-1999 SCRA 120120 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Dynamic Object-Oriented Requirements System (DOORS) l Generate, parse existing and link to external requirements documents l Assign attributes to requirements and restructure requirements into documents, tree structures, matrices and back-to-back trees l Create views of requirements by interactive sorting and filtering l Provides for requirements traceability by creating links between the tool and various other external documents and tools l Includes modifiable routines for cost-benefit analysis, bottom-up weight calculation, impact analysis and test results l Creation and customization of new document templates

121 Copyright  1995-1999 SCRA 121121 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Systems Level Automation Tool for Engineers (SLATE) l Integrates requirements, design alternatives and technical performance measures l Use of textual outline, graphic block diagram and a functional, control or data flow diagram l Translate requirements into a system architecture and display it as a hierarchical block diagram/ functional flow diagram l Maps a requirements audit trial across system levels l Evaluation of alternative designs and implementation decisions before implementation l Multiple-perspective display of a conceptual design l Functional decomposition and requirements flowdown and traceability l Measures for technical performance

122 Copyright  1995-1999 SCRA 122122 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements and Traceability Management (RTM) l Implementation independent l Requirements gathered in a central repository and apparent inconsistencies refined l Provides functionality, user interfaces, and hardware platform support relevant for each of the disciplines associated within a project's development l All project info stored in a central on-line database l Graphical tool to represent the chosen information flow l Standard template that can be reused and redesigned for each project l Manages information objects and relationships between them l Specifies user-defined attributes to be defined for each information class

123 Copyright  1995-1999 SCRA 123123 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements and Traceability Management (RTM)- (Cont.) l Captures the contents of requirements documents into a project database l Identifies requirements by selecting the style or component type in the document corresponding to an information class l Requirements can be extracted from an ASCII document and stored in the database as information objects l Edit, merge or expand information to show information which is implied l Combine different documents in a number of different views l Assign attribute values to characterize each requirement l Select, view and edit individual records l Track dynamically, individual requirements through the project life-cycle

124 Copyright  1995-1999 SCRA 124124 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Statemate Requirements Tracer l Parsing of requirements from original, imported or locally created documents l Linkages between original and derived requirements, and between system models and requirements l Checks for ensuring completeness and correctness of allocation l Access, modify or link requirements while editing or modifying model element l Link derived requirements to originals, and original requirements to design elements l Process development using multiple requirements files l Back-reference model elements to requirements l Impact assessment on requirements due to modification of design elements l Identification of requirements and design elements that have not been updated on changing original requirements

125 Copyright  1995-1999 SCRA 125125 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Advanced Design Environment Prototyping Tool (ADEPT) l Developed by The Center for Semicustom Integrated Systems (CSIS) at The University of Virginia l Employs both simulation-based and mathematical approaches for analysis l Supports the integrated performance and dependability analysis of system level models l Extended version supports operational specification modeling and hardware / software codesign l Capable of simulating both interpreted and uninterpreted models in a common simulation environment using hybrid modeling l Founded on VHDL descriptions and Petri Net Representations of models l Spans numerous design phases, enabling the possibility of a common simulation environment

126 Copyright  1995-1999 SCRA 126126 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP l The Motivation for RSM l Requirements Engineering and Requirements Analysis l Specification Modeling Methodology l SMM Survey l CASE Tools l RASSP Requirement Capture and Test Planning m Review of the problem and the approach to solution m Examples q FFT q SAR m Use of the virtual prototype l Summary RSM Outline

127 Copyright  1995-1999 SCRA 127127 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP The Problem l A written set of requirements for the design must be converted to executable requirements l A methodology must be identified to proceed from the written to the executable, and then to the specifications, ultimately leading to synthesis of hardware l The design specifications would be driven by the requirements thus captured l The specifications are tested and validated against a test bench

128 Copyright  1995-1999 SCRA 128128 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements vs. Specifications 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 l Requirement denotes input to the overall design cycle; Specification denotes the detailed design data produced at the output of the design cycle l Requirements defines what needs to be done, while specifications outline how to do it

129 Copyright  1995-1999 SCRA 129129 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP CEENSS-supported System Design Process Requirements Capture (product, systems, etc.) Requirements Modeling and Analysis Functional Architecture (high-level behavioral VHDL specification) Architecture Definition (hw-sw partitioning) Software Simulatable Specification (e.g, SDL) Autocode Generation or SW Reuse Software Compilation Hardware/Software Codesign, Cosimulation Hardware Simulatable Specification (Behavioral or RTL) VSPECDOORS Hardware Synthesis Hardware Architecture and Partitioning (Technology Independent) Renoir Analog/RF Models Technology Specific (VHDL-AMS) Digital Models Technology Specific (VHDL) Monet, Visual Architect

130 Copyright  1995-1999 SCRA 130130 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP FFT Processor Latency delay of 200 us and noise specification of X dB Example1: FFT Description Sensor 32 bit data word @ 5 MW/s Clock @ 5 MHz Clock @ 20 MHz 32 bit data word FILE I/O Buffer 15:0031:16 16 bit in phase data samples from A/D converter 16 bit quadrature-phase (Q) data samples from A/D converter Buffered I and Q data arrays 2 at 512 words X 16 bits Sink FILE I/O Buffer 32 bit data word Integer Valued Known Golden Results @ rising_edge of 20 MHz 2 phase clock read_data Input Buf. Full Output Buf. Full @ rising_edge of 20 MHz 2 phase clock write_data Requirements for an FFT Processor System

131 Copyright  1995-1999 SCRA 131131 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Example1: Requirement to Executable Requirement 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;

132 Copyright  1995-1999 SCRA 132132 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Example 1:Requirement to Executable Requirement- (Cont.) l Requirement: "The processor shall buffer input data into 512 element buffers and process the data with max. latency of 20 us" l 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;...

133 Copyright  1995-1999 SCRA 133133 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Example1: Scope of Executable Requirements ItemRequirementRepresented by executable requirement Data I/O portsData format specified  Protocol specified  Timing & data rate specified  Physical - Control portCommands and behavior specified  Data format specified  Protocol specified  Timing & data rate specified  Physical - Modes of operationA 512 point FFT algorithm  AccuracyMax. error to be specified  Latency20 us  Physical constraints Size, weight, power- TestabilityBest practice- ScalabilityTBD- EnvironmentAir cooled- Assumed quantityTBD-

134 Copyright  1995-1999 SCRA 134134 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Example2: Executable Requirement to Executable Specification l Compute the linear prediction model for a segment of speech samples l Frame size is 240 samples with 12 bit resolution minimum l Frame rate is 30ms l Speech sampled at 8 KHz l Use hamming weighted window on input data Speech Data Linear Prediction Coefficients Window Data Compute prediction coefficients Signal Processor Model 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 Control

135 Copyright  1995-1999 SCRA 135135 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Requirements Signal Processor Entity 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: IN SpeechType; lpCoef: OUT lp_coeffType; -- -- "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; Control Information Data

136 Copyright  1995-1999 SCRA 136136 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Requirements Signal Processor Architecture ARCHITECTURE behavior OF SignalProcessor IS TYPE window_array_type IS ARRAY (0 to data'LENGTH -1); CONSTANTwindow_size_real: REAL := real (data'LENGTH); BEGIN Compute: PROCESS (start_processor) VARIABLEfirst_time: BOOLEAN := FALSE; VARIABLEwindow_coeff: window_array_type; VARIABLEwindowed_data: window_array_type; VARIABLEgamma, lp_coeff : lp_coeffType; VARIABLEautocorr: 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; Window Data Find Autocorrelations Levinson- Durbin Recursion Sensitivity List Write Data to Testbench

137 Copyright  1995-1999 SCRA 137137 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Requirements Test Bench Entity 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: OUT SpeechType; lpCoef: IN lp_coeffType; -- -- "start_processor" is the control line from the test bench -- telling the processor when to begin computing -- start_processor: OUT OnOffType; start_read: IN OnOffType); END TestBench; Control Information Data

138 Copyright  1995-1999 SCRA 138138 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Requirements Test Bench Architecture ARCHITECTURE behavior OF TestBench IS TYPE window_array_type IS ARRAY (0 to data'LENGTH -1); SIGNALstart_data: OnOffType := OFF; BEGIN Start: PROCESS VARIABLEstart: OnOfdType := ON; BEGIN IF (start = ON ) THEN start_data <= ON, OFF AFTER default_delay; start := OFF; END IF; END PROCESS Start; Test_bench: PROCESS (start_read, start_data) VARIABLEdata_in: window_array_type; VARIABLEin_line: LINE; FILEinput_data: text is in "DATAFILE.in"; FILEoutput_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 readline (input_data, in_line); read (in_line, data_in(i)); i := i+1; end loop; data <= data_in; 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; Sensitivity List Read data from file Send to processor Write results to file

139 Copyright  1995-1999 SCRA 139139 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Elements in Executable Specification of System Model [LMC-Meth] 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 System Timing and Performance Data System Functionality Data Algorithm descriptions Control strategies Task execution order Synchronization primitives Inter-process communication (IPC) BIT and fault diagnosis Physical Constraint Data 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

140 Copyright  1995-1999 SCRA 140140 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Specification Signal Processor Entity ENTITY SignalProcessor IS GENERIC (LP_ORDER: INTEGER := 10; COST: CostType := 1;-- Dollars WEIGHT: WeightType := 5);-- Kilograms 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: IN SpeechType; lpCoef: OUT lp_coeffType; -- -- "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; Control Information Data Physical Parameters

141 Copyright  1995-1999 SCRA 141141 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Specification Signal Processor Architecture ARCHITECTURE behavior OF SignalProcessor IS TYPE window_array_type IS ARRAY (0 to data'LENGTH -1); CONSTANTwindow_size_real : REAL := real (data'LENGTH); BEGIN Compute: PROCESS (start_processor) VARIABLEfirst_time: BOOLEAN := FALSE; VARIABLEwindow_coeff, windowed_data: window_array_type; VARIABLEgamma, lp_coeff : lp_coeffType; VARIABLEautocorr: 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); Add_cost_info (COST, cost_global); Add_weight_info (WEIGHT, weight_global); first_time := TRUE; 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; Task 1 Task 2 Task 3 Sensitivity List Control flow information Define functional information and task breakdown Perform fixed/floating point tradeoffs (16 bit arith) Add cost and weight info to global values

142 Copyright  1995-1999 SCRA 142142 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Specification Algorithm Descriptions 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; 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 corr; Algorithms chosen to perform necessary functions Perform bit width trade-offs Implement hamming weights using look-up tables

143 Copyright  1995-1999 SCRA 143143 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Specification Algorithms Descriptions (Cont.) procedure levinson_durbin ( autocorr : in CORR_LAGS; gamma : inout LP_COEFFS; lp_coeff : inout LP_COEFFS; size: in INTEGER) is variablealpha : REAL; variablebeta: REAL; variabletmp: LP_COEFFS; 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; Determine from possible candidate algorithms the best to compute the prediction coefficients Find the minimum bit widths causing the least amount of degradation

144 Copyright  1995-1999 SCRA 144144 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Example3: A Test Planning System used for the SAR model

145 Copyright  1995-1999 SCRA 145145 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Example3: An Example Test Bench Requirement 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) l Specific requirements specify the values of the system parameters m 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

146 Copyright  1995-1999 SCRA 146146 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Example3: Storing System Requirements l Specification Repository m Associate primary requirements with physical system components m Provide mechanism for changing the default requirements values used in the test plan l Extract the requirements values and feed them to the test plan and the goal tree system using a parser

147 Copyright  1995-1999 SCRA 147147 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP l 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 Example3: Linking Using the Requirements Interface for SAR SAR Requirements Interface 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 decimation factor sampling freq. Pulse width of recv signal b/w of recv signal no. of samples Primary Derived

148 Copyright  1995-1999 SCRA 148148 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Example3: Test Generation l Two approaches to test vector generation m Model-based: q Specific implementation used in generating tests q State-based or path-based m Environment-based: q Uses environment surrounding model under test to develop the test vectors q Tester not concerned about internal behavior of the MUT

149 Copyright  1995-1999 SCRA 149149 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline l The Motivation for RSM l Requirements in the Systems Definition Phase l Requirements Engineering and Requirements Analysis l Specification Modeling Methodologies l SMM Survey l CASE Tools l RASSP Requirement Capture and Test Planning l Summary

150 Copyright  1995-1999 SCRA 150150 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Challenges of the Requirements Process l Requirements, especially for automated processes, are difficult to uncover l Because of the dynamic nature of requirements, it is often difficult to establish baselines as well as to justify cost investment based upon them l Design might begin prematurely if inappropriate requirements techniques are used l 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 l Lack of confidence in requirements engineering often results due to lack of convincing evidence that works

151 Copyright  1995-1999 SCRA 151151 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Proven Useful l Applied throughout major industries l Many practical methodologies l Many useful tools l Evaluation techniques exist

152 Copyright  1995-1999 SCRA 152152 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP References l [ARMSTRONG94] Armstrong, James R., Frank, Geoffrey. "Test Bench Development for RASSP DSP Models", 1st Annual RASSP Conference Proceedings, August 15-18, 1994. l [CY90] Coad P., Yourdon E. Object-Oriented Analysis. Prentice-Hall, 1990. l [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. l [Sarkar94] A., Waxman, R. and Cohoon, J.P.,“Specification Modeling Methodologies for Reactive System Design,” University of Virginia, Departmental Report. l [SM88] Schlaer S., Mellor S.J. Object-Oriented Systems Analysis. Yourdon Press, 1988. l [IEEE] All referenced IEEE material is used with permission. l [IEEE1220] IEEE Standard 1220-1994 Trial-Use Standard for Application and Management of the Systems Engineering Process l [Lincoln3] "Executable Requirements: Opportunities and Impediments," MIT-LL RASSP Program, Anderson A.H. l [LMC-Meth] RASSP Methodology Version 2.0, Lochkeed Martin ATL l [Hsia] "Status Report- Requirements Engineering", Hsia, Davis and Kung

153 Copyright  1995-1999 SCRA 153153 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Additional Reading 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. l 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 22- 145. l 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. l 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. l Belina F., Hogrefe D., and Sarma A. SDL with Applications from Protocol Specifications. Prentice Hall, 1991.

154 Copyright  1995-1999 SCRA 154154 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Additional Reading l Bjorner D., Jones C.B. The Vienna Development Method: The Meta-Language. Lecture Notes in Computer Science. No. 61. Springer-Verlag. 1978. l Blackburn R. L., and Thomas D. E. Linking the Behavioral and Structural Domains of Representation in a Synthesis System. DAC 85:374-380. l Calvez J.P. Embedded Real-Time Systems: A Specification and Design Methodology. Wiley Series in Software Engineering Practice. 1993. l Cameron J.R. "An overview of JSD". IEEE Transactions on Software Engineering. Vol SE-12. No. 2. February 1986. l CCITT. Recommendation Z.100: Specification and Description language (SDL). Volume X, Fascicle X.1, Blue Book, October 1988. l Coleman D. "Introducing Objectcharts or How to Use Statecharts in Object-Oriented Design". IEEE Transactions on Software Engineering. Vol. 18, No. 1. Jan 1992. l 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.

155 Copyright  1995-1999 SCRA 155155 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Additional Reading l Davis A. " A Comparison of Techniques for the Specification of External System Behavior". Communications of the ACM. Vol 31, No. 9. 1988. l DeMarco T. Structured Analysis and System Specification. Yourdon Computing Series, Yourdon Press, Prentice Hall, 1979. l Dutt N. D. and Gajski D. D. Designer Controlled Behavioral Synthesis Proceedings of the 26th Design Automation Conference, pages 754-757, 1989. l Drusinsky D. and Harel D. Using Statecharts for hardware description and synthesis. In IEEE Transactions on Computer-Aided Design, 1989. l Dijkstra E.W. "Guarded commands, nondeterminacy, and formal derivation of programs". Communications of the ACM, Vol 18, No. 8. 1975. l Ehrig H. and Mahr B. Fundamentals of Algebraic Specification - 1. EATCS Monographs on Theoretical Computer Science 6. Springer-Verlag. 1985. l Feijs L.M.G. and Jonkers H.B.M. Specification and Design with COLD-K. LNCS 490, pp. 277-301. l 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. l Færgemand O. and Olsen A. New Features in SDL-92. Tutorial, Telecommunications Research Laboratory, TFL, Denmark. 1992.

156 Copyright  1995-1999 SCRA 156156 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Additional Reading l Gajski D.D., Vahid F., and Narayan S. A system-design methodology: Executable- specification refinement. In Proceedings of the European Conference on Design Automation (EDAC), 1994. l Halbwachs N. Synchronous Programming of reactive Systems. Kluwer Academic Publishers, 1993. l Harel D. "Biting the Silver Bullet: Toward a Brighter Future for System Development". IEEE Computer. Vol. 25, No. 1. Jan 1992, pages 8-24. l Harel D. "On Visual Formalisms". Communications of the ACM. Vol. 31, No. 5. 1988 p 514-530. l Harel D. "Statecharts: A Visual Formalism For reactive Systems". Science of Computer Programming, Vol 8. 1987, pages 231-274. l Hu D.C. and DeMicheli G. HardwareC - a language for hardware design. Stanford University, Technical Report CSL-TR-90-419, 1988. l 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. l Hatley D.J. and Pirbhai I.A. Strategies for Real-time System Specification. Dorset House Publishing, New York, 1987.

157 Copyright  1995-1999 SCRA 157157 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Additional Reading l IEEE Standard VHDL Language Reference Manual. IEEE Inc., NY, 1988. l i-Logix Inc. ExpressVHDL Documentation, Version 3.0. 1992. l ISO/IS 8807. Information Processing Systems - Open Systems Interconnection: LOTOS - A Formal Description Technique. 1989. l Jackson M.A. System Development. Prentice-Hall, 1983. l Jackson M.A. Principles of Program Design. Academic Press, 1975. l 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. l 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. l Maraninchi F. Argos: A graphical synchronous language for the description of reactive systems. Report RT-C29, Univeriste Joseph Fourier, 1991.

158 Copyright  1995-1999 SCRA 158158 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Additional Reading 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. l Manna A. and Pnueli A. The temporal logic of reactive and concurrent systems: specification. Berlin Heidelberg New York: Springer. 1991. l Peterson "Role of Executable Specifications", Capt.Greg Peterson, Wright Lab l Saracco R., Smith J., Reed R. Telecommunication Systems Engineering using SDL. Elsevier Science Publishers. 1989. l Sarkar A. An Integrated Specification and Performance Modeling Approach for Digital System Design. Ph.D. Thesis. University of Virginia. Charlottesville, U.S.A. 1995. l 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.

159 Copyright  1995-1999 SCRA 159159 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Additional Reading l Thomas D.E. and Moorby P. The Verilog Hardware Description Language. Kluwer Academic Publishers, 1991. l Wing J.M. "A specifier's introduction to formal methods". IEEE Computer, Vol 23, No. 9. 1990. pp 8-24. l Woo N., Wolf W., and Dunlop A. Compilation of a single specification into hardware and software. AT&T Bell Labs, 1992. l Ward P.T., Mellor S.J. Structured Development for Real-time Systems, Vols 1 & 2. Yourdon Computing Series, Yourdon Press, Prentice Hall 1985. l 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.

160 Copyright  1995-1999 SCRA 160160 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Additional Reading l EIA Standard 632 for Systems Engineering l A Systems Engineering Process Model: Conceptual Approach l 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 l Dept. of Air Force Acquisition Risk Management Guide l High-Level System Modeling Specification & Design Methodologies, Edited by Waxman, Berge, Levia, & Rouillard, Kluwer, 1996 l "Embedded Real-Time Systems - A Specification and Design Methodology", Jean Paul Calvez, John Wiley & Sons, 1993 l "Method Integration- Concepts and Case Studies", Edited by Klaus Kronlof, John Wiley&Sons, 1993

161 Copyright  1995-1999 SCRA 161161 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Additional Reading l "Benchmark I Requirements", Alan H Anderson, MIT Lincoln Lab l "Executable Requirements Benchmarking," Alan H Anderson, MIT Lincoln Lab l EIA-IS 632 Standard l "Rapid Digital System Prototyping-Current practice, Future Challenges", V K Madisetti, IEEE D&T, Fall '96, pp18 l Richards M., Gadient A., Frank G., eds. Rapid Prototyping of Application Specific Signal Processors, Kluwer Academic Publishers, Norwell, MA, 1997 l Advanced Design Environment Prototyping Tool Tutorial, University of Virginia l "Role of Executable Specifications", Capt. Greg Peterson, Wright Labs l "Final Review", TRW, September 29, 1998.


Download ppt "Copyright  1995-1999 SCRA 1 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Copyright  1995-1999 SCRA All."

Similar presentations


Ads by Google