Transaction Level Modeling: An Overview

Slides:



Advertisements
Similar presentations
Synthesis of Protocol Converter Using Timed Petri-Nets Anh Dang Balaji Krishnamoorthy Manoj Iyer Presented by:
Advertisements

Design Methodology for Systems-on-Chip What is needed and what is not Daniel D. Gajski Center for Embedded Computer Systems University of California, Irvine.
SoC Challenges & Transaction Level Modeling (TLM) Dr. Eng. Amr T. Abdel-Hamid ELECT 1002 Spring 2008 System-On-a-Chip Design.
Copyright  2003 Dan Gajski and Lukai Cai 1 Transaction Level Modeling: An Overview Daniel Gajski Lukai Cai Center for Embedded Computer Systems University.
ECOE 560 Design Methodologies and Tools for Software/Hardware Systems Spring 2004 Serdar Taşıran.
Transaction Based Modeling and Verification of Hardware Protocols Xiaofang Chen, Steven M. German and Ganesh Gopalakrishnan Supported in part by SRC Contract.
February 28 – March 3, 2011 Stepwise Refinement and Reuse: The Key to ESL Ashok B. Mehta Senior Manager (DTP/SJDMP) TSMC Technology, Inc. Mark Glasser.
08/31/2001Copyright CECS & The Spark Project SPARK High Level Synthesis System Sumit GuptaTimothy KamMichael KishinevskyShai Rotem Nick SavoiuNikil DuttRajesh.
Software Testing and Quality Assurance
Mahapatra-Texas A&M-Fall'001 cosynthesis Introduction to cosynthesis Rabi Mahapatra CPSC498.
Spec-C, Handel-C, SystemC : A Comparative Study By: Nikola Rank 13 March 2006.
Copyright  2006 Daniel D. Gajski 1 Extreme Makeover of System Design Science Daniel Gajski Center for Embedded Computer Systems (CECS) University of California,
Copyright  1999 Daniel D. Gajski IP – Based Design Methodology Daniel D. Gajski University of California
1 An Exploration of the MPEG Algorithm Using Latency Insensitive Design EE249 Presentation (12/04/1999) Trevor Meyerowitz Mentored by: Luca Carloni.
1 Ivan Lanese Computer Science Department University of Bologna Italy Concurrent and located synchronizations in π-calculus.
Transaction Level Modeling Definitions and Approximations Trevor Meyerowitz EE290A Presentation May 12, 2005.
Visual Basic Introduction IDS 306 from Shelly, Cashman & Repede Microsoft Visual Basic 5: Complete Concepts and Techniques.
End-to-End Design of Embedded Real-Time Systems Kang G. Shin Real-Time Computing Laboratory EECS Department The University of Michigan Ann Arbor, MI
Transaction Based Modeling and Verification of Hardware Protocols Xiaofang Chen, Steven M. German and Ganesh Gopalakrishnan Supported in part by SRC Contract.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
1 Embedded Computer System Laboratory RTOS Modeling in Electronic System Level Design.
(1) Introduction © Sudhakar Yalamanchili, Georgia Institute of Technology, 2006.
Presenter : Cheng-Ta Wu Vijay D’silva, S. Ramesh Indian Institute of Technology Bombay Arcot Sowmya University of New South Wales, Sydney.
Principles Of Digital Design Chapter 1 Introduction Design Representation Levels of Abstraction Design Tasks and Design Processes CAD Tools.
Extreme Makeover for EDA Industry
New Strategies for System Level Design Daniel Gajski Center for Embedded Computer Systems (CECS) University of California, Irvine
Automatic Communication Refinement for System Level Design Samar Abdi, Dongwan Shin and Daniel Gajski Center for Embedded Computer Systems, UC Irvine
Model-Driven Analysis Frameworks for Embedded Systems George Edwards USC Center for Systems and Software Engineering
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
A Graph Based Algorithm for Data Path Optimization in Custom Processors J. Trajkovic, M. Reshadi, B. Gorjiara, D. Gajski Center for Embedded Computer Systems.
Performance evaluation of component-based software systems Seminar of Component Engineering course Rofideh hadighi 7 Jan 2010.
Design & Co-design of Embedded Systems Next Step: Transaction-Level Modeling Maziar Goudarzi.
Lyra – A service-oriented and component-based method for the development of communicating systems (by Sari Leppänen, Nokia/NRC) Traditionally, the design,
EEE440 Computer Architecture
Submodule construction in logics 1 Gregor v. Bochmann, University of Ottawa Using First-Order Logic to Reason about Submodule Construction Gregor v. Bochmann.
Unit 2 Architectural Styles and Case Studies | Website for Students | VTU NOTES | QUESTION PAPERS | NEWS | RESULTS 1.
Basic Concepts of Component- Based Software Development (CBSD) Model-Based Programming and Verification.
CprE 588 Embedded Computer Systems Prof. Joseph Zambreno Department of Electrical and Computer Engineering Iowa State University Lecture #5 – System-Level.
Verify 2003 System Debugging and Verification : A New Challenge Daniel Gajski Samar Abdi Center for Embedded Computer Systems University.
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Open Incremental Model Checking (OIMC) and the Role of Contracts Model-Based Programming and Verification.
Software Quality and Safety Pascal Mbayiha.  software engineering  large, complex systems  functionality, changing requirements  development difficult.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
Duminda WijesekeraSWSE 623: Introduction1 Introduction to Formal and Semi- formal Methods Based on A Specifier's Introduction to Formal Methods (J. Wing)
Lecture VIII: Software Architecture
System-on-Chip Design
Andreas Hoffmann Andreas Ropers Tim Kogel Stefan Pees Prof
Asynchronous Interface Specification, Analysis and Synthesis
Register Transfer Specification And Design
APPLICATION OF DESIGN PATTERNS FOR HARDWARE DESIGN
Chapter 3 Top Level View of Computer Function and Interconnection
Software Design Methodology
Communication-Based Design
IP – Based Design Methodology
Model-Driven Analysis Frameworks for Embedded Systems
Introduction to cosynthesis Rabi Mahapatra CSCE617
Logical architecture refinement
CS223: Software Engineering
Lesson 4 Synchronous Design Architectures: Data Path and High-level Synthesis (part two) Sept EE37E Adv. Digital Electronics.
Luís Ferreira Pires Dick Quartel Remco Dijkman Marten van Sinderen
CSSSPEC6 SOFTWARE DEVELOPMENT WITH QUALITY ASSURANCE
An Embedded Systems Course and Course
HIGH LEVEL SYNTHESIS.
CprE 588 Embedded Computer Systems
Mark McKelvin EE249 Embedded System Design December 03, 2002
Software Analysis.
William Stallings Computer Organization and Architecture 7th Edition
Top-Down Design with Functions
Presentation transcript:

