University of Southern California Dissertations and Theses

A comprehensive framework for the specification of hardware /software systems

(USC Thesis Other)

A comprehensive framework for the specification of hardware /software systems

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content INFORMATION TO USERS This manuscript has been reproduced from the microfilm master. UM I films the text directly from the original or copy submitted. Thus, some thesis and dissertation copies are in typewriter face, while others may be from any type of computer printer. The quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandard margins, and improper alignment can adversely affect reproduction. in the unlikely event that the author did not send U M I a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note w ill indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are reproduced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps. ProQuest Information and Learning 300 North Zeeb Road, Ann Arbor, M l 48106-1346 USA 800-521-0600 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A COMPREHENSIVE FRAMEWORK FOR THE SPECIFICATION OF HARDWARE/SOFTWARE SYSTEMS Copyright 2001 by Diogenes Cecilio da Silva Junior A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (COMPUTER ENGINEERING) December 2001 Diogenes Cecilio da Silva Junior Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. U M I Number 3065848 UMI’ U M I Microform 3065848 Copyright 2002 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, M l 48106-1346 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. UNIVERSITY OF SOUTHERN CALIFORNIA The Graduate School University Park L O S ANGELES, CALIFORNIA 90089-1695 This d isserta tio n , w ritte n b y Diogenes Cecilio da Silva Junior__________ U nder th e d irectio n o f h ia... D isserta tio n C om m ittee, a n d app ro ved b y a d its m em bers, has been p re se n te d to a n d a ccep ted b y The G raduate School, in p a rtia l fu lfillm en t o f requ irem ents fo r th e degree o f D OCTOR OF PHILOSOPHY D o n o f G raduat e S t u d i es D ate nprpmher 17 . 2001_____ DI SSER TA TIO N COMMITTEE^ ^ _______________________ c b^ m Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Dedication To Eliane, Wife. Friend and Companion. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Acknowledgements I take this opportunity to express my sincere and deep appreciation to my Advisor. Prof. Alice C. Parker. This work could not be accomplished without her guidance and support through these years. She was always available to help with this research with fruitful discussions and encouragement, going beyond the role of an advisor and caring about our personal lives. More than an advisor, she became our friend. I would like to thanks Professors Peter Beerel and Ming-Deh Huang for serving in my defense committee and Prof. Sandeep Gupta for serving in my guiding committee. Their suggestions and comments were most valuable. I also would like to thank my colleagues and friend at U.S.C. for their friendship and support over these years. In special. I would like to mention Pravil Gupta, Chih- Tung Chen. Dong-Hyun Heo, Yosef Tirat-Geffen, Suhrid Wadekar, Sami Habib and Arani Sinha. I specially thank my parents, Diogenes C. da Silva (in memoriam) and Olga P. Silva, for their love and support, not withstanding personal sacrifices to provides us the best education. I also would like to thank my parents-in-law, Jair Rangel and Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Maria Magdalena Rangel, for their continuous support and care. To my beloved daughter Caroline, your life has replenished my hope in future. My deepest gratitude goes to my wife, Eliane Guimaraes Rangel Silva, for the love, support, encouragement and sacrifices throughout my graduate studies. She interrupted her professional career to help me pursue my academic goal. Without her daily presence I would have not succeeded. I dedicate this thesis to Eliane. I would like to specially thank a group of friends for the continuous support and encouragement to pursue this degree. Professors Jose M. da Mata. Antonio O. Fernandes. Clarindo de Padua and the special support from Claudionor Coelho Jr. here in the U.S. I also would like to thank the support from the Computer Science from the Federal Univ. of Minas Gerais. Brazil. I also would like to thank to a group of fellow Brazilians I have the opportunity to meet in Los Angeles and share our struggles being away from home and pursuing a higher education, in special Jose Renato and Ana Beatriz Santos, Fernando and Luciana Moreira. Otavio e Flavia Thiemann. Eduardo and Fernanda Esteves. and Monica Melle. I would like to acknowledge the financial support from the Conselho Nacional de Pesquisa. Brazil under grant CNPq 201211/91-2, and the Advanced Research Projects Agency under contract number 53-4503-9319/J-FBI-94-161. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table of Contents Dedication............................................................................................................ ii Acknowledgements.............................................................................................iii List of Figures..................................................................................................... ix List of Tables....................................................................................................... xi Abstract..............................................................................................................xii Chapter 1...............................................................................................................1 1.1 Motivation...................................................................................................1 1.2 Problem statement...................................................................................... 6 1.3 Overview of the Approach..........................................................................7 1.3.1 System Data Structure..........................................................................8 1.3.2 OSCAR...............................................................................................10 1.4 Rationale....................................................................................................1 1 1.4.1 Representation. Specification and Modeling...................................... 1 1 1.4.2 Design Representation........................................................................ 12 1.4.3 Verification........................................................................................ 13 1.4.4 System-level Design Activities...........................................................14 1.5 Thesis Organization...................................................................................15 Chapter 2 .............................................................................................................16 2.1 Languages..................................................................................................16 2.1.1 SDL.....................................................................................................17 2.1.2 Java.....................................................................................................18 2.1.3 VHDL.................................................................................................19 2.1.4 Verilog HDL...................................................................................... 20 2.1.5 SpecCharts.........................................................................................21 2.1.6 SystemC............................................................................................. 21 2.1.7 Rationale for Languages.....................................................................22 2.2 Software Systems.....................................................................................23 2.3 Software Architectures............................................................................. 23 v Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.1.6 SystemC............................................................................................. 21 2.1.7 Rationale for Languages.................................................................... 22 2.2 Software Systems..................................................................................... 23 2.3 Software Architectures............................................................................. 23 2.3.1 Wright................................................................................................ 24 2.3.2 Unicon............................................................................................... 25 2.3.3 Rapide................................................................................................ 25 2.3.4 Darwin............................................................................................... 26 2.4 Representation.......................................................................................... 26 2.4.1 Task Flow Graphs.............................................................................. 27 2.4.2 Related Representation Models......................................................... 27 2.4.3 Design Data Structure - DDS.............................................................29 2.5 Conceptual Modeling............................................................................... 33 2.5.1 Information Modeling....................................................................... 33 2.5.2 Data Modeling................................................................................... 35 2.6 Formal Verification of Concurrent Systems.............................................36 2.6.1 Temporal Logic................................................................................. 37 2.7 Process Algebra........................................................................................ 40 2.7.1 CCS....................................................................................................40 2.7.2 CWB..................................................................................................42 Chapter 3 ........................................................................................................... 43 3.2 Properties of a System.............................................................................. 46 3.2.1 Abstraction........................................................................................ 47 3.2.2 Separation of Concerns...................................................................... 49 3.2.3 Redundancy Minimization................................................................ 54 3.2.4 Diverse Design Methodologies......................................................... 54 3.2.5 Model of Computation and Support for Correctness......................... 56 3.2.6 Requirements and Constraints........................................................... 56 3.3 System Primitives..................................................................................... 57 3.3.1 Behavior............................................................................................ 58 3.3.2 Communications and Synchronization...............................................59 3.3.3 Data Structures.................................................................................. 60 3.3.4 Storage............................................................................................... 62 3.3.5 Non-Functional Primitives................................................................ 63 Chapter 4 ........................................................................................................... 65 4.1 The Components....................................................................................... 68 4.1.1 Models of a Component.................................................................... 69 4.2 The Formal Definition.............................................................................. 70 4.2.1 The Four Domains............................................................................. 70 vi Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.2.2 Process Flow Domain........................................................................ 72 4.2.3 Timing and Sequencing Row Domain............................................... 75 4.2.4 Logical Structure Domain..................................................................77 4.2.5 Physical Structure Domain.................................................................78 4.3 Bindings.................................................................................................... 79 4.3.1 Behavior Bindings............................................................................. 79 4.3.2 Realization Bindings......................................................................... 81 4.3.3 Binding Hierarchical Objects.............................................................82 4.4 Timing Predicates..................................................................................... 83 4.4.1 Synchronous Deterministic Choice Predicates...................................84 4.4.2 Synchronous Loop Predicates............................................................86 4.4.3 Asynchronous Predicates....................................................................86 Chapter 5 ............................................................................................................90 5.1 Object Semantics...................................................................................... 90 5.1.1 Hierarchy...........................................................................................95 5.2 Process Row Domain............................................................................... 96 5.3 Timing/Sequencing Row Domain.......................................................... 102 5.4 Logical Structure domain........................................................................105 5.5 Physical Structure Domain......................................................................108 5.6 Bindings...................................................................................................111 5.7 Timing Predicates....................................................................................115 5.8 The Reference Class................................................................................116 5.9 Information Detailed Representation...................................................... 117 5.9.1 Persistency of Information............................................................... 118 5.9.2 Information Representation.............................................................. 121 Chapter 6 ...........................................................................................................128 6.1 Petri Nets.................................................................................................129 6.2 Syntax-directed Translation....................................................................134 6.2.1 Translating SDS Descriptions into Petri Nets.................................. 136 6.2.2 Sequential Composition....................................................................137 6.2.3 Parallel Composition........................................................................137 6.2.4 Choice.............................................................................................. 138 6.2.5 While Loop...................................................................................... 140 6.2.6 For Loop.......................................................................................... 141 6.2.7 Wait or Synchronization...................................................................143 6.2.8 Asynchronous Predicate...................................................................144 6.2.9 Linking Subnets................................................................................146 6.3 Translation Validation............................................................................ 147 vii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 7 ........................................................................................................... 149 7.1 Specification Issues at the System-Level.................................................151 7.1.1 Languages......................................................................................... 151 7.1.2 Representation.................................................................................. 152 7.2 Problem Approach................................................................................... 153 7.3 OSCAR - Visual Language.................................................................... 155 7.3.1 Tasks................................................................................................. 159 7.3.2 Ports.................................................................................................. 161 7.3.3 Connectors........................................................................................ 162 Chapter 8 ........................................................................................................... 163 8.1 Conclusions............................................................................................. 163 8.2 Future Work............................................................................................ 165 References......................................................................................................... 167 viii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. List of Figures Figure 1.1: System-level design steps..........................................................................3 Figure 2.1: The DDS domains and relatioships..........................................................30 Figure 2.2: DDS data-flow graph and its simplified information model................... 34 Figure 4.1: a) A block-diagram system description, b) The SDS model overview, from block-diagram to the four domains representation....................................68 Figure 4.2: The synchronous predicate template....................................................... 85 Figure 4.3: The asynchronous predicate template......................................................89 Figure 5.1: SDS domains and object type Relations..................................................91 Figure 5.2: Types and super-types relations for models and links.............................92 Figure 5.3: Process Flow Domain information model, a) Process flow view, b) Corresponding information model.....................................................................94 Figure 5.4: Process flow domain types, (a) Model type, (b) Link type......................97 Figure 5.5: Process flow domain information model attribute examples................. 101 Figure 5.6: Partial SDS textual representation of Figure 5.5. Only process flow domain sub-components are represented here..............................................101 Figure 5.7: Timing/sequencing Flow Domain types................................................ 104 Figure 5.8: Logical Structure Domain types............................................................ 109 Figure 5.9: Physical Structure Domain types...........................................................110 ix Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 5.10: Binding types....................................................................................... 112 Figure 5.11: Binding objects on LSD and PSD........................................................114 Figure 5.12: Timing Predicate types........................................................................ 116 Figure 5.13: The reference class and its types..........................................................119 Figure 5.14: Array representation in SDS................................................................ 122 Figure 5.15: Example of a data structure of type RECORD and its composition by aggregation....................................................................................................... 123 Figure 5.16: SDS representation for data structure of type RECORD..................... 124 Figure 5.17: A stream of a video frame represented in the LSD and TFD...............126 Figure 6.1: An illustration of a transition firing, (a) initial state: (b) final state.......131 Figure 6.2: Example of (a) a Free-choice Petri net: (b) not a Free-choice Petri net. 134 Figure 6.3: Sequential composition..........................................................................138 Figure 6.4: Parallel composition.............................................................................. 139 Figure 6.5: Choice composition............................................................................... 139 Figure 6.6: The while loop construct........................................................................141 Figure 6.7: For loop construct................................................................................ 142 Figure 6.8: Wait construct........................................................................................144 Figure 6.9: The asynchronous predicate...................................................................146 Figure 7.1: View of the coordination in OSCAR.....................................................157 Figure 7.2: An OSCAR screen.................................................................................159 x Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. List of Tables Table 2-1: A brief comparison of major language characteristics............................. 22 Table 2-2: CCS basic operators................................................................................. 41 Table 3-1: List of properties of a system................................................................... 47 Table 3-2: List of system primitives..........................................................................57 Table 5-1: Object semantic relationship.................................................................... 95 Table 6-1: some typical interpretations for Petri net objects.................................... 130 Table 6-2: SDS to Petri net translations properties...................................................147 xi Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Abstract This dissertation presents the design and analysis of a system-level representation SDS. and a user interface to SDS. OSCAR. SDS is first presented conceptually and then defined precisely in terms of an information data model. The translation of SDS to Petri nets is presented, and small Petri nets representing SDS constructs are verified. SDS represents a broad range of system properties including functionality, timing, communication, concurrency, requirements and constraints. SDS is hierarchical, represents behavior as well as structure, supports separation of concerns, supports verification, supports a wide range of design styles, minimizes redundancy, can represent a system at various design stages, and can capture physical constraints. SDS has its roots in the USC Design Data Structure DDS. First, a set of properties of a good system representation is defined. This set covers properties that make a system representation comprehensive, neutral and unified. SDS embodies the properties discussed. From this set of properties, a set of primitives is defined. This set of primitives is broad enough to represent a large range of systems and covers diverse aspects such as behavior, logical structure and physical structure. This set of primitives forms the basis of SDS. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. SDS is defined in a formal graph theoretical manner. An information model is presented based on the graph theoretical definition. This information model enriches the graph model with ancillary information while maintaining the rigorous definition of the graph model. It enables SDS to be implemented in a computing system, allowing tools to analyze and synthesize designs. SDS primitives can be translated to a range of formal models enabling the verification of behavioral properties, like liveness and safety. It also enables the verification of synthesis design phases. In this work SDS was translated to Petri nets and analyzed with an automatic tool (INA.) OSCAR is a visual interface to SDS with a formal semantics and syntax based on a visual coordination language paradigm. It is used to capture the behavior and the coordination aspects of concurrent and communicating processes. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 1 Introduction 1.1 Motivation Current system designs are complex and demand high development efforts. Projections point to a continuous increase in the complexity in years to come [Keutzer et al.. 2000]. The market for those systems requires new products with shorter development time. These two forces combined demand new products that are correct, complex and delivered in a short time. A system is a collection of independent operational components that may cooperate to accomplish a more complex task. Examples of system designs range from cellular phones, to camcorders, and to satellites. The design of systems is comprised of many different tasks: most of them can be automated. One important property of a system-level design specification is implementation independence, giving latitude of possible realizations under the given constraints. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. System-level design steps span from the conceptual phase to the concrete or physical piece of hardware and/or software that realizes its functionality. System design can proceed top-down, bottom-up. most constrained portion first, least constrained portion first, or some combination of these approaches. The top-down approach is similar to Software Engineering’ s Waterfall model [Boehm. 1981], but in this case each step refines the conceptual design towards the implementation, as shown in Figure 1.1. In addition, most system design activities also involve some bottom-up design activities as shown in the figure. In the scope of this work, a synthesizable algorithmic description of each process is the final target of the top- down design process, since from this point high-level synthesis tools will be able to generate an implementation in hardware. Due to the complexity of most systems and the large amount of information to be captured by a system-level specification, the earlier an error is detected in the design cycle the faster each design cycle is. To avoid dealing with a large amount of information usually only necessary details are captured, i.e. only the functionality and behavior that is not implementation-dependent or might overly restrict the possible implementation options. With this information, validation checks can be made in order to assert the design properties captured and avoid later redesigns that are usually very costly. As these conceptual errors are fixed early, the refinements steps can add more details to the specification, substantially relieving the designer of redesigns due to conceptual errors. 2 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. concept analysis and refinem ents physical informatiol (cost, sp eed , etc.) implementation idea algorithmic design le ss abstract design more abstract design Figure 1.1: System-level design steps. It is virtually impossible to design a system by starting with something that is free of any architecture. Systems that are specified and analyzed based on a structure-free paradigm usually rely on some sort of casting of this description into a pre-defmed set of possible architectures. This approach severely reduces the choices of implementations and may not guarantee an optimal design. To improve the quality of design an implementation-independent language and representation are necessary. Digital hardware description languages (HDL) were not developed to deal with complex system-level designs. In order to fill the gap from concept to a formal specification, different approaches have been proposed. During the conceptual or 3 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. more abstract phases the most common approach is the use of block-diagrams to graphically refine abstract designs. The problem with block-diagrams is their usual informal semantics. Blocks and lines can have different meanings from diagram to diagram, and even worse in the very same diagram. Furthermore, blocks alone cannot express completely the intended behavior and do not include features such as timing information, design constraints and communication support. Although the USC DDS [Granacki. 1987; Knapp and Parker. 1985] is a rich and unified representation, it is intended for a lower level in the design process that demands a large amount of details that makes it hard to be used at the system level. During the design of a digital system, it is important to determine whether the specification of the system has the intended functionality. Much progress has been made in the formal specification of software systems, but less progress has been made on systems that are composed of hardware and software, or are purely hardware. Recent efforts have focused in the underlying model of computation used in the specification. A precise and formal model of computation allows verification of important properties of a system, such as the absence of deadlock. Most system specifications are informal, either in natural language or in block-diagram form. Informal specifications cannot be easily validated, since the semantics of the specification language are imprecise. Formal methods are languages, techniques, and tools having a strong mathematical foundation for specifying or describing systems [Clarke et al., 1996]. This basis provides the means for defining consistency and completeness [Wing, 4 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 1990]. The use of formal methods does not guarantee a priori correctness. When used early in the development they can identify design flaws that would otherwise not be discovered until later. After development, formal methods can be used to check correctness of the implementation against the specification and to check the equivalence of different implementations. Formal methods used in the specification can become an important piece of documentation and form part of the communication among the client, the designer, and the tester. An additional advantage of formal methods is the fact that formal methods are usually amenable to mechanical analysis and manipulation. Some aspects of systems, such as deadlock and concurrency, are modeled quite well using variants of the Petri net [Peterson. 1977], and process algebra variants like CSP [Hoare, 1978], and CCS [Milner, 1980]. However, comprehensive formal models of hardware systems at a more abstract level are yet to be developed. Verification of system-level designs requires the use of a framework where important views of a design are formally presented. Current HDLs, albeit formal, do not address all system-level aspects. Ad hoc extensions to languages tend to be less formal or narrowly restricted to some constructions and lacking a minimal generality. Not only the description language but also the internal representation must be formal and comprehensive. Usually internal representation schemes are defined with synthesis only as the ultimate goal: such schemes are not necessarily applicable when verification or validation is the goal. 5 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. U Problem statement The objective of this work is to define a formal framework for the specification of hardware and/or software system designs. To overcome the limitations presented above, we have defined a system-level representation SDS to address the following aspects: • Comprehensive representation. • Clear separation of concerns regarding important properties of a system, e.g. computation and communication, behavior and structure, and functionality and timing, • Precise and formal model of computation. • Support for design validation and verification. • Support for a broad range of system properties, • Implementation independence with no enforced design decisions, rather support for make them. • Ability to represent designs at various design stages, and • Ability to capture a broad range of system requirements, namely, functionality, timing, logical structure and physical structute and constraints. To make this representation useful a data model has been defined containing the information model of SDS. This information model can be easily implemented in a computer system. This representation was translated to a formal mathematical Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. model, namely Petri nets, and its primitives were analyzed against some fundamental properties. To properly specify a general system we have designed a visual system description language based on block diagrams called OSCAR. 13 Overview of the Approach We have developed an external block-diagram language (OSCAR) and an internal representation (SDS) that have a formal basis in a semantic definition. The language and internal representation are being used to verify some aspects of system correctness not covered by other formal models. To cope with the inherent complexity of systems we propose to view systems as a composition of cooperating and communicating processes. To improve and emphasize this distinction we have enforced the separation of concerns between computation and communication. This view implies that the module in a block- diagram is the locus of functionality and it communicates with other modules through ports. Although simple, this approach can capture an abstract view of systems. To accomplish this a multi-level specification is necessary. A single level of abstraction would be either too complex and maybe inconsistent in itself, or even incomplete. Moving from a more abstract to a more concrete domain requires different approaches to capture the knowledge of the system. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The communication and concurrency are captured using a coordination visual language, and the computations and more detailed descriptions are captured using a textual language. The former language provides for a more abstract view where not all details are relevant and the latter for a more concrete view where visual or iconic languages tend to be too complex. Underlying all these views is a formal representation in order to avoid ambiguity and inconsistency. The communication model is based on a message-passing paradigm. Message passing is an abstract and neutral approach to concurrency and other methods can be easily derived. 13.1 System Data Structure SDS is intended to be an internal representation capable of capturing the client's desires and designer's knowledge of a system in a unified, formal and comprehensive data structure. This data structure can then be examined by analysis and synthesis tools. Although completeness of a system-level design is a necessary condition for behavioral synthesis. SDS does not guarantee such a property but enables designers to capture partial specifications and eventually, as the designer provides more details, represent a complete design to be synthesized. SDS supports a number of system design approaches, including top-down and bottom-up designs. The top-down design approach captures the dynamic behavior of a system by refining a conceptual view of the system in terms of more detailed components. The dynamic behavior is represented in SDS by the independent domains of Process Flow and Timing/Sequencing Flow. 8 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The bottom-up design approach captures the structural and static view of a system by composing components in order to obtain components that are more complex. It is represented in SDS by the Logical Structure and the Physical Structure domains. These domains are almost independent of each other and to the two other domains. An important aspect of SDS is the capability to represent not only information transferred between processes but the structure of the information, analogous to that defined by data structure commands in programming languages. Information may be represented by both extremes in terms of abstractness, the abstract data type (ADT) structural definition and the physical constraint of the size of a memory bank. In the SDS a system has explicit relationships called bindings from its behavior domain to its timing domain, thus the data structure can have bindings from its representation in the Process Row Domain to the Timing/Sequence Row Domain, and thus exhibit dynamic properties, representing a message packet or a stream of a video frame. For example, if the data structure is hierarchical, each sub-block can have its own binding providing a complete dynamic description. The scope of SDS ranges from an abstract design captured as a block diagram to a collection of connected processes to a full description of all processes and channels. If a full description exists, a designer is able to use high-level synthesis tools or manual design to synthesize RTL designs. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 132 OSCAR OSCAR is a block-diagram language used to capture system-level designs in a graphical environment Although this tool defines a structured description that denotes an architectural view of the system, it does not impose any architectural final realization. The basic objects are Tasks represented by circles and boxes. Ports represented by dots, and Connectors represented by lines. Tasks are the placeholders for processes that realize the intended behavior. Tasks can be subdivided into physical and purely behavioral modules. In order to communicate and synchronize, processes send and receive messages or signals. Ports are used to characterize process borders and define observable events. Each port is linked to a communication/synchronization primitive in the behavioral code. Ports also convey time and control/sequencing information. Connectors describe the dynamic interconnection of modules. Connectors represent an abstraction of a protocol with communication patterns, message vocabulary, data types and timing and temporal information. OSCAR declares types, instantiates elements, and describes interconnections among instantiated elements. Type declaration gives context independence to elements. The semantics for an element can only be extracted from its declaration. A new type can be specialized from a library maintaining some invariants. Instantiated elements separate declared types from their use, and allow the possibility to use replicate elements of a given type, enriching the specification power. Connectors 10 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. “link" the elements without the necessity of name matching, allowing the description to be constrained and providing a high-level abstraction of the system. 1.4 Rationale 1.4.1 Representation, Specification and Modeling A design representation can be used to express two major views: a specification or a model of a system. The specification describes the intention and the model describes the realization. Specification languages describe the designer's desire expressing “what I want": whereas modeling languages describe “what the system will do." A model of a given system will say what is the delay from input to output, but a specification will state the expected maximum delay. Modeling languages are usually declarative, and describe a system as a collection of properties or characteristics. Most hardware languages have aimed at modeling the design and historically it is due to the need to simulate the behavior. Initially the simulated systems were small and physical properties could be examined. As circuits became complex, these simulations became costly and HDL models, originally designed for simulation, are now interpreted as specifications. A specification language primarily describes behavior and is often imperative. It is usually used to abstract details and present a simpler, clearer description of a more complex behavior. Programming languages are a good example of such languages, 11 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. where a simple high-level command is translated into a collection of many small instructions. Recent technological advances have blurred the differences between hardware and software, and both are now very complex. New technologies have also demanded the use of tools to help design specific hardware/software systems known as embedded systems, system-on-a-chip (SoC) and hardware-software codesign. On the HDL side, a demand for a specification language has spurred a series of proposed system-level languages. Programmable logic permits a single component to perform either an application-specific function or a microprocessor, and even further a reconfigurable processor. Thus, a common specification with support for distinct models is desirable. SDS is a data structure able to represent a specification and possible implementation models in a unified way. SDS. as a representation, can represent both views and will serve as an interface between these two views. An specification will be translated into an intermediate form that is not dependent on a single realization. 1.4.2 Design Representation Representation of digital designs is an often-neglected aspect of research and very few approaches have been proposed in the literature to our knowledge. Our research is based on the DDS, Design Data Structure, developed at U.S.C., which spans from high (or algorithmic) to physical levels [Afsarmanesh, 1989; Chen, 1994; 12 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Granacki. 1987; Hayati. 1990; Knapp and Parker. 1985]. DDS is a unified and neutral representation based on four domains or axes that are almost independent of each other, hierarchical, and is self-contained. Both specification and implementation are represented. There are bindings linking domains in order to relate them. e.g. an addition operation to an ALU. The separate domains bring a simple consistency and little redundancy. DDS is well suited for high-level designs because it represents designs from RTL down to the physical level. At the system level however not all the information and detail represented in DDS is necessary. Furthermore, some important system-level concepts, albeit present in DDS. are not explicitly or readily available and can be expressed in more than one way out of many possibilities. This sets the stage for a specific representation scheme that addresses system-level issues and provides information for easy design checks at this level. 1.43 Verification Whether a design is correct, consistent or complete is a property of the design itself. Validation and verification are different techniques used to ascertain such properties. Some properties can be checked against a set of rules and others are checked against a model assumed to be correct. Validation involves the analysis of static aspects of the system. The consistency of a description can be validated using a formal language to capture the design. In this way communication port resolution, interconnection resolution, data resolution, 13 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. and message-type resolution can be thought of as in a compiler, a syntax checker based upon a set of design rules. Verification is used to check dynamic aspects of a system, such as communication patterns, interconnection compatibility and general system properties such as liveness and safety. SDS supports validation as well as verification. 1.4.4 System-level Design Activities At the system level, a design is defined as a collection of multiple autonomous processes that can communicate and cooperate. A system has an interface through which it communicates with the external world. Several activities must be performed before a described system can be synthesized. The functional specification must be validated against rules of composition, for example, all interconnections are correct and the data types are compatible. That same functional description must also satisfy some properties to ensure correct behavior, such as “ ‘bad things cannot happen” and “good things must happen." Structural and physical requirements must also be met in order to the system be realized. For example, a given function is computationally intensive and demands a large amount of processing power and there is not enough space on the intended device, thus requiring the partitioning into smaller pieces. Finally, each process or sub-processes must be converted to a physical design. According to the described requirements and constraints, processes can be realized as hardware, software or a composition of both. At this stage of the design high-level tool may be 14 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. used to compile algorithmic specifications into either hardware or software components. l i Thesis Organization This thesis is organized as follows. This Chapter presented an overview of this thesis. Chapter 2 is a review of related works on system specification and representation, specification languages and formal methods. Chapter 3 elaborates a set of system design requirements for a good representation. A minimum list of properties are listed and discussed. In order to obtain these properties a list of primitives are present and discussed. Chapter 4 presents the conceptual model of SDS in a graph theoretical approach. Each domain is formally defined, and the bindings are formally defined. Chapter S presents an object data model for a machine implementation. Chapter 6 presents the translation of a subset of SDS primitives to Petri nets and provides an analysis on some important properties for each primitive. Chapter 7 describes the visual language OSCAR. The main factors driving the need for that approach are presented. The semantics and visual syntax are described. OSCAR should be understood as a view on SDS. Chapter 8 presents the conclusions and outlines future research directions. 15 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 2 Related Research In this chapter, a number of related research efforts are presented. They are divided into four major areas: languages and frameworks for specification of hardware and software systems, digital design representation, and formal methods. Some research directly relevant to the research is described in the appropriate chapters. Recently there has been an increasing interest in the areas of specification, representation and verification of hardware/software systems [Edwards. 2000]. There are no references in the literature that describe a comprehensive representation like SDS. 2.1 Languages In the Electronic Design Automation (EDA) field there are many specification models known and currently used. They are used mostly to specify the behavior of systems. They can be grossly grouped into categories such as graphical languages, imperative languages, functional languages, and synchronous languages. The 16 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. majority of HDLs are intended to describe RTL behavior with some including algorithmic or high-level behavior. Worthwhile representatives for each groups include: graphical languages such as SpecCharts [Gajski et al., 1992] and SDL [ITU- T. 1993]: imperative languages such as VHDL. Verilog HDL, HardwareC [Ku and DeMicheli. 1990], ISPS [Parker et al., 1979], and SLIDE [Parker and Wallace. 1981]: functional languages such as Silage [Hilfinger. 1985]: and synchronous languages such as Signal and Esterel [Boussinot and Simone. 1991]. A direct consequence of the intended target of the above languages is the lack of system-level features such as communication and synchronization mechanisms, program modularity, and non-functional aspects such as timing, area and power constraints. This lack of system-level features has led some groups to combine different languages to cover a broader range of systems [Ernst and Jerraya. 2000: Jerraya et al.. 1999]. In the following paragraphs, a few representative languages are discussed in more detail. 2.1.1 SDL SDL (Specification and Description Language) is an ITU-T standard language [ITU-T, 1993] widely used in telecommunication systems to specify protocols and services. SDL is a formal specification language based on communicating extended finite state machines. It provides structuring information in the form of blocks that may be composed by other blocks, channels and signals or refined in terms of 17 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. procedures, services, macros, and channels and signals. The 1992 version also includes object-oriented constructions. Communication is handled by a message- passing mechanism based on asynchronous signals sent via FIFO channels. A SDL description is hierarchical when only blocks and channels are used, and when a block is refined into primitives like procedures and statements the block becomes a leaf and cannot be refined further. 2.1.2 Java Java is a general-purpose, object-oriented, platform-independent and strongly typed language [Gosling et al., 19961. Influenced by C++, it differs because its object-orientation is cleaner and simpler, and the inheritance mechanism is simplified. It is a simpler language because Java has no explicit memory manipulation (pointer), no manual deallocation, and uses standard libraries [Rosenstiel and Weiier. 1997], Although the language is designed for software systems, it has attracted the attention of embedded systems designers, mostly because they are looking for a single language to specify both the hardware and software parts [Helaihel and Olukotun, 1997]. Java offers the user threads, through a class, with a set of primitives. However. Java suffers from serious drawbacks that make it hard to use. The first one is the inherent sequential nature of the language, which is common to any object- oriented language. In other words, one cannot execute two different methods within the same object, and since the object is the primary element of program modularity, 18 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. it becomes more difficult to model hardware properly. The second drawback is the performance issue. Java code is at least one order of magnitude slower than C/C++ code because the language is interpreted over a virtual machine (JVM) that gives platform independence [Lindholm and Yellin. 1996]. Interpretation is also responsible for making timing estimations almost impossible. Still, few static decisions are made, and in fact, they are made at run time and garbage collection is executed without user control. Finally, concurrency is at a coarse-level, only provided by the thread class. Synchronization, however, is supported at a lower level using monitors. 2.13 VHDL VHDL (VHSIC Hardware Description Language) is an attempt to bring together two separate tasks in EDA. namely simulation and specification. Based on the ADA language. VHDL inherits modularity, inheritance and operator overloading. Programmers can define libraries of data structures and operators and selectively import/export them. The basic data type is the bit. Some libraries extend this set to include composite types such as byte, integer and user-defined word sizes. A VHDL program defines one entity and one or more architecture bodies. The entity specifies the input/output ports that the behavior uses to communicate with the exterior world. The architecture bodies can be described in a structural, behavioral or data-flow language. There is a special type called signal that resembles global variables in programming languages. 19 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. There is the notion of a process that can be re-executed when the value of one in a list of variables or signals is changed. Process communication is performed by exchanging values through signals, or can be abstracted by defining Send and Receive functions that can then be simulated, but there is no standard synchronization primitive. In other words, it is up to the designer to decide and describe the communication mechanism. Synchronism is supported at two levels, at the process level by the use of a sensitivity list that lists variables and signals that triggers the re-execution of that process, and at the statement level by the use of the wait command. The simulation aspect of VHDL defines dynamic or temporal semantics that involves a two-dimensional space where internal evaluations are first performed and then the system clock is advanced. 2.1.4 Verilog HDL Verilog was influenced by the C language and supports specification and simulation modes. Unlike VHDL, modularization is not well defined and overloading is not present. A major limitation of Verilog is the lack of a strongly typed syntax. In contrast with the other languages, it does offer an exception handling primitive with the statement disable which disables the current sequential block and transfers the control to the next statement that follows that block. Similar 20 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. to VHDL communications can be emulated/simulated using global signals and explicit statements in a low-level way. for example @(negedge) clock 10 q = d: which means that ten units of time after the negative edge of clock the value of d is assigned to q . 2.1.5 SpecCharts Derived from Harel’ s Statecharts [Drusinsky and Harel. 1987: Harel, 1987], SpecCharts are targeted to reactive and control-oriented systems [Gajski et al., 1992: Vahid et al., 1995]. Internally the system is represented by a set of communicating finite state machines (FSM). The various processes are synthesized and the output is a VHDL file. Hierarchy is supported through the composition of behaviors. One shortcoming of this approach is the user-defined structure of communicating FSMs. Since the leaf nodes are pure sequential VHDL code the designer must perform this refinement step. Synchronization and communication are the same as VHDL with the addition of two special transitions from a behavior, TI (transition-immediately) and TOC (transition-on-completion). The former transition can be used as a kind of synchronization primitive. 2.1.6 SystemC SystemC is a subset of the language C++ augmented with a set of libraries aimed at the specification, simulation and synthesis of digital hardware. It was influenced 21 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. by VHDL and Verilog HDL and uses global signals, an abstraction of physical wires, to provide for the synchronization among processes. Processes have similar semantics to the VHDL and Verilog processes. Although SystemC provides a better programming environment than that of Verilog. it does not address true system-level features. 2.1.7 Rationale for Languages The current set of HDLs does not address some important system-level features. Overall, communication and synchronization features resemble physical systems and are more adequate to model designs at the register level. These HDL's are aimed at the simulation. However, some of these languages can describe the computation of processes well: and thus can be used as host languages in a system-level framework, leaving the communication and synchronization to be supplied by a coordination language. Table 2-1 provides a brief comparison of these system-level features. Table 2-1: A brief comparison of major language characteristics. Language System level features Program Modularity Type Checking Communication Synchronization Java Yes Strong Shared memory Monitors V H D L Yes Strong Shared memory Global signals Verilog H D L No Weak Shared memory Global signals SpecCharts No No Shared memory and m essages Signals and blocking channels SDL No Yes M essage passing Global signals SystemC Yes Strong Shared memory Global signals Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 23 Software Systems In the software domain, systems specification software engineering provided some tools like CASE. Object-Oriented Analyses and specification languages like Z and VDM to help designers. A recent research area is software architectures which is concerned with software system structure: software organization, the role of components, and the assurance of component's interaction [Shaw and Clements. 1996]. 23 Software Architectures Software Architecture has been a very active research field in Software Engineering. Its goal is to provide a formal way of describing and analyzing large software systems. In general, a system can be described by a collection of components and interactions among them. Abstractly, software architecture involves the description of elements, patterns that guide the composition, and constraints on these patterns [Shaw et al.. 1995]. One key highlight of this research is the case of style and pattern stressed by the CMU group [Garlan. 1995: Shaw and Garlan. 1994]. Systems are too complex to be described by a single language. They are usually described in recurring organizational patterns and idioms, called styles by Garlan. A generic system organization may be described by a language, but specific requirements may not. Domain-specific requirements lead to the use of idioms to better express and 23 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. differentiate among the requirements. Styles can also be seen as families of architectures that adopt a common set of design constraints that can provide a basis for analysis and reuse [Garlan et al., 1994]. Although Module Interconnection Languages (MIL) and Interface Definition Languages (IDL) [Prieto-Diaz and Neighbors. 1986] have been available for quite some time, they do not characterize the relationships between components, semantics of interconnections or analysis capabilities. Another important aspect of research is the importance of connectors. Connectors abstract the interconnection of components. They require a well-defined description and semantics just as the components do[Allen and Garlan. 1994], 2.3.1 Wright Wright is an ADL (Architecture Description Language) defined by Allen and Garlan [Allen and Garlan. 1996] to formally describe and analyze connectors. The formal basis is a subset of CSP [Hoare. 1978] used to describe the dynamics of interconnections. This specification is then used to verify if a component’ s port is compatible with a connector’ s port (called role in Wright), and to verify some other properties. Both components and connectors are considered first-class objects and must be declared and instantiated. Components have ports and connectors have roles to communicate. The glue specifies how these entities relate to each other. Further dynamic aspects are made explicit in a spec declaration that gives temporal 24 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. information. Raising the importance of connectors in a system, Wright gives functionality to ports through the definition of a role, where a vocabulary is accepted. The interplay of these words describes a pattern of relationship captured in the glue section. The last section spec adds a new dimension to the temporal description abstracting the behavior, allowing the kind of temporal verification present in temporal logics. 2-3.2 Unicon Unicon [Shaw et al.. 1995] is a language intended to describe the structures of software systems. The focus is on compiling architecture descriptions and modules into an executable code. Unicon is an abstract description that addresses connectivity in terms of locally available connection types, for example pipes in a Unix system, discriminates between different components and connectors, and checks the configuration. Unicon provides a language where the syntax supports a set of well- defined objects with known attributes. It supports composition for components only. 133 Rapide Rapide [Luckham et al., 1995] is an event-based, concurrent object-oriented language designed for real-time/concurrent systems. The main difference from the other works cited above is Rapide s execution model, which is based on a posef a partial ordered set. A simulation environment is also part of this system from which 25 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. analysis tools can be used. The communication patterns can be described but there are no compatibility checks or verification. 2-3.4 Darwin Darwin [Magee and Kramer. 1995] is a declarative language intended to configure systems with dynamic and static structures. Dynamic structures evolve as execution progresses either by internal or external activation. The system is composed of components, which provide or use services, and are connected by bindings. Components after declaration can be instantiated statically replicated and conditionally configured. Darwin is internally modeled in the pi-calculus [Milner et al.. 1992]. which is a calculus for describing and analyzing concurrent systems with evolving communicating structure. This latter characteristic makes the pi-calculus more appropriate than either CSP or CCS as a formal basis. 2.4 Representation Several models are used to represent digital designs. The most common is a graph representation where functionality, sequencing, timing and sometimes resources are modeled. Some frameworks combine languages and tools and integrate different languages and models of computation. Ptolemy [Kalavade, 1995] is a framework that supports a variety of description languages and models of computation while maintaining a uniform and coherent analyzing and simulation 26 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. tool. We will focus on general task flow graphs, related system representation models and on the USC DDS. 2.4.1 Task Flow Graphs For system-level designs a general abstract method of description is Task-Flow Graphs (TFG). where the vertices represent tasks or computation units, and edges represent data or control flow and associated information, such as bandwidth, rate, and delay or time interval. At the behavioral or algorithmic level, a usual form of TFG is the so-called CDFG (Control and Data Flow Graph). Both flows are embedded in a single graph, where nodes represent states and operations and edges represent data-flow, time sequencing and timing requirements. The Task Flow Graph (TFG) is a very common yet informal way of representing or specifying systems. Along with block diagrams, their semantics vary from system to system. A simple literature survey in our research group shows that in four system-level tools at USC there are four different semantics for TFGs [Chen. 1994; DeSouza-Batista and Parker, 1994; Heo et al., 1997; Prakash, 1993]. 2.4.2 Related Representation Models A few representation models in the literature provide for system design representations. Most of the representations model the behavioral aspect of designs only. The most recent attempts also take into account the separation of concerns and make a clear distinction between functionality and timing. They also attempt to use a 27 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. layered approach to provide a functional hierarchy [Edwards et al., 1997: Lavagno et al.. 2000: Sander and Jantsch. 1999: Vermeulen et al.. 2000]. The Y chart model [Gajski et al., 1994] is a threefold representation of designs and uses three distinct domains: structural, functional and geometrical domains. The synthesis process is represented as a path from the functional to the structural to the geometrical domains axes. Refinement is modeled as a path over the same axis towards the axes origin. In this model there is no clear representation for time and concurrency. Design Cube [Ecker et al., 1996] models designs described in VHDL. It is aimed at representing design using three views: the view of the model, timing property and abstraction of value. A model is a single point in a three-dimensional space spanned by three geometrically orthogonal axes called view, timing and values. A H axes are divides into three levels. The view axis represents designs as sequential, concurrent and structure. The timing axis represents designs at the levels time causality, clock related and propagation delay. Finally, the value axis represent designs using abstract values, composite bit values and bit values. It is clear there is a strong dependency on the VHDL view of a system, while limits its applicability to other forms of specification. The lack of physical representation makes this representation unable to unify the design process completely. The Rugby model [Jantsch et al., 1999] is a conceptual framework for the representation of hardware/software systems and the design process. Rugby uses four dimensions to represent designs: time, computation, communication and data 28 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. domains. Each dimension can also represent the design development progress. An orthogonal dimension represents the design manipulation. The model can represent designs from the conceptual to the physical levels. Again, there is no separate representation for the logical and physical structures. 2.43 Design Data Structure - DDS The DDS (Design Data Structure) [Granacki. 1987: Hayati. 1990: Knapp and Parker. 1985]. separates the diverse aspects of a digital system using four nearly independent domains that can be related to each other see Figure 2.1. The four domains are named Data Flow. Timing and Sequencing. Structural and Physical domains. To relate them special links called bindings are defined. The DF (Data Flow) graph is a bipartite acyclic graph defined by the three-tuple DF=(N,V.E). where N is the set of operation nodes, V is the set of value nodes, and E is the set of edges connecting both sets of nodes. The TS (Timing and Sequencing) graph is a DAG defined by the two-tuple TS=(P.E). where P is the set of point nodes, representing an instant of time, and E is the set of arc edges representing different types of time intervals while connecting the points. There are seven types of points: • pi: simple point. • beta: AND-fork. simultaneous start of both descendents. 29 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • mu: AND-join. simultaneous end of both incoming branches, where delays are added after the first one is finished. • gamma: OR-fork. exclusive OR start of one of the descendents. • rho: OR-join. end of one of the incoming OR branches. • alpha: LOOP begin, and • omega: LOOP end; TS Operational Binding DF T ransformation Realization Binding P Figure 2.1: The DDS domains and relatioships. 30 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Here are four types of edges: • sigma: an interval of time, which represents sequencing of DF operations and corresponding values, where the actual value will be determined after scheduling. • theta: a time constraint: this arc represents a timing specification and must have a value or a time range defined. • chi: a causal relation, which represents causality only and has no time defined, and • delta: an inertial delay, used to represent the lumped physical inertial delay associated with both inputs and outputs. The S (Structural) graph is defined by the two-tuple S=(M,C), where M is the node set of Modules, and C is an edge set of Carriers connecting the node set. This domain represents the topology of the design and is similar to a schematic diagram. The module is just a building block whose behavior implementation/realization is defined by a binding to the Physical domain. The carrier is the only kind of structural item that a value can be bound to, either as storage or as a transfer function. The P (Physical) graph is defined by the two-tuple P=(BJM), where B is the node set of Blocks, and N is the edge set of Nets connecting the node set. The block is a physical entity such as a PC board, and the net is a wire or cable used to connect blocks. Both objects can be tagged with unstructured text. 31 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. There are two types of bindings: • Operational: links the Data-Flow, Structure and Time-Sequencing graphs. In general, they are many-to-many since operations can be multiplexed in space or in time. Operational bindings have two subtypes: o VCR - Value-Carrier-Range: Binds a DF value node, a TS range and an S carrier. In the high-level specification only the value node and possibly the timing range exist. After allocation, the modules are selected and then the necessary carriers are defined and bound. o OMR - Operator-Module-Range: Binds a DF operational node, a TS range and an S module, similarly to the VCR binding, after allocation. • Realization: links the Structure and Physical graphs. These bindings typically are made after some design activities, namely when the RTL description is synthesized. They are fixed in time. There are two subtypes o MB - Module-Block: Binds a structural module to a physical block. o CN - Carrier-Net: Binds a structural carrier to a physical net. In DDS. the design cycle starts with a VHDL description and is translated to DDS using a commercial parser and lexical analysis tool with the VHDL2DDS back end [Chen, 1991]. The DDS file set is composed of two parts, the entity and body 32 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. parts. The entity part describes the process interfaces and declares the DF and TS graphs. The DF graph has a Value node definition for each port. No timing information is created. The body part also contains DF and TS graphs corresponding to process behavior in the VHDL file. All interface ports declared in the entity part are represented in the body part as DDS DF-nets (Data-Flow nets). DF-nets relate the behavior value with the port-value definition, thus linking both parts. In the TS graph, all edges are of the type sigma (dummy) and no timing value is attached to them. Some of the bindings are shown in dashed lines. 2.5 Conceptual Modeling Conceptual Modeling is the task of extracting and understanding the knowledge of relevant aspects about the Universe of Discourse of a system. It transforms an abstraction in terms of user requirements into an abstraction of a specification. Some formalisms have been developed to enable users to reason about that knowledge and to communicate the understanding to another user [Loucopoulos. 1992]. A conceptual model specifies the functional requirements, and includes not only classes and relations but also events and constraints [Rolland and Cauve, 1992]. 23.1 Information Modeling Information modeling is the task of capturing the conceptual structure of the Universe of Discourse: objects and concepts, the relationships among pieces of 33 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. information, constraints and how they coherently express the overall system. An important aspect of this process is its formal approach. Although information modeling is an abstract domain, the major result of this task is a common understanding of some area of interest. Fig depicts a simplified information model of a DDS data-flow graph in EXPRESS. a = b + c; opr1 d = a * 2; opr2 OPR 1 i Value OPR 2 OPR 1 t> i Value DF-Mode) OPR 2 Algorithm CDFG DDS Figure 2.2: DDS data-flow graph and its simplified information model. In electronic systems efforts for modeling its principal aspects using languages, frameworks and interchange formats has been under investigation for some time, in 34 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. VHDL [Giumale and Kahn. 1995]. in EDIF [Lau and Kahn. 1993], in CFI [CFL 1992]. and in frameworks [Schettler and Bredenfeld. 1992: Wilkes and Scholz, 1992]. Another area of interest is the representation of system-level and behavioral- level designs [Conradi. 1994: Conradi, 1995], and is centered on the use of EXPRESS [ISO. 1994]. The major goals are to • give designers a clear understanding of the data, • facilitate interoperability of different standards, and • support integration of tools. Data Modeling Data modeling is concerned with the static aspects of information systems, e.g. objects, relationships and integrity constraints. This activity is more constrained than informational modeling since it assumes some physical realization as the objective, such as a database. It usually employs a simpler notation and is closer to the implementation [Mylopoulos, 1992]. Data modeling is the process of modeling and formalizing data requirements with a conceptual modeling tool. Most commonly used tools are entity relationship (ER) diagrams, the object-oriented paradigm, and semantic data modeling. In order to model the reality (implemented data structures) abstractions are used, such as classification, aggregation, specialization and generalization. 35 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.6 Formal Verification of Concurrent Systems There are a wealth of references in the literature on formal verification. A correlated field is distributed systems. Both share the same formal basis and sometimes they are intermixed. The main objective is the verification of concurrent software systems, and some techniques have been applied to hardware verification. The input languages used for formal verification can be divided into two formalisms: logic and algebra. The First one usually employs modal logic to express system properties and the tools are called model checkers. These tools are able to deal with necessity and eventuality modalities. The second one expresses system behavior and the tools, called verification tools, check the equivalence of two descriptions. Most of these tools assume an interleaving concurrency and there are varieties of equivalences: strong and weak bisimulation, branching bisimulation, and testing and trace equivalences. Most tools use a finite state automaton as their internal representation. They can be further classified as transition-based, e.g. transition graphs and acceptance trees, and state-based, such as Kripke structures. The former type is usually adopted by process algebras and the latter type by model checkers. 36 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Given the input language there are three approaches to verification: • Behavioral: using behavioral equivalences on transition systems, • Logical: using model checkers on Kripke structures, and • Equational: either equation solving (refinement upon missing parts) or equation reasoning (simbolic manipulation) that uses theorem provers. We have analyzed two approaches: temporal logic and process algebras. 2.6.1 Temporal Logic Systems in general exhibit properties and designers want to assure that some properties hold. These properties can be stated as requirements to be met by the implementation. Two categories of properties are usually verified. Safety properties state that “nothing bad ever happens": a system must not engage in a proscribed activity. Liveness properties state that “something good eventually happens”: a system must engage in some desired activity. Temporal Logic [Cleaveland et al.. 1996: Gupta. 1992: Yoeli, 1990] is a branch of formal logic that has been used to verify system properties of hardware designs. Formal logic deals with static situations where the truth of propositions does not change over time. Temporal logic is an extension of predicate logic that allows reasoning over dynamic situations, which increases the ability to express change. Propositional logic deals with absolute truth where propositions are either true or false. Predicate logic extends the notion of truth by making it relative, or dependent 37 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. on (actual) variables. Modal logic extends it further, where the meaning of a predicate may also depend on the current state. There are two important advantages to temporal logic: the first one is the natural ability to express dynamic (temporal) properties, and the second one is that temporal logic can be used at almost any level of abstraction. On the other hand, temporal logic is not useful to reason about quantitative time, only sequences. It is also not well suited to functional verification. Two schools of temporal logic have emerged: • Linear-time Logics: describe systems is terms of the sets of their possible (partial) runs or sequences, and • Branching-time Logics: describe systems as LTL plus the points where two behaviors diverge or in other words as behavior trees instead of sequences. Linear time logic (LTL) semantics is useful to describe execution histories and thus permit properties to be stated about sequences exhibited. Branching-time logic (BTL) semantics is useful to model future behavior supporting checking choices available during execution. Another set of system properties can also be verified. Fairness states that a process gets a chance to execute regardless of other processes. From an observational point of view in CCS if a process persistently offers an experiment, and if the observer persistently attempts it, then it will eventually succeed [Milner, 1980]. 38 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. From a temporal logic perspective, we look only for paths where constraints are held infinitely often. A lesser strong property is Justice that requires that if a process is enabled continuously beyond a certain time, then it will be executed eventually. Finally. Impartiality requires that all processes execute infinitely often. This property arises from the interleaving concurrency, where a single CPU is available to all processes and some mechanism must exist to make sure that all of them can execute. The verification process checks a specification in some temporal logic against a realization from which a state graph is extracted. This process is called model checking by Emerson and Clarke and is used with the logic CTL (Computation Tree Logic) [Clarke et al.. 1996: Gupta. 1992]. LTL extends the prepositional calculus with the following operators: • DA (Always): A is true now and will remain true always. • O A (Eventually): A is either true now or will become true eventually. • OA (Next-time): A will be true at the next instant of time, and • A U B (Until): B is true now or will become true, and that A will be true at least as long as B is not yet true. BTL has the same operators as LTL, now called G. F, X for the operators always, eventually, nest-time and until, respectively. Furthermore, BTL offers two path-quantifier operators, A meaning “for all paths” and E meaning “for some path”. As examples, the formula AX f means that / is true in every immediate successor state. EX f means that / i s true in some immediate successor. 39 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. One serious limitation of the model-checking approach is the inherent reliance on an explicit state-transition graph representation. Since the number of states in a global graph increases exponentially with the number of elements in parallel, the result is commonly called the state explosion problem. There are many attempts to deal with this situation, symbolic methods being one of the most promising. 2.7 Process Algebra Process algebras have emerged as a framework for analysis and specification in the field of communicating and concurrent processes. Some representatives are CCS [Milner. 1980]. CSP [Hoare, 1978] and ACP [Bergstra and Klop. 1988]. A major characteristic of process algebras is the inherent ability to abstract to different levels. The semantics are usually defined in terms of a labeled transition system (LTS) followed by an operational semantics. They offer one or more notions of equivalence or preorder to verify different descriptions of the same system. Behavioral equivalences prove that two different behaviors are equivalent, even when some “uninteresting" details are omitted. Preorders prove that a lower-level description is a satisfactory implementation of a more abstract one. A detailed tutorial can be found in Inverardi [Inverardi and Priami. 1996]. 40 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.7.1 CCS CCS is concerned with observable communications, i.e. communication between processes that can be seen by an external observer. Another class of communication, which the observer cannot distinguish, is called internal. CCS is founded on two ideas. The first is observation, or how an external observer experiences the behavior of a process. With this idea comes the notion of observation equivalence, when two systems are indistinguishable. The other idea is synchronized communication, an indivisible action of a composite system where processes communicate. The key concept in CCS is the agent, which is used to model all elements of a system, devices and media. An agent behavior is described by actions. which may be communications between agents or independent concurrent actions. Two agents communicate if they perform complementary actions, send and receive. A special constant action 0 is the “inactive” mode where an agent is not able to communicate anymore. In Table 2-2 the basic operators of CCS are displayed. CCS supports equivalence checking, where a specification is compared against a representation. The specification can be regarded as a more abstract description of a behavior while the representation is a more detailed one. The basic equivalence operator in CCS is bisimulation. 41 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 2-2: CCS basic operators. Prefix o l A action a followed by behavior A. Choice A + B either behaves as A or B. Composition A 1 B agents A and B operates concurrently. Restriction AM labeled actions are not visibly performed. Relabeling A[f] function f substitutes labels in A. Recursion rec x _ A recursive agent. 2.7.2 CWB Concurrent Workbench (CWB) [Cleaveland et al.. 1993] is an automated tool for the analysis of CCS programs. It is a very rich offering several equivalence and preorders, checks and supports the modal logic HML. thus offering both a process algebra and a temporal logic analysis tool. 42 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 3 Representation Requirements for System Design System specification is the process of collecting the client's desires, hopes and constraints. The designer must translate the client's requirements, usually expressed in an informal manner, into a more formal description amenable to automatic manipulations. The main objectives of a specification are to • Communicate the designer knowledge and requirements for the design. • Provide a common representation to support the design validation and verification. • Provide an interface for the design tools. Major requirements include representing intended behavior, properties and constraints. Behavior can be described by formal languages. While most of these languages capture only the functionality, others can also describe the timing involved. Properties and constraints determine particular characteristics of the 43 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. systems. They impose limits on the behavior. Almost no languages offer any kind of properties or constraint description capabilities. In the case of hardware designs, constraints are usually used as parameters to the design tools, and the tools will analyze or try to synthesize the behavior under the given constraints. Frameworks of design tools have been used in order to integrate these different aspects, providing a more seamless design flow. They manage the different input and output formats for each tool and the sequence of tool invocation. In the following, we present some definitions to be used in the rest of this work. We emphasize one important distinction between architecture, as a structured description of a complex system, and the intended realization of such a system, called micro-architecture [Bell and Newell. 1971]. As an example, an instruction set architecture (ISA) defines the possible behaviors of a central computer unit (CPU), in terms of its instructions, and does not impose any particular implementation. An integrated circuit or circuits use a given ISA in a particular implementation and realizes a particular CPU as a micro-architecture. Definition 3.1: An Architecture is a conceptual structure that describes the functional behavior of a system, usually in a logical way, and independent of any implementation. 44 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. An architecture describes WHAT a system is intended to do. An architecture is a structured description of an intended functionality. The structure is used to deal with the complexity of such system, malting it easier to understand. Definition 3.2: A Micro-architecture is a description of how a given architecture is implemented, and defines the organization of the data and control flows, the logical design and the physical implementation. A micro-architecture describes HOW a system implements an architecture. The main difference from the architecture is the presence of detailed information on how the structured components are implemented and used. A micro-architecture contains a well-defined information flow and describes how the components are activated. Finally, after several synthesis steps physical information is present. The overall design is now completely defined and few, if any decisions are still necessary. Definition 3.3: A System is a collection of concurrent and communicating processes that cooperate in order to perform a more complex task. □ A system is viewed as a collection of independent processes that cooperate to perform a more complex task. In order to cooperate, processes communicate to exchange information and to synchronize activities. Traditional high-level synthesis focused on a single process and little attention was paid to cooperation among 45 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. processes. Design of system must not only address the synthesis of processes but also their cooperation. A system design is more than just a behavioral or functional specification. It may involve an intended architecture, as the designer conceptual view, that must evolve into a micro-architecture in order to be realized. A system design framework must be able to support and represent the conceptual system, the intended architecture and the its final micro-architecture. 3.2 Properties of a System To effectively represent a broad range of systems and their designs, a set of properties is necessary to capture the desires and intentions of clients and designers. These properties involve all aspects of the system, behavior, logical and physical structures and constraints. Table 3-1 below summarizes these properties, which were introduced in Section 1.3.1. 46 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 3-1: List of properties of a system. Property Examples Abstraction Hierarchy, Encapsulation Separation of Concerns Function and time. Behavior and structure. Computation and communication Redundancy Minimization Diverse Design Methodologies Top-down, Bottom-up Incremental Design Model of Computation Support for Correctness Validation, Verification Requirements and Constraints Size, Power consumption. Weight, Delays Each of these properties will be discussed. 3.2.1 Abstraction Systems tend to be complex and designers usually impose some sort of a logical partition or structured approach, breaking the system into smaller modules that are easier to describe. These modules do not necessarily imply physical modules. Usually they convey some specific functionality, behave according to a set of events and manipulate data that can be easy to comprehend. Requirements can impose physical realization for some modules, which means that the module interface can be well defined, implying more-detailed sets of events and data formats for inputs and outputs. Abstract modules are used to represent the intended behavior, whether it is a purely behavioral or a physical module. At the system-level, a module can be seen as 47 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. a “ black box", where the designer assigns an intended behavior and interacts with the environment or other modules via ports. This permits incomplete or partially defined components to coexist with well-defined modules, as long as the interconnection rules are observed. It also permits physical modules to be abstracted from their internal details. Hierarchy is the definition of an object by the aggregation or refinement of other simpler objects. Hierarchy is a strategy to handle the complexity of systems. By carefully hiding unimportant details at a given level, the designer can express the knowledge of a design. One advantage is the possibility of reuse of components. Hierarchy can be divided in two major approaches: • Composition: an object is composed of a collection of simpler objects making it a more complex one: or • Refinement: an object has different views with the possible increase of details. Abstract modules can be hierarchical, containing sub-modules. For behavioral modules, hierarchy is simple to understand and can be considered as function composition. Physical modules can contain both physical and behavioral modules. As long as the physical modules are abstracted as black boxes there is no difficulty composing them into more complex physical modules. 48 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. In order to allow both abstract and physical modules to coexist in a single system description they must be described at the same level of abstraction. Thus, to use physical (and more detailed) modules, a wrapper (or encapsulation) is used to filter excessive details into a more abstract representation. 3JL 2 Separation of Concerns Design complexity is often addressed using more abstract description levels. Higher levels of abstraction provide the ability to exploit a larger set of possible solutions. A new paradigm for system designs is the separation of concerns early in the design process. Various aspects can be better explored providing more alternative solutions. Moreover, these concerns are also orthogonal, in the sense that they are not only independent but also one aspect can be related to another one. Orthogonal concerns can be manipulated independently. Examples of such separations are: • Separation of functionality and timing • Function and architecture • Communication and computation Separation of functionality and timing is a well-known and accepted paradigm in the High-Level community. The timing behavior can be changed without changing the functionality. Hence, timing and functionality are orthogonal concerns. USC’s DDS uses two independent, orthogonal, but explicitly related sub domains to represent each aspect. Functionality is decomposed into data-flow dependencies and 49 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. causal dependencies and they are represented in the data-flow and timing-sequencing axes, respectively. Timing is represented along with the timing-sequencing axis. The separation between communication and computation leverages the complexities of dealing with what a particular module performs - as described by its specification - and how it receives data and signals and sends the results. In conventional software programming, it is common practice to relegate the communication to the operating system, mainly due to the limited possibilities offered. However, when writing a real-time or an embedded software module the programmer needs to know the details of each input and output and use specific libraries to support communication and synchronization. In hardware design, this problem becomes more complex since the number of possible implementations is high. Usually designers make early commitments for input and outputs, reducing the design space search. A coordination model defines the mechanism used to coordinate the interaction among distinct processes. In parallel programming environments, the coordination of parallel programs implies three important issues: communication, synchronization, and process management. For digital systems the important issues are: communication and synchronization. Process management is not of prime concern because the system is considered static, in other words, there is no dynamic process creation. For hardware systems, it is clear that only static structures are used. However, some software (sub) systems may present dynamic process creation and management, which demand specific support 50 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. from the operating system and are mostly used on some specific classes of real-time systems. Coordination is usually explicit and occurs at points in the program. An important advantage of using a coordination model is the fact that it combines well- known sequential languages with coordination mechanisms. Coordination programming environments can be divided into two major classes: • Communication-based models: communication between concurrent tasks occurs through the exchange of messages. The usual semantics provides both synchronization and communication. • Shared-memory models: coordination is provided by the semantics of operations on shared data structures. A classical example is Linda [Gelemter and Carriero. 1992]. A different classification can divide coordination models into languages, such as Linda, and libraries or platforms, such as MPI [Gelemter and Carriero, 1992]. Coordination libraries offer a set of primitives with extra linguistic support for parallel and distributed programming. On the other hand, coordination languages offer a complete solution to specification through a complete language. Gelemter [Gelemter and Carriero, 1992] defined Coordination as: Programming = Computation + Coordination 51 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. This paper stressed the importance of a clear separation betw een the components of the computation and their interaction. The main purpose of coordination languages is to separate the control issues from the computation concerns. A coordination language offers several advantages: • Reuse of components: • Reuse of coordination: • Orthogonality, a coordination language is not a general purpose programming language: • Generality, any system can be described from massively parallel to fine grained to heterogeneous systems: • Abstraction, since detailed information regarding the computation is hidden in the computation language. Host languages, or general-purpose languages, are used to describe the computations. Due to the inherent generality of the coordination model, the same coordination program can be used with modules defined in a different host language, or the modules can be written in the different host languages. The host language defines atomic processes. Each process is concerned with its own computation and does not know anything about other computations, even if it interacts with other processes. Recent works on digital systems specification deal with a coordination approach, although not in these terms. They present a coordination view and attempt to 52 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. separate process interaction from internal behavior through the decoupling of functionality from timing. Dasdan [Dasdan et al., 1998] describes the system using a two-level hierarchy approach, where the upper level defines an acyclic task graph and a lower level defines a cyclic task graph. The main reason for this approach is the fact that different algorithms are used to analyze the upper and lower levels. Sander [Sander and Jantsch. 1999] uses a three layer functional model with tagged- events containing the time. The first layer, called the system layer, describes functions as a composition of a set of equations and can have several levels. The system layer functions are decomposed into skeleton functions. The middle layer, called the skeleton layer, is composed of templates from a synthesis library and can have either a hardware or a software interpretation. Skeletons contain both structural and also timing information, which does not permit further hierarchical decomposition. The bottom layer is the elementary layer and consists of primitive and combinatorial functions; components of the elementary layer are synthesized into VHDL or C code. Vermeulen [Vermeulen et al., 2000] defines a three-level approach for data-intensive applications and models data as streams. The first level is called process control. It specifies the system as concurrent threads and their guarding conditions. A second level called loop/index layer defines multidimensional operations on scalar operations over streams of data. The third is called scalar layer and defines scalar operations. 53 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3 1 3 Redundancy Minimization To minimize redundancy in the representation. SDS uses the separation of concerns and represents the behavior in two distinct and independent domains, one to represent the functionality, similar to a single-assignment dataflow language, and one to represent temporal relations, such as timing intervals and causality relations (control flow). 3.2.4 Diverse Design Methodologies Human designers tend to describe systems beginning with general concepts using abstract specifications and through successive refinement steps increase the amount of information. Several structured approaches are used in different system areas, such as genera] software applications using SA/SD (structured approach/structured design) and object-oriented approaches, real-time systems [Harel, 2001] and digital hardware design [Gajski et al.. 1992: McFarland and Kowalski. 1990: Sander and Jantsch. 1999]. The top-down approach is a very intuitive way of dealing with complexity. Hiding unwanted or unnecessary information designs can be easily manipulated. The major advantage of the top-down approach is the greater flexibility in exploring possible designs. This lead to the pyramid view of design explorations, where a specific decision is modeled as the pyramid’s vertex top and at the bottom lie all possible solutions. As more details are added to the design, the pyramid's top is 54 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. pushed down, reducing the height and consequently the size of the base. As the process proceeds, the number of possible solutions is reduced, yielding the final implementation. Even if designers prefer a top-down approach, they seldom use it in a pure manner. They start with at least one architecture in mind and use their knowledge about physical-level modules to guide design decisions. This is the major roadblock to an implementation-free system description. This led to the use of pure functional languages by many groups in an effort to decouple low-level information constraints at early stages of development. The problem with purely functional descriptions is that they are far away from physical realizations, and demand a great effort to map functions to hardware components making the resultant design activities difficult to automate. In addition, they do not represent the typical system design process well. One possible solution to this problem is to permit designers to incorporate low- level details that may help the exploration of the design space at the early stages. In the EDA community, this has been allowed for RTL designs [McFarland and Kowalski, 1990] and for High-level designs [Gupta et al., 1994]. In short, system design involves a composed top-down and bottom-up approach. Design requirements, such as cost and performance are the usual candidates for this selected set of details. Important details regarding the intended use of the design, such as PCB dimensions, input and output devices, interfaces connections and the use of public standards, might also be included. 55 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3 i i Model of Computation and Support for Correctness The increasing complexity of systems demands new approaches that involve the reuse of components, since designing systems from scratch is almost impossible. To reduce design iterations and to improve the design quality a rigorous framework is necessary. A model of computation (MoC) is composed of a description mechanism, i.e. syntax, and rules for computation of the behavior, i.e. semantics. A model of computation has mathematical properties that can be efficient used to analyze a system without the need of expensive verification tasks [Edwards et al.. 1997: Lavagno et al.. 2000: Lee and Sangiovanni-Vicentelli. 1998]. Some of the most common used models of computation are: Discrete Events, Finite State Machines. Petri nets. Data Flow Networks, and Communicating Concurrent Systems. To address the correctness issue, design simulation and formal verification techniques are used. Simulation takes a representation of the system and executes this model subject to the description on a computer, allowing the designer to assess the system’s behavior. Formal verification uses a formal mathematical model and either compares against a formal higher-level specification or asserts certain properties of the system to be proven true. 3 2 6 Requirements and Constraints Existing systems are constrained by many factors, among them physical limitations, a restricted set of micro-architectures, and implementation costs. 56 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Requirements imposed on the system usually serve as guidelines during synthesis. Requirements and constraints may be related to diverse aspects of the system and be attached to the behavior. logical structure or physical components. A careful mechanism must be used to avoid over-specification. 3 3 System Primitives A non-exhaustive list of system primitives and system building blocks employed by designers was surveyed. Table 3-2 lists the compiled SDS set of primitive constructs. These primitives are the guiding elements used in the definition of SDS. Table 3-2: List of system primitives. Functional Behavior Computation Sequential, Parallel. Iteration, Conditional execution Communication Synchronous, Asynchronous. Blocking, Non-blocking Interfacing Routing, Data conversion Temporal Causality, Execution times. Data rate Duration and delay Data Type Data Types, streams Persistence Storage Non- FunctionaJ Requirements strength Logical Structure Intended micro- architecture Performance Constraints Geometrical constraints Form factor, dimensions: 2D. 3D Costs Area, Consumption, Delays 57 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. We defined a list of primitive constructs necessary to represent a broad range of systems. It is possible to combine these SDS primitives to obtain more complex blocks, and to decompose a complex block or design into a collection of these primitives. 3J.1 Behavior Behavior is decomposed into computation, communication, timing and information primitives. Computation primitives are basic and straightforward covering the necessary constructions to represent any computation. They can represent sequential and parallel compositions, iterations and conditional execution. The interfacing primitives actually do not belong in the table, since interfacing primitives are in fact system building blocks composed by simpler primitives, such as computation, communication, temporal and data primitives. They are a good example of system building blocks that may involves a mixture of architecture and micro-architecture elements (or simpler building blocks) and are not in fact purely SDS primitives. To deliver products in a shorter time, design reuse has become necessary in the design community. Some functional building blocks can be obtained as sub-systems called Intellectual Property (IP) blocks, also known as Virtual Components (VC). IPs are used as placeholders for hardware components. They are divided into three main groups: Hard, Firm and Soft blocks [VSI. 1997], Hard IPs are process/vendor specific and generally described as layout net lists with some simulation code. They 58 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. can be offered with different optimization options like power, size or speed. Each block is mapped to a specific technology. Firm IPs are defined as RTL descriptions in a structural HDL without any physical descriptions, such as routing or floorplanning. They are optimized for some specific architecture. Soft IPs are delivered as synthesizable source code. e.g. as an HDL code. 3.3.2 Communications and Synchronization In order to communicate, processes send and receive messages or signals. In this way. they can coordinate actions and cooperate in a global behavior. The approach used in this work is the message-passing paradigm. This paradigm is used because it provides an abstract form of communication and synchronization and can be implemented either by message passing or by using semaphores. Two types of primitives are defined in terms of message types: signal/wait over binary messages and send/receive over information messages. Signal/Wait is used only for synchronization purposes. Send/Receive is used to both carry information and synchronize as well. The primitives can also be of two kinds: blocking or non-blocking. Blocking primitives disrupt the normal sequencing of operations and wait for the condition to be met or the message arrival. Non-blocking primitives can be regarded as regular information transfers; however, they imply a rendezvous communication where both send and receive must occur at the same time. 59 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Blocking primitives guarantee behavior determinism, and process-based systems can be scheduled using finite-size buffers [Kahn. 1974: Lee and Sangiovanni- Vicentelli. 1998]. Non-blocking primitives do not guarantee determinism but require fewer resources. Scheduling is usually obtained using dynamic buffers. They are usually implemented in software and the operating system handles the dynamic aspects of scheduling and buffer control. In SDS. we decided not to enforce any specific policy of communication behavior at the early stages of the design. Thus, the designer is free to use either policy. 3 J J Data Structures Important data structure concepts need to be captured at the system level. Data can be categorized by more than one view. The structure can be either scalar or composed, sometimes called multi-dimensional. Scalar refers to single data elements of some defined type. Abstract Data Type (ADT) constructs provide a clear way to describe a complex data structure. Records permit the description of data structures composed by elements of different types. However, not only structural, static properties are present at a system-level description, but also dynamic properties are defined by the environment and internal physical components. These above- mentioned static properties are covered by most high-level programming languages and hardware description languages as well. 60 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Dynamic properties refer to the view of data structures over time. They are usually associated with data transfer protocols. They may describe rates like transfer rate and arrival rate, as well as flow control like synchronous/asynchronous or protocol behavior. Multi-dimensional data structures can be subdivided into two broad categories: a set of ordered elements, e.g. an array, and a bag or unordered set of elements, e.g. a record composed by elements of different types or sizes. The first category of elements can be accessed by an index or by traversing the structure. The second category of elements can only be accessed by using a key that point to an element. Indexing can also define other categories. These categories include self- addressed data structures that need an index to uniquely identify an element, such as arrays, fifos. lifos, stacks, linked lists, trees, and key-addressed data structures that demand a key to uniquely identify an element, such as records, caches, and hash tables. The Abstract Data Type (ADT) is a mechanism widely used in high-level algorithmic languages to represent complex data structures. Besides hiding specific details of its internal representation. ADT offers easy access to its components or fields. The relative position of fields is usually implied by the programming language and its associated operating system. Since SDS is a language-independent representation, this information must be explicitly represented. ADT captures only the static, structural aspects of a data structure. Dynamic properties, such as repetition rate, bit or baud rate, transfer rate, flow control, 61 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. synchronous or asynchronous connections are not captured. There is a need for an extension to the data structure description in order to capture these aspects also. Creating a new language to address these aspects is a very risky enterprise, since most designers do not want to give up their fluency in a well-established language. A coordination language is an excellent candidate to develop because it extends current host languages with a language able to capture the dynamic aspect of communication and the designer can use the same HDL for description of computations. Finally, these concepts may ultimately be implemented in some storage or memory module. More important, these memory modules are always implemented as an array or vector of memory cells. The representation must be able to capture both extremes, the ADT and dynamic properties of a data structure and the physical implementation, along with the possible refinement levels. 33.4 Storage Although not a necessity at a conceptual-level description of a system, the concept of storage is sometimes involved in a architectural description. It also can appear as a design constraint in the target architecture. Even though this work does not address architectural concepts, it is should be able to capture essential ones. Storage implies persistency, which is the ability to hold information over time. Information is lost when new information is written over. Storage elements may exhibit a weaker kind of persistency that is dependent on the power supply. In SDS, storage also implies that a given value is bound to a module with a storage predicate. 62 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. To be read the given value must be fetched from that module and a location must be specified in order to obtain it. To write a to a storage location a two-tuple containing a location and a value or a set of values is sent to the module. This is abstract enough to describe a physical memory or a register in a database. This architectural requirement usually appear at the description of input and output ports that connect to a storage module. However, data intensive applications, such as signal processing, scientific applications and telecommunication, use algorithms where the data to be processed is usually described by matrices. The communication between processes can describe the transfer of a complete matrix or pieces like sub-matrices, lines or columns. At the conceptual and behavioral levels, physical details like word width and capacity may not be necessary. During high-level synthesis, both parameters can be determined and optimized [Gupta. 1994], 3 J 5 Non-Functional Primitives Non-functional primitives and non-logical structural primitives are closely related to the requirements and quantitative constraint properties, and they are equivalent to predicates attached to objects in SDS. Requirement strength reflects the designer interest in that given requirement or constraint to be satisfied as specified. Strengths are used by synthesis tools to improve trade-off decisions. For example, strengths can be classified as must, should and may. Performance constraints are specified requirements usually imposed in behavior to be satisfied by the 63 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. implementation, and guide the trade-offs during the synthesis stage. Most common examples of performance constraints are: maximum execution delay, maximum silicon area and maximum power consumption. Geometrical constraints delimit the area or space available to the implementation. They can be expressed as two- dimensional values, three-dimensional values, given form-factors or footprints. A cost reflects the amount of resources used by implemented objects. A graph theoretical model representing these properties will be presented in Chapter 4. 64 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 4 SDS - System-Level Conceptual Model SDS is a hierarchical representation of a system. It uses four distinct domains. The domains represent the process flow, the timing/sequencing flow, the logical structure and the physical structure of a system design. A system component is described in terms of these domains and a set of relations across the domains. There is no direct relationship among objects in different domains. The domains can be partially or completely orthogonal to each other. Orthogonal domains mean that the domains are independent of each other and changes in one domain do not affect the other domain. For example, a single behavior, represented in the process flow and timing flow domains, can be mapped to several different implementations represented in the physical domain. A binding is an explicit and specific formal representation of relationships between objects in different domains. SDS definitions of orthogonality and binding follow closely DDS definitions [Knapp and Parker, 1985]. However, SDS defines 65 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. full orthogonality among the process flow, timing/sequencing flow and logical structure, whereas DDS employs near orthogonality for all domains. From Chapter 3. a system is defined as a collection of concurrent and communicating processes that cooperate to accomplish a more complex task. In SDS. the system behaves as a globally asynchronous locally synchronous (GALS) architecture. Each process is locally synchronous while the communication is primarily asynchronous. A major factor driving SDS is the separation of concerns. In order to handle the complexity of system designs several concerns are selected and addressed particularly. The first concern regards behavior that can be seen as composed of functions performed over a time axis. Some approaches define a simpler concept of behavior as functions without relation to time. SDS addresses this concern making a clear distinction between function and timing and assigns them to two separate and orthogonal domains linked by bindings. Functions are decomposed into primitive objects. These objects perform actions and information is exchanged among them. Both actions and values, represented in the process flow domain, are then related to time intervals in the timing domain. Another concern is the description of processes and their communication. Processes are the objects used to capture the computation of a given behavior. Imperative languages are commonly used to describe such computational behaviors, such as programming languages and hardware description languages. However, imperative languages impose a suggested architecture. In fact, declarative languages contain significantly less implementation information. These languages are also 66 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. called Host Languages, and in most cases can use an operational semantics and can be directly translated into some formal model. The communication among processes can use a different class of language tailored to describe communication and synchronization actions and the data transfer involved. These languages are called Coordination Languages and are orthogonal to the host languages. The main benefit of this approach is that more than one host language can be used to describe different processes: a single coordination language will integrate all the processes descriptions. Coordination languages provide mapping mechanisms to link host languages communication primitives to the specified communication channels. Figure 4.1 illustrates a system-level block-diagram and the corresponding SDS domains and bindings. These domains and bindings will be described later in more details later in this chapter. The block diagram illustrates conceptually what is represented by the SDS model, and suggests a possible user interface strategy for the SDS Figure 4.1 (a) depicts two processes, T1 and T2, connected by channel Cl. Task T1 sends a message msg to channel C l. A channel denotes two ports and a connector linking them. As a prime component, a channel may have an associated behavior, such as a protocol. Channels can also be structured containing a hierarchy and physical requirements, such as a mechanical connector composed of a set of pins. 67 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Task Task T2 T1 C hannel C1 \receiv e(): send(M sg): Port T im ing/Sequencing Domain Logical Structural Domain P hysical Structure Domain P ro c e ss Flow Domain Figure 4.1 : a) A block-diagram system description, b) The SDS model overview, from block-diagram to the four domains representation. 4.1 The Components The fundamental object in SDS is the component that represents a single physical entity. This entity may be a specification, a design in progress or a physical component. The system to be designed is the initial top-level component. It may start 68 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. being described by a specification with indication of possible physical components or as a process flow or a structural block diagram, and is represented as an incomplete component. As the design progresses more details are added to that component which remains incomplete. When more details are added and the physical information is more detailed, it reaches the point where enough information is available and the component may be manufactured. 4.1.1 Models of a Component Components are described in terms of four domains and a set of bindings that explicitly relates the four domains. The four domains are projections of the component and not all are necessarily covered by an abstract specification. The physical structure domain is not hierarchical in SDS. but the other three are hierarchical. Consequently, a design can have many refinement steps and all of them can be represented. In a top-down methodology the process and timing domains will be largely populated and the logical structure domain will have some structural or topological information captured. These three domains do not impose any specific realization. In a bottom-up approach, physical components are aggregated in order to compose a more complex component. Since the four domains are orthogonal and there is no implicit relation among them, therefore explicit bindings are used to relate entities in the four domains to each other. 69 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.2 The Formal Definition A graph theoretical definition of all domains will be presented in this subsection. The purpose of such formalism is to provide a solid definition of each domain. A detailed information model will be presented in Chapter 5. 4.2.1 The Four Domains The motivating factor to use four orthogonal domains is the separation of concerns. The first concern is the separation of time from functionality. This led to the use of two domains, the Process Flow (PFD) and the Timing/Sequencing Flow (TFD) domains. Together they represent the operational behavior of the system. This separation is very useful for a top-down approach where the main goal is to describe the system’s behavior correctly and later on take into account the time delays and constraints. Without any time requirement or constraint, a partial order is induced by data dependencies and the basic control flow can be completely represented in the TSD domain. As a natural consequence of human activity, a topological or logical organization is usually employed to facilitate the design capture. To represent this logical organization the Logical Structure Domain (LSD) is used. Again, from a top-down approach, block diagrams are often used by the designer to specify the logical structure of the design. These diagrams cluster items that the designer feels that are logically related. This topological organization does not necessarily induce or impose 70 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. a physical realization. A given block in a block diagram can be directly realized, clustered with other blocks or partitioned in order to be implemented. This domain can also be used to represent abstract hardware and software components and connecting carriers. In SDS, the LSD represents the intention of the system. LSD captures the constraints of the system either imposed as a goal in top-down specification or imposed by a physical component in a bottom-up specification. The LSD serves also as the interface between the behavior (process flow and logical structure domains) and the actual implementation (physical structure). The Physical Structure Domain (PSD) is used to represent clients' and designers' physical requirements and constraints and actual components. This domain is partially orthogonal to the other three domains. When using a bottom-up approach, the designer starts with actual components and connect them together which imposes a concrete organization. Special binding relations link physical to logical components representing this kind of organization. Consequently, every physical component is linked to a logical one. but the inverse is not true and only LSD leaf nodes are bound to PSD components. In SDS, the PSD represents implementation information imposed on the system by the designer or environment. Each object may be represented in all four domains. Some objects may not have representation in some domains, especially in the physical structure if there are no specified physical constraints. 71 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 43*2 Process Flow Domain The process flow domain (PFD) defines the operational aspects of a design, capturing the functionality of computations and coordination as envisioned by the block-diagram approach with the major objects being: processes (tasks and components) and channels - as operational nodes - and information transferred among processes. Tasks represent functional process (sometimes called behavioral) descriptions. These descriptions do not have any intended specific implementation but may have physical constraints, such as maximum latency time or maximum physical area. Components represent processes with a physical implementation, such as an Ethernet interface card, an ASIC or a hard-IP. Each process performs one intended function as desired by the designer and can have a (possible) complete SDS description on all four domains retrieved from a library of components. The second separation of concern regards the separation of computation from coordination. Computation means the execution of a function and coordination the communication or synchronization involved between two computations. This concern is explicitly represented by the use of Channels to model the coordination. Channels capture the coordination mechanism to be used and thus become orthogonal to the computation mechanism. With this clear separation, different coordination mechanisms can be changed without modifying the computation. Given an abstract description, the coordination details can be left to a better synthesis 72 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. search. Channels can represent protocols involved in the communication or the use of semaphores for the synchronization. A degenerate channel will be realized by ordinary wires with a simple handshake protocol connecting two adjacent pieces of hardware. Since channels may involve some functionality and may take time to be accomplished, they are of the same importance as processes described above. Definitional: A Process Flow Domain is defined as a bipartite graph PFD = (O. I, Lp). where 0 is the set of vertices that represents operational nodes. An operational node o,. has a type, denoted by type(Oj). with type(Oj) e {algorithm, hw, channel). This set can be sub-divided into two subsets, the set of process nodes composed of algorithm and hw nodes, and the set of channel nodes. Set Oh is the set of process nodes, with type(OH) e {algorithm, hw). Set Oc is the set of channel nodes, with type(Oc) € {channel}. Thus, O = Oh u Oc. 1 is the set of vertices that represents information. An information vertex it it e I. has an attribute data_type(it) which is its information type definition. L p is the set of edges between operational and information nodes Ipj, Ipj e Lp, with Lp c (OxI u IxO). 3 73 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Operational nodes can be hierarchical and may contain sub-nodes. Algorithm nodes represent processes with a functional specification and imply that that process has no physical realization. Functional specification is usually obtained by using a top-down approach. Hw nodes represent processes with a physical realization: their presence is due to a bottom-up approach used by the designer and is usually imposed as a constraint to the design space. Hw nodes may have a functional specification. Channel nodes represent data communication or synchronization between two processes and may have a functional (protocol) specification and (maybe partial) physical realization. Channel nodes can also posses persistency to model the storage of information. A persistent channel node requires a specific behavior to handle persistent objects. Thus, in SDS persistence is modeled by a channel object with a persistence tag. The specific behavior includes the ability to store and retrieve information that includes the storage functionality itself and the connection protocol needed to store and retrieve the information. For example, a magnetic disk unit, a memory bank or a database can be modeled as persistent channels. Information nodes represent information transferred between two processes by a channel and it may imply a data transfer or synchronization signal. Information nodes can be hierarchical and be composed by the aggregation of sub-nodes. 74 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4 2 3 Timing and Sequencing Flow Domain The timing and sequencing flow domain (TFD) defines a partial order on the operations and information exchanges as represented in the PFD. The TFD is composed of two components: points and ranges. Points have an infinitesimal duration of time and thus are considered to be instantaneous. Points serve as delimiters of time intervals and sometimes can have a special semantics. Ranges represent time intervals and may have an expression defining the interval duration. Definition 42: The Timing/Sequence Flow Domain is defined as a directed acyclic graph (DAG) TSD = (P, R). where P is the set of vertices that represent points. A point p * e P is an enumerated type denoted by type(p,). with type(pi) e {simple. OR, AND}. R is the set of edges that represents ranges. A range q e R is also an enumerated type denoted by type(rj), with type(rj) e {causal, constraint, delay. loop}, with R c (PxP). □ OR points represent conditional flow. OR points are used in pairs of OR-fork and OR-joint points. Each OR-fork point has a single in-edge and two out-edges while each OR-joint point has two in-edges and a single out-edge. Each OR-fork 75 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. point is associated with a condition that determines which path to follow. Only one out-edge is traversed according to the condition associated to the OR-fork point. AND points represent parallel composition. Similarly. AND points are used in pairs of AND-fork and AND-join points. No condition is associated with an AND point and all out-edges may be traversed if there is no predicate associated with the out-edges. Causal ranges represent a generic time interval. A range in the system can be initially characterized as causal. A “pure" causal range has no duration associated with it. Constraint ranges represent a time interval with a designer specified timing requirement. The requirement is defined by an expression using a relational operator such as equal, less than, or greater than or equal to. Constraint ranges capture top- down timing information. Delay ranges represent a time interval obtained from the physical component bound to that range, i.e. this is bottom-up information retrieved from the component's actual details. Loop ranges represent a loop block as denoted by a wait, while-loop or for-loop in programming languages. For wait loops the range blocks until the condition becomes true. For countable loops, this range will be traversed as many times as the result of arithmetic expression attached to the loop. Ranges can be hierarchical and contain sub-ranges. Points have no hierarchy. 76 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.2.4 Logical Structure Domain The logical structure domain (LSD) captures the structural view of the system as described by the designer and denotes a topological logical unit An object in LSD does not convey any meaning besides the logical organization either specified by the designer in a top-down approach or imposed by a physical requirement or constraint in a bottom-up approach. The LSD should be viewed as the middle ground where behavior and actual components are related. The LSD is hierarchical and that hierarchy conveys the notion of composition, i.e. modules are composed by aggregation of sub-modules defining a composition tree structure. Definition 43: The Logical Structure Domain is defined as a bipartite graph LSD = (Om ~ O r.. Vl ), where O m is the set of modules. O r is the se t o f carriers. VL is the set of edges vl, g VL , with VL c (Om x O r u O r x Om). □ Modules represent logical units related to PFD operational nodes but there may not be a one-to-one correspondence. Modules can be hierarchical and an aggregation 77 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. of sub-modules. Modules can have persistency and can be used to model registers and memory subsystems. A special predicate is used to model this feature. Carriers represent a logical unit related to PFD information nodes, but again there may be no one-to-one correspondence. Carriers can also be hierarchical and aggregate sub-carriers. 4.25 Physical Structure Domain The physical structure domain represents physical constraints imposed by the requirements that convey specific physical information linked by a catalog entry and a possible list of free-form physical constraints. The catalog contains the set of possible choices of physical components. This domain captures partial information as described by the designer and represents physical properties and attributes of a component such as size, weight and cost. Definition 4.4: The Physical Structure Domain is defined as a bipartite graph PFD = (Ob. O n, Vf), where Ob is the set of physical blocks. On is the set of physical nets. VF is the set of edges vf, e VF , with VF c (O b x On u On x O b). □ 78 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Blocks represent a physical component. Blocks are considered to be a black box without internal details. As such, blocks have no hierarchy. This approach avoids problems with isomorphism and each block is related to a single LSD module. The internal representation of each physical component is beyond the scope of the Thesis. A component’s internal representation could be in DDS (Design Data Structure) form, for example. Nets represent physical connections such as cables and backplanes. 4.3 Bindings Binding predicates, or bindings for short, are inter-domain relations that connect objects of different domains otherwise not related. There are two sets of bindings in SDS. The first set. behavior bindings, relates the process flow, timing/sequencing flow and logical structure domains. The second set. realization bindings, relates the logical structure and physical structure domains. 43.1 Behavior Bindings Behavior Bindings capture the full intended behavior. Behavior bindings are relations on three domains and link objects from the process flow, timing/sequencing and logical structure domains. With this relation is possible to know What, When and Where an event happens. What happens is represented by objects in the process flow domain (O u Ov). When something happens is represented by objects in the 79 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. timing/sequencing flow domain (R) and where an event happens by the logic structure domain (Oi u Or). For example, a process Tl is bound to a module Ml and a time interval Rl. That means the process Tl is performed by module MI during the interval R1 . Behavior bindings are divided into two sets: behavioral process bindings Bbp and behavioral information bindings B bi- The set Bb is the union of all behavioral bindings. Definition 4.5: The behavioral process binding is a relation B b p = O x R x Om that relates an operational node (algorithm, hardware or channel) to a range and to a module. Definition 4.6: The behavioral information binding is a relation B b i = I x R x O r that relates an information object to a range and to a carrier. The set of behavior binding defined by B b = B bp v j B b i is the intended behavior. In Figure 4.1 Bl is a behavior process binding relating process Tl to range Rl to module Ml. and B3 is a behavior information binding relating information Msg to module M3. 80 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4 3 i Realization Bindings Realization bindings capture physical (actual) components as required by the client or designer. They are necessary to the design. Realization bindings are relations on two domains and link objects between the logical structure and physical structure domains. With this relation is possible to know How an event happens and it is represented by components o f the physical structure domain (O b u On)- For example, module MI is bound to a physical block BI that implements at least the intended functionality associated with the module. Realization bindings are also divided into two sets: realization process bindings BRp and realization information bindings Bri. The set BR is the union of all realization bindings. Definition 4.7: The realization process binding is a relation B rp = Om x Ob that relates modules to blocks. □ Definition 4.8: The realization information binding is relation B ri = O r x O n that relates carriers to nets. □ 81 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The set of realization bindings defined by Br = Brp u Brv is the intended (partial) realization as specified. In Figure 4.1 B2 is a realization process binding relating module M l to block Bl. 43 J Binding Hierarchical Objects Since objects on the PFD. TFD and LSD domains are hierarchical and the PSD domain is not hierarchical, the bindings are made complex. The hierarchy defines an order that is a tree, with the root element the system model. Each element below can have a depth associated with it. Bindings between elements from different domains must respect both hierarchies and a higher-level element cannot have a successor bound to an element with a higher level then the one to which it is bound. Realization bindings do not exhibit this complexity since the physical domain is not hierarchical and its components are considered to be black boxes. The intended functionality is matched by name between a module and a block. Thus, isomorphism exists in this realization, and the represented design may not yet be optimal, since optimization is a task to be performed by lower-level synthesis tools. Another consequence of this approach is the fact that only leaf nodes on the LSD are bound to blocks on the PSD. As such, physical blocks may be systems themselves and have internal SDS or even DDS representations. However, in SDS where an instance of each physical block is used, it is considered a black box component. This simplifying assumption allows us to delineate clearly the line between system design and component design. 82 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. To use its internal hierarchy and bind objects across elements would make consistency checks very difficult or even impossible. Another justification is the fact that physical elements are represented in SDS to support bottom-up methodologies that aggregate elements into a more complex element, and strongly rely on composition rules to obtain correct designs that do not take into consideration internal details. 4.4 Timing Predicates Timing predicates are information associated with TFD ranges that determine the activation of each range. If a range has no (timing) predicate it is an active range and will be traversed when the control flow reaches its source point. If a predicate is associated with a range, it will be traversed if and only if the predicate evaluates to a binary true value. There are two kinds of timing predicates: • Synchronous predicates, and • Asynchronous predicates. Synchronous predicates indicate the occurrence of a synchronous event, i.e. an event that occurs at a known time interval, even if this interval cannot be precisely determined. There are two types of synchronous predicates: deterministic choice and countable loops. The deterministic choice of control represents the familiar if- then-else exclusive conditional statement in programming languages. The countable loop represents for-loops or loops that have a bounded iteration. 83 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. An asynchronous predicate indicates the occurrence of an asynchronous event, i.e. it is not know exactly when the behavior bound to the associated range will be executed. When the asynchronous predicate becomes true an action is to be taken immediately. The main use of asynchronous predicates is to model resets and timeouts. 4.4.1 Synchronous Deterministic Choice Predicates A synchronous deterministic choice predicate is attached to each "then" out-edge of an OR-point and each "else" out-edge receives a negated predicate. These edges, ranges in the IT'D, are of kind causal, constraint or delay. For example, the following piece of code if cond then T1 else T2; indicates that if cond evaluates to true, the branch T1 will be executed, otherwise T2. To represent this choice of executions, a predicate <cond> is attached to branch Tl and a predicate <not-cond> is attached to T2. The synchronous characteristic of this predicate is that the time when it is tested and the branch decision is known. Definition 4.9: A synchronous deterministic choice predicate, is a two-tuple SCP={<cond. binding}, where <cond> is a binary expression and binding is a behavior process binding. a 84 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The condition is a regular expression that evaluates to either true or false. The binding captures the full behavior for each of the branches. Since ranges can be hierarchical, the predicate is inherited by all sub-ranges of each branch. The succeeding ranges after the OR-join point do not inherit any of predicates defined at the ranges after the OR-fork point. Figure 4.2 shows a template representation for an if-then-else statement and how it is represented in SDS. Binding B1 relates process T1 to range R1 and to module Ml and has the notation B1={T1. Rl. M l} . Similarly. B2 relates T2, R2 and M 2. Note that Rl and R2 are ranges of kind causal, constraint or delay. The synchronous predicates have the form SPl={cond. B1} for the then branch and SP2={not cond. B2} for the else branch. M1 R1 O R Fork OR join R2 / r "N SP2 M2 Figure 4.2: The synchronous predicate template. 85 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.4.2 Synchronous Loop Predicates Similar to choice predicates, loop predicates are also synchronous. The first difference is that they apply only to edges of kind loop. The second difference is that the cond in the predicate evaluates to an integer value, which is the number of iterations. Definition 4.10: A synchronous loop predicate is a two-tuple SLP={<arith exp>. binding), where <arith exp> is a regular expression that evaluates to an integer value. This value defines the number of iterations that the process bound to it will be invoked. The binding here is a process behavior binding whose range is of kind loop. 3 Since the range may be hierarchical, this predicate is inherited by all sub-ranges: however, it is no inherited by the edges that succeed this loop edge. 4.43 Asynchronous Predicates Asynchronous predicates model the occurrence of an asynchronous event such as timeouts and reset. When the asynchronous condition evaluates to true an immediate action is to be taken. An asynchronous event is an event that may occur at any time in a system, and as such cannot be easily captured by a directed graph as SDS’ TFD. 86 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Definition 4.11: An asynchronous predicate is a three-tuple AP={<binary exp>, a_range. point}, where <binary exp> is a binary regular expression that defines the conditions under which the asynchronous event occurs, a.range is the asynchronous timing range and point is the start timing point for the timing range to be initiated. □ When the asynchronous condition defined by the expression cbinary expr>. evaluates to true, an immediate action is to be taken. The asynchronous range a_range is already active and the action that serves that event, bound to the interval that follows the timing point, is taken. The specification of asynchronous event in a system implies that this event may occur any time during the system’s execution, thus a concurrent structure should be used to model the synchronous system behavior and the asynchronous event. In SDS. it is represented by the use of a pair of AND points, with one out-edge, a TFD range, bound to the rest of the system and another out-edge bound to the asynchronous event and marked with an asynchronous predicate. Another characteristic of asynchronous predicates is the possibility of preemption. When an asynchronous event occurs, the immediate action is performed and that action may or may not preempt the remaining system. A preemptive predicate can represent the occurrence of a reset, which means that all activities are to be stopped and resumed from a known point. A non-preemptive asynchronous 87 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. event is used to represent actions to be taken with unknown time of occurrence and that does not need to interrupt the rest of the system. An example is the wait for an external signal, and when that signal occurs an action is taken but the rest of the system can continue to operate as usual. These two constructions can model exceptions and non-deterministic loops. Loops are represented by a loop range marked with an asynchronous predicate and that range is inactive until the condition evaluates to true. i.e. no succeeding range is also active. Exceptions are represented by a causal, constraint or delay range. As an example. Figure 4.3 shows the SDS representation for the following code: when cond do TO : When cond becomes true, the action TO is to be taken. As an asynchronous event the time when TO is executed in not known and cannot be determined. The behavior process binding BO={TO. R O . M O } relates TO to range R O to module MO. The range RO has simple points PI and P2 as source and sink points, respectively. The concurrent template has range Rl bound to the asynchronous event and R2 to the (synchronous) system. The asynchronous predicate is defined as APl={<cond>, Rl, PI}- As stated above an asynchronous event is defined for the whole (sub) system and since the ranges can also be hierarchical, the inheritance is confined between the matching AND points. If the predicate is also preemptive. i.e. upon the occurrence of the asynchronous event all activities must stop, the asynchronous range is marked 88 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. with the predicate and all sibling out-edges (the rest of the system) posses an asynchronous predicate with a negated condition. RO Pi % P2 M O AP1 k V ___________ 1 N AND AND R2 Figure 4.3: The asynchronous predicate template. 89 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 5 SDS - Information M odel The information model presented in this section is provided as a common basis to describe the semantics of SDS components and objects. The modeling will make explicit the common features and the differences of the objects used in the four domains. As such it can be seen as a conceptual meta-modeling of data structures. As opposed to data modeling that is concerned with programming language primitives, information modeling abstracts from particular implementations and provides a basis for a general model. 5.1 Object Semantics A SDS component can be represented by objects in four domains, as seen in Section 4.2. The graph theoretical descriptions of process flow, logical structure and physical structure domains have each two classes of nodes and a single class of edges. The timing/sequencing flow domain has a single class of nodes and one class of edges. These classes are also characterized as 90 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Models, for nodes related to operations: • Links. for nodes related to information: and. • References, for edges connecting models and links. Figure 5.1 shows the type relations of model and link classes for a component in each domain. The reference class has simple types and no relations Object Domain Process Timing Logical Structure Model algorithm hw channel range Physical Structure block Link information point carrier Figure 5.1: SDS domains and object type Relations. net 91 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The class Model is the super-type for the objects with semantics related to operations. From this super-type, the types for operation nodes from PFD. ranges from TFD. modules from LSD and blocks from PSD are derived. ■ q nam e nam e Carrier (LSD) Block (PSD) Node (PFD) Information (PFD) Link Model Point (TFD) Module (LSD) R ange (PSD ) Net (PSD ) Figure 5.2: Types and super-types relations for models and links. The class Link is the super-type for the objects with semantics related to connection. The types for information from PFD. points from TFD, carriers from 92 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. LSD and nets from PSD are derived. Figure 5.2 shows these classes and their type relations. The class Reference is the super-type for the objects with semantics related to interconnection between the super-types Model and Link. The reference class is introduced here to explicitly model and represent the interconnection between objects in these classes defining a connection link. A reference object defines a netlist connecting a model to a link using pins1 . Pins are specific objects attached to models and links that represent their inputs and outputs. The class reference is present in the graph theoretical models as the edge sets. With this artifact the interconnections between objects are defined by a netlist that has a pin object attached to an instance of kind Model in one side and another pin to an instance of kind Link on the other side. Section 5.8 will describe in detail the reference class. A netlist exists for the process flow. logical structure and physical structure domains. For example, a process netlist interconnects an operational node to a channel node having one reference to a process pin attached to the operational node and another reference to another process pin attached to a channel node. Each instance of an information node has a reference to this process netlist. Figure 5.3 shows an example of a SDS information model of its internal representation. Msg I is an information node object and has Netl, of kind PF-Net. in its netlist reference. 1 The term pin is used loosely here to denote an I/O connection. 93 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Netl has in its pinjist the set pli={Pn, Pci} of kind PF-Pin. Pji is a point object and has node T| as a connected_to reference, and Pci is connected to node C 1. T1 T2 M sgl M sg2 C l (a) (b) Figure 5.3: Process Flow Domain information model, a) Process flow view, b) Corresponding information model. Table 5-1 shows a generic view relating all three classes of objects. The references class makes use of pins, namely PF-Pins, LS-Pins and PS-Pins, to be attached to PFD, LSD and PSD models respectively. Each type of link object may reference their respective reference object. 94 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table 5-1: Object semantic relationship. Domain \ Classes Models Links References Process Flow Algorithm, HW , Channel Information PF-Net Sequencing Flow Range Point - Logical Structure Module Carrier IS-Net Physical Structure Block Net PS-Net 5.1.1 Hierarchy One strategy of coping with complexity is to break a piece of the problem down into smaller and several pieces. Then, these pieces and their interconnections can be described separately. This principle of Decomposition is used in SDS to describe complex systems [Ebert, 1994]. Applying the principle of decomposition to the context of graphs leads to the principle of Refinement where a node of one graph can be replaced by another detailed (sub) graph. This refinement relation generates a directed tree-like hierarchy. This principle can be implemented using typed and attributed graphs, typed graphs because the graphs use several types of nodes and arcs, and attributed because the graphs use additional information attached to nodes and arcs. Aggregation is another concept used in the SDS hierarchy where an object is seen as the concatenation of sub-components. SDS objects use attributes like 95 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. procjref and charmel_ref. see Figure 5.5, as a list of sub-components that refines a component as an aggregation of several processes and channels. An empty attribute field denotes a primitive component. Their interconnection is described by a list of reference objects in the attribute field netjist, which is part of link objects such as the information objects in the process flow domain. See the objects Netl and Net2 in Figure 5.3(b). In order to provide full connectivity, ancillary objects, such as the pins Pti and Py:. are used to connect two model objects, T1 and Cl, and relate the link object. Msg I. being .ramferred. 5.2 Process Flow Domain The information model for the process flow domain uses three objects: nodes, links and pf-pins. The node super-type models the operational components and can have three sub-types: algorithm, hw or channel. Links represent the information to be transferred between nodes. Pf-pins represent the connection between processes and information nodes. Figure 5.4 shows the types for model and link objects: pf- pins will be discussed later with other reference objects. A process flow node is a super-type from which derive two sub-types: composed process and channel. A composed process has the sub-type process from which derives two basic types: algorithm and hw. The super-type node is in turn a sub-type of type model and inherits its attribute name. 96 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. nod* protocol behavior (unction function channel_ret composed process channel proc_rel into _ ref info_ref kmd kind i process algorithm - c catalog -a strength (a) information 1 -------- a data.type a kmd has_sub_mto -a net.bst (b) Figure 5.4: Process flow domain types, (a) Model type, (b) Link type. 97 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A node definition contains the following information common to composed process and channel sub-types: • Function describes the intended functionality of the node in a free textual format. • Kind defines a predefined function name from some taxonomy, such as JPEG_Encoder. CPU, EFT. EDCT. Ethernet. RS-232 or TCP/IP_stack. • Proc_ref is a list of process nodes instances that composes the node. An empty field denotes a primitive node. Each element is of type composed process. • Info_ref is a list of information node instances used to compose the node. Similarly, an empty field denotes a primitive node. Composed process type has the specific attributes: • Behavior is a reference to a host language, e.g. VHDL or C, describing in details the computation of that node. • Channeljref is list of channel nodes instances used to connect internal nodes. Similarly, an empty field denotes a primitive node. Channel type is not hierarchical, i.e. is not composed of sub-channels, but may be refined by a hierarchical process. Channel type has the following attributes: • Protocol is a reference to a protocol description language, e.g. MSC (message sequence charts) [ITU-T, 1993]. 98 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Procjref is a reference to a composed process instance that refines the channel kind. It may describe a full sub-system that may involve processes and channels. As an example of a proc_ref meaning for a channel, we describe a channel of kind Ethernet to be used in a system with an imposed personal computer architecture. An Ethernet channel defines two Ethernet cards and a cable. If both computers are geographically separated instead of connected by a single cable, the channel may define several cables and a sub-network composed by hubs, switches and routers. Hw type represents actual processes and as such has a specific description based on some taxonomy. e.g. “electronic/component/interface/ethemet/phys- layer/lOmbps". Hw types are related to the physical constraints attached to the hw node and have the following attributes: • Catalog is a two-tuple, where the first element describes a catalog entry to the detailed physical data sheet or to some taxonomy of physical components, and the second element is the Strength defining the intensity of this constraint. An information type definition contains the following attributes: • Datajtype is a generic name used to convey the meaning of this information instance. • Kind is a definition provided by the host or coordination language. 99 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Netjist is a list of reference objects of type pf-net that connects this information instance to node instances. An information instance can be hierarchical and contains sub-information instances. The hierarchy captured denotes a data typing structure that may induce a data type ordering. Figure 5.5 shows an example of a hierarchical process node (JPEG) composed of process nodes DCT. Q and ENC. and channels Cl and C2. There are four instances of information links connecting the five nodes. JPEG’s attribute field proc_ref has three entries one for each node, but for clarity reasons only the reference to DCT is shown. Similarly, the field channel_ref has two entries (Cl and C2) and the field info_ref has four entries (II »o 14). Figure 5.6 shows a textual representation of the above example. Only process flow entries are shown. The first four lines create an instance of a composed process, name it JPEG, assign a behavior description file and describe its intended function. The remaining lines refine the component, depicting the references to its internal constituents. 1 0 0 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. JPEG encoder channel_ref proc_ref info ref DCT ENC C1 C2 Figure 5.5: Process flow domain information model attribute examples. Create composed_process JPEG JPEG has name JPEG JPEG has behavior “c:/design/jpeg/jpeg.vhdl' JPEG has function "JPEG encoder side' JPEG has proc_ref DCT JPEG has proc_ref Q JPEG has proc_ref ENC JPEG has channel_ref Cl JPEG has channel_ref C2 JPEG has info_ref II JPEG has info_ref 12 JPEG has info_ref 13 JPEG has info ref 14 Figure 5.6: Partial SDS textual representation of Figure 5.5. Only process flow domain sub-components are represented here. 1 0 1 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5 3 Timing/Sequencing Flow Dom ain The Timing/Sequencing flow domain uses only one model super-type range, one link type point and one reference type tf-net. Figure 5.7 shows the types range and link. The type tf-net is discussed in Section 5.8. The range super-type is a hierarchical model and can be composed by points and ranges. A range definition has the following attribute fields: • Kind describes the (enumerated) type of the range. • Predicate is a list of possible predicates attached to the range. • Interval is two-tuple, where the first element is an arithmetic expression that defines the time duration of a range, and the second element is the corresponding strength. • Point jref is a list of references to point instances that compose a range. • Range_ref is a list of references to range instances that compose a range. There are four sub-types derived from the super-type range: • Causal_range separates two instantaneous events. All ranges in a system can be considered causal, and the reason to single out one type is to explicitly represent an unknown time interval, usually captured during system specification. • Constraint_range is a causal range with a specified time interval. • Delayjrange is similar to the constraint range, but its attributes are known and actually measured and can be obtained in a library of 102 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. components. Delay ranges have an attribute catalog to reference the source of this physical data. • Looprange is a causal range that either repeats itself, as in for-loops. or blocks the execution until the condition is satisfied. Loop ranges have an attribute called reg_expr that describes a regular expression that determines the condition governing the loop. This expression may evaluate to a binary or an integer value Points are link objects without hierarchy and have the following attributes: • Kind is one of the enumerated set: simple, and-fork. and-join. or-fork. or- join. • Sink is a possible list of ranges that succeed the current point. • Source is a possible list of ranges that antecede the current point. • Sub_point is a reference to the first or last point in a sub-range for the sink or source range, respectively. 103 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. range -a point_ref -a range_ref kind -Q predicate interval loop, range constraint, range ------ 1 I i | delay.range ! | c au sal.ra n g e ........... i i ............. reg_expr O 1 — — Q strength catalog (a) point | sink source - a sub.point -Q kind (b) Figure 5.7: Timing/sequencing Flow Domain types. 104 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.4 Logical Structure domain The logical structure domain captures the logical structure or topology of the system. In itself, it does not convey any meaning besides that of reflecting the topological view of such structure. This view is provided by the designer when specifying the system and can be obtained by conscious decisions in a top-down approach, reflecting the designer’s view. This view can also be provided by a bottom-up approach when the designer requires a given physical component and that component demands a certain structure. Meaning is assigned to LSD components when they are bound to objects in the PFD and TFD. providing then full behavior for the system. The information model for the logical structure domain is similar to the PFD model and uses three objects: modules, carriers, and ls-pins. Modules represent the structural aspect of PFD nodes, i.e. logically models processes and channels. Carriers model PFD information objects. Both objects can be hierarchical and be composed by sub-components. It should be noted that this hierarchy is described as an aggregation of elements and will be discussed in more details on Section 5.1.1. Ls- pins will be discussed on Section 5.8. LSD objects can have two different kinds of bindings: behavior bindings and realization bindings. Behavior binding relates LSD objects to PFD and TFD objects. Realization bindings relate LSD objects to PSD objects. To avoid the repetition of physical components and still be easy to understand. SDS does not enforce 105 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. isomorphism in realization bindings. Since realization binding captures the bottom- up design approach, sometimes designers use components with multiple functionalities. These components may eventually be mapped to distinct logical objects without any compromise. In order to represent memory and persistent components SDS uses a model object, in this case a module type. Link objects represent the flow or transfer of information only. Figure 5.8 shows the types module and carrier. A module definition contains the following attributes: • Function describes the intended functionality. • Kind defines a list of names, similar to the PSD process kind, but here it may define a list, instead of a single name, of available functions or computations. • Carrierjref is a list of carrier instances used to connect internal modules. • Module_ref is a list of aggregated modules instances. • Persistency is a two-tuple, where the first element is a tag that defines the module as persistent, and the second element is the storage size or capacity. Carrier is a super-type and its definition contains the following attributes: • Kind defines the sub-type of a carrier either scalar (or primitive) or multi dimensional. 106 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Keyjist is a list of names for each type of sub-carrier. • Dimension is a list of tuples. Each two-tuple defines a numerical range of the type. The tuple’s elements represent the lower and upper bounds of the range. A scalar type (of size 1) has both bounds equal to zero. • Organization is a super-type for sub-types scalar and multi-dimensional. It is hierarchical and can be decomposed into multi-dimensional sub components or to a primitive scalar. • Multi-dimensional is a super-type for complex data structures and defines two sub-types. • Capacity defines carrier capacity to transfer information in terms of a bandwidth. • Carrierjref is a list of aggregated carrier instances. An empty field defines a primitive carrier that can be bound to a physical net. • Net_list is a list of reference objects of kind ls-net that connects internal ls-pins. that in turn connect to modules. Scalar sub-type is a primitive type and admits no hierarchy. Scalar objects can either be a composite type with data_type attributes or be of primitive type _BIT. Multi-dimensional sub-type has the attribute organization that admits two sub- types: ARRAY and RECORD. Type ARRAY is an ordered set of elements of the same type. Type RECORD is a set of elements of different types and has the following attributes: 107 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Org_ref is a list of types for each element. • Keyjist is a list of names that identifies each element. 5.5 Physical Structure Domain Physical structure domain components capture actual components. In SDS a physical object is seen as a black box. in other words no internal representation is used. The physical object may be a sub-system lesci bed in SDS and/or DDS, but no internal object is related to any object in the SDS system description. To bind a PSD object to a LSD object, a name-based mapping is used. The field kind in both objects is used to provide the names. Hence, a common taxonomy is needed to avoid mismatches and semantic mistakes. In our current work, an internal partial taxonomy is being employed. Further developments in the EDA community may lead to a standard naming methodology [VSI. 1998] that may be used easily in SDS. Objects in the PSD have a larger set of attributes because they are closer to the actual implementation and can offer more information. Not all information is captured in SDS. but only the information relevant to system behavior. Further and more complete information can be retrieved using the attribute catalog. Some of these attributes are closely related to attributes in the LSD. In fact, each attribute set in the LSD is a sub-set of the equivalent attribute in the PSD. Since they are considered black boxes, objects in the PSD have no hierarchy. 108 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. m odule ■a function ■a persistency O m odule, ref <3 earner, ref -a dimension (a) -a persistency kind dimension capacity organization org.ref SCALAR data.type c RECORD multi-dimensional ARRAY earner (b) Figure 5.8: Logical Structure Domain types. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The information model of the physical structure domain uses two types: blocks and nets. Ps-pins represent the connection between blocks and nets. Blocks represent physical entities, such as chips, boards, connectors. IP (intellectual property) components, a personal computer or memory bank. Nets represent connectivity objects, like wires or cables. Figure 5.9 shows the types defined for the PSD. block -Q function -O kind -Q 3 0 . dimension -a cost.iist — 3 strength -O catalog net -O 30 dimension size capacity n et.list strength catalog (a) Figure 5.9: Physical Structure Domain types. (t>) Blocks and nets have the following common attributes: • 3D_dimension is a four-tuple, where the first three elements are a three- tuple that describes the physical dimensions of the block, and the fourth element is the Strength that specifies the intensity of this constraint. • Catalog is a catalog entry to the detailed physical data sheet or to some taxonomy of physical components. 110 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Blocks have the following attributes: • Kind is a list of function names implemented by the block. • Function is a textual description of the intended functionality. • Cost_list is a list of cost parameters associated to the block, such as power consumption or monetary cost. Nets have the following attributes: • Kind defines the type of the net. • Netjist is a list of references to instances of kind ps-net. • Size defines the carrier ability to represent information in terms of bitwidth. • Capacity is a description of a net capacity to transfer information in terms of bandwidth. 5.6 Bindings The Binding type is used to represent the bindings in SDS. Figure 5.10 shows the binding type relations. The super-type Binding has an attribute name to uniquely identify a biding instance. Two sub-types are defined: B_Behavior, for behavior bindings defined as a three-tuple, and B_Realization, for realization bindings defined as a two-tuple. The super-type B_Behavior has an attribute rangejref, which is a reference to a possible list of instances of TFD ranges. Two sub-types are derived: BB_Info, for 11 1 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. behavior information binding, and BB_Proc. for behavior process binding. Each sub- type has a pair of attributes that reference to instances of objects. The super-type B_Realization has two sub-types: BR_Info. for realization information binding, and BR_Proc. for realization process binding. Each sub-type has two attributes that reference to instances of objects. Isomorphism In a structural to physical binding, more than one component can be mapped to a single physical component, thus, creating a "shared by” relation and leading to a non-isomorphism between these two hierarchies. Non-isomorphism also appears after high-level allocation when more than one data-flow operation is bound to a single logical module, e.g. an addition and a subtraction are allocated to a single ALU. name Binding I B.Reahzation B.Behavtor BB Jnfo BR.Info info.ref camer.ref m od.ref proc.ref K 3 1 — a camer.ref m od.ref net. ref block.ref Figure 5.10: Binding types. 112 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DDS [Knapp and Parker. 1985] is not an isomorphic representation and the two main reasons are: 1) an isomorphic representation, specially between the logical and physical domains would lead to a poorly organized hierarchy: and 2) would increase the cost of implementation since sharing would not be permitted. SDS permits non-isomorphism as well, based on the same principles as DDS. Furthermore, since the LSD has a free interpretation, many objects are not related to any physical object, thus increasing the occurrences of non-isomorphism. Figure 5.11(a) shows a partial view of the LSD of a design in progress with module M3 refined by three modules of kinds Mm c and M cab ie- A realization binding relates module M^ie to the physical block of kind CAT5_cable. Figure 5.11 (b) shows one possible refinement of module Mm c and a set of realization bindings. It should be noted that SDS binds only LSD leaf modules to PSD blocks. In this design instance, modules LLC and MAC are bound to chip 1 that is able to realize their intended functions, module PHY is bound to block chip2, and the output connector is bound to block RJ-45. Another possible realization is to bind the module Mm c as a whole to a physical block E-NIC, which is an Ethernet card. Note that E-NIC has its own internal hierarchy, but since it is a PSD block, it is seen as a black box and the module Mm c is now considered as a leaf node and then bound to E-NIC block. In this case, the Mm c hierarchy is not considered in this design instance. 113 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. PC board Mnic Mnic cable Logical Structure (a) CAT 5 cable Physical Structure £ LLC M AC / PHY / / RJ-45 LLC M AC PHY Logical Structure Physical Logical Structure Structure Figure 5.11: Binding objects on LSD and PSD. Physical Structure Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.7 Timing Predicates Timing predicates are represented by the T_Pred super-type. Figure 5.12 shows the type relations. Two types are derived: Sync_Pred. for synchronous predicates and Async_Pred for asynchronous predicates. T_Pred has an attribute name to uniquely identify an instance. The Sync_Pred is a super-type for the synchronous predicates and has the attibute bbp_ref that is a reference to an instance of a behavior process binding. Two sub-types are derived: SLP. to represent synchronous loop predicates and SCP. to represent synchronous deterministic choice predicate. SLP has the attribute arith_expr that is a reference to a textual arithmetic expression that evaluates to an integer number. SCP has the attribute bin_expr that is a reference to a textual binary expression that evaluates to either true or false. The Async_Pred is a type to represent asynchronous predicates and has three predicates: • Bin_express is a reference to a textual binary expression. • A_range_ref is a reference to a TFD range that models the asynchronous event. • Poinr_ref is a reference to a TFD point where the action related to the event is bound. This point succeeding range is shared by the behavior process binding that defines that asynchronous action. 115 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. name T_Pred b bp.ref ; -a bin_expr SC P SLP anth_expr * — a Figure 5.12: Timing Predicate types. 5.8 The Reference Class The reference class is composed of two super-types: ref_net and ref_pin. Ref_nets represent the object th.»t co.meets the output ref_pin of one model instance, e.g. a PSD process, to the input ref_pin of another process, and relates this connection to the link instance, e.g. a PSD information object. Ref_Pin has the following attributes: • Kind defines the direction of data transfer that can be either input or output. • Datajxpe defines the type of information the pin can handle. It may reference to a structural description similar to an abstract data type. Type definitions in SDS are weakly typed. For example, a pf-pin may define a 116 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. set of enumerated messages, such as ack. and data, or complex information such as an image frame of 800x600 color pixels. A more refined ls-pin may define ack_packet, data_packet. or image_strcam. • Rate is the time interval between occurrences of the same event of an input or output information transfer. • Correlation is a two-tuple composed of a time interval and a ref_pin reference. The time interval is between occurrences of different events of an input or output information transfer, where one event is the transfer on the current pin and the other event is another transfer that occurs on the ref_pin. Pf-pins have the attribute proc_ref, which is a reference to a PFD node instance to which the pins is attached. Ls-pins have the attribute modjref. which is a reference to a LSD node instance to which the pins is attached. Ps-pins have the attribute blockjref, which is a reference to a PSD node instance to which the pins is attached. Ref_Nets have only one attribute pin_list. which is a two-tuple, composed by two references to a source and a sink pin instances. For pf-nets the instances are pf-pins. for ls-nets the instances are ls-pins and for ps-nets the instances are ps-pins. 5.9 Information Detailed Representation System-level information descriptions involve both structural and temporal aspects. Information can range from scalar values to multi-dimensional streams to 117 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. packets of messages. Information can be fed to input ports at some given rate as streams or be stored at some memory device, like a magnetic disk. Depending on the granularity, the information timing can be regarded as instantaneous. For example, when a coarse granularity is used, a message arrives to an input port and the entire contents it carries is immediately captured. When a finer granularity is used, the message's meaning is wrapped in additional data, such as a header and a tail. In this case, in order to access its contents the header and tail must be processed and each part arrives in sequential order. The structural aspect of information is represented in the LSD using (possible hierarchical) carriers. These carriers are then bound to TFD ranges and this binding provides the temporal aspect. Since both carriers and ranges can be hierarchical, each instance of information granularity can be bound to a range at the same level of hierarchy maintaining some isomorphism at the behavioral view. i.e. the objects on the PFD. TFD and LSD domains. 5.9.1 Persistency of Information Persistency is captured and represented in SDS using channels (PPD), modules (LSD) and blocks (PSD). It cannot be captured by information nodes (PFD) because information per se is not persistent. Likewise, carriers (LSD) are not adequate because they are bound to physical nets. Finally, nets (PSD) may not fully capture persistency, even though some technologies may provide persistency, e.g. the CMOS technology, however, persistency in physical nets is not generally the case. 118 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. -d p in _ list ; PS-Net (PSD) LS-Net (LSD) Ref Net PF-Net (PFD) (a) a proc_ref a mod ref name -q data,type kind < j correlation PS-Pin (PSD) LS-Pin (LSD) Ref-Pin PF-Pin (PFD) 4 block ref I (t» ) Fig jre 5.13: The reference class and its types. Persistent information cannot rely only on the physical property of a given technology, and it should be retrieved consistently, i.e. once stored in a persistent component that same information should be recovered correctly without changes in its content The basic operation of persistent components is based on storing a datum 119 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. with a key, and later recovering that same datum with the same key2. Intuitively this operation denotes a behavior that can be represented by a function to store and a function to recover the information. Thus, the operation of persistent component should use SDS behavior representation features that are based on the model type of components and can be captured by channels, modules and blocks, and fully represented with a behavioral binding. Using what was described above a special attribute is used to characterize persistency. Persistent components may be introduced into the design from a bottom- up perspective, either by the designer who required a consistent module in the system, e.g. a memory sub-system, or by an analysis tool that finds necessary a temporary storage, e.g. due to different rates of production and consumption between two processes. Persistent model objects demand related objects to be persistent as well. A persistent information node demands persistent input and output pins that have specific operations and a restricted set of coordination. It is important to notice here that the notion of persistent operation directly affects the coordination view of the system. Binding persistent components requires special care. For the behavior bindings, only persistent objects can be related. Persistent modules have attributes to represent ' The key is used to uniquely address a datum. For example, a key in a semiconductor memory is an address, while in a database is a record identification or a query. 120 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. their capacity. Realization bindings relate persistent modules to persistent block and the capacity attribute must be matched or exceeded by the physical object. 5.9J Information Representation Systems demand more complex data formats than lower levels of design. Scalar and one-dimensional arrays are not sufficient, and abstract data types (ADT) are commonly used by programmers. Thus, a more complex model is needed to represent ADTs and reflect the system level of abstraction. ADTs are also structured and hierarchical. SDS supports ADTs with arbitrary levels of hierarchy using aggregation. The most primitive information type defined is the type _BIT. which represents a binary value or bit. Using aggregation, bits can represent information that is more complex: for example, an array of eight bits can represent a byte. As long as the aggregation is considered as a single unit, it is classified as SCALAR. i.e. no internal sub-element can be directly accessed. Multi-dimensional information can be organized by aggregating several scalar elements. Arrays are multi-dimensional information where all the elements are of the same type. Figure 5.14 shows the definitions of a one-dimension array of eight bits, named A. and a two-dimension array of size 4x4 elements of type A named B. 1 2 1 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. array A [0..7] of _BIT; create A as LSD_carrier A has org ARRAY A has dimension [0,7] A has data_type _BIT array B [0..3][0..3] of A; create B as LSD_carrier B has org ARRAY B has dimension [0,3][0,3] B has data_type A Figure 5.14: Array representation in SDS. Records are multi-dimensional information objects, where each element of the record may have different types. They are an aggregation of fields identified by a key with a name, and each element type can be an ADT of its own. f5.l5shows the definition of record C that is composed by four fields: sender, receiver and command of type A. and field ack of type _BIT. Type C is the new record type and instantiates types A and the primitive type _BIT. Figure 5.16 shows the SDS representation for record C using the type definition of Figure 5.15. Each field is instantiated, having a unique name. The definitions for fields receiver and command follow closely the definitions for sender. After the fields are defined, they can be aggregated at the definition of the composed type named C. Note the list of references to the sub-fields and their respective key entries. 1 2 2 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. record C { A sender,receiver; A command; _BIT ack; > C BIT sender ack receiver command Figure 5.15: Example of a data structure of type RECORD and its composition by aggregation. This scheme of ADT representation provides for the definition of more complex data structures, such as lists, trees and tables. Efficient memory management of embedded systems resorts to meta-data representation to improve performance in terms of access time and power consumption [Wuytack et al.. 1999. Balasa. 1993 #190. Gupta. 1994 #116], 123 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. create sender as LSD_carrier sender has org SCALAR sender has dimension [0,0] sender has data_type A create receiver create command create ack LSD_carvitr cck has org SCALAR ack has dimension [0,0] ack has data_type _BIT create C as LSD_carrier C has org RECORD C has org_ref sender C has org_ref receiver C has org_ref comm C has org_ref ack C has key_list “sender* C has key_list “receiver* C has key_list “command* C has key_list "ack* Figure 5.16: SDS representation for data structure of type RECORD. Another important aspect is that information at the system-level is not only structurally complex but has a dynamic aspect as well. Information either is fed or has to be retrieved at some interval of time. This is particularly important on signal processing or communication systems, where information is fed to the system with some periodicity. 124 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Definition 5.1: A Data Stream, or Stream for short, is a sequence of synchronous data items called samples. a Each data item can be viewed as a sample and streams can be hierarchical. Data items appear at synchronous intervals called sample slots, and these slots can occur over cycles. A unit cycle means that a sample is followed by the next sample. A cycle 'arger than one implies an interval of time between samples. The structural hierarchy of a stream can be represented in a way similar to an ADT. The dynamic timing aspect is represented using TFD ranges and binding logical carriers to ranges. Since both domains are hierarchical. SDS can fully represent streams. Although not part of this work, to capture the timing behavior of a stream the specification language can use Allen's intervals [Allen. 1983] to relate samples of data, the structural organization and the timing interval among those chunks of data. To illustrate the representation of a stream we take as an example an image stream of a video frame composed of 800x600 pixels, i.e. one frame is equal to 600 lines with 800 columns and a pixel in each position. In Figure 5.17, the stream is represented in the logical structure and timing flow domains. Explicit bindings relate data samples to timing ranges on multiple levels of hierarchy. 125 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. L600 level 1 LSD 1 1 1 P2 P800 F 1 -►O level 2 O " \ L 1 ♦o- V»1 _ P800 level 3 Q e » 0 » Q — L 2 - ► O TFD Figure 5.1 7: A stream of a video frame represented in the LSD and TFD. Definition 5.2: A Packet is a sequence of heterogeneous concatenated data items. Packets are usually asynchronous, having heterogeneous items and are characterized in time by a data rate. □ Asynchronous communications are usually defined by a baud rate, which is the rate of symbols, and can be equated to a bit rate. A packet is analogous to a data structure record composed by heterogeneous fields. The main parts of a packet are the header, the body and an optional tail. The header carries control information. 12 6 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. such as sender, receiver, flow control, and length. The body carries the information. The tail carries error control and sometimes recovery information. In a similar fashion, packets can also exhibit multiple levels of hierarchy in both LSD and TFD. As a matter of comparison, streams are analogous to data structure arrays and packets to records. 127 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 6 Translation to Petri Nets In this chapter, a syntax-directed translation of SDS descriptions to Petri nets is presented. This automatic translation transforms each basic SDS construct into a Petri net. The resulting nets are then connected according to SDS original description. The overall mapping is semantic preserving in the sense that the SDS control behavior is mapped to Petri nets. Data dependent behavior cannot be easily represented in Petri nets, since we do not represent the data in Petri nets. However, data-dependent control flow can be represented with a non-deterministic behavior. Petri nets offer a formalism to model concurrency, non-deterministic choice, synchronization and causality [Peterson. 1977]. Besides, there are a wealth of formal verification techniques available [Vercauteren et al., 1998], [Pastor et al., 2001], [Murata, 1989]. Important properties of Petri nets are decidable [Murata, 1989], among them liveness and reachability. 128 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. In this chapter, a special class of Petri net is focused. Ftee-Choice Petri nets, that explicitly represents and makes clearly distinct the notions of concurrency and choice. 6.1 Petri Nets In this section, we define the basic Petri net terminology and notation. Some extensions are also introduced and can be added to the basic definition. For a more complete definition, the reader is referred to the tutorial [Murata. 1989] and to detailed extensions in [Best and Thiagarajan. 1987]. Definition 6.1: A Petri net (PN) is a four tuple N = (P. T. F. m 0). where: P is a finite set of places. T is a finite set " * f transitions. where P u T * 0 . and P n T = 0 . F is a set of direct arcs F={ PxT u TxP}. and mo is the initial marking defined as m o: P — »Nat. □ A Petri net is a directed bipartite graph composed of two kinds of nodes, places and transitions, and directed arcs. Arcs link places to transitions and transitions to places. Tokens are also a primitive concept like places and transitions and may be assigned to places. The number and positions of tokens may change during the execution of a Petri net. A marking is a mapping of places to the set of natural 129 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. numbers, indicating the number of tokens in the places of a Petri net. Let M be the set of all markings in a Petri net, the initial marking mo e M denotes the initial state of a Petri net. Table 6-1 shows some typical interpretations of places and transitions in a Petri net. Table 6-1: some typical interpretations for Petri net objects. Input places Transitions Output places Preconditions Event Postconditions Input data Computation Output data Resource needed Job Resource release Buffer Process Buffer Most of the theoretical work on Petri nets is based on the formal definition given above. However, a graphical representation called a Petri net graph is used to illustrate the concepts. A circle represents a place and a bar or a box represents a 'ransition. Directed arcs connect places and transitions. An arc connecting a plac.' p, to a transition t, defines p * to be an input place of tr Similarly, an arc from transition tj to a place p* defines pt to be an output place of t} . A circle containing a dot represents a place that contains a token. A transition without any input place is called a source transition, and one without any output place is called a sink transition. Source transitions are always enabled and sink transitions consume but do not produce tokens. 130 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The behavior of many systems can be described in terms of states and their changes. To simulate the dynamic behavior of a system, a state (marking) is changed according to a transition rule: 1 . A transition / is enabled if each of its input places is marked with at least one token. 2. An enabled transition may or may not fire (or be activated.) 3. A firing of an enabled transition t removes one token from each of its input places and adds one new token to each of its output places. To illustrate these concepts. Figure 6.1 (a) depicts a Petri net with the initial marking m o = (2.1.0). Transition tl is enabled since each of its input places has at least one token. After the firing of 11 , one token is removed from places p 1 and p2 and a new token is inserted in place p3. as seen in Figure 6.1 (b). The final marking is denoted as mi = (1.0.1). p1 p1 P2 P2 (a) (b) Figure 6.1: An illustration of a transition firing, (a) initial state; (b) final state. 131 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The following properties are decidable and important in this work: o Reachability: a marking m ’ is reachable from a marking m if there is a firing sequence fs starting at marking m and finishing at marking m o Liveness: a petri net is live if no matter what marking has been reached it is possible to fire any transition of the net through some further firing sequence. A live net guarantees deadlock-free operation. An important extension to the general Petri net definition is a new kind of arc called inhibitor arc [Murata. 1989]. An inhibitor arc connects a place to a transition. It is represented by a dashed line terminating with a small circle. The inhibitor arc disables the transition when the input place has a token and enables the transition when there is no token and the other input places enable the transition. The inhibitor arc adds the ability to test the absence of tokens providing the capability of modeling priorities and increases the power of Petri nets to the level of Turing machines [Murata. 1989]. Another interesting extension is the Free-Choice Petri net. The Free-choice Petri net (FCPN) is a sub-class of Petri nets and exhibits a clear distinction between choice and concurrency. This makes FCPN appropriate to model computations in which the outcome of a choice depends only on a value and not in the arrival of a token. The overall mapping from SDS maps computations to one type of nodes (transitions) and channels to another type (places). Data-dependent control, or choice, is mapped as a place with multiple transitions, one for each possible condition. 132 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Definition 6.2: A Free-Choice Petri Net (FCPN) is an extended Petri net where every arc from a place is either a unique outgoing transition or is a unique incoming arc to a transition. □ Free choice nets allow modeling both conflict and synchronization, and represent them explicitly in the structure of the net. Figure 6.2 (a) shows a FCPN. where place pi represents a choice and enables transitions tl and t2 simultaneously. However, only one transition can fire since there is only one token at the enabling place. A conflict arises when a place enables two distinct transitions, thus implying a non- deterministic choice. FCPN imposes the restriction that a (conflict) transition that is successor of a choice place has exactly one predecessor place. In other words, this transition should depend only on the predecessor choice. The direct implication is that when such a conflict transition is enabled, all the output transitions of that place are also enabled. Therefore, the FCPN models data-dependent control by abstracting the if-then-else decision as a non-determin'<-tic choice [Sgroi et al., 1999]. Figure 6.2 (b) is not a FCPN because both transitions tl and t2 are enabled by .he same places. Synchronization is modeled by a transition that has more than one incoming arc. and one of them is connected to a synchronizing place. The interpretation is that this transition can only fire when the synchronizing token is present at the synchronizing place and all other predecessor places have a token as well. 133 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. t1 p 1 t 1 t2 t2 (a) (b) Figure 6.2: Example of (a) a Free-choice Petri net: (b) not a Free-choice Petri net. 6.2 Syntax-directed Translation Petri nets have been used to model diverse aspects of computing systems [Peterson. 1977]. The nice features of Petri nets have spurred a recent increase in their use in embedded systems for the analysis, scheduling and synthesis of hardware and software components. Julie [Vercauteren et al.. 1997: Vercauteren et al., 1998] is a tool developed to design embedded systems specified in a process calculus that is then translated to an internal Petri net representation where system verifications can be performed, in special the absence of deadlock. Cortadella et al. [Cortadella et al., 2000] translates FIowC. a language C dialect with communication extensions, to Petri net and performs analysis and schedule of sequential programs whose implementation is mapped as software to be executed on a processor. Sgroi et al. [Sgroi et al., 1999] uses FCPN to synthesize embedded software. 134 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Petri nets are also used as an internal representation. Peng et al. [Eles et al.. 1998] model designs using an extended timed Petri net to represent the control of a digital design and a directed graph for the data path. A translation from VHDL is performed generating the internal representation. Ancillary annotations are used to relate the control and data representations. Jong and Lin [Jong and Lin. 1994] generate protocol converters for communicating interfaces described by siguai transition graphs and represented internally by Petri net. Muller and Kramer [Mueller and Kraemer. 1993] translate a multi-process synthesizable subset of VHDL specifications to Petri net. Special care is taken to capture the multi-process behavior using signal assignments and waits. The Petri net is then reduced to improve analyses. Olcoz and Colom [Olcoz and Colon, 1993] translate VHDL descriptions to Petri net. They not only translate processes but the simulation semantic of the language they call the kernel. In this approach, the description of each process is translated into a Petri net. First sequential statements are translated, then the signal and wait statements and finally the Petri net corresponding to the kernel process. This kernel Petri net is built based on the signal and wait statements used in the processes for communication and synchronization. The resulting Petri net combining the processes and the kernel is then used to analyze properties of the VHDL program, again in special deadlock-freedom. 135 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6.2.1 Translating SDS Descriptions Into Petri Nets The objective of this approach is to provide an early analysis of a system description. Petri nets offer sound methods for reasoning about dynamic behavior of the control part of a system, including the verification of liveness properties, such as “something good eventually happens”, e.g. the absence of deadlocks, and safety properties, such as “nothing bad happens”. Since the Petri nets representation does not capture data dependencies, deadlocks depending on signal values are not detected. In SDS. the TFD imposes a total partial order, thus eliminating the need to analyze PFD, since all information dependency is already captured in the TFD. Therefore, the TFD is translated into a Petri net. The translation procedure is a syntax-directed translation, since each basic SDS construct is semantically self-contained and does not depend on any other source of semantic information. The TFD is traversed in a bottom-up approach where each construct is found and translated into a corresponding Petri net. In this fashion, not is only each construct captured and translated, but also the overall control structure is preserved. The class of basic constructs is composed by the following members: sequential composition, parallel composition, choice, for loop, while loop, wait and asynchronous predicate. Each Petri net has only one input place, representing the beginning execution of the SDS structure, and one output place representing the end of execution. The composition of the complete behavior is accomplished either by 136 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. fusion of places, the end place of one net fused with the beginning place of the succeeding net. or by adding a transition with an incoming arc from the output place and adding an outgoing arc to the input place. 62JI Sequential Composition Sequential composition captures a sequence of two or more ranges in the TFD. such as the sequence of two consecutive statements in a programming language. Figure 6.3 v a) depicts the SDS representation of sequential execution of T| and T; bound to ranges rl and r2. respectively. Figure 6.3 (b) depicts the corresponding Petri net. where transitions tl and t2 represent the ranges rl and r2. and. by the related bindings, the processes T| and T2 . Places pi and p2 are the entry and exit points of the Petri net, respectively. As an example of net reduction. Figure 6.3 (c) shows a possible reduction where the transition tt 2 represents the combined processes Ti and Ti. 6.23 Parallel Composition The parallel composition is represented in SDS by the use of a pair of matching AND nodes, one AND-fork and one AND-join, and as many ranges as needed from the fork node to the join node. Figure 6.4 (a) depicts the SDS representation of a two-branch parallel composition. The translation to Petri net is straightforward; the AND-for is translated to the transition tO and the AND-join by transition t3. Notice 137 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. that t3 is a synchronizing transition and will proceed after both sides finish, i.e. tl and t2 fire and generate a token each. v iS) P3 P2 P1 r2 r1 (a) (b) (c) Figure 6.3: Sequential composition. 6.2.4 Choice The choice is represented by two SDS constructs, the matching OR pair of points and the synchronous predicate (SP). The first point is an OR-fork and only one of its outgoing ranges is enabled. Each range has a synchronous predicate that evaluates to either true or false. The ranges are connected to the matching OR-join point. Each range is translated into a transition, rl and r2, and a choice is induced by place pi. The labels associated with the outgoing arcs from place pi to transitions rl and r2 are not used by the Petri net and serve only as commentary. 138 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. / AND AND r2 V (a) Figure 6.4: Parallel composition. SP OR OR (a) Figure 6.5: Choice composition. (b) (b) 139 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6 ^ 5 While Loop The while loop construct is a bit more complex. In SDS. it is represented by a loop range with two synchronous predicates and two behavioral bindings. The loop range will repeat itself depending on the condition. The operational semantics defines that while the condition is true the loop body is to be executed and the condition tested again, again repeating the sequence. In SDS the condition execution must be evaluated prior to the range r2 where the while loop is represented. Upon reaching range r2 if condition cond also true, the behavior binding BO is analyzed and TO executed. Then the other behavior binding B1 is executed and the loop condition re-evaluated. Figure 6.6 (a) depicts the SDS construct. The translation to Petri Net involves the evaluation of the condition, a test on that condition and a decision to exit or to execute the loop body with an immediate branch back to the condition evaluation. Figure 6.1 (b) depicts the resulting Petri net. Upon entering the net. the transition T cond is fired representing the evaluation of the condition. Place P2 represents the decision on the outcome of that condition result. The arc labeled F represents the exit of the while loop, while the arc labeled T fires transition TO representing the loop body, which is bound to process To in SDS through binding B o- From T0 the place PI receives a token again and fires the condition evaluation. 140 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. r2 I So <loop> cond S P c o n d = {<cond>. B1} SPT0= {<cond>. B1} B0= {T0. r2,m2} ® cond ~ {"^"cond’^ 1 ’^2^’^ c o n d ^ (a) Figure 6.6: The while loop construe:. 6.2.6 For Loop cond (b) The for-loop construct is composed in SDS by a loop range with a timing synchronous predicate and a behavior binding. The timing predicate determines the number of times this loop is to be executed and relates the behavior binding with the process to be executed. Figure 6.7 (a) depicts the SDS representation for a loop that executes process Ti one hundred times. The operational semantics imposes that process Ti must be executed at least once and then the loop ranges are computed. 141 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. <loop> SP={<0<=i<=99, B1} o (a) Figure 6.7: For loop construct. SP. ,sp (b) Figure 6.7 (b) depicts the corresponding Petri net. When the execution arrives at the entry place pi. the First transition is fired. This enables transition T1 to be fired. Place p2 represents the loop control with arc labeled according to the possible outcomes. Firing transition rl computes the loop bounds and enables transition T1 again. The firing of transition r2 exits the Petri net. An important result of this translation process from SDS to Petri net is already present in this simple example. Comparing Figure 6.6 (a) to Figure 6.7 (a), it is easy to observe the difference between them: however, comparing Figure 6.6 (b) to Figure 6.7 (b) shows that there is no structural difference between them. All the labeling 142 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. used on the Petri net is for commentary purpose only and is not used by the Petri net. This first comparison shows the loss of knowledge or information when translating SDS into Petri net. 6.2.7 Wait or Synchronization A wait or a synchronization SDS construct is a TFD range with a timing predicate but no behavior binding: the process is blocked from further execution while the condition does not evaluate to true. Figure 6.8 (a) depicts the SDS representation where the range rl is of kind loop. Attached to rl there is a synchronous predicate SPw a n with the defined condition but no process to execute, since it is modeled as a not-busy wait. The translation is straightforward as 'vpicu.d in Figure 6.8 (b). with transition T 1 representing the wait loop. Place Pltm j . nrese»-is the condition result and place PI the TFD entry point pi. Place P2 represents the exit point. Transition T1 will only fire when the execution reaches the construct by place PI receiving a token and the condition evaluates io true depositing a token at place P co n d - 1 4 3 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. O-Tt t O bond SPw art= {<cond>, -} (a) (b) Figure 6.8: Wait construct. 6.2.8 Asynchronous Predicate Process-based specification may use a special composition called interruption to model events like reset. A process Q1 is interrupted by the first event of process Q2. written Ql [> Q2. When interrupted, process Q1 enters a suspended state, and the composition assumes the behavior of Q2. After Q2 is terminated successfully. Ql leaves the suspended state and resumes. Vercauteren et al. [Vercauteren et al., 1997], when translating this composition, produces a Petri net where every transition (event) in Ql has a self-loop. Each self-loop enables the firing of net of Q2 and is enabled by the termination of Q2. Although this is an abstract specification, its representation is very close to a realization. A similar approach is adopted in DDS [Knapp and Parker, 1985] to represent an asynchronous event. The asynchronous binding attached to a range is in fact an abstraction of a parallel fork to the reset (asynchronous) action. 144 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. An SDS construct illustrating the use of the asynchronous predicate is shown in Figure 6.9 (a). As defined in Chapter 4. an asynchronous predicate imposes a parallel construct where one branch is bound to the asynchronous event and the other branch to the rest of the system. One asynchronous timing predicate. AP. defines the condition that triggers the action represented by the TFD sub-graph pa, P b and rO . The translation to Petri net can be subdivided into three major parts, as seen in Figure 6.9 (b). The first part translates the parallel construct and is represented by the net composed of places PI to P6. The only difference from the regular parallel construct is the existence of an extra arc from transition Tl. The second part represents the wait condition for the asynchronous event and is similar to the previously defined wait construct. The extra arc from Tl is part of the enabling of the wait transition TO . The final part is the representation of the condition evaluation by the subnet composed by places Cl and C2, and transition Tc o n d - When T c o n d is fired, a token is sent to place Pa of the wait subnet. If that condition is dependent on an input signal instead of the cond evaluation subnet, place Pa is linked to the output of that input signal representation. An extra transition was added between places C2 and Pa and the second arc emanating, labeled preempt, is an inhibitor arc to be used to preempt other processes if the asynchronous predicate is of kind preemptive. The arc is then connected to transitions to be disabled. 145 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. cond AP={<cond>,r1,r0} O - H ^ o P4 p5 r2 Pa «) Pb (a) (b) Figure 6.9: The asynchronous predicate. 6.2.9 Linking Subnets Linking the translated subnets is a straightforward procedure. Since most of the statements composing a process are determinate, in the sense that once started the net will eventually finish and will not need external resources or conditions. There are two main options: • Insert an extra transition between the end place of the previous subnet to the beginning place of the next subnet. Only one arc is used in each connection. • Fuse or “abut” the end place with the beginning place, saving the creation of the extra transition and arcs. 146 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The exception to these cases above is the use of one synchronization or blocking communication primitive. To solve this problem the process can be sub-divided into sub-processes before and after that primitive and the two sub-processes plus the synchronization primitive can be connected in a way similar to the Asynchronous Predicate of Section 6.2.8. 6 3 Translation Validation Each of the above-translated SDS structures was tested using a Petri Net analysis tool called INA et al. - Integrated Net Analyzer [Starke and Roch. 2000], To model input and output signals, source and sink transitions are used, respectively. To test for liveness and safeness each end place was fused into the beginning place. Table 6-2: SDS to Petri net translation properties. Petri Net Properties Structure #Places #Transitions Live Safe No. Reach. States Sequential 2 2 Yes Yes 2 Parallel 5 4 Yes Yes 5 Choice 2 3 Yes Yes 2 For Looo 3 4 Yes Yes 3 While Loop 3 4 Yes Yes 3 Wait 2 1 Yes Yes 1 Async. Predicate 11 8 Yes Yes 21 The table confirms our claims about the for loop and the while loop, and the analysis results are the same for both. Except for the asynchronous predicate, all 147 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. constructs have a small number of reachable states. The asynchronous predicate construct involves a more complex Petri net composed of simpler sequential, parallel and wait constructs and the resulting number of reachable states is larger than the number of places and transistions. This hints at the problem of the increasing number of reachable states when composing the translated SDS constructs. We also experimented with the asynchronous predicate, but without fusing the beginning place for the condition test, simulating an input port without tokens, i.e. an input port without data. This modification disabled transition ro in Figure 6.9. accumulating tokens at place P6. thus making the net not safe and not live which may lead to deadlock. In this Chapter we have shown that the SDS underlying formal model is solid and each SDS construct is safe and live after translation to Petri nets. After translating processes into composed Petri nets, deadlocks will exist only if the composition of SDS constructs itself induces the deadlock. 148 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 7 OSCAR In this chapter, we present OSCAR3 , a visual language for the capture of system designs. OSCAR was designed to be a user interface to several USC system-level design tools. OSCAR provides an interface to enter SDS information but is limited to certain structures in SDS found in the system design tools OSCAR supports. Our initial goal was to provide a unified and consistent framework for the capture, representation and validation mechanisms where system-level design requirements are given and corresponding high-level information is also available. The representation can be used as the input specification to system-level synthesis tools. A visual language is presented to capture the design in a structured way. Relevant system-level aspects are captured and more detailed information can be attached. The behavior of individual modules is described using a Hardware 3 OSCAR is homage to the Brazilian architect Oscar Niemeycr. 149 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Description Languages (HDL). Specification using HDLs is not new and attempts go back to the early sixties. The earliest standard is VHDL [IEEE. 1987]. and a later one is Verilog [Thomas and Moorby. 1991]. Besides these standards, research groups defined their own languages, such as HardwareC [Ku and DeMicheli, 1990], Silage [Hilfmger and Rabaey. 1992] and ISPS [Parker et al., 1979]. In USC's ADAM synthesis environment, a subset of VHDL was selected: a commercial compiler is used to parse the source code and a back-end optimizes and generates a DDS representation. A common characteristic among most of these languages is the lack of a clear communication mechanism and the lack of exception handling, although Verilog has some exception handling and HardwareC offers some communications primitives. Some properties of the design specified with OSCAR can be checked against a design rule set and system-level properties, e.g. communication and synchronization among modules can be validated. System design capture cannot rely only on available HDLs. since none of them was designed for describing designs at the system level. Block diagrams are too informal to be used and even Task Flow Graphs (TFG) can lead to ambiguities. At present, there is no standard to guide their definition and use. However, all of the above approaches offer interesting characteristics. Block diagrams and TFGs exhibit inherent abstraction. HDL offers a syntax formality and defines information in terms of abstract data types. All these characteristics could be used in a single framework. 150 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 7.1 Specification Issues at the System-Level 7.1.1 Languages Software architecture techniques [Garian and Shaw. 1994: Kramer et al.. 1993: Luckham et al.. 1995: Moriconi et al.. 1995: Shaw et al.. 1995] cope with large software systems in a more formal manner. A common approach among researchers in tiiia area is the use of a structured view of a system. Our specification research has been influenced by the work of Garian [Garian and Shaw. 1994], He suggests that a rigorous basis for understanding architectural styles is needed for a better use of software architecture. Garian gives the following useful requirements: Vocabulary: consists of a set of basic components and connectors to be considered as design elements. This set is the basic type for this language. Configuration Rules: is a set of topological constraints that determine the permitted composition of elements. Semantic Interpretation: is a set of composed and well-formed elements that provides a well-defined and unambiguous meaning. Three views of Software Architecture styles can be found in the literature: Language where the vocabulary is modeled as a set of grammatical productions. A semantic interpretation is easy and some analysis can be performed, and types where the vocabulary is viewed as a set of types. Object-oriented specifications provide a suitable basis for hierarchical definitions. The elements can be referenced as generalization/specialization of basic types. Theory when a given style can be 151 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. viewed as a set of axioms and rules. Verification can be done by theorem proving and refinements can be derived precisely and formally. A language, as a semantic carrier, is obviously necessary to convey the design knowledge of a design. A Type-oriented approach is more suited to system-level design since important aspects are addressed, such as hierarchy, refinement and reuse. 7.1.2 Representation Representation of digital designs is an often-neglected aspect of research and very few approaches exist. OSCAR has its origin in the DDS (Design Data Structure) developed at the University of Southern California, which spans from high to physical levels [Afsarmanesh. 1989: Chen. 1994: Granacki. 1987: Hayati. 1990; Knapp and Parker. 1985]. Briefly speaking it is a unified and neutral representation based on four domains that are near orthogonal, and it supports hierarchy. Each domain is independent of the others and self-contained. Both specification and implementation are represented. There are bindings that link domains in order to relate them. The separate domains bring a simple consistency and little redundancy. DDS is well suited for high-level designs and specifies and represents designs down to the physical level. However, at the system level not all the information and detail requested by the DDS is necessary. Furthermore, important system-level concepts, albeit present in DDS, are not explicidy and readily available and can be expressed in many possible ways. This set the stage for a specific representation 152 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. scheme that addresses system-level issues and provides information for easy design checks. More details can be left to DDS if consistency is kept between the two representations. 72 Problem Approach To cope with the inherent complexity of systems. OSCAR views systems as composed of cooperating communicating processes or components. This view implies that a component in a block diagram is the locus of functionality and it communicates with other components through ports linked by connectors. Although simple, this approach can capture an abstract view of systems. However, we need to fill in the gap from this abstraction in order to provide a more concrete view. To accomplish this, a multi-level specification is necessary. A single level of abstraction would be either too complex and maybe inconsistent in itself, or incomplete. Moving from a more-abstract to a more-concrete domain requires different approaches to capture the information. We include the use of both visual and textual design capture, the former for a more abstract view where all details are not relevant, and the latter for a more concrete view where visual or iconic languages tend to be too complex. OSCAR uses a two-level specification. The communication model used by OSCAR is based on a message-passing paradigm. We choose it due to the fact that message passing is an abstract and neutral approach to concurrency. Other methods can be easily derived. We define a 153 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. set of communication primitives to use during the design capture. These primitives can be divided into two groups: blocking and non-blocking, and specialized for synchronization and data-transfer. An important aspect of this model is that it is an observational approach: i.e. all events must be visible and explicitly declared at any level of representation. Our goal in constructing OSCAR was to specify and represent a system-level design without compromising its final realization. Furthermore, we wanted OSCAR to validate each design such that it could be synthesized later. To meet the first goal a prototype GUI was developed to aid in capturing the design and to generate a representation. Partial correctness is verified during this process in a way similar to compilation. During this phase, syntactical errors are found and displayed for the designer. Because the system specification is graphical, syntactic errors connote more meaning than simply failure to use the specification language properly. A set of rules is defined and embedded within the GUI. In Figure 7.1 this multi-level specification is shown. The high-level description is a visual language that captures a structural view of the system as composed of communicating components. Each component can be composed of interconnected components or its behavior described at the low-level by a HDL. We have developed an external block-diagram language and an internal representation that have a formal basis in a semantic definition. The language and internal representation are being used to verify some aspects of system correctness not covered by other formal models. 154 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 7 3 OSCAR - Visual Language OSCAR is a block-diagram visual language designed to capture and represent system-level digital designs in a graphical form (see Figure 7.2). Initially OSCAR was conceived as a GUI to provide a framework and to capture designs graphically. All file manipulations and the operating system interfaces are provided to help designers focus on the design itself. The resulting design is represented as a set of referenced design objects, tasks, ports and connectors, with system-levei and graphical related information. Although this tool is an architectural description it does not impose any architectural final realization. Software Architecture ideas have influenced the overall project, extending OSCAR to be a visual architecture description language, where not only is the system-level design captured in a structured form but also the information, data types used and communications between components that are of great importance are captured. OSCAR can be seen as an Architecture Description Language (ADL) with an underlying Model of Computation (MoC). This ADL is the glue that binds behavior and coordination together. It maps the sending and receiving of messages to ports. It also checks the consistency between the host language messages and the coordination language ports. Temporal relations can also be included and the overall task timing requirements relate input ports, behavior and output ports. Specific timing requirements can only be related to ports, since the behavior is either yet to be synthesized or there is a choice of available detailed behaviors to be decided during 155 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the micro-architecture synthesis design phase. Task behaviors can be mapped from blocks to algorithms or functions in a design library. A more abstract level of specification can also be used, such as CCS or Behavior Expressions. ADLs are typically concerned only with the description of the architecture or structure of a system, and thus offer a limited set of coordination primitives. Since they were designed for software systems, the coordination primitives usually reflect the underlying operating system, making them unsuitable for hardware systems. In OSCAR the effort to separate concerns led to the use of two different languages for design specification: a host language and a coordination language. The coordination language is defined to be a visual language to capture the system as a block-diagram and to formally define the interaction among blocks. The host language can be an HDL that has been augmented with a class of communication and synchronization primitives. Figure 7.1 depicts the coordination approach used in OSCAR. The picture at the top shows the visual coordination language specification of a system composed of two communicating processes. Tasks A and B are connected and two ports are used. The bottom picture depicts the glue connecting the primitive operation sendf), used in the host language code, to the output port. 156 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Connector A K Ports Task A behavioral de s c r i pt i on output port Figure 7.1: View of the coordination in OSCAR OSCAR is based on Garian's software architecture research [Garian and Shaw, 1994]. OSCAR declares types, instantiates elements, and describes interconnections among instantiated elements. This is referred to as a Type Style [Garian. 1995]. The Type declaration gives context independence to elements. The semantics for an element can only be extracted from its declaration. Using a simple mechanism of inheritance a new type can be specialized from a library maintaining some invariants. Instantiated elements separate declared types from their use, and allow the use of replicate elements of a given type, thus enriching the specification power. The 157 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. description of interconnections links the elements without the necessity of name matching, permitting the description to be constrained, and providing a high-level abstraction of the system. OSCAR has three object types: • Tasks, represented by circles and boxes. • Ports, represented by dots, and • Connectors, represented by lines. The language provides a basis for syntactical formalism where rules can be defined for the objects and their intra- and inter-relationship. For example, the system's interface ports are connected to the component's ports of the same kind. i.e. input-to-input ports, whereas between components, connections of the same kind are not allowed. Besides the graphical editor, a set of dialog boxes completes the textual information (see fields name on properties windows) and can set file pointers associated with the objects, as in field file in Figure 7.2. The visual nature of the language imposes a necessary GUI that can be used to provide abstractions in a very controlled way, hiding unneeded details from the user. This GUI is written using the language Tk [Welch. 1997] for the graphical support and C for the internal data-structure management. 158 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Files C oapofxnt Witt Filter Tail Mode: Head Mode: Input Port: Output Pert: stop Filter 03 15 backup/ I book/ [icons# lib-/ Figure 7.2: An OSCAR screen. 7J.1 Tasks Tasks are the placeholders where processes are described. Task behavior is described using a host language that captures the computations to be performed. This implies that only the computations are to be captured as the Task contents. In this sense, only the functional aspect of each task is captured, in contrast with the behavioral aspect of some hardware description languages that include or impose a 159 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. specific hardware. Micro-architectural and physical constraints and requirements are captured by the visual language as predicates on the system components. OSCAR uses as a host language a subset of VHDL [Chen, 1994] extended with communication primitives. Since designs can incorporate Commercial Off-The-Shelf (COTS) parts. OSCAR provides a way of specifying when a task is already implemented and thus some physical data is already available. Otherwise, the task has only a behavioral description. Since a COTS part realizes a given behavior, its own behavioral description is not mandatory and may be left unspecified. Physical components are represented graphically as boxes and behavioral components as circles4 . Tasks communicate through primitives. These primitives are part of a package written in VHDL to be used by OSCAR and SDS. A primitive sends, receives or synchronizes with another primitive providing high-level functionality at the VHDL level. This high-level aspect is implementation independent. Message passing provides an abstract form of communication and synchronization and can be implemented using either message-passing or semaphore mechanisms. Semaphores are used when a software only implementation is used. 4 An interesting approach is being now used in the Intellectual Property aspect of ASIC design for Embedded Systems and System-on-a-chip [VSI. 1998]. Components are called hard, firm or soft IP according to how much of their behavior and interface are fixed in silicon. 160 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. since most CPUs provide mechanism for direct implementation of semaphores. Message passing is used when the system is implemented using multiple hardware modules or a hardware/software codesign, preserving the Globally Asynchronous Locally Synchronous (GALS) paradigm. The approach used in this work is the message-passing paradigm. To support both reactive and communicating approaches to systems, two types of primitives are defined: signal/wait over binary messages and send/receive over general data-type messages. These primitives can be specialized as blocking or non- blocking. 732 Ports Ports characterize process boundaries and define their observable interface events, which are messages passed between primitives in the host language. These events are the only visible events for each process. Each port is of a specific kind, either input or output, and is linked to a communication/synchronization primitive in the host language. Ports also posse refined, in the sense of synthesis, functionality of that connection. This refinement provides a lower-level description of the communication when more details are important. The most important details captured are time and control/sequencing information. In our work, all of the timing information is attached to ports. For example, the latency a task takes to process a given set of data is defined as the time between the time the data is received by the 161 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. input port to the result present at the output port, and does not have any link to any internal element within the process description. Ports are represented in OSCAR as small colored dots located at task edges. The red color represents an input and a yellow dot denotes an output. 7 J J Connectors Connectors describe the dynamic aspect of communications between processes. A connector is an abstraction of a communication sub-system that includes a protocol and links two ports. A Connector description is not an interface or a protocol language but an abstraction where data types, messages, patterns and timing and temporal information are captured and represented. It may also involve a more complex communication sub-system composed of functional elements, such as network cards, modems, hubs, switches, and routers. 162 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 8 Conclusions and Future Work 8.1 Conclusions In this thesis, we have presented SDS, a comprehensive framework representing functionality, timing, logical structure and physical structure aspects of system designs. SDS is capable of representing multiple levels of design captured from conceptual to algorithmical levels, with support for a hierarchical representation. SDS was developed taking into account the separation of concerns among the diverse system aspects. More precisely, separation of concerns between: • communication and computation, using the Reference class in the information model to represent a coordination language for communication and textual behavioral languages as host languages, • behavior and structure, using orthogonal domains, PFD and 1'FD for the behavior and LSD for the logical structure, 163 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • function and time, also using orthogonal domains. PFD for the function and TFD for the time. SDS provides a clear definition for the logical structure domain. In SDS the logical structure domain represents the logical or topological view of the system and serves as the interface between the behavior and the actual design and components represented in the physical domain. SDS also provides a clear definition for the physical structure domain. In SDS the physical structure domains represents actual component of the system and captures designs or constraints specified in a bottom-up approach. Each domain has formal semantics defined and their interconnection is also formally defined. This provides for a common representation to support design validation and verification. SDS supports multiple HDLs to be used as host languages to describe computations. Coordination languages can also be represented in a common and coherent framework. SDS offer support for different design approaches, such as data intensive, stream-based and embedded designs. SDS is capable of representing the information used in the design, capturing the structural and temporal aspect of data structures. SDS was developed from a list of primitive constructs able to capture a broad range of systems. Each SDS control flow construct was validated after being translated to Petri nets. 164 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A visual language. OSCAR, was also developed as an interface tool to SDS. OSCAR defines a visual coordination language based on a message-passing paradigm. OSCAR can capture a subset of SDS constructs and shows that a single language is not capable to specify systems, but a comprehensive framework can be used as a common representation for multiple languages. 8.2 Future Work We plan to extend our translation from SDS to Petri nets to include timed Petri nets and ultimately stochastic timed Petri nets (TPN). There is a relationship between stochastic TPN (STPN) and Markov chains that we would like to explore, and also a relationship between CCS and Petri nets that invites further study. We plan to expand OSCAR into a framework incorporating VHDL as the host language translating the internal processes to SDS constructs (host language) and linking the communication functions to SDS reference class objects (coordination language) as described by the visual language. OSCAR still needs to be extended to capture the channels operational details, and a high-level protocol description language should be researched and developed. Another expansion to OSCAR is the definition of dialects of system designs. Each dialect is aimed at a particular kind of system, e.g. microprocessor-based, network-based, or real-time system. Each dialect defines a set of system building blocks that are translated into SDS constructs. A micro-architecture flavored block- 165 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. diagram specification tool can capture this mixed form specification, automatically discriminate low-level features and generate SDS representations. From the definition of the logical structure domain, it is now possible to develop clear architectural and micro-architectural system templates. These templates, with a more rigid structure, would merge with the system described in SDS. Finally, a specific architecture and micro-architecture language is needed to capture specific system building blocks and communication and synchronization mechanisms available in different architectures. 166 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. References [Afsarmanesh. H.. 1989] Afsarmanesh. H. “The EVE VLSI Management Environment/* PhD. USC. Los Angeles. CA. 1989. [Allen. J. F.. 1983] Allen. J. F. “Maintaining Knowledge about Temporal Intervals/’ Communications o f the ACM, 26( 11), 832-843. 1983. [Allen. R.. and Garlan. D.. 1994] Allen. R.. and Garlan. D. “Formal Connectors.” CMU-CS-94-l 15. Camegie-Mellon University. 1994. [Allen, R.. and Garlan. D.. 1996] Allen, R.. and Garlan. D. “The Wright Architectural Specification Language.” . CMU. 1996. [Bell. C. G.. and Newell. A., 1971] Bell. C. G.. and Newell. A. Computer Structures: Readings and Examples. Me Graw-Hill. New York. NY. 1971. [Bergstra. J. A., and Klop. J. W.. 1988] Bergstra. J. A., and Klop. J. W. “Process Theory Based on Bisimulation Semantics.” Linear Time. Branching Time and Partial Order in Logics and Models of Concurrency. J. W. d. B. a. W.-P. d. R. a. G. Rozenberg. ed.. 50-122. 1988. [Best. E.. and Thiagarajan. P. S.. 1987] Best. E., and Thiagarajan. P. S. “Some Classes of Live and Safe Petri Nets.” Concurrency and Nets - Advances in Petri Nets. K. Voss. H. J. Genrich, and G. Rozenberg, eds., Springer-Verlag. 71-94. 1987. [Boehm. B. W„ 1981] Boehm. B. W. Software Engineering Economics.. 1981. [Boussinot, F., and Simone. R. D., 1991] Boussinot, F.. and Simone, R. D. ‘ The ESTEREL Language.” Proc. of IEEE, 79(9), 1293-1304. 1991. [CFI, 1992] CFI. “Design Representation Programming Interface - Electrical Connectivity. Version 1.4.0-100194.” . 1992. [Chen, C.-T., 1991] Chen. C.-T. “VHDL2DDS: A VHDL Language to DDS Data Structure Translator.” CEng TR-91-21, U. of Southern California, Los Angeles. 1991. 167 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [Chen. C.-T.. 1994] Chen. C.-T. “System-level Design Techniques and Tools for Synthesis of Application-Specific Digital Systems,” Ph.D., U. Southern California. Los Angeles, CA. 1994. [Clarke. E., Wing. J., and al.. 19%] Clarke. E„ Wing. J.. and al. “Formal Methods: State of the Art and Future Directions.” ACM Computing Surveys. 28(4). 626- 643. 19%. [Cleaveland. R„ Parrow. J.. and Steffen, B.. 1993] Cleaveland. R.. Parrow. J., and Steffen. B. “The Concurrency Workbench: a semantics-based tool for the Verification of concurrent systems.” ACM Trans, on Programming Languages and Systems. 15(1). 36-72. 1993. [Cleaveland. R.. Smolka. S.. and al.. e.. 1996] Cleaveland. R.. Smolka. S.. and al., e. “Strategic Directions in Concurrency Research.” ACM Computing Surveys. 28(4), 607-625. 19%. [Conradi. P., 1994] Conradi. P. “Information Analysis in High-Level Synthesis.” TR-94-39. UCI, Irvine, CA. 1994. [Conradi. P.. 1995] Conradi. P. “Information Model of a Compound Graph Representation for System and Architecture Level Designs.” Proc. of the European Design Automation Conf.95, 3-8. 1995. [Cortadella. J., Kondratyev, A., Lavagno, L., Massot. M., Moral. S.. Passerone. C., Watanabe. Y.. and Sangiovanni-Vincetelli, A.. 2000] Cortadella. J., Kondratyev. A.. Lavagno. L., Massot. M.. Moral. S., Passerone, C., Watanabe, Y.. and Sangiovanni-Vincetelli. A. “Task Generation and Compile-Time Scheduling for Mixed Data-Control Embedded Software.” DAC. 489-494. 2000. [Dasdan, A.. Ramanathan, D.. and Gupta. R. K., 1998] Dasdan, A., Ramanathan. D., and Gupta. R. K. “A Timing-Driven Design and Validation Methodology for Embedded Real-Time Systems.” ACM TODAES, 3(4), 533-553. 1998. [DeSouza-Batista. J. C.. and Parker. A. C., 1994] DeSouza-Batista, J. C., and Parker. A. C. “Optimal Synthesis of Application Specific Heterogeneous Pipelined Multiprocessors.” International Conference on Application-Specific Array Processors, 99-110. 1994. [Drusinsky. D., and Harel. D.. 1987] Drusinsky, D., and Harel, D. “Using Statecharts for Hardware Description.” Int'l Conf. on Computer Aided Design, 162-165. 1987. 168 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [Ebert J.. 1994] Ebert J. “Design Representation." Enciclopedia of Software Engineering, J. J. Marcianik. ed.. Wiley-lnterscience. 382-394. 1994. [Ecker. W.. Hofmeister. M.. and Maerz-Roessel. S., 1996] Ecker, W.. Hofmeister. M., and Maerz-Roessel, S. “The Design Cube - A Model for VHDL Designflow Representation and its Application." High-Level System Modeling: Specification and Design Methodologies, R. Waxman. J.-M. Berge. O. Levia. and J. Rouillard. eds.. Kluwer Academic Press, 83-128. 1996. [Edwards. S.. Lavagno. L.. Lee, E. A., and Sangiovanni-Vicentelli. A.. 1997] Edwards. S.. Lavagno. L , Lee. E. A., and Sangiovanni-Vicentelli. A. "Design of Embedded Systems: Formal Models. Validation, and Synthesis.” Proceedings of IEEE. 85(3). 366-390. 1997. [Edwards, S. A.. 2000] Edwards. S. A. Languages for Digital Embedded Systems. Kluwer Academic Press. Boston. 2000. [Eles, P.. Kuchcinski. K., and Peng, Z.. 1998] Eles. P.. Kuchcinski. K.. and Peng, Z. System Synthesis with VHDL. Kluwer Academic Press. 1998. [Ernst. R.. and Jerraya. A. A.. 2000] Emst. R.. and Jerraya. A. A. “Embedded System Design with Multiple Languages.” ASPDAC. Yodkohama. Japan. 2000. [Gajski. D.. Narayan. S.. and Vahid. F.. 1992] Gajski. D.. Narayan, S., and Vahid. F. "A System-level Specification & Design Methodology.” TR #92-102. U.C. Irvine. 1992. [Gajski. D.. Vahid. F.. Narayan, S., and Gong. J.. 1994] Gajski. D.. Vahid. F.. Narayan, S.. and Gong, J. Specification and Design of Embedded Systems. PTR Prentice Hall. 1994. [Garlan. D.. 1995] Garlan. D. “What is Style?” 1st. Intl. Conference on Architectures for Software Engineering, Seattle, WA, 96-100. 1995. [Garlan. D.. Allen, R., and Ockerbloom, J., 1994] Garlan, D., Allen, R., and Ockerbloom. J. “Architectural Mismatch: Why Reuse is so Hard.” IEEE Software. 12(6), 17-26. 1994. [Garlan, D., and Shaw, M., 1994] Garlan, D.. and Shaw. M. “An Introduction to Software Architecture.” CMU-CS-94-166, Camegie-Mellon University. 1994. [Gelemter, D.. and Carriero, N., 1992] Gelemter, D.. and Carriero, N. “Coordination Languages and their Significance.” Comm, of the ACM. 35(2), 96-107. 1992. 169 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [Giumale. C.. and Kahn. H.. 1995] Giumale. C.. and Kahn, H. “Information Models of VHDL.” Proc. o f the 32nd Design Automation Conf., 678-683. 1995. [Gosling. J.. BJoy. and Steele. G., 1996] Gosling. J.. BJoy. and Steele. G. The Java Language Specification. Addison-Wesley. 19%. [Granacki. J.. Jr.. 1987] Granacki. J.. Jr. “Understanding Digital Systems Specifications Written in Natural Language.” Ph.D., USC. 1987. [Gupta. A.. 1992] Gupta. A. “Formal Hardware Verification Methods: A Survey.” Formal Methods in System Design, 1(1). 151-238. 1992. [Gupta. P.. 1994] Gupta. P. “High-Level Synthesis of Memory-Intensive Application-Specific Systems.” Ph.D.. U. Southern California, CENG TR 94- 20. 1994. [Gupta. P.. Chen. C.-T.. DeSouza-Batista. J. C.. and Parker. A. C.. 1994] Gupta. P.. Chen. C.-T., DeSouza-Batista, J. C.. and Parker. A. C. “Experience with Image Compression Chip Design Using Unified System Construction Tools.” Proc. of the 31st. Design Automation Conf, 250-256. 1994. [Harel. D.. 1987] Harel. D. “Statecharts: A Visual Formalism for Complex Systems." Science o f computer programming, 8. 231-271. 1987. [Harel. D.. 2001] Harel, D. “From Play-In Scenarios to Code: An Achievable Dream." IEEE Computer, 34( 1). 53-60. 2001. [Hayati. S.. 1990] Hayati. S. “The Synthesis of Control-Dominated Applications Specific Integrated Circuits Using Global Based Design Management.” Ph.D.. USC. 1990. [Helaihel. R.. and Olukotun. K.. 1997] Heloihel. R., and Olukotun, K. “Java as a Specification Language for Hardware-Software Systems.” ICCAD 97, 690- 697. 1997. [Heo. D.-H.. Parker. A., and Ravikumar, C. P.. 1997] Heo. D.-H., Parker, A., and Ravikumar. C. P. “Rapid Synthesis of Multi-chip Systems.” 10th. Intl. Conference on VLSI Design. 1997. [Hilfinger, P.. and Rabaey, J.. 1992] Hilfinger, P., and Rabaey. J. “DSP Specification Using the Silage Language.” {Anatomy of a Silicon Compiler], R. W. Brodersen. ed., 199-220. 1992. 170 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [Hilfinger. P. N.. 1985] Hilfinger, P. N. “A High-Level Language and Silicon Compiler for Digital Signal Processing.” IEEE 1985 Custom Integrated Circuits Conference. 213-216. 1985. [Hoare. C. A. R.. 1978] Hoare, C. A. R. “ ‘Communicating Sequential Processes.” Communications of the ACM, 21(8). 666-677. 1978. [IEEE. 1987] IEEE. IEEE Standard VHDL Language Reference Manual, IEEE. 1987. [Inverardi. P.. and Priami. C.. 1996] Inverardi. P.. and Priami. C. “Automatic Verification Of Distributed System: The Process Algebra Approach.” Formal Methods In System Design, 8(1), 7-38. 1996. [ISO. 1994] ISO. “EXPRESS Language Reference Manual.” , ISO. 1994. [ITU-T. 1993] ITU-T. “Recommendation Z.IOO. CCITT Specification and Description Language SDL.” Z 100, ITU-T. 1993. [Jantsch. A.. Kumar. S.. and Hemani. A.. 1999] Jantsch. A., Kumar. S., and Hemani, A. “The Rugby Model: A Conceptual Frame for the Study of Modelling, Analysis and Synthesis Concepts of Electronic Systems.” DATE, Munich, Germany. 72-78. 1999. [Jerraya. A. A., Romdhani. M., Marrec, P. L., Hessel, F.. Coste. P.. Valderrama. C., Marchioro. G. F.. Daveau, J. M., and Zergainoh. N.-E., 1999] Jerraya. A. A.. Romdhani. M.. Marrec. P. L.. Hessel. F., Coste, P., Valderrama. C.. Marchioro, G. F.. Daveau, J. M., and Zergainoh, N.-E. “Multilanguage Specification for System Design.” System-Level Synthesis, A. A. Jerraya and J. Mermet. eds.. Kluwer Academic Press, 103-136. 1999. [Jong. G. d., and Lin. B.. 1994] Jong, G. d.. and Lin, B. “A Communicating Petri Net Model for the Design of Concurrent Asynchronous Modules.” 31st. DAC, 49- 55.1994. [Kahn. G.. 1974] Kahn. G. “The Semantics of a Simple Language for Parallel Programming.” Proc. of IFIP Congress 74,471-475. 1974. [Kalavade, A., 1995] Kalavade. A. “System-level Codesign of Mixed Hardware- Software Systems,” PHD Thesis, University of California, California, USA. 1995. [Keutzer, K., Malik, S., Newton. A. R„ Rabaey. J. M., and Sangiovanni-Vincentelli. A.. 2000] Keutzer. K., Malik. S.. Newton, A. R., Rabaey, J. M., and 171 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Sangiovanni-Vincentelli. A. “System-Level Design: Orthogonalization of Concerns and Platform-Based Designs.” IEEE Trans, on CAD, 19(12). 1523- 1543. 2000. [Knapp. D.. and Parker. A.. 1985] Knapp, D.. and Parker, A. “A Data Structure for VLSI Synthesis and Verification.” Ph.D.. U. Southern California. Los Angeles. 1985. [Kramer. J.. Magee, J.. Ng. K.. and Sloman. M.. 1993] Kramer. J.. Magee, J.. Ng, K., and Sloman, M. “The System Architect’ s Assistant for Design and Construction of Distributed Systems.” 4th Workshop on Future Trends of Dist. Comp. Sys.. Lisbon. 1993. [Ku. D.. and DeMicheli. G.. 1990] Ku. D.. and DeMicheli. G. “HardwareC - A Language for Hardware Design (version 2.0).” CSL-TR-90-419, Stanford University. 1990. [Lau. R.. and Kahn. H., 1993] Lau. R.. and Kahn. H. “Information Modelling of EDIF.” Proc. of the 30th Design Automation Conf, 278-283. 1993. [Lavagno. L.. Sangiovanni-Vicentelli, A., and Sentovich, E. M., 2000] Lavagno. L.. Sangiovanni-Vicentelli. A., and Sentovich. E. M. “Models of Computation for System Design.” Architecture Design and Validation Models. E. Boerger, ed.. Springer. Berlim. 243-296. 2000. [Lee. E. A., and Sangiovanni-Vicentelli, A.. 1998] Lee, E. A., and Sangiovanni- Vicentelli. A. “A Framework for Comparing Models of Computation.” IEEE Trans, on CAD, 17(12). 1217-1229. 1998. [Lindholm. T.. and Yellin. F.. 1996] Lindholm. T.. and Yellin, F. The Java Virtual Machine Specification, Addison-Wesley. 1996. [Loucopoulos. P.. 1992] Loucopoulos, P. “Conceptual Modeling.” Conceptual Modeling. Databases and CASE. P. L. a. R. Zicari. ed., 1-26. 1992. [Luckham, D.. Kenney. J.. Augustin, L., Vera, J., Bryan, D., and Mann, W„ 1995] Luckham. D., Kenney, J., Augustin. L., Vera, J., Bryan. D., and Mann, W. “Specification and Analysis of System Architecture Using Rapide.” IEEE Transactions on Software Engineering, 21(4), 336-355. 1995. [Magee. J., and Kramer, J.. 1995] Magee, J., and Kramer, J. “Modelling Distributed Software Architecture.” 1st. International Woorkshop on Architectures for Software Systems. Seattle, WA, 206-222. 1995. 172 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [McFarland. M. C.. and Kowalski. T. J., 1990] McFarland. M. C.. and Kowalski. T. J. "Incorporating Bottom-Up Design into Hardware Synthesis.” IEEE Trans, on CAD. 9(9). 938-950. 1990. [Milner. R.. 1980] Milner. R. A Calculus o f Communicating Systems. Springer- Verlag. 1980. [Milner. R.. Parrow. J.. and Walker. D.. 1992] Milner, R., Parrow, J., and Walker, D. "A Calculus of Mobile Processes. Parts I and II.” Journal of Information and Computation. 100. 1-40 and 41-77. 1992. [Moriconi. E.. Qian. X.. and Riemenschneider. R.. 1995] Moriconi. E.. Qian. X.. and Riemenschneider. R. "Correct Architecture Refinement.” IEEE Transactions on Software Engineering, 21(3). 356-372. 1995. [Mueller. J.. and Kraemer. H.. 1993] Mueller. J.. and Kraemer. H. "Analysis of Multi-Process VHDL Specifications with a Petri Net Model.” ICCAD. 474- 479. 1993. [Murata. T.. 1989] Murata. T. "Petri Nets: Properties. Analysis and Applications.” Proceedings o f IEEE. 77(4), 541-580. 1989. [Mylopoulos, J.. 1992] Mylopoulos. J. "Conceptual Modeling in TELOS." Conceptual Modeling. Databases and CASE, P. L. a. R. Zicari. ed.. 49-68. 1992. [Olcoz. S.. and Colon, J. M.. 1993] Olcoz, S., and Colon. J. M. "A Petri Net Approach for the Analysis of VHDL Descriptions.” CHARME, Arles, France. 15-26. 1993. [Parker. A. C.. Thomas, D. E., Crocker, S.. and Cattel, R. G. G., 1979] Parker, A. C.. Thomas. D. E.. Crocker, S., and Cattel, R. G. G. “ISPS: A Retrospective View." 4th Intl. Symposium on CHDL, Palo Alto, 21-27. 1979. [Parker, A. C., and Wallace, J. J.. 1981] Parker. A. C., and Wallace, J. J. "SLIDE: An VO Hardware Description Language.” IEEE Transactions on Computers, 30(6). 423-439. 1981. [Pastor. E.. Cortadella. J., and Roig, O., 2001] Pastor, E., Cortadella, J., and Roig, O. "Symbolic Analysis of Bounded Petri Nets.” IEEE Trans, on Computers, 50(5), 432-448. 2001. [Peterson. J. L.. 1977] Peterson, J. L. "Petri Nets.” ACM Computing Survevs, 9(3), 223-252. 1977. 173 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [Prakash. S.. 1993] Prakash. S. “Synthesis of Application-Specific Multiprocessor Systems.” PhD. U.S.C.. Los Angeles. CA. 1993. [Prieto-Diaz. R.. and Neighbors. J. M., 1986] Prieto-Diaz. R.. and Neighbors. J. M. “Module Interconnection Language.” The Journal of Svstems and Software. 6(4). 307-334. 1986. [Rolland. C.. and Cauve. C.. 1992] Rolland. C.. and Cauve, C. “Trends and Perspectives in Conceptual Modeling.” Conceptual Modeling, Databases and CASE. P. L. a. R. Zicari. ed., 27-48. 1992. [Rosenstiel. W.. and Weiler. C.. 1997] Rosenstiel. W.. and Weiler. C. “Using Java in Embedded Systems Design.” SASIM197.69-74. 1997. [Sander. I., and Jantsch. A., 1999] Sander. I., and Jantsch. A. “System Synthesis Utilizing a Layered Functional Model.” CODES '99. Rome. Italy, 136-140. 1999. [Schettler. O.. and Bredenfeld. A.. 1992] Schettler, O.. and Bredenfeld, A. “Handling Schema Information in the DASSY Data Model.” 3rd. IFIP Workshop on Electronic Design Automation Frameworks. Bad Lippspringe. Germany. 41- 50. 1992. [Sgroi. M.. Lavagno. L.. Watanabe, Y.. and Sangiovanni-Vecentelli. A., 1999] Sgroi. M.. Lavagno. L.. Watanabe, Y.. and Sangiovanni-Vecentelli. A. “Synthesis of Embedded Software Using Free-Choice Petri Nets.” DAC. New Orleans. LA USA. 805-810. 1999. [Shaw. M.. and Clements, P.. 1996] Shaw. M., and Clements, P. "A Field Guide to Boxology: Preliminary Classification od Architectural Styles for Software Systems.". SEI-CMU. 1996. [Shaw. M., DeLine. R., Klein. D., Ross. T., Young, D., and Zelesnik, G.. 1995] Shaw, M., DeLine. R.. Klein. D.. Ross. T., Young, D., and Zelesnik. G. "Abstractions For Software Architecture And Tools To Support Them.” IEEE Transactions on Software Engineering, 21(4), 314-335. 1995. [Shaw. M.. and Garlan. D., 1994] Shaw, M., and Garlan, D. “Characteristics Of Higher-Level Languages For Software Architecture.” , SEI-CMU. 1994. [Starke. P. H.. and Roch, S.. 2000] Starke. P. H., and Roch. S. “INA et al.” Tool Demonstrations 21st International Conference on application and Theory of Petri Nets, Aarhus. Denmark. 51-56. 2000. 174 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [Thomas. D. E.. and Moorby, P.. 1991] Thomas. D. E.. and Moorby. P. The VERILOG Hardware Description Language. Kluwer Academic Press. 1991. [Vahid. F.. Narayan. S.. and Gajski. D.. 1995] Vahid. F., Narayan. S.. and Gajski. D. "SpecCharts: A Language for System-level Synthesis.” IEEE Trans, on CAD of Integrated Circuits and Systems, 14(6), 694-706. 1995. [Vercauteren, S.. Verkest. D.. Jong. G. d.. and Lin. B.. 1997] Vercauteren. S.. Verkest. D.. Jong. G. d.. and Lin, B. “Derivation of Formal Representations from Process-based Specification and Implementation Models.” ISSS. Antwerp, Belgium. 16-23. 1997. [Vercauteren, S.. Verkest. D.. Jong. G. d.. and Lin. B., 1998] Vercauteren, S.. Verkest. D.. Jong. G. d.. and Lin. B. “Efficient Verification using Generalized Partial Order Analysis.” DATE. Paris. France. 782-789. 1998. [Vermeulen. F.. Catthoor. F.. Verkest, D.. and Man, H. d., 2000] Vermeulen, F.. Catthoor, F., Verkest. D.. and Man, H. d. “Formalized Three-Layer System- Level Model and Reuse Methodology for Embedded Data-Dominated Applications.” IEEE Trans, on VLSI Systems, 8(2). 201-216. 2000. [VSI. 1997] VSI. “Architecture Document - ver. 1.0.” VSI - AD vl.0. VSI Alliance. 1997. [VSI. 1998] VSI. "VSI System Level Design Model Taxonomy.” VSI-SLD vl.0. VSI Alliance. Inc.. Los Gatos. CA. 1998. [Welch. B. B.. 1997] Welch. B. B. Practical Programming in Tel and Tk. Prentice Hall PTR. Upper Saddle River. NJ. 1997. [Wilkes. W.. and Scholz, G.. 1992] Wilkes, W.. and Scholz. G. “Different Levels of Information Models for Use in Frameworks.” 3rd. IFIP Workshop on Electronic Design Automation Framework’ :. Bad Lippspringe, Germany, 21- 39. 1992. [Wing. J., 1990] Wing, J. “A Specifier’ s Introduction to to Formal Methods.” IEEE Computer, 23(9), 8-24. 1990. [Wuytack, S.. Julio L. da Silva, J.. Catthoor, F., Jong, G. d.. and Ykman-Couvreur, C., 1999] Wuytack. S., Julio L. da Silva, J.. Catthoor, F., Jong, G. d., and Ykman-Couvreur. C. “Memory Management for Embedded Network Applications.” IEEE Trans, on CAD, 18(5), 533-544. 1999. 175 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [Yoeli. M.. 1990] Yoeli. M. '‘Formal Verification of Hardware Design.” . 159-165. 1990. 176 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