Transaction Level Modeling: An Overview Daniel Gajski Lukai Cai Center for Embedded Computer Systems University of California, Irvine www.cecs.uci.edu/~{gajski, lcai}

Acknowledgement We would like to thank transaction level team at CECS that has contributed many ideas through numerous lunch discussions: Samar Abdi Rainer Doemer Andreas Gerstlauer Junyu Peng Dongwan Shin Haobo Yu

Overview Motivation for TLM TLM definition TLMs at different abstraction levels TLMs for different design domains SL methodology = model algebra Conclusion

Motivation SoC problems SoC solutions TLM questions This paper Increasing complexity of systems-on-chip Shorter times-to-market SoC solutions Higher level of abstraction – transaction level modeling (TLM) IP reuse System standards TLM questions What is TLM ? How to use TLM ? This paper TLM taxonomy TLM usage

TLM Definition TLM = < {objects}, {compositions} > Objects Computation objects + communication objects Composition Computation objects read/write abstract (above pin-accurate) data types through communication objects Advantages Object independence Each object can be modeled independently Abstraction independence Different objects can be modeled at different abstraction levels

Abstraction Models Time granularity for communication/computation objects can be classified into 3 basic categories. Models B, C, D and E could be classified as TLMs.

A: “Specification Model” Objects Computation -Behaviors Communication -Variables Composition Hierarchy Order Sequential Parallel Piped States Transitions TI, TOC Synchronization Notify/Wait