A low-complexity construction of algebraic geometric codes better than the Gilbert -Varshamov bound

PDF

Fine-grained control of security services

PDF

Induced hierarchical verification of asynchronous circuits using a partial order technique

PDF

Dynamic logic synthesis for reconfigurable hardware

PDF

I -structure software caches: Exploiting global data locality in non-blocking multithreaded architectures

PDF

A methodology for the hardware/software co-design of embedded systems

PDF

Group key agreement: Theory and practice

PDF

Algorithms for the discrete logarithm problem and algebraic aspects of quantum computation

PDF

Information hiding in digital images: Watermarking and steganography

PDF

Optimal Motion Planning In The Presence Of Velocity Constraints

PDF

Consolidated logic and layout synthesis for interconnect -centric VLSI design

PDF

A black box approach to problems in computational algebra

PDF

Energy efficient hardware-software co-synthesis using reconfigurable hardware

PDF

A unified mapping framework for heterogeneous computing systems and computational grids

PDF

Computer-aided lesion detection in positron emission tomography: A signal subspace fitting approach

PDF

Energy and time efficient designs for digital signal processing kernels on FPGAs

PDF

Software quality analysis: a value-based approach

PDF

Algebraic sets decomposition, polynomial congruences, and extended Hilbert irreducibility

PDF

Hierarchical design space exploration for efficient application design using heterogeneous embedded system

PDF

A CMOS frequency channelized receiver for serial-links

Asset Metadata

Creator Silva, Diogenes Cecilio da, Jr. (author)

Core Title A comprehensive framework for the specification of hardware /software systems

Degree Doctor of Philosophy

Degree Program Computer Engineering

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag engineering, electronics and electrical,OAI-PMH Harvest

Language English

Contributor Digitized by ProQuest (provenance)

Advisor Parker, Alice (committee chair), Beerel, Peter (committee member), Huang, Ming-Deh (committee member)

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c16-204857

Unique identifier UC11334706

Identifier 3065848.pdf (filename),usctheses-c16-204857 (legacy record id)

Legacy Identifier 3065848.pdf

Dmrecord 204857

Document Type Dissertation

Rights Silva, Diogenes Cecilio da, Jr.

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the au...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus, Los Angeles, California 90089, USA