B: “Component-Assembly Model” Objects Computation - Proc - IPs - Memories Communication -Variable channels Composition Hierarchy Order Sequential Parallel Piped States Transitions TI, TOC Synchronization Notify/Wait

C: “Bus-Arbitration Model” Objects Computation - Proc - IPs (Arbiters) - Memories Communication - Abstract bus channels Composition Hierarchy Order Sequential Parallel Piped States Transitions TI, TOC Synchronization Notify/Wait

D: “Bus-Functional Model” Objects Computation - Proc - IPs (Arbiters) - Memories Communication - Protocol bus channels Composition Hierarchy Order Sequential Parallel Piped States Transitions TI, TOC Synchronization Notify/Wait

E: “Cycle-Accurate Computation Model” Objects Computation - Proc - IPs (Arbiters) - Memories - Wrappers Communication - Abstract bus channels Composition Hierarchy Order Sequential Parallel Piped States Transitions TI, TOC Synchronization Notify/Wait

F: “Implementation Model” Objects Computation - Proc - IPs (Arbiters) - Memories Communication -Buses (wires) Composition Hierarchy Order Sequential Parallel Piped States Transitions TI, TOC Synchronization Notify/Wait

Characteristics of Different Abstraction Models

Model Algebra Algebra = < {objects}, {operations} > [ex: a * (b + c)] Model = < {objects}, {compositions} > [ex: ] Transformation t(model) is a change in objects or compositions. Model refinement is an ordered set of transformations, < tm, … , t2, t1 >, such that model B = tm( … ( t2( t1( model A ) ) ) … ) Model algebra = < {models}, {refinements} > Methodology is a sequence of models and corresponding refinements

Model Definition Model = < {objects}, {composition rules} > Behaviors (representing tasks / computation / functions) Channels (representing communication between behaviors) Composition rules Sequential, parallel, pipelined, FSM Behavior composition creates hierarchy Behavior composition creates execution order Relationship between behaviors in the context of the formalism Relations amongst behaviors and channels Data transfer between channels Interface between behaviors and channels Verify 2003 Copyright Ó2003 Dan Gajski and Samar Abdi

Model Transformations (Rearrange and Replace) Rearrange object composition To distribute computation over components Replace objects Import library components Add / Remove synchronization To correctly transform a sequential composition to parallel and vice-versa Decompose abstract data structures To implement data transaction over a bus Other transformations . a*(b+c) = a*b + a*c Distributivity of multiplication over addition B2 B3 B1 = Distribution of behaviors (tasks) over components analogous to…… PE1 PE2 Verify 2003 Copyright Ó2003 Dan Gajski and Samar Abdi

Model Refinement Definition Ordered set of transformations < tm, … , t2, t1 > is a refinement model B = tm( … ( t2( t1( model A ) ) ) … ) Derives a more detailed model from an abstract one Specific sequence for each model refinement Not all sequences are relevant Equivalence verification Each transformation maintains functional equivalence The refinement is thus correct by construction Refinement based system level methodology Methodology is a sequence of models and refinements Verify 2003 Copyright Ó2003 Dan Gajski and Samar Abdi

Verification Transformations preserve equivalence Same partial order of tasks Same input/output data for each task Same partial order of data transactions Same functionality in replacements All refined models will be “equivalent” to input model Still need to verify first model using traditional techniques Still need to verify equivalence of replacements Model A Designer Decisions Refinement Tool t1 t2 … tm Library of objects Model B Verify 2003 Copyright Ó2003 Dan Gajski and Samar Abdi

Synthesis Set of models Sets of design tasks Profile Explore Select components / connections Map behaviors / channels Schedule behaviors/channels . Each design decision => model transformation Detailing is a sequence of design decisions Refinement is a sequence of transformations Synthesis = detailing + refinement Challenge: define the sequence of design decisions and transformations

Design Domains

SCE Experiment is Very Positive Source: http://www.cecs.uci.edu/~cad/sce.html

Conclusion Computation and communication objects of TLM are connected through abstract data types TLM enables modeling each component independently at different abstraction levels The major challenge is to define necessary and sufficient set of models for a design flow The next major challenge is to define model algebra and corresponding methodology for each application such that algorithms and tools for modeling, verification, exploration, synthesis and test can be easily developed Opportunities are bigger than anything seen before