May 19, 2006 - In this report we aim to provide an exhaustive list of requirements for components in an ...... fault parameter values using the standard SpecC compiler. ('scc', Section A.1) ..... Furthermore, the SpecC code of behavioral PE models can describe ...... port âGBusâ connects to a Toshiba GBus as a master. Note.
Center for Embedded Computer Systems University of California, Irvine
System-On-Chip Component Models Andreas Gerstlauer Gunar Schirner Dongwan Shin Junyu Peng Rainer D¨omer Daniel D. Gajski
Technical Report CECS-06-10 (revision of CECS-TR-03-26) May 19, 2006 Center for Embedded Computer Systems University of California, Irvine Irvine, CA 92697-2625, USA (949) 824-8919 http://www.cecs.uci.edu
System-On-Chip Component Models Andreas Gerstlauer Gunar Schirner Dongwan Shin Junyu Peng Rainer D¨omer Daniel D. Gajski
Technical Report CECS-06-10 (revision of CECS-TR-03-26) May 19, 2006 Center for Embedded Computer Systems University of California, Irvine Irvine, CA 92697-2625, USA (949) 824-8919 {gerstl,hschirne,dongwans,pengj,doemer,gajski}@cecs.uci.edu http://www.cecs.uci.edu
Abstract This report defines and describes a format for models of system components required for system-on-chip (SoC) design. In an SoC design process, starting from an initial system specification, an implementation of the system is created through a series of interactive and automated steps by gradually synthesizing and assembling a system design using components taken out of a set of databases. Generally, databases are needed for processing elements (PEs), communication elements (CEs), bus and other communication protocols, and RTL units. In this report we aim to provide an exhaustive list of requirements for components in an automated SoC design flow using the example of a concrete database format. Following a description of the basic database format in general, this report defines the format of each of the three databases in detail. Using information in this report, specific database formats for diverse SoC design flows can be developed. Specifically, the database format in this report is used successfully in our SoC Design Environment, SCE.
Contents 1
Introduction
1
2
General Database Format 2.1 Database Organization . . . . . . 2.2 Component Format . . . . . . . . 2.2.1 Platform Components . . 2.2.2 Attributes . . . . . . . . . 2.2.3 Parameters . . . . . . . . 2.2.4 Weight Tables . . . . . . . 2.2.5 Item Types for Metric Set 2.2.6 Data Types for Metric Set 2.2.7 Default Values . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
1 1 2 2 2 3 5 6 6 8
3
Processing Elements 3.1 PE Behaviors . . . . . . . . . . . . 3.1.1 General Format . . . . . . . 3.1.2 Attributes . . . . . . . . . . 3.1.3 Weight Tables . . . . . . . . 3.1.4 Memory Tables . . . . . . . 3.1.5 Computation Functionality . 3.1.6 Memory . . . . . . . . . . . 3.2 PE Operating System Models . . . . 3.2.1 OS Shell . . . . . . . . . . 3.2.2 Interrupt Task Templates . . 3.3 PE Network Models . . . . . . . . . 3.3.1 Network Model Behavior . . 3.3.2 Network Adapters . . . . . 3.4 Bus-Functional PE Models . . . . . 3.4.1 Bus-Functional Layer . . . . 3.4.2 IP Adapters . . . . . . . . . 3.4.3 Hardware Abstraction Layer 3.4.4 Interrupt Handling . . . . . 3.4.5 Arbitration . . . . . . . . . 3.5 Cycle-Accurate PE Models . . . . . 3.5.1 Instruction Set Models . . . 3.5.2 IP Models . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
8 8 8 10 11 12 12 14 15 15 16 17 18 19 20 21 23 25 27 29 36 38 38
4
Communication Elements 4.1 CE Behaviors . . . . . . . 4.1.1 General Format . . 4.1.2 Attributes . . . . . 4.1.3 Bridges . . . . . . 4.2 Bus-Functional CE Models
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
38 40 40 42 42 42
5
Bus Protocols 5.1 Bus Channels . . . . . 5.1.1 General Format 5.1.2 Attributes . . . 5.1.3 Weight Tables . 5.2 Protocol Layer . . . . 5.2.1 General Format
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
45 45 48 53 53 54 54
. . . . . .
. . . . . .
i
5.3
5.4
6
5.2.2 Data Transfer Protocol . 5.2.3 Synchronization Protocol 5.2.4 Arbitration Protocol . . Transaction-Level Models . . . 5.3.1 General Format . . . . . 5.3.2 Data Transfer . . . . . . 5.3.3 Synchronization . . . . 5.3.4 Arbitration . . . . . . . Media Access Layer . . . . . . 5.4.1 General Format . . . . . 5.4.2 Data Links . . . . . . . 5.4.3 Memory Access . . . .
RTL Units 6.1 RTL Behaviors . . . . . 6.1.1 General Format . 6.1.2 Attributes . . . . 6.1.3 Operations . . . 6.2 Examples . . . . . . . . 6.2.1 Functional units . 6.2.2 Storage units . . 6.2.3 Busses . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
54 57 58 58 58 61 61 61 64 64 66 68
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
68 73 73 74 74 77 77 77 77
References
77
A Manual Pages A.1 scc - SpecC Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 sir gen - SpecC Design Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90 91 96
ii
List of Figures 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 22 19 20 21 23 24 25 26 27 28 29 30 31 32 33 34 35 36
Format of platform component annotations. . . . . . . . . . . . . . . . . . Format of component attribute annotations. . . . . . . . . . . . . . . . . . Format of SIR PARAMETERS annotation. . . . . . . . . . . . . . . . . . Format of item header annotations. . . . . . . . . . . . . . . . . . . . . . . Format of data header annotations. . . . . . . . . . . . . . . . . . . . . . . Format of weight annotations. . . . . . . . . . . . . . . . . . . . . . . . . Format of PE behaviors. . . . . . . . . . . . . . . . . . . . . . . . . . . . Format of PE behavior PE BF BUS annotations. . . . . . . . . . . . . . . Example of IP PE behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . Format of PE behavior memory interfaces. . . . . . . . . . . . . . . . . . . Format of PE OS models. . . . . . . . . . . . . . . . . . . . . . . . . . . . Format of OS interrupt task templates. . . . . . . . . . . . . . . . . . . . . Format of PE network models. . . . . . . . . . . . . . . . . . . . . . . . . Format of PE IP ADAPTER annotations. . . . . . . . . . . . . . . . . . . Example of IP network model. . . . . . . . . . . . . . . . . . . . . . . . . Format of network model adapters. . . . . . . . . . . . . . . . . . . . . . . Format of bus-functional PE models. . . . . . . . . . . . . . . . . . . . . . Format of bus-functional PE BF BUS annotations. . . . . . . . . . . . . . Example of bus-functional CPU model. . . . . . . . . . . . . . . . . . . . Example of bus-functional IP model. . . . . . . . . . . . . . . . . . . . . . Format of bus-functional IP adapters. . . . . . . . . . . . . . . . . . . . . . Format of hardware abstraction layer (HAL) for bus-functional PE models. Format of CE behaviors. . . . . . . . . . . . . . . . . . . . . . . . . . . . Format of CE behavior CE BF BUS annotations. . . . . . . . . . . . . . . Format of CE behavior bridge interfaces. . . . . . . . . . . . . . . . . . . . Format of bus-functional CE models. . . . . . . . . . . . . . . . . . . . . . Format of bus-functional CE BF BUS annotations. . . . . . . . . . . . . . Generic example of bus model. . . . . . . . . . . . . . . . . . . . . . . . . Format of bus channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Format of protocol layer models. . . . . . . . . . . . . . . . . . . . . . . . Format of TLM channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . Master identity through connectivity. . . . . . . . . . . . . . . . . . . . . . Format of media access layer models. . . . . . . . . . . . . . . . . . . . . Format of media access layer interfaces. . . . . . . . . . . . . . . . . . . . Format of RTL unit behavior models. . . . . . . . . . . . . . . . . . . . . Format of RT OPERATIONS annotation. . . . . . . . . . . . . . . . . . .
iii
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 3 4 5 5 5 8 9 13 14 16 17 18 18 20 20 22 22 26 35 35 35 40 41 42 44 44 47 48 55 61 62 64 66 73 76
List of Tables 1 2 3 4 5 6 7 8 9 10 11 12 15 16 13 14 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 34 33 35 36 37 39 38
Example of a profiling table. . . . . . . . . . . . Example of the operation weight table of a DSP. . Example of a weighted result. . . . . . . . . . . Example of a traffic weight table. . . . . . . . . . Example of a memory weight table. . . . . . . . Item types for operation metric set (operations). . Item types for traffic metric set . . . . . . . . . . Data types for metric sets. . . . . . . . . . . . . An alternative operation weight table of the DSP. General annotations for behavioral PE models. . . PE behavior attribute annotations. . . . . . . . . PE behavior weight annotations. . . . . . . . . . Item types for memory tables. . . . . . . . . . . Data types for memory tables. . . . . . . . . . . Header annotations for operation metrics. . . . . Header annotations for traffic metrics. . . . . . . Header annotations for memory tables. . . . . . . PE behavior memory table annotations. . . . . . Memory interface annotations. . . . . . . . . . . PE OS model annotations. . . . . . . . . . . . . PE OS interrupt task annotations. . . . . . . . . . PE network model annotations. . . . . . . . . . . Bus-functional PE model annotations. . . . . . . Bus-functional IP adapter annotations. . . . . . . General annotations for behavioral CE models. . CE behavior attribute annotations. . . . . . . . . Bridge interface annotations. . . . . . . . . . . . Bus-functional CE model annotations. . . . . . . General annotations for bus protocol channels. . . Bus channel attribute annotations. . . . . . . . . Bus channel weight annotations. . . . . . . . . . Header annotations for traffic metrics. . . . . . . Classification of RTL units. . . . . . . . . . . . . General annotations for RTL unit behavior. . . . RTL unit data types. . . . . . . . . . . . . . . . . RTL behavior attribute annotations. . . . . . . . RTL unit port attribute annotations. . . . . . . . . operators in RT OPERATIONS. . . . . . . . . . RTL unit port types. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 5 6 6 6 7 7 7 8 9 11 12 12 12 13 13 14 14 15 16 18 19 23 25 41 43 43 45 49 54 54 55 73 74 74 75 75 75 77
List of Listings 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 18 17 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
Database organization example. . . . . . . . . . . . . . . . . . . Component attributes example. . . . . . . . . . . . . . . . . . . . Parameterized component example. . . . . . . . . . . . . . . . . Component weight table example. . . . . . . . . . . . . . . . . . PE behavior example. . . . . . . . . . . . . . . . . . . . . . . . . Example of PE behavior for simple IP with given functionality. . . Example of PE behavior for system memory. . . . . . . . . . . . Example of PE OS model. . . . . . . . . . . . . . . . . . . . . . Example of PE OS interrupt task template. . . . . . . . . . . . . . Example of PE network model for simple IP. . . . . . . . . . . . . Example of IP network adapter. . . . . . . . . . . . . . . . . . . . Example of bus-functional PE model for simple IP. . . . . . . . . Example of bus-functional IP adapter model. . . . . . . . . . . . Example of bus-functional model for programmable PE. . . . . . Example of bus-functional model for PE with interrupt controller. Example of interrupt controller model. . . . . . . . . . . . . . . . Example of arbiter model. . . . . . . . . . . . . . . . . . . . . . Example of bus-functional model for CPU with arbiter. . . . . . . Example of instruction set simulation (ISS) PE model. . . . . . . CE behavior example. . . . . . . . . . . . . . . . . . . . . . . . . Example of CE behavior for a bridge. . . . . . . . . . . . . . . . Example of bus-functional CE model. . . . . . . . . . . . . . . . Bus channel example. . . . . . . . . . . . . . . . . . . . . . . . . Example of a data transfer protocol interface. . . . . . . . . . . . Example of data transfer protocol model. . . . . . . . . . . . . . . Example of synchronization protocol model. . . . . . . . . . . . . Example of bus channel with support for multiple masters. . . . . Example of arbiter bus protocol. . . . . . . . . . . . . . . . . . . Bus channel with TLM. . . . . . . . . . . . . . . . . . . . . . . . Example of data transfer protocol TLM. . . . . . . . . . . . . . . Adapter channel for defining master identity. . . . . . . . . . . . . Interface for the TLM arbitration channel. . . . . . . . . . . . . . Implementation of the TLM arbitration. . . . . . . . . . . . . . . Example of media access layer interface. . . . . . . . . . . . . . . Example of master media access layer data link model. . . . . . . Example of slave media access layer data link model. . . . . . . . Example of master media access layer memory access model. . . . Example of slave media access layer memory access model. . . . Example of RT OPERATIONS annotation. . . . . . . . . . . . . Example of RTL unit. . . . . . . . . . . . . . . . . . . . . . . . . Example of 3-stage pipelined multiplier. . . . . . . . . . . . . . . Example of register. . . . . . . . . . . . . . . . . . . . . . . . . . Example of register file. . . . . . . . . . . . . . . . . . . . . . . . Example of bus. . . . . . . . . . . . . . . . . . . . . . . . . . . .
v
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 4 4 6 11 14 15 16 17 19 21 24 26 27 29 33 36 37 39 43 43 46 52 55 56 57 59 60 60 62 63 64 65 67 69 70 71 72 78 79 81 84 85 88
System-On-Chip Component Models A. Gerstlauer, G. Schirner, D. Shin, J. Peng, R. Do¨ mer, Daniel D. Gajski Center for Embedded Computer Systems University of California, Irvine Irvine, CA 92697-2625, USA {gerstl,hschirne,dongwans,pengj,doemer,gajski}@cecs.uci.edu http://www.cecs.uci.edu
Abstract
computational parts onto PEs taken out of the PE database. The communication element (CE) database contains brigdes, transducers, arbiters and interrupt controllers that are used to assemble the system communication network during network and communication synthesis. The bus protocol database contains timing-accurate descriptions of protocols of system busses and other communication structures used to implement communication between the different PEs in the system. Finally, the RTL unit database contains register-transfer units like register files, ALUs and other functional units, memories, local busses, etc. RTL units taken out of the RTL database are used to synthesize computation mapped to custom hardware PEs down to a cycle-accurate RTL description. This report describes and defines a format of databases for use in automated SoC design flows, thereby outlining requirements for modeling components for system design in general. First, Chapter 2 defines the general format of the SoC databases. Then, in Chapter 3, Chapter 4, Chapter 5, and Chapter 6 the specifics of the PE, CE, bus, and RTL databases are described in detail, respectively.
This report defines and describes a format for models of system components required for system-on-chip (SoC) design. In an SoC design process, starting from an initial system specification, an implementation of the system is created through a series of interactive and automated steps by gradually synthesizing and assembling a system design using components taken out of a set of databases. Generally, databases are needed for processing elements (PEs), communication elements (CEs), bus and other communication protocols, and RTL units. In this report we aim to provide an exhaustive list of requirements for components in an automated SoC design flow using the example of a concrete database format. Following a description of the basic database format in general, this report defines the format of each of the three databases in detail. Using information in this report, specific database formats for diverse SoC design flows can be developed. Specifically, the database format in this report is used successfully in our SoC Design Environment, SCE.
1 Introduction
2 General Database Format
In state-of-the-art design flows for system-on-chip (SoC) design, an initial specification of a system is taken down to an actual implementation through a series of interactive and automated steps [1]. In such design flows, the system is gradually synthesized and assembled using system components taken out of a set of databases. Specifically, an SoC design flow needs to include databases for processing elements (PEs), communication elements (CEs), bus or other communication protocols, and RTL units. The processing element (PE) database contains programmable processors, synthesizable custom hardware components, system memories, IPs, etc. at different levels of abstraction. Such PEs are used during the design flow to implement the computation of the system by mapping
Our databases for SoC design are described in the form of SpecC code, i.e. the format of the databases is based on the SpecC syntax [2] and the SpecC source code for each database must be compilable into SIR (SpecC Internal Representation) files using the SpecC compiler (‘scc’, Section A.1).
2.1
Database Organization
For each database, there is exactly one top-level SIR file. The top-level database SIR acts as a container for all components stored in the database. The database SIR includes components through import of individual component SIR 1
2.2.1
files where component SIR files have to be stored in the same directory as or a sub-directory of the directory the database SIR is located in. Each component in the database must be stored in a separate SIR file. Component SIRs will be imported as needed throughout the design flow. Therefore, component SIRs must be self-contained. In case of databases with multiple models of each component at different levels of abstraction, each model can be stored in a separate SIR file as long as the top-level database SIR contains all component models through direct or indirect import. In those cases, the basic component model used during allocation will contain pointers to other models (in the form of annotations) and tools will import those models when needed in the design flow. The advantage of separate component files is that at any stage of the design flow, the system design will not contain any yet unused component models. Since different models of components out of the different databases get imported into the same system design throughout the design flow, SIR design (import) names and identifiers defined in the SIR files must be unique across all databases and components. Furthermore, identifiers should be chosen appropriately to reduce conflicts with names defined in the system design itself. It is highly recommended to use unique prefixes for component names such that naming conflicts are avoided. Listing 1 shows a simple example for database organization. The database database (Listing 1(c)) contains two components, Component0 and Component1, that are stored in separate files component0 (Listing 1(a)) and component1 (Listing 1(b)), respectively.
2.2
Platform Components
components = ’{’ component_list ’}’ component_list = component_name | component_list ’,’ component_name
Figure 1: Format of platform component annotations. The database supports the concept of platform metacomponents that act as virtual containers for a whole set of real components. In any of the databases (PE, CE, bus or RTL), a component can be designated as a platform meta-component by attaching a special components CE COMPONENTS, annotation ( PE COMPONENTS, BUS COMPONENTS or RT COMPONENTS) to it. Allocating such a platform meta-component will result in all components listed in the components annotation being allocated instead. As such, platform components can ease and simplify the design process by allocation a whole set of related components (a platform) together in one shot. The format of the platform components annotations in shown in Figure 1. A components annotation is a complex annotation that provides a list of names of components belonging to the given platform. All the components listed must exist in the same PE, CE, bus or RTL database that the platform component is in. A platform component can not point to a component in a different database or to a different type of component. For example, a PE platform component can not include and refer to any CE or bus components.
Component Format
Components are described by SpecC objects (behaviors or channels) in the SoC databases. Depending on the database, part or all of the functionality of a component is described through the SpecC code of the component object. As needed, component objects can be hierarchically composed out of other SpecC objects stored together with the top-level component object in the database. Note that unless noted, SpecC code describing component functionality in the databases is for simulation purposes only and does not have to be synthesizable, i.e. apart from the restrictions of the database format defined in this document, any valid SpecC code can be used. On top of SpecC code to describe functionality, additional meta-information about each component is stored in the database in the form of SpecC annotations attached to the component object. Apart from general annotations for database management, components generally have attributes, parameters, and profiling weight tables.
2.2.2
Attributes
Component attributes describe characteristics or metrics for a component. Attributes of a component are stored as annotations attached to the component object under different keys or names as defined by the database. The general format of the value of an attribute annotation is defined in Figure 2. An attribute is either a simple annotation giving a fixed attribute value or a complex annotation describing a range of possible values for an adjustable attribute. For an adjustable attribute, the system designer will be allowed to tune the attribute value during allocation in the SoC design process within the range defined by the annotation. The range of values for an adjustable attribute is given as a list of possible values. Each entry in the list is either a single, fixed value or a pair of values defining the lower and upper boundaries of an interval of values (for numeric 2
1 b e h a v i o r Component0 ( ) ;
1 b e h a v i o r Component1 ( ) ;
3 //
3 //
2 //
...
2 //
...
(a) component0.sc 1 //
(b) component1.sc
Component d a t a b a s e
2
3 import ” component0 ” ;
4 import ” component1 ” ;
(c) database.sc
Listing 1: Database organization example. parameters defined for the component model used during allocation are relevant and parameter values supplied to this model are reused to generate all subsequent models.
attribute = value | attribute_range
Components are made parameterizable through the SIR PARAMETERS annotation used by ‘sir gen’. Figure 3 describes the extended format of the SIR PARAMETERS annotation for use in component parameterization. The annotation defines a list of parameters where each parameter is a tuple consisting of the parameter name followed by a default value, a range of possible values, a string describing the parameter, and a string for the parameter unit. The range of parameter values is described as a list of range value in the same format as for attributes, see Section 2.2.2. The type of the default value defines the type of the parameter and all values in the range have to be of the same type.
attribute_range = ’{’ default_value ’,’ range_list ’}’ range_list = range_value | range_list ’,’ range_value range_value = value | ’{’ min ’,’ max ’}’
Figure 2: Format of component attribute annotations.
Instances of parameterizable components are generated from the component source code by substituting the value of a parameter for all occurrences of the parameter name in the component macro described through the SpecC code of the component. For more information, please refer to the documentation of ‘sir gen’.
types only). The first entry in the list must be a single value describing a sensible default. In all cases, all values must be of the same type as defined by the attribute. Listing 2 shows an example of component attribute annotations. The annotations define a fixed value of 2.3 for PE COST and a range of values from 0.0 up to 60000000.0 with a default of 60000000.0 for PE CLOCK FREQUENCY. 2.2.3
For the purpose of inclusion in the database, components should be written in such a way that they compile with default parameter values using the standard SpecC compiler (‘scc’, Section A.1) instead of ‘sir gen’
Parameters
All components in the SoC databases can be parameterizable. For a parameterized component, the system designer selects values for each of the component’s parameters during allocation. The SoC design tools will then supply the parameter values to the SpecC Design Generator (‘sir gen’, Section A.2) to generate application-specific implementations of the component for use in the design as needed. In case of components with multiple models, only
An example of a parameterized component is shown in Listing 3. The component has one parameter BITWIDTH of unsigned integer type that can vary between 2 and 64. The parameter description is “Width” and parameter values are given in “bits”. The component source code defines a default value BITWIDTH DFLT of 32 for the parameter and uses this value if no value is supplied for BITWIDTH through ‘sir gen’, e.g. for inclusion in the database. 3
1 b e h a v i o r DSP ( ) ; 2
3 n o t e DSP . PE COST = 2 . 3 e0 ; 4
5 n o t e DSP . PE CLOCK FREQUENCY = { 60 e6 , { 0 . 0 , 6 e7 } } ;
Listing 2: Component attributes example. _SIR_PARAMETERS = ’{’ parameter_list ’}’ parameter_list = parameter | parameter_list ’,’ parameter parameter = ’{’ name ’,’ deflt ’,’ prm_range ’,’ description ’,’ unit ’}’ prm_range = ’{’ range_list ’}’ range_list = range_value | range_list ’,’ range_value range_value = value | ’{’ min ’,’ max ’}’
Figure 3: Format of SIR PARAMETERS annotation. 1 # d e f i n e BITWIDTH DFLT 32 u 2
3 # i f n d e f BITWIDTH
4 # d e f i n e BITWIDTH BITWIDTH DFLT
5 # endif 6
7 b e h a v i o r Add ( o u t u n s i g n e d b i t [ BITWIDTH− 1 : 0 ] sum ,
in in
8 9 10 { 11 12 13 14 15 16 17 18 19
note
u n s i g n e d b i t [ BITWIDTH− 1 : 0 ] a , u n s i g n e d b i t [ BITWIDTH− 1 : 0 ] b )
RT COST = BITWIDTH ∗ 3 . 0 ;
n o t e SIR PARAMETERS = { { ”BITWIDTH” , BITWIDTH DFLT , { {2u , 64 u} } , ” Width ” , ” b i t s ” } }; v o i d main ( v o i d ) { sum = a + b ; }
20 } ;
Listing 3: Parameterized component example. 4
+ *
int 1 3
float 2 4 item_header = ’{’ item_list ’}’
Table 1: Example of a profiling table.
+ *
int 1 4
float 2 8
item_list = item_type | item_list ’,’ item_type
Table 2: Example of the operation weight table of a DSP. 2.2.4
Figure 4: Format of item header annotations.
Weight Tables
Component weight tables describe the special characteristics or metrics of a component which are used to evaluate the design metrics [4]. The design metrics are determined by the metrics of the system architecture represented by component weight tables and the metrics of the system behavior represented by profiling tables. For example, Table 1 represents the profiling table of a system behavior. The top/bottom row represents an addition(”+”)/multiplication(”*”) operation, and the left/right column represents integer(”int”)/float(”float”) data type. Then, the ”3” indicates that the system behavior executes the multiplication operation of integer type three times during simulation. Assume we map the above system behavior to a DSP component. The weight table of the DSP representing the required clock cycles for each operation is listed in Table 2. The ”4” describes that the DSP takes 4 clock cycles to complete the execution of one multiplication operation of integer type. Accordingly, the weighted result computed by multiplying the weights in the weight table with the entries in the profiling table is described in Table 3. The summation of the weighted result, which equals to 49, indicates the total computation time of the design is 49 clock cycles. Design metrics can be classified into three categories: operation metric set, traffic metric set, and memory metric set. In the component weight table, each row represents the weights for one item type and each column represents the weights for one data type. The possible item types and data types of different metric sets are listed in Section 2.2.5 and Section 2.2.6, respectively. Table 2, Table 4, and Table 5 are the examples of operation weight table, traffic weight table, and memory weight table. In general, operation weight tables and traffic weight tables are manually generated by designers. Memory weight tables are automatically generated by SCE based on the memory attributes. Weight tables are stored in the data base by use of three
data_header = ’{’ data_list ’}’ data_list = data_type | data_list ’,’ data_type
Figure 5: Format of data header annotations.
weight_table = ’{’ item_list ’}’ item_list = item_col | item_list ’,’ item_col item_col = ’{’ data_list ’}’ data_list = value | data_list ’,’ value
Figure 6: Format of weight annotations.
5
1 b e h a v i o r DSP ( ) ; 2
3 n o t e DSP . PE WEIGHT OPERATION HEADER ITEMTYPE = { ”+” , ” ∗ ” } ; 4
5 n o t e DSP . PE WEIGHT OPERATION HEADER DATATYPE = { ” i n t ” , ” f l o a t ” } ; 6
7 n o t e DSP . PE WEIGHT OPERATION DYNAMIC = { { 1 , 2 } , { 4 , 8} } ;
Listing 4: Component weight table example.
+ *
int 1 12
float 4 32
local global
Table 3: Example of a weighted result. in out
int 1 3
float 4 32
Table 5: Example of a memory weight table.
float 2 4
type "float" (return type of function), with the execution number of function F1. In this case, the operations inside F1 will not be calculated again. The possible values of item types of the traffic metric sets are listed in Table 7.
Table 4: Example of a traffic weight table. annotations: item header annotation, data header annotation, and an actual weight table data annotation. Item header and data header annotations lists the supported item and data types, respectively. The format of the item header annotation and the data header annotation are defined in Figure 4 and Figure 5, respectively. The available item types and data types are listed in Section 2.2.5 and Table 2.2.6. The actual weight tables are stored in corresponding table data annotations. The items in a weight table are stored as a two- dimensional array (item types first), as defined in Figure 6. Listing 4 shows an example of a component weight table annotation, which matches the example described earlier. 2.2.5
int 1 12
2.2.6
Data Types for Metric Set
Operation and traffic metric sets share the same set of possible values of data types, which are listed in Table 8. Besides the data types listed in Table 8, data type annotations can also contain three groups of composite data types: Bit vectors We can define bit vectors with different lengths as different data types. The corresponding data type format is "bit[size]", "unsigned bit[size]", "bit4[size]" or "unsigned bit4[size]". For example, data belonging to either bit[8:0] or bit[9:1] can be defined as an independent data type "bit[9]" in the data header annotation.
Item Types for Metric Set
Arrays We can define arrays with different lengths as different data types. The corresponding data type format is "basic type[size]". For example, data belonging to int[23] and int[24] type can be defined as independent data types "int[23]" and "int[24]", respectively.
The possible values for item types of operation metric sets are listed in Table 6. An operation metric set defines values for basic operations corresponding to weights for the data flow and control flow complexity of the code. For the operation metric set, besides the items listed in Table 6, each global function can be treated as an independent operation type. For example, if there is a global function float F1(int arg1, long arg2), we can put "F1" into the item header annotation of operation. Consequently, the weighted result of function "F1" is computed by multiplying the weight of the entry in the row representing the item type "F1" and in the column representing the data
User-defined types Every user-defined structure/union/enum type can be treated as one independent data type. It uses the structure/union/enum names as the data type names. For example, if a structure is defined as struct s1{int a; float b} and we want to define it as an independent data type, the defined data 6
Name "void" "#1" "#i" "()" "this" "[]" "f()" "." "->" "p++" "p--" "[:]" "++p" "--p" "&p" "*p" "+x" "-x" "˜ " "!" "sizeof(E)" "sizeof(T)" "()x" "@" "*" "/" "%" "+" "-" "" "" "=" "==" "!=" "&" "ˆ " "|" "&&" "||" ":?" "="
Name "*=" "/=" "%=" "+=" "-=" "=" "&=" "ˆ= "|=" "’"
Description void operation const data access operation identifer access operation parenthesis operation ”this” pointer access operation array access operation function call operation member access operation member pointer access operation post-increment operation post-decrement operation bit slice operation pre-increment operation pre-decrement operation address deriving operation content deriving operation unary plus operation negation operation not operation logic not operation size of operation (on expression) size of operation (on type) type conversion operation concatenation operation multiplication operation division operation modulo operation addition operation substraction operation left shift operation right shift operation less operation greater operation less equal operation greater equal operation equal operation operation not equal operation and operation eor operation or operation logic and operation logic or operation condition operation assignment operation
Description multiplication & assignment operation division & assignment operation modulo & assignment operation addition & assignment operation substraction & assignment operation left shift & assignment operation right shift & assignment operation and & assignment operation eor & assignment operation or & assignment operation comma operation
Table 6: Item types for operation metric set (operations) (continued).
Name "in" "out"
Description input traffic output traffic Table 7: Item types for traffic metric set
Name "bool" "char" "unsigned char" "short int" "unsigned short int" "int" "unsigned int" "long int" "unsigned long int" "long long int" "unsigned long long int" "float" "double" "long double" "void" "event" "void*"
Table 6: Item types for operation metric set (operations).
Description bool char unsigned char short int unsigned short int int unsigned int long int unsigned long int long long int unsigned long long int float double long double void(for return value of function) event pointer
Table 8: Data types for metric sets.
7
+ * -
int 1 4 0
float 2 8 0
long 0 0 0
in the PE database. PE behaviors are used for PE allocation and they define the basic characteristics like attributes and parameters for a PE and all of its lower-level models. Furthermore, the SpecC code of behavioral PE models can describe high-level functional aspects of the PE in case all or part of the PE’s functionality is pre-defined and fixed.
Table 9: An alternative operation weight table of the DSP.
3.1.1
type "struct s1" can be put into the data header annotation.
pe_behavior = behavior pe_name ports_opt interfaces_opt body_opt ’;’
If the above three groups of hierarchical data types are not defined, we use their basic types to compute the weighted result. For example, if no data type "int[24]" is defined, the data with type int[24] will be treated as 24 integer ("int") types. 2.2.7
ports_opt = | ’(’ ’)’ | ’(’ channel_port_list ’)’
Default Values
When specifying weight tables, designers do not need to put all the item types (e.g. Table 6 or Table 7) to the item header annotation, and do not need to put all the data types (e.g. Table 8) to the data header annotation. The default value of weights for the item types that are not in the item header annotation is 0. Similarly, the default value of weights for data types that are not in the data header annotation is 0. As a result, there is no different between Table 2 and Table 9 in terms of values of weights.
channel_port_list = channel_port | channel_port_list ’,’ channel_port channel_port = interface_name | interface_name port_name interfaces_opt = | implements interface_list
3 Processing Elements
body_opt = | ’{’ internal_definitions_opt ’}’
Processing elements are represented by SpecC behaviors in the PE database. For each PE model, a corresponding behavior declaration needs to exist in the database. The PE database can contain different PE models at varying levels of abstraction corresponding to the steps in the design flow. At minimum, behavioral PE models used for PE allocation and for initial implementation of specification behaviors mapped onto PEs are required to exist for each PE (Section 3.1). In addition, PEs can optionally have bus-functional models for use after communication synthesis (Section 3.4) and implementation models for cycle-accurate simulation in case of PEs with part or all of their functionality fixed (Section 3.5). In case of synthesizable or programmable PEs, PE models provide templates that will be filled automatically during the design process.
3.1
General Format
Figure 7: Format of PE behaviors. A PE behavior is created through a special SpecC behavior declaration or definition. The format of PE behaviors is shown in Figure 7. The name of the SpecC behavior defines the name of the PE component. For PEs with fixed computation functionality, the PE behavior can have ports of abstract, message-passing interface type and an internal or external body (Section 3.1.5). PE behaviors carry a number of annotations for general database management, attributes (Section 3.1.2), and optional parameters (see Section 2.2.3). Table 10 lists the general annotations that are attached to PE behaviors for database management and in order to describe basic information about the corresponding processing element. In detail, the following annotations are supported:
PE Behaviors
Behavioral PE models are the basic models of PEs and the PE behaviors represent the PEs available in the database. Therefore, for each PE there must be at least a behavioral model and the set of PE behaviors defines the list of PEs
PE LIBRARY Name describing the PE database the behavior is a member of. Used to distinguish between 8
Name PE LIBRARY PE CATEGORY PE COMMENT PE COMPONENTS PE OS MODEL PE NET MODEL PE BF MODEL PE BF BUS PE CA MODEL
Description Name of parent PE database Name of PE category PE description List of components for platform PE Name of PE’s OS model Name of PE’s network model Name of bus-functional PE model List of PE ports and bus protocols Name of cycle-accurate PE model
Type String String String String String String String Figure 8 String
Table 10: General annotations for behavioral PE models. pe_bus = ’{’ bus_list ’}’ bus_list = port | bus_list ’,’ port port =
’{’ port_name ’}’ | ’{’ port_name ’,’ bus_name ’}’ | ’{’ port_name ’,’ bus_name ’,’ protocols ’}’ | ’{’ port_name ’,’ bus_name ’,’ protocols ’,’ addresses ’}’
protocols = protocol_name | ’{’ protocol_list ’}’ protocol_list = protocol | protocol_list ’,’ protocol protocol = protocol_name | ’{’ protocol_name_list ’}’ protocol_name_list = protocol_name | protocol_name_list ’,’ protocol_name addresses = ’{’ address_list ’}’ address_list = address | address_list ’,’ address address = address_value | ’{’ start_address ’,’ end_address ’}’
Figure 8: Format of PE behavior PE BF BUS annotations. 9
Default – ”” ”” – – – – – –
PE and other behaviors, i.e. required for PE behaviors.
no bus protocol instances are given, the corresponding port will be allowed to connect to the given bus in any form (e.g. as any master and/or slave). Note that a complete, fixed list of ports, busses, protocol instances and addresses is required for PEs that have a bus-functional model (see PE BF MODEL above).
PE CATEGORY Name of the category the PE belongs to. PE categories are mandatory and are used to classify PEs into different groups for PE allocation and selection. PE COMMENT Brief description of the PE that will be used and displayed as an aid during selection and allocation.
PE CA MODEL Name of the behavior providing a cycleaccurate implementation model of the PE. The named behavior has to exist in the PE database. Required for PEs that have pre-defined, fixed hardware implementation. See Section 3.5.
PE COMPONENTS List of names of actual components that are part of the platform in case of a platform PE. If the annotation does not exist, the PE is a regular component, not a platform. See Section 2.2.1.
Listing 5 shows an example of a simple PE behavior. The behavior defines a PE named MyDSP that is part of the “processor” library and belongs to the “DSP” category in that database. The PE has a pre-defined interface with exactly one port (“portA”) that connects to a MyDSP Bus from the bus database as a MyDSP Bus bus master using external addresses in the range from 0x000000FF through 0xFFFFFFFF (consequently excluding/reserving addresses in the range from 0 through 255 for internal use). database. In addition, OS, bus-functional and cycle-accurate models MyDSP OS, MyDSP BF and MyDSP ISS of the PE are made available.
PE OS MODEL Name of the behavior providing an OS model for the PE. The named behavior has to exist in the PE database. Required for programmable software PEs that support dynamic scheduling through operating systems. See Section 3.2. PE NET MODEL Name of the behavior providing a network model for the PE. The named behavior has to exist in the PE database. Required for PEs that have pre-defined, fixed interfaces on the pin level. See Section 3.3.
3.1.2
PE BF MODEL Name of the behavior providing a busfunctional model of the PE. The named behavior has to exist in the PE database. Required for PEs that have pre-defined, fixed interfaces on the pin level. See Section 3.4.
Attributes
Basic characteristics and metrics of PEs are described through attribute annotations attached to the PE behaviors. Attribute annotations can be given using the format defined previously in Section 2.2.2. Specifically, the following attributes can be attached to PEs (Table 11):
PE BF BUS List of logical bus ports (each representing a set of pins) for PEs with pre-defined interfaces. The format of the annotation is shown in Figure 8. A logical port in the list is defined by its name, the name of its corresponding (unparameterized) bus from the bus database (see Section 5.1), the name(s) of data transfer protocol instances used to connect to the bus, and an optional (range of) external bus addresses supported by the component port. Data transfer protocol instances have to match the names defined for the port’s bus in the bus database (see BUS PROTOCOL annotations, Section 5.1.1). Ports can use multiple protocol instances each (e.g. connecting as both master and slave). For each instance either a specific name or a list of possible names to select from has to be given.
PE CLOCK FREQUENCY Clock frequency the PE is operating at. For PEs where the clock can be adjusted up to a maximum frequency, this should be an adjustable attribute. PE MIPS MIPS performance rating of the PE, i.e. maximal throughput of the PE in million instructions per second. PE COST Cost of the PE. The cost unit depends on the database (e.g. price or area). PE POWER Power consumption rating of the PE, i.e. usually average power consumption when not idling. PE INSTRUCTION WIDTH Number of bits in a PE instruction word, i.e. width of the internal instruction bus.
If the annotation is not given, it is assumed that the PE’s interface can be defined freely during connectivity selection. If no bus name is given for a port, the port will be allowed to connect to any bus. Finally, if
PE DATA WIDTH Number of bits in a PE data word, i.e. width of the internal data bus. 10
1 b e h a v i o r MyDSP ( ) ;
2 n o t e MyDSP . PE LIBRARY
= ” processors ” ;
3 n o t e MyDSP . PE CATEGORY = ”DSP” ; 4 n o t e MyDSP . PE COMMENT
= ”PE e x a m p l e ” ; = { { ” p o r t A ” , ” MyDSP Bus ” , ” m a s t e r ” , { { 0xFFu , 0xFFFFFFFFu } } }
5 n o t e MyDSP . PE BF BUS
6 7 };
8 n o t e MyDSP . PE OS MODEL = ”MyDSP OS” ;
9 n o t e MyDSP . PE BF MODEL = ”MyDSP BF” ;
10 n o t e MyDSP . PE CA MODEL = ” MyDSP ISS ” ;
Listing 5: PE behavior example. Name PE CLOCK FREQUENCY PE MIPS PE COST PE POWER PE INSTRUCTION WIDTH PE DATA WIDTH PE CHAR WIDTH PE DATA MEMORY PE PROGRAM MEMORY
Description Clock frequency Throughput Cost Power consumption Instruction word width Data word width Machine character width Size of internal data memory Size of internal program memory
Unit Hz MIPS W bits bits bits byte byte
Type double double double double uint uint uint ulong ulong
Default 0.0 0.0 0.0 0.0 0u 0u 8u 0ul –
Table 11: PE behavior attribute annotations. PE CHAR WIDTH Number of bits in a basic machine character, i.e. width of smallest addressable unit.
PE WEIGHT OPERATION STATIC Each item in the weight table represents the occupied instruction word or control word for an operation with a certain item type and data type in the PE.
PE DATA MEMORY Size of internal data memory of PE. For PEs without separate program memory space, data memory size is the total size of combined program and data memory.
For general purpose processors and DSPs, one design metric represents the number of of instructions that the system behavior contains after mapping the system behavior to the PE. For custom hardware, it represents the number of control words that the system behavior contains after synthesizing the system behavior to the PE.
PE PROGRAM MEMORY Size of internal program memory of PE for PEs with dedicated program memory space separate from data memory. Note that using adjustable attributes for these annotations will define the amount of flexibility available in the PE template. 3.1.3
PE WEIGHT OPERATION DYNAMIC Each item in the weight table represents the clock cycles required to execute an operation with a certain item type and data type in the PE. One design metric represents the computation time of the design.
Weight Tables
Weight tables of PEs are described through weight table annotations attached to the PE behaviors. Weight table annotations can be given using the format defined previously in Section 2.2.4. Specifically, the weight annotations that can be attached to PEs are listed in Table 12. Each one is used by at least one design metric after mapping a system behavior to a system architecture. The weight annotations and examples of their represented design metrics are:
PE WEIGHT TRAFFIC STATIC Each item in the weight table represents the occupied machine characters by a storage unit (such as a variable) of the system behavior with a certain item type and data type in the PE. The machine character corresponds to the ”char” data type in the SpecC language. This is used to compute the static traffic. One design 11
Name PE WEIGHT PE WEIGHT PE WEIGHT PE WEIGHT
OPERATION STATIC OPERATION DYNAMIC TRAFFIC STATIC TRAFFIC DYNAMIC
Metric Code size Computation time Static traffic Dynamic traffic
Unit words cycles chars chars
Type double double double double
Default 0.0 0.0 0.0 0.0
Table 12: PE behavior weight annotations. Name "bool" "char" "short int" "int" "long int" "long long int" "float" "double" "long double" "bit" "void*"
metric represents the port width of the system behavior. It equals to the traffic when each port of the behavior is accessed once. PE WEIGHT TRAFFIC DYNAMIC Each item in the weight table represents the occupied machine characters by a storage unit (such as a variable) of the system behavior with a certain item type and data type in the PE. The machine character corresponds to the ”char” data type in the SpecC language. This is used to compute the dynamic traffic. One design metric represents the dynamic traffic of the design. It equals to the amount of traffic going through the ports of the system behavior during simulation.
Table 16: Data types for memory tables.
Besides the weight annotation, the item header annotation and data header annotation are also required. The header annotations for operation metric set and traffic metric set are shown in Table 13, and Table 14 PE WEIGHT OPERATION STATIC and respectively. PE WEIGHT OPERATION DYNAMIC use header annotations in Table 13. PE WEIGHT TRAFFIC STATIC and PE WEIGHT TRAFFIC DYNAMIC use header annotations in Table 14. 3.1.4
and alignment, see Table 15 and all basic SpecC data types (Table 16), respectively. Furthermore, the following annotations are used to define PE memory tables (Table 18): PE MEMORY LAYOUT Size and alignment table (in machine characters) of variables of basic type in the local memory of the PE as determined by the target compiler and the target PE itself. Table given in the format defined in Figure 6. Items not specified default to size and alignment on the current host.
Memory Tables
Name "Size" "Alignment"
Description bool char short int int long int long long int float double long double bit vectors pointer
PE MEMORY BITPACKING Boolean flag to distinguish between tight or loose packing of bits in bitfields inside structs. True for tight packing. Defaults to packing on current host.
Description Variable sizes in memory. Variable alignment in memory.
Memory tables defined for the basic types will be used to compute memory weights (sizes) for all basic and composite types found in the design.
Table 15: Item types for memory tables. Memory tables attached to PE behaviors describe the layout of variables in the PE memory as determined by the compiler on top of the machine architecture. Memory table annotations follow the same basic format as for weight table annotations defined in Section 2.2.4. The available item types and data types for PE memory tables are listed in Table 15 and Table 16. Memory tables for sizing and alignment share the same item and data header annotations shown in Table 17 where item and data types iterate over types of memory data (size
3.1.5
Computation Functionality
For intellectual-property (IP) PEs with fixed functionality in terms of the computation the PE can perform, the PE behavior in the PE database can optionally provide a highlevel, abstract simulation model of the PE. The behavioral IP model will be plugged into the system for simulation and has to accurately model the computation performed by the IP including estimated timing. On the other hand, 12
Name PE WEIGHT OPERATION HEADER DATATYPE PE WEIGHT OPERATION HEADER ITEMTYPE
Type in Table 8 in Table 6
Default – –
Table 13: Header annotations for operation metrics. Name PE WEIGHT TRAFFIC HEADER DATATYPE PE WEIGHT TRAFFIC HEADER ITEMTYPE
Type in Table 8 in Table 7
Default – –
Table 14: Header annotations for traffic metrics. the behavioral IP model should exclude unnecessary implementation details in order to achieve the fastest possible simulation speeds. The IP model is a black-box model used for simulation only and therefore only needs to be functionally correct in terms of the input and output values that can be observed at its ports. For such IPs, the PE database has to provide a SpecC body for the PE behavior. The body can be either internal or external. In the former case, the SIR file of the PE contains a complete SpecC definition of the PE behavior including its body. In the latter case, the PE database provides a shared library with the PE behavior’s body to be linked against the design for simulation. The shared library and associated annotations at the PE behavior can be created via the IP mechanism of the SpecC compiler (see ‘scc’ manual page, Section A.1). Behavioral PE models of IPs communicate with the rest of the system at an abstract, message-passing level. PE behaviors of IPs must have ports that are of one of the following interface types out of the standard SpecC channel library:
_PE_attr _PE_attr _PE_NET_MODEL _PE_NET_MODEL _PE_BF_MODEL _PE_BF_MODEL _PE_CA_MODEL _PE_CA_MODEL
IP
(a) Behavioral model
• i sender, i receiver, or i tranceiver • i typed sender, i typed receiver, i typed tranceiver
or
_PE_attr _PE_attr _PE_NET_MODEL _PE_NET_MODEL _PE_BF_MODEL _PE_BF_MODEL _PE_CA_MODEL _PE_CA_MODEL
IP
PE behaviors are not allowed to have ports of any other interface or standard type. A simple example of an IP with pre-defined computation is shown in Figure 9(a) and Listing 6. The IP has three ports for receiving and sending integers that get processed internally. The body of the IP’s PE behavior provides SpecC code for the main method that simulates the IP’s functionality (in this case, simple incrementation) and timing (through a waitfor statement modeling the IP’s input-to-output delay). Since the IP behavior represents real hardware that never exits, the IP model is executing in an endless loop. Finally, the IP behavior provides the required general annotations for database management. Although not shown in the example, IPs supply standard at-
IP_Net (b) Wrapped network model
Figure 9: Example of IP PE behavior.
13
Name PE MEMORY HEADER DATATYPE PE MEMORY HEADER ITEMTYPE
Type in Table 16 in Table 15
Default ”” ””
Table 17: Header annotations for memory tables. Name PE MEMORY LAYOUT PE MEMORY BITPACKING
Description Table with layout of variables in PE memory Flag for tight packing of bits in struct bitfields
Unit chars -
Type uint bool
Default Host Host
Table 18: PE behavior memory table annotations. tributes and can be made parameterizable like any other PE behavior. As an alternative to providing a dedicated behavioral IP model, the IP’s PE behavior in the database can instead be provided in a bottom-up manner. This requires that a low-level IP model (e.g. the IP’s network model, see Section 3.3) is encapsulated in a behavioral wrapper, as shown in Figure 9(b). In this case, the wrapper contains the necessary code to abstract all low-level IP communication into the required behavioral interface.
1 # i n c l u d e 2 3 DEFINE I TYPED SENDER ( i p i n t ,
int ) int )
4 DEFINE I TYPED RECEIVER ( i p i n t , 5
6 behavior IP ( i i p i n t r e c e i v e r
data input , i i p i n t r e c e i v e r cmd input , i i p i n t s e n d e r output )
7 8 9 { 10 11 12 13 14 15 16
note note note note note note
PE LIBRARY PE CATEGORY PE COMMENT PE NET MODEL PE BF MODEL PE CA MODEL
= = = = = =
3.1.6
” processors ” ; ” IP ” ; ” IP example ” ; ” IP Net ” ; ” IP BF ” ; ” IP RTL ” ;
mem_interface = interface interface_name ’{’ ’}’ ’;’
Figure 10: Format of PE behavior memory interfaces.
i n t cmd , d a t a ;
17 18
For PEs that can act as system-level memories shared among other PEs, the PE behavior has to be turned into a server providing global storage to other PEs. Examples of such PEs are dedicated shared memory PEs or custom hardware PEs that support memory-mapped I/O. In the database, this is modeled by letting the PE behavior implement a channel interface through which other PEs can access the memory. The PE’s memory interface in the database has to be empty and acts as a template that will be filled as part of the design flow. See Figure 10 for the general format of memory interface definitions where a memory PE behavior implements such an interface. In addition, memory interfaces have to have a number of general annotations for database management (Table 19):
v o i d main ( v o i d ) { while ( true ) { c m d i n p u t . r e c e i v e (&cmd ) ; d a t a i n p u t . r e c e i v e (& d a t a ) ; i f ( cmd ) d a t a ++; waitfor (1000000); o u t p u t . send ( d a t a ) ; } }
19 20 21 22 23 24 25 26 27 28 29
Memory
30 } ;
Listing 6: Example of PE behavior for simple IP with given functionality.
PE MEMORY Boolean flag to distinguish PE behavior memory interfaces from other normal interfaces. True for memory interface templates. An example of a system memory PE behavior is shown in Listing 7. The memory behavior MyMem implements 14
Name PE MEMORY
Description Flag for memory interface templates
Type bool
Default false
Table 19: Memory interface annotations. the PE behavior running on top of this OS. In addition the the OS shell itself, a PE’s OS model also has to provide prototypes and templates for implementation of any interrupt handling available in the PE. In order to be able to handle interrupts in cooperation with the OS, the OS models has to provide templates of interrupt handlers and interrupt handling tasks to allow implementation of an interrupt chain from the HAL (see Section 3.4.4) through the OS interrupt handlers, OS interrupt tasks and to the application. Templates for interrupt handlers and interrupt tasks provide a blueprint for the tools to generate actual interrupt chains depending on application requirements and selected target operating systems. A typical interrupt chain in software starts with the lowest, hardware-specific level of interrupt handlers (triggered by the hardware) in the PE’s HAL (see Section 3.4.3). Interrupt handlers in the HAL perform, if necessary, de-multiplexing of shared interrupts and then call a source-specific interrupt handler in the PE’s OS shell (see PE OS INT HANDLER, Section 3.2.1). Interrupt handlers in the OS shell, in turn, simply relay execution of the interrupt to an interrupt task (running on top of the OS, see Section 3.2.2) via a call to the task’s start method (see PE OS TASK START). The start method then triggers execution of the task body (see PE OS TASK BODY) either via a direct call or using OS-specific synchronization. Finally, the task body contains the actual application-specific code for user-level interrupt handling and interrupt processing.
1 i n t e r f a c e IMyMem { 2 3 };
note
PE MEMORY = t r u e ;
4
5 b e h a v i o r MyMem( )
implements IMyMem
6 7 {
n o t e PE LIBRARY = 1 ; n o t e PE CATEGORY = ” Memory” ; = { n o t e PE BF BUS { ” p1 ” , ”MyMem Bus” , ” s l a v e ” , { { 0u , 1024 u } } } }; n o t e PE BF MODEL = ”MyMem BF” ;
8 9 10 11 12 13 14 15
v o i d main ( v o i d ) { }
16 17 18 } ;
Listing 7: Example of PE behavior for system memory. the memory interface IMyMem. As required, the memory interface template is empty and has the proper annotation attached. Attached to the memory PE behavior are the normal general annotations which mark the behavior as a PE behavior in the “Memory” category, define a single port “p1” of MyMem Bus slave type and provide a busfunctional model in the form of the MyMem BF behavior of the PE database (since the memory has a fixed, predefined pin-level interface). Since the PE is a pure system memory that can not provide any computational functionality (IP with fixed but empty computation, see Section 3.1.5), the memory’s PE behavior does not have any ports and the main method is empty.
3.2
3.2.1
OS Shell
The general format of PE OS model shells is shown in Figure 11. The OS model shell is a SpecC behavior with an internal body that has an empty main method (i.e. is empty in terms of functionality it executes). The main method will later be filled with the actual PE behavior. If the PE has interrupt handling capabilities, the OS shell has to include a definition of an interrupt handler method. This method serves as a prototype for generation of actual interrupt handlers by the tools. As such, the method has to define an insertion point for any interrupt handling code to be filled in later. For this purpose, the method has to include a label body that is attached to an empty statement. All interrupt handling code will then be inserted by the tools at the point defined by this label. OS models for programmable PEs have a set of general
PE Operating System Models
For programmable software PEs that support a flexible computation behavior and dynamic scheduling through operating systems, the PE database has to contain an OS model of the PE. A PE’s OS model provides templates to insert an operating system into the PE and to implement interrupt handling on top of the PE’s operating system. A PE OS models is basically an empty shell that that will be wrapped around the PE’s behavioral model. This OS shell serves as a placeholder to accommodate the actual operating system for the PE and the computation tasks of 15
Name PE BF MODEL PE OS INT TASK PE OS INT HANDLER
Description Name of bus-functional PE model Name of PE’s interrupt task template behavior Name of OS model’s interrupt handler method prototype
Type String String String
Default – – –
Table 20: PE OS model annotations. os_behavior = behavior pe_os_name ports_opt ’{’ os_behavior_body ’}’ ’;’ os_behavior_body = ’{’ internal_definitions_opt os_int_handler internal_definitions_opt ’}’ os_int_handler = void os_int_handler_name ’(’ void ’)’ ’{’ statements_opt "body" ’:’ ’;’ statements_opt ’}’
1 b e h a v i o r MyDSP OS ( ) {
note note note
2 3 4 5
/ / i n t e r r u p t handler ( top half ) prototype void i n t H a n d l e r ( void ) { body : ; }
6 7 8 9 10 11
v o i d main ( v o i d ) { par { } }
12 13 14 15
Figure 11: Format of PE OS models.
PE BF MODEL = ”MyDSP BF” ; PE OS INT HANDLER = ” i n t H a n d l e r ” ; PE OS INT TASK = ” MyDSP IntTask ” ;
16 } ;
purpose annotations for database and design flow management (Table 20):
Listing 8: Example of PE OS model.
PE BF MODEL Name of the behavior providing a busfunctional model of the PE. This annotation has to match the name annotated at the PE behavior itself (Table 10 in Section 3.1.1).
In addition to its empty main method, the OS model includes an interrupt handler prototype method intHandler. Furthermore, the OS model associates the interrupt task template MyDSP IntTask with this PE.
PE OS INT TASK Name of the behavior providing the interrupt task template for handling of interrupts through the PE’s OS. The named behavior has to exist in the PE database. See Section 3.2.2.
3.2.2
Interrupt Task Templates
The format of OS interrupt task templates is shown in Figure 12. An interrupt task template is a SpecC behavior with an internal body that has an empty main method. Depending on the chosen target OS, the main method will either be filled or left empty when generating actual interrupt task implementations. In addition, the template has to provide prototypes for methods to implement the task body and to trigger and start execution of the task. Note that the start method has to be exported via an interface such that it can be called from other behaviors. In the template, the task body method has to be empty. It is filled with necessary code for notification of application tasks or bus drivers by the tools. On the other hand, the start method in the template has to include code that calls the task body method directly. This provides a default task implementation that executes the task body without involvement of the OS whenever the task is triggered. If there is no OS running on the PE, this default task implementation will be inserted into the PE by the tools. On
PE OS INT HANDLER Name of the method in the OS model providing a prototype for generation of interrupt handlers on top of the PE’s OS. The named method has to exist in the OS shell. Interrupt handlers in the OS shell are the entry points for implementation of interrupts entering the OS. They will be called by the interrupt handlers in the PE’s HAL (see Section 3.4.3). In turn, OS shell interrupt handlers will be filled by the tools with code to trigger execution of an associated interrupt task (via a call to the tasks’s start method, see PE OS TASK START, Section 3.2.2) containing the user-level interrupt code. An example of a OS model shell MyDSP OS for a programmable PE is shown in Listing 8. The OS model belongs to the PE with the bus-functional model MyDSP BF. 16
os_int_task = behavior os_int_task_name ports_opt implements os_int_task_interface_name ’{’ os_int_task_body ’}’ ’;’ os_int_task_body = ’{’ internal_definitions_opt os_int_task_body_func os_int_task_start_func internal_definitions_opt ’}’ os_int_task_body_func = void os_body_func_name ’(’ void ’)’ ’{’ ’}’ os_int_task_start_func = void os_start_func_name ’(’ void ’)’ ’{’ statements_opt os_body_func_name ’(’ ’)’ ’;’ statements_opt ’}’
1 i n t e r f a c e IMyDSP IntTask { 2 3 };
void s t a r t ( void ) ;
4
5 b e h a v i o r MyDSP IntTask ( )
implements IMyDSP IntTask
6 7 { 8 9 10
note note
PE OS INT TASK START = ” s t a r t ” ; PE OS INT TASK BODY = ” body ” ;
v o i d body ( v o i d ) { }
11 12 13
void s t a r t ( void ) { body ( ) ; }
14 15 16 17
v o i d main ( v o i d ) { }
18 19 20 } ;
Figure 12: Format of OS interrupt task templates.
Listing 9: Example of PE OS interrupt task template.
the other hand, if required by the target OS, tools will fill the main method of the task with code that executes the task body whenever a task execution is triggered via the start method. In these cases, the start method will be replaced with code that triggers another iteration of the main method. Interrupt task templates that are part of a PE’s OS model have a set of general purpose annotations for database and design flow management (Table 21):
The body method will be executed whenever the interrupt task is triggered by the OS interrupt handler (via the task’s start method, see above). The named method provides a template to be filled with the actual user-level code to process the interrupt. An example of an interrupt task template is shown in Listing 9. It shows an interrupt task template MyDSP IntTask with start and body methods. As required, the start method is exported via an implemented interface and its default implementation calls the task’s body method.
PE OS INT TASK START Name of the method in the interrupt task that has to be called in order to trigger and start execution of the interrupt task. This method has to exist and has to be exported through an interface implemented by the interrupt task.
3.3
PE Network Models
For IP components with pre-defined functionality, the PE database has to include a network model of the IP that describes its behavior and its network interfaces for the purpose of system simulation at the network level. In addition to a simulation model of the computation behavior, similar to the high-level behavioral model of the IP (see Section 3.1.5), a PE network model has to provide an interface to the IP at the level of logical point-to-point links going in and out of the IP. The IP network model will be plugged into the system for simulation at the network level. It has to accurately model the computation performed by the IP including estimated timing. On the other hand, it should exclude unnecessary implementation details in order to achieve the fastest possible simulation speeds. The network model is
The start method will be called by the corresponding interrupt handler in the OS shell (see PE OS INT HANDLER, Section 3.2.1) to trigger task execution. A start method relays execution of userlevel interrupts to the specific interrupt code in the task body method. The named start method has to provide a default implementation with a direct call to the body method. If necessary, this direct call will be replaced by the tools with OS-specific task synchronization instead. PE OS INT TASK BODY Name of the empty method in the interrupt task that provides a placeholder for the actual task body to be filled in later. An empty method with the given name has to exist in the task template. 17
Name PE OS INT TASK START PE OS INT TASK BODY
Description Name of method to trigger interrupts task execution Name of interrupt task body method
Type String String
Default – –
Table 21: PE OS interrupt task annotations. a black-box model used for simulation only and therefore only needs to be functionally correct in terms of the input and output values that can be observed at its ports. Since an IP has pre-defined functionality in terms of both computation and communication, communication with the IP can generally not be synthesized arbitrarily but has to adhere to the proprietary IP protocol on all levels. Network models therefore have to provide a communication adapter that provides implementations of high-level, network protocols required for communication with the IP. During the design process, IP adapters will be inlined into all components communicating with the IP. There, they will become the drivers for the application to communication with the IP over the network. An IP network adapter translates between the high-level, behavioral and the mid-level network interfaces of the IP, implementing all necessary protocol drivers in between. On the one side, it provides an interface to the application side that matches the behavioral message-passing interface of the IP (Section 3.1.5). On the other side, the adapter supports a connection with the IP network behavior via corresponding logical links. Internally, it then maps all behavioral message-passing calls by the application into a set of logical link transfers as dictated by the IP. 3.3.1
pe_ip_adapter = ’{’ adapter_name ’,’ channels ’}’ channels = ’{’ channel_name_list ’}’ channel_name_list = channel_name | channel_name_list ’,’ channel_name
Figure 14: Format of PE IP ADAPTER annotations. nal or external body, i.e. for IPs the body can be supplied as an external library in the same manner as for the behavioral IP model (Section 3.1.5). The name of the behavior defines the name of the PE network model and has to match the corresponding annotation at the PE behavior (see Section 3.1.1, PE NET MODEL annotation). Network models of IPs communicate with the rest of the system at a point-to-point, logical link level. IP network behaviors must have ports that are of one of the following interface types out of the standard SpecC channel library: • i sender, i receiver, or i tranceiver (c double handshake type communication)
Network Model Behavior
• i send or i receive (c handshake type communication)
net_behavior = PE network behaviors are not allowed to have ports of any behavior pe_net_name ports other interface or standard type. ’{’ internal_definitions_opt ’}’ ’;’ ports =
IP network models have a set of general purpose annotations for database and design flow management (Table 22): PE IP ADAPTER Names of the channels providing the adapter wrapping the protocol stack for communication with IP network models. See Section 3.3.2.
’(’ channel_port_list ’)’
channel_port_list = channel_port | channel_port_list ’,’ channel_port
The format of the annotation is shown in Figure 14. A network adapter is defined by its name and a list of channels it provides for communication with the IP. The name of the adapter is the name of a channel that has to exist in the database. The named adapter channel has to have a matching set of ports that allow a direct connection between adapter and PE network model.
channel_port = interface_name | interface_name port_name
Figure 13: Format of PE network models.
The adapter has to provide a list of channels that allow external behavioral communication with the IP
The general format of PE network models is shown in Figure 13. The network model is a behavior with an inter18
Name PE IP ADAPTER
Description Name of the communication adapter for IPs
Type Figure 14
Default –
Table 22: PE network model annotations. or cycle-accurate RTL model (see Section 3.5.2) for the IP in a bottom up manner (Figure 15(b)). In all cases, the network model has two ports that can be connected (in the actual design) to two logical link channels for sending and receiving data over the network. Note that the as part of communication refinement in the network model, the three original message-passing ports from the IP’s high-level behavioral model (Section 3.1.5) are implemented over two logical links only at the network level. Finally, the network model provides a pointer to its IP adapter IP Net Adapter that implements the network drivers for communication with the IP (see Section 3.3.2). Corresponding to the list of ports in the IP’s high-level behavioral model (see Listing 6), the adapter exports three matching instances “cmd input”, “data input” and “data output” of internal channels (see Listing 11).
1 import ” I P ” ; 2
3 behavior IP Net ( i r e c e i v e r
input , i sender output )
4 5 { 6 7 8
n o t e PE IP ADAPTER = { ” I P N e t A d a p t e r ” , { ” cmd input ” , ” d a t a i n p u t ” , ” d a t a o u t p u t ” } };
9
I P I n t R e c e i v e r cmd ( i n p u t ) ; IP Int Receiver data in ( input ); data out ( output ) ; IP Int Sender
10 11 12 13
I P i p ( cmd , d a t a i n , d a t a o u t ) ;
14 15
v o i d main ( v o i d ) { i p . main ( ) ; }
16 17 18 19 } ;
3.3.2
Network Adapters
IP network adapters are SpecC channel definitions with an internal body as shown in Figure 16. The name of the channel defines the name of the adapter and has to match the corresponding annotation at the PE network model (see Section 3.3.1, PE IP ADAPTER annotation). Network adapter channels have a list of ports of interface type that has to match the list of ports in the IP network model (i.e. similar restrictions on port and interface types apply in general). Number, order and types of ports have to match with reversed directions such that the two can be connected and communicate via a set of logical link channels to be inserted in between when instantiating them (as indicated by the dashed channel in Figure 15). Internally, network adapter channels describe the implementation of high-level IP communication by mapping messages down to a proper sequence of link transfer over the adapter’s ports. IP communication can be described directly in the body of the adapter or hierarchically through a stack of other adapter channel instances. However, at the highest-level, network IP adapters have to contain instances of adapter channels that export interfaces providing message-passing communication with the IP equivalent to the set of ports in the behavioral IP model (Section 3.1.5). For every port in the behavioral model, the IP network adapter has to export a corresponding channel (via the PE IP ADAPTER annotation at the network model behavior, see Table 22) that implements an interface which matches the interface for connection and communi-
Listing 10: Example of PE network model for simple IP. network model through the adapter. Entries in the list have to match names of channels instantiated inside the adapter. The list of channels has to be an exact match with the list of ports in the behavioral model of the IP (Section 3.1.5) in terms of number, order and interface type provided An example of a network model for the previously introduced IP (behavioral model from Listing 6, Figure 9), is shown in Figure 15(a) and Listing 10. In this example, the body of the network model is built by internally instantiating and executing the high-level behavioral model of the IP (see Section 3.1.5). On top of the behavioral model, the network model implements the necessary refinement of IP communication via a set of adapter channel instances. These adapter channels implement the IP’s network interface and they perform the necessary data formatting between the network links and the high-level messagepassing interface of the behavioral model. Wrapping around the IP’s high-level behavioral model ensures that the network model provides the same computation functionality. In general, however, a PE network model can be implemented in any desired way. Apart from implementing a dedicated network model from scratch, the database can, for example, contain a network model that wraps around an existing bus-functional (see Section 3.4.2) 19
net_adapter_channel = channel pe_net_adapter_name ports interfaces_opt ’{’ internal_definitions_opt ’}’ ’;’ ports =
IP_Net_Adapter
| ’(’ ’)’ | ’(’ channel_port_list ’)’
channel_port_list = channel_port | channel_port_list ’,’ channel_port channel_port = interface_name | interface_name port_name
_PE_IP_ADAPTER _PE_IP_ADAPTER
IP
interfaces_opt = | implements interface_list
Figure 16: Format of network model adapters.
IP_Net
cation with the behavioral port. As shown in Figure 15, the combination of IP network model plus IP network adapter has to be a drop-in replacement for the IP’s behavioral model, i.e. without modifications in the high-level application, it can communicate with the IP network model through the network adapter. Again, note that even though all network-level IP communication is performed over two logical links only, the IP adapter exports three channels matching the three ports in the IP’s behavioral model. The necessary multiplexing and de-multiplexing is performed as part of the IP adapter and the IP network model wrapper, respectively. Listing 11 shows the code for the network adapter of this simple IP example. The adapter connects to the IP through input and output links. Internally, the adapter implements high-level IP communication via a set of adapter channel instances that perform the necessary data formatting to translate from high-level application messages to untyped link transfers over the adapter’s ports. As indicated by the PE IP ADAPTER annotation at the network model (see Listing 10), the adapter exports three channel instances cmd input, data input and data output corresponding to the three message-passing ports of the behavioral IP model (see Listing 6).
(a) Refined behavioral model
IP_Net_Adapter
_PE_IP_ADAPTER _PE_IP_ADAPTER
IP_Net
IP_BF / IP_CA
(b) Wrapped pin-accurate model
Figure 15: Example of IP network model.
3.4
Bus-Functional PE Models
For PEs with fixed, pre-defined interfaces and communication functionality, the PE database has to contain a busfunctional model of the PE. A bus-functional PE model 20
to the IP’s behavioral model (see Section 3.1.5). For programmable PEs with flexible computation behavior (i.e. no functionality provided in the PE behavior, Section 3.1.5) but fixed, pre-defined interfaces and communication functionality, the bus-functional PE model has to provide a hierarchy with at least two layers: a top-level bus-functional layer describing the PE pin interface on the outside and an internal empty hardware abstraction layer (HAL) at the leaf of the bus-functional model hierarchy describing the interface for accessing the PE’s communication implementation from the programmable computation on the inside (Section 3.4.3). A PE is considered programmable in terms of its computation if the bus-functional PE model provides a hardware abstraction layer (HAL). As part of the design process, communication synthesis will use the HAL of the bus-functional PE model as a template and modify it to implement computation on the PE on top of the services provided by the HAL model. In terms of services, the HAL defines the insertion point for implementing the PE’s computation and it provides communication services for stream and memory I/O and interrupt handling. The HAL together with the outer bus-functional layers model the corresponding capabilities of the pre-defined PE implementation (e.g. number and type of external interfaces, amount and level of interrupts, etc.). The HAL marks the boundary between hardware and software in programmable PEs. SpecC code for the HAL and the subbehavior hierarchy inserted into the HAL will later be implemented in software. On top of an implementation of the HAL on the target processor taken out of the OS databases, target-specific code will be generated for the HAL model. Layers of the PE model above up to and including the bus-functional layer represent the hardware implementation of the PE and will later be replaced with a description of the real PE hardware taken out of the databases for manufacturing. If no hardware abstraction layer is provided, on the other hand, the bus-functional PE model is considered to be a self-contained simulation model of the complete PE including computation and communication that will be plugged into the system simulation as is.
1 import ” I P ” ; 2
3 channel I P N e t A d a p t e r ( i s e n d e r
input , i r e c e i v e r output ) implements I I P N e t A d a p t e r
4 5 6 {
IP Int Sender cmd input ( input ) ; IP Int Sender data input ( input ); IP Int Receiver data output ( output ) ;
7 8 9 10
void send cmd input ( i n t i n p u t ) { cmd input . send ( i n p u t ) ; } void s e n d d a t a i n p u t ( i n t i n p u t ) { d a t a i n p u t . send ( i n p u t ) ; }
11 12 13 14 15 16 17
void r e c e i v e o u t p u t ( i n t ∗ o u t p u t ) { data output . receive ( output ) ; }
18 19 20 21 } ;
Listing 11: Example of IP network adapter. accurately describes the PE interface at the pin-level and it provides a simulation-model of the PE’s communication aspects on top of any computation functionality as defined by the PE’s behavioral model, if any (see Section 3.1). Bus-functional models can be thought of as additional communication layers that wrap around the PE behavioral or OS model. A bus-functional model can consist of several layers of behaviors that create a hierarchy or tree of behavior instantiations. At minimum, a top-level busfunctional layer has to exist that provides a pin-accurate model of the PE. Through this layer and its optional sublayer instance hierarchy, the bus-functional PE model describes the communication behavior of the PE at its pins and it has to provide the same computational functionality as the PE’s behavioral model. For bus-functional models, we can distinguish two types of components that both have fixed communication interfaces: fully pre-defined IP components and programmable PEs with flexible computation. For IPs, both computation and communication functionality is fixed. The busfunctional mode of an IP provides a timing- and dataaccurate descriptions in terms of signals and values that can be observed at the PE’s pins. Bus-functional IP models only have to provide a single bus-functional layer but they can consist of several hierarchical layers internally (Section 3.4.1). However, bus-functional IP models need to supply an adapter that wraps and abstracts communication with the IP up to the message-passing level equivalent
3.4.1
Bus-Functional Layer
The general format of bus-functional PE models is shown in Figure 17. The outer bus-functional layer is given as a SpecC behavior definition with an internal or external body, i.e. for IPs the body can be supplied as an external library in the same manner as for the behavioral PE model (Section 3.1.5). The name of the bus-functional layer behavior defines the name of the bus-functional PE model and has to match the corresponding annotation at the PE 21
bf_bus = ’{’ bus_list ’}’ bus_list = interface | bus_list ’,’ interface interface = ’{’ inst_name ’,’ port_name ’,’ protocol ’}’ protocol = protocol_name | ’{’ protocol_name_list ’}’
bf_behavior = behavior pe_bf_name pins body_opt ’;’ pins =
protocol_name_list = protocol_name | protocol_name_list ’,’ protocol_name
’(’ pin_list ’)’
pin_list = pin | pin_list ’,’ pin pin =
Figure 18: Format of bus-functional PE BF BUS annotations.
behavior (see Section 3.1.1, PE BF MODEL annotation). pin_direction signal bit_sign bit_vector pin_name Finally, bus-functional PE behaviors have to have a list of ports of bitvector signal type representing the pins of the PE. Bus-functional PE behaviors have a set of general purpose annotations for database and design flow management (Table 23):
pin_direction = | in | out | inout
PE IP ADAPTER Names of the channels providing the adapter wrapping the protocol stack for communication with IP network models. See Section 3.4.2.
bit_sign = | signed | unsigned
The format of the annotation is shown in Figure 14. A bus-functional adapter is defined by its name and a list bit_vector = bit ’[’ const_expression ’:’ const_expression ’]’of channels it provides for communication with the IP. The name of the adapter is the name of a channel | bit ’[’ const_expression ’]’ that has to exist in the database. The named adapter body_opt = channel has to have a matching set of ports that al low a direct connection between adapter and the bus| ’{’ internal_definitions_opt ’}’ functional PE model. The adapter has to provide a list of channels that allow external network-level communication with the bus-functional IP through the adapter. Entries in the list have to match names of channels instantiated inside the adapter. The list of channels has to be an exact match with the list of ports in the network model of the IP (Section 3.3) in terms of number, order and interface type provided.
Figure 17: Format of bus-functional PE models.
PE HAL MODEL Name of the behavior providing the hardware abstraction layer (HAL) for the busfunctional PE model (see Section 3.4.3). Required for programmable PEs with flexible computation. The 22
Name PE IP ADAPTER PE HAL MODEL PE INT HANDLER PE BF BUS
Description Name of the communication adapter for IPs Name of PE hardware abstraction layer (HAL) model Name of HAL interrupt handler method for an interrupt pin List of internal bus protocol instances
Type Figure 14 String String Figure 18
Default – – – –
Table 23: Bus-functional PE model annotations. named behavior has to exist in the PE database. The HAL behavior has to be instantiated as a leaf in the tree of subbehaviors of the bus-functional PE model.
of the system, the model provides a bus-functional layer with an internal body that implements the IP’s communication and computation functionality. Communication is modeled accurately through an instance of the IP bus protocol from the bus database. When composing the system, the bus-functional IP model connects to the bus corresponding to port “port1” (defined in the behavioral IP model) as slave type through its internal bus protocol instance. In this example, the IP is modeled by instantiating and refining the mid-level network model of the IP (see Section 3.3) in a wrapper that implements the necessary additional communication details, as described above. Therefore, it is ensured that the model provides the same computation functionality as its network model. In general, however, a bus-functional PE model can be implemented in any desired way. Apart from implementing a dedicated bus-functional model from scratch, the database can, for example, contain a bus-functional model that wraps around an existing cycle-accurate RTL model (see Section 3.5.2) in a bottom up manner (Figure 19). Apart from the bus-functional layer itself, the IP shown in the example comes with a bus-functional adapter channel IP BF Adapter that implements the bus drivers for communication with the IP (see Section 3.4.2). Corresponding to the list of ports in the IP’s network model (see Listing 10), the adapter exports two matching channels. Note that in this case, both exported channel connections map down to and are implemented by the same channel instance “ipdrv” in the IP adapter (i.e. all links for communication with the IP are implemented by and go through the same “ipdrv”, see Listing 13 in Section 3.4.2).
PE INT HANDLER Name of the method in the HAL behavior that acts as the interrupt handler for the interrupt pin the annotation is attached to. See Section 3.4.3. PE BF BUS List of bus interface instances used inside the bus-functional PE model. Internally, pins of a busfunctional PE model are only allowed to be accessed by and connected to instances of bus protocol implementations/models from the bus database. Furthermore, every pin has to eventually be connected to at least one such protocol instance. Inside the hierarchy of bus-functional PE model behaviors, the annotation has to be attached to all behaviors that are endpoints for pins of the PE. For each such behavior, the annotation has to provide a list of all protocol implementations from the bus database instantiated inside that behavior. The format of the annotation is shown in Figure 18. For each instance, its name, the name of the logical port it belongs to, and the name of a corresponding protocol instance in the bus database (defining the connectivity of pins to bus wires) has to be given. The logical port name has to match a port name defined in the behavioral PE model ( PE BF BUS annotation, see Section 3.1.1). The logical port in the behavioral PE model defines a corresponding bus, and bus database protocol instance names and types in the annotation have to match names and types defined in the bus database for that bus (see BUS PROTOCOL annotations, Section 5.1.1). A reference to a bus database protocol instance can either be given as a specific name or as a list of names to select from in case the PE can be connected in either of those ways shown in the bus database.
3.4.2
IP Adapters
For IP PEs with fixed computation and communication functionality (see also Section 3.1.5 and Section 3.3), communication with the IP can generally not be synthesized arbitrarily but has to adhere to the proprietary IP protocol on all levels. Apart from the IP bus model that describes the lower layers of IP communication in the bus protocol database, bus-functional IP models therefore need to supply a complete protocol stack in the form of an IP adapter that covers communication with the IP from the network
An example of a simple bus-functional PE model for the previously introduced IP (behavioral and network PE models from Listing 6, Figure 9 and Listing 10, Figure 15, respectively) is shown in Listing 12. To supply an accurate simulation model of the IP for co-simulation with the rest 23
1 import ” I P B u s ” ; 2 import ” I P N e t ” ;
3
/ / IP b u s / / IP n e t w o r k model
4 b e h a v i o r IP BF ( i n
signal bit [1] ready , out s i g n a l b i t [ 1 ] ack , signal bit [31:0] dat )
5 6 7 { 8 9
note note
10
};
11
PE BF BUS = { { ” b u s ” , ” p o r t 1 ” , ” s l a v e ” } } ; PE IP ADAPTER = { ” I P B F A d a p t e r ” , { ” ipdrv ” , ” ipdrv ” }
12 13 14
I P B u s S l a v e b u s ( r e a d y , ack , d a t ) ; s l a v e i f ( bus ) ; IP SlaveIO
/ / IP p r o t o c o l / / IP i n t e r f a c e
IP Net ipnet ( s l a v e i f , s l a v e i f ) ;
/ / IP n e t w o r k model
15 16 17
v o i d main ( v o i d ) { i p n e t . main ( ) ; }
18 19 20 21 } ;
Listing 12: Example of bus-functional PE model for simple IP. link level down to the pins of the IP bus.
in the high-level application, the application can communicate with the low-level bus-functional IP through network and bus-functional adapters. During the design process, IP adapters will be inlined into all components communicating with the IP. There, they will become the drivers and interfaces for communication with the IP over the pins and wires of the busses or other media. Internally, adapter channels describe the implementation of IP communication by mapping each message and then link transfer down to its proper sequence of events on the IP bus wires for transferring data, synchronization, etc. IP communication can be described directly in the body of the adapter or hierarchically through a stack of other adapter channel instances. However, in bus-functional IP adapters, the lowest level of communication, the IP bus protocol itself, has to be implemented using the IP bus protocol models out of the bus database. For this purpose, bus-functional IP adapters have a set of general purpose annotations for corresponding database and design flow management (Table 24):
Bus-functional IP adapters are SpecC channel definitions with an internal body as shown in Figure 20. The name of the channel defines the name of the adapter and has to match the corresponding annotation at the bus-functional PE model (see Section 3.4.1, PE IP ADAPTER annotation). On the one side, adapter channels connect to the IP through their list of ports of bitvector signal type that has to match the list of wires in the IP bus and hence the list of IP pins with reversed directions. On the other side, adapter channels export interfaces that provide logical link communication with the IP equivalent to the set of links connecting to the IP network model (Section 3.3.1). For every port in the IP network model, the bus-functional IP adapter has to export a corresponding channel (via the PE IP ADAPTER annotation at the bus-functional behavior, see Table 23) that implements an interface which matches the interface of a channel connecting to and communicating with the IP network port. As shown in Figure 19, the combination of busfunctional IP model plus bus-functional IP adapter has to be a drop-in replacement for the IP’s network model. Consequently, the combination of bus-functional model and adapter can be directly connected to the IP’s network adapter (see Section 3.3.2). All together, bus-functional model plus adapters implements a drop-in replace for the high-level behavioral IP model, i.e. without modifications
PE BF BUS List of bus interface instances used inside the bus-functional IP adapter. Internally, pins of a bus-functional IP adapters are only allowed to be accessed by and connected to instances of bus protocol implementations/models from the bus database. Furthermore, every pin has to be connected to at least one such protocol instance. The annotation has to provide a list of all protocol implementations from the 24
Name PE BF BUS
Description List of internal bus protocol instances
Type Figure 18
Default –
Table 24: Bus-functional IP adapter annotations. of a handler has to match the corresponding annotation attached to the interrupt pin in the bus-functional layer (see Section 3.4.1, PE INT HANDLER annotation). Finally, the HAL model has to provide access to the PE’s communication services for use by the code that will be inserted in the design process . The bus-functional layer the HAL model is part of defines the protocol in the bus database that is used by the PE for external communication (see Section 3.4.1, PE BF BUS annotation). The HAL then has to make all the high-level interfaces at the top of the protocol stack available (i.e. data link and memory access interfaces, see Chapter 5.4). Depending on the boundaries between hardware and software in the PE, interfaces can be made available either as ports of the HAL model of corresponding interface type or by instantiating part or all of the protocol stack channels inside the HAL model. In either case, all bus communication available inside the HAL is eventually mapped to transactions on the PE pins through the hierarchy of layers of the bus-functional PE model. An example of a bus-functional PE model for a programmable CPU is depicted in Figure 22. The figure shows an example that includes all possible parts that a busfunctional model, specifically for programmable PEs, can have and that will be described in detail in the following sections. In its outermost bus-functional layer MyCPU BF (Section 3.4.1) it encapsulates a model MyCPU HW of the CPU core including hardware abstraction layer MyCPU HAL (Section 3.4.3), a model of the interrupt controller MyCPU IC including interrupt handling in the core and in the HAL (Section 3.4.4), and a model of a built-in arbiter MyCPU Arbiter (Section 3.4.5). As shown in the figure, the model can optionally have extra layers to further encapsulate arbiter and HW core, for example. Finally, the figure also shows the different annotations attached to the different parts of the model. For each annotation, the target it points to is indicated. On the other hand, the code for an example of a minimal programmable PE (without arbiter or interrupt controller) is shown in Listing 14. In this case, the bus-functional PE model only consists of a hardware abstraction layer (Listing 14(a)) and an outer bus-functional layer (Listing 14(b)). The HAL model (Listing 14(a)) imports the PE’s external bus protocol out of the bus database in oder to instantiate its data link layer channel. The data link layer channel communicates with the lower layers of the bus protocol stack through a corresponding port of the HAL model. As
bus database instantiated inside that adapter. The format and explanation of the annotation are the same as for the PE BF BUS annotation the the bus-functional layer (see Figure 18 and Section 3.4.1). An example of a bus-functional IP adapter for communication with the IP introduced in Listing 12 is shown in Listing 13. The adapter connects to the IP bus through Addr, Data, and Ctrl ports. Internally, the adapter implements IP communication via a stack of bus interface and bus protocol adapter channel instances. The IP bus protocol instance bus (of type IP Bus Master corresponding to a “master” type connection to port “port1” of the PE, as defined in the behavioral IP model) drives and samples the bus wires according to the IP protocol to exchange data and synchronize with the IP. On top of the bus protocol, the ipdrv instance implements the state machines for implementation of all link-level IP communication. As indicated by the PE IP ADAPTER annotation at the bus-functional model (see Listing 12), both of the two links going in and out of the IP at the network level (corresponding to the input and output ports of the IP’s network model, see Listing 10) are implemented by this ipdrv instance. 3.4.3
Hardware Abstraction Layer
The general format of the hardware abstraction layer (HAL) for bus-functional PE models is shown in Figure 21. The HAL is a SpecC behavior definition whose name defines the name of the HAL model and has to match the corresponding annotation at the high-level PE behavior (see Section 3.1.1, PE HAL MODEL annotation). A HAL model generally has ports and implements interfaces to communication with the outer layers of the bus-functional PE model. In particular, the HAL layer implements an interface that makes its interrupt handler methods public in order for them to be invoked by the outer layers as required. The HAL model has to provide an internal SpecC body that acts as a template to be filled later. It has to contain exactly one main method (required by SpecC) that is empty. Furthermore, the HAL model has to define empty interrupt handler methods that are called by the outer layers of the bus-functional model whenever an interrupt is detected on one of the PE’s interrupt pins. If the PE’s interrupt pin has a bit width greater than one, the corresponding handler has to have one unsigned integer argument which gets assigned the index of the detected interrupt when being called by the PE’s interrupt model (see Section 3.4.4). The name 25
1 import ” I P B u s ” ; 2
3 channel IP BF Adapter ( out s i g n a l
bit [1] ready , signal bit [1] ack , signal bit [31:0] dat ) implements I I P B F A d a p t e r in
4 5 6 7 {
note
8
PE BF BUS = { { ” b u s ” , ” p o r t 1 ” , ” m a s t e r ” } } ;
9
/ / IP p r o t o c o l / / IP d r i v e r
I P B u s M a s t e r b u s ( r e a d y , ack , d a t ) ; IP MasterIO i p d r v ( bus ) ;
10 11 12
v o i d s e n d i n p u t ( c o n s t v o i d ∗d , u n s i g n e d l o n g l ) { i p d r v . send ( d , l ) ; }
13 14 15 16
v o i d r e c e i v e o u t p u t ( v o i d ∗d , u n s i g n e d l o n g l ) { ipdrv . receive (d , l ) ; }
17 18 19 20 } ;
Listing 13: Example of bus-functional IP adapter model.
_PE_HAL_MODEL _PE_HAL_MODEL
BusWrap
MyCPU_Bus_Arbiter
_PE_BF_BUS _PE_BF_BUS
MyCPU_Bus_Slave
Intr. logic Int
Ctrl Detect
MyCPU_IC
My_CPU_BF Figure 22: Example of bus-functional CPU model.
26
intA intB
_PE_INT_HANDLER _PE_INT_HANDLER
MyCPU_HW
intNHdlr
_CE_ARBITER _CE_ARBITER
MyCPU_Arbiter _CE_BF_BUS _CE_BF_BUS
Flag[6]
intAHdlr
Int_Mask
MyCPU_Bus_MAC
MyCPU_HAL
MyCPU_Bus_Master
_PE_BF_BUS _PE_BF_BUS
intN
1 import ” MyDSP Bus ” ;
/ / bus p r o t o c o l
2
3 interface 4 5 };
IMyDSP IntHandlers { void i n t H a n d l e r ( void ) ;
6
7 b e h a v i o r MyDSP HAL ( IMyDSP Bus Master p r o t o c o l )
implements I M y D S P I n t H a n d l e r s
8 9 {
MyDSP Bus MasterLink l i n k ( p r o t o c o l ) ; MyDSP Bus MasterMem mem( p r o t o c o l ) ;
10 11 12
/ / bus data stream / / b u s memory a c c e s s
void i n t H a n d l e r ( void ) { }
13 14 15
v o i d main ( v o i d ) { }
16 17 18 } ;
(a) Hardware abstraction layer (HAL)
Listing 14: Example of bus-functional model for programmable PE. required, the HAL model contains an empty main method and it provides a single interrupt handler intHandler that is made public through the HAL’s implemented interface. The top-level bus-functional layer (Listing 14(b)) then imports the HAL model and the bus-functional behavior MyDSP BF instantiates the HAL behavior (line 22) and provides a pointer to the HAL model through the corresponding annotation (line 18). Inside the bus-functional behavior’s main method, the HAL model is executed in a try-interrupt construct that models the interrupt control logic of the PE’s hardware. Normal execution of the HAL is interrupted and the HAL’s interrupt handler method is invoked whenever an interrupt (rising edge) on the PE’s interrupt pin Intr is detected. As required, the annotation at the interrupt pin points to the HAL interrupt handler to reflect that fact (line 19). Finally, the busfunctional model provides the required pointer to the PE protocol in the bus database (line 17), it instantiates the lower layer channels of the protocol stack (line 21), and it maps the bus protocol onto the HAL’s ports to complete the protocol implementation in the model. 3.4.4
ent layers of the bus-functional PE model then describe the PE’s interrupt behavior of detecting interrupts, suspending regular computation, and executing the HAL interrupt handlers during system simulation. The example of Listing 14 shows how to model such behavior for a typical simple processor core with a single interrupt condition input. In order to support more complex interrupt capabilities with more than one source of interrupts, different priorities, masking, etc., the PE database needs to include interrupt controllers as part of the bus-functional PE models. Interrupt controllers sit in front of the basic PE core model and are modeled by adding another layer to the busfunctional PE model between the processor core and the outer bus-functional layer. Typically, the interrupt controller provides a set of interrupt lines at the pins of the top-level bus-functional layer while internally communicating with the core via the PE bus and the core’s interrupt condition input. The core then interrupts normal computation and executes the appropriate handler depending on the inputs received from the interrupt controller. Overall, the combination of layers has to simulate the proper interrupt behavior while maintaining the relationship between interrupt pins at the bus-functional layer and interrupt handlers in the HAL required by the database format. An example of a bus-functional PE model for a programmable PE that includes an interrupt controller is shown in Listing 15. In contrast to the example shown previously, the hardware abstraction layer (Listing 15(a)) now contains templates for two separate interrupt handlers. In the next layer, the interrupt control logic (List-
Interrupt Handling
Bus-functional models for programmable PEs have to include a definition of the PE’s interrupt capabilities and its interrupt handling. As described previously, the top-level bus-functional layer defines the interrupt pins available at the physical PE interface and the HAL model provides corresponding empty interrupt handler templates. The differ27
1 import ”MyDSP HAL” ; 2
3 //
/ / hardware a b s t r a c t i o n l a y e r
Interrupt control logic
4 b e h a v i o r MyDSP ICL ( I M y D S P I n t H a n d l e r s h a n d l e r s ) 5 { 6 7 8
v o i d main ( v o i d ) { handlers . intHandler ( ) ; }
9 }; 10
11 / /
Bus−f u n c t i o n a l l a y e r
12 b e h a v i o r MyDSP BF ( o u t s i g n a l 13 14 15 16 { 17 18 19
bit signal bit out s i g n a l b i t in signal bit
[31:0] [31:0] [2] [1]
Addr , Data , Ctrl , Int )
n o t e PE BF BUS = { { ” b u s ” , ” p o r t A ” , ” m a s t e r ” } } ; n o t e PE HAL MODEL = ”MyDSP HAL” ; n o t e I n t . PE INT HANDLER = ” i n t H a n d l e r ” ;
20 21 22 23 24 25 26 27 28 29 30 31 32
MyDSP Bus Master b u s ( Addr , Data , C t r l ) ; MyDSP HAL h a l ( b u s ) ; MyDSP ICL i c l ( h a l ) ;
/ / bus p r o t o c o l
v o i d main ( v o i d ) { try { h a l . main ( ) ; } interrupt ( rising Int ) { i c l . main ( ) ; } }
33 } ;
(b) Bus-functional layer
Listing 14: Example of bus-functional model for programmable PE (continued).
28
1 import ” MyDSP Bus ” ;
/ / bus p r o t o c o l
2
3 interface 4 5 6 };
IMyDSP IntHandlers { void i n t A h a n d l e r ( void ) ; void i n t B h a n d l e r ( void ) ;
7
8 b e h a v i o r MyDSP HAL ( IMyDSP Bus Master p r o t o c o l )
implements I M y D S P I n t H a n d l e r s
9 10 {
MyDSP Bus MasterLink l i n k ( p r o t o c o l ) ; MyDSP Bus MemAccess mem( p r o t o c o l ) ;
11 12 13
/ / bus data l i n k a c c e s s / / b u s memory a c c e s s
void i n t A h a n d l e r ( void ) { } void i n t B h a n d l e r ( void ) { }
14 15 16 17 18
v o i d main ( v o i d ) { }
19 20 21 } ;
(a) Hardware abstraction layer (HAL)
Listing 15: Example of bus-functional model for PE with interrupt controller. ing 15(b)) that is part of the model of the processor core hardware (Listing 15(c)) is modified to communicate with the interrupt controller. The interrupt control logic is triggered to interrupt normal computation on events at the core’s interrupt condition line and busy lines (Listing 15(c), line 23). Internally, the control logic processes pending interrupts as long as the interrupt condition is active and the bus is not busy (Listing 15(b), line 24). Part of the interrupt control logic is a wrapper around the bus protocol that generates the busy signal for blocking of interrupts during bus protocol transactions (in order to maintain bus protocol timing, normal computation must not be interrupted in the middle of a bus transaction). If there is a pending interrupt, the interrupt logic communicates with the interrupt controller over the PE bus to acknowledge the interrupt and receive the interrupt vector. It then subsequently calls the corresponding interrupt handler in the HAL. Finally, in the top-level bus-functional layer of the PE model (Listing 15(d)), the processor core model and the interrupt controller model are instantiated and connected via wires and pins of the bus-functional layer. Furthermore, the appropriate annotations are attached to the interrupt pins of the bus-functional layer pointing back to the interrupt handlers in the HAL. An example of a simple interrupt controller model is shown in Listing 16. The interrupt controller (Listing 16(c)) consists of interrupt detection modules (one per
interrupt line) and a control module that communicates via an interrupt status register (ISR). The interrupt detection behaviors (Listing 16(a)) model the edge detection on the interrupt lines, setting a bit in the status register whenever an interrupt is detected. The control behavior (Listing 16(b)) watches the status register, signals interrupts to the core, and performs interrupt acknowledge cycles on the PE bus according to the priority of interrupts as long as there are interrupts pending. Note that due to the additional layer of bus-functional hierarchy needed for encapsulation of the interrupt controller, PE BF BUS annotations pointing to the bus protocol instantiations inside the bus-functional model are not attached to the outermost bus-functional layer. Instead, such annotations are attached to both the processor core and interrupt controller behaviors that instantiate the protocol implementations driving the bus-functional pins. In case of the interrupt controller model, the list of protocol instances contains both the slave data protocol instance and the interrupt detection logic instances connected to the interrupt pins. 3.4.5
Arbitration
For busses that support multiple masters on the bus via a centralized arbitration scheme (see Section 5.2.4), additional arbiter components are required as part of the over29
1 import ”MyDSP HAL” ; 2
3 //
Bus p r o t o c o l w r a p p e r
4 c h a n n e l MyDSP Bus Wrap ( IMyDSP Bus Master bus , 5 6 { 7 8 9 10 11 12 13 14
implements IMyDSP Bus Master
void r e a d ( b i t [ 3 1 : 2 ] addr , Busy = 1 ; b u s . r e a d ( a d d r , } void w r i t e ( b i t [ 3 1 : 2 ] addr , Busy = 1 ; b u s . w r i t e ( a d d r }
o u t s i g n a l b i t [ 1 ] Busy )
bit [31:0] ∗data ) { d a t a ) ; Busy = 0 ; bit [31:0] data ) { , d a t a ) ; Busy = 0 ;
i n t s n d A c k I n t r ( ) { return bus . s n d A c k I n t r ( ) ; }
15 16 } ; 17
18 / /
Interrupt control logic
19 b e h a v i o r MyDSP ICL ( IMyDSP Bus Master bus , 20 21 { 22 23 24 25 26 27 28 29 30 31
IMyDSP IntHandlers handlers , i n s i g n a l b i t [ 1 ] I n t , i n s i g n a l b i t [ 1 ] Busy )
v o i d main ( v o i d ) { unsigned b i t [ 0 : 0 ] vec ; w h i l e ( I n t && ! Busy ) { vec = bus . s n d A c k I n t r ( ) ; switch ( vec ) { case 0: return h a n d l e r s case 1: return h a n d l e r s } } }
/ / process pending i n t e r r u p t s / / acknowledge , r e c e i v e v e c t o r / / c a l l corresponding i n t e r r u p t handler . intAhandler ( ) ; . intBhandler ( ) ;
32 } ;
(b) Interrupt control logic
Listing 15: Example of bus-functional model for PE with interrupt controller (continued).
30
1 import ”MyDSP HAL” ;
/ / hardware a b s t r a c t i o n l a y e r / / interrupt control logic
2 import ”MyDSP ICL” ; 3
4 //
Processor core
5 b e h a v i o r MyDSP HW( o u t s i g n a l
6 7
in
8 9 { 10 11 12
note
bit signal bit signal bit signal bit
[31:0] [31:0] [2] [1]
Addr , Data , Ctrl , Int )
PE BF BUS = { { ” b u s ” , ” p o r t A ” , ” m a s t e r ” } } ;
s i g n a l b i t [ 1 ] Busy = 0 ;
13 14 15 16 17 18 19 20 21 22 23 24 25 26
MyDSP Bus Master b u s ( Addr , Data , C t r l ) ; MyDSP Bus Wrap wrap ( bus , Busy ) ; MyDSP HAL h a l ( wrap ) ; MyDSP ICL i c l ( wrap , h a l , I n t , Busy ) ;
/ / bus p r o t o c o l
v o i d main ( v o i d ) { try { h a l . main ( ) ; } i n t e r r u p t ( I n t , Busy ) { i c l . main ( ) ; } }
27 } ;
(c) Processor core
Listing 15: Example of bus-functional model for PE with interrupt controller (continued).
31
1 import ”MyDSP HW” ;
/ / processor core // interrupt controller
2 import ” MyDSP IC ” ; 3
4 b e h a v i o r MyDSP BF ( 5 6 7 8 9 { 10 11 12 13 14
in in
signal signal signal signal signal
bit bit bit bit bit
[31:0] [31:0] [2] [1] [1]
Addr , Data , Ctrl , intA , intB )
16 18 19 20 21 22 23 24
//
interrupts
n o t e PE HAL MODEL = ”MyDSP HAL” ; n o t e i n t A . PE INT HANDLER = ” i n t A h a n d l e r ” ; n o t e i n t B . PE INT HANDLER = ” i n t B h a n d l e r ” ; signal bit [1] Int = 0;
// interrupt line
MyDSP HW hw ( Addr , Data , C t r l , I n t ) ; MyDSP IC i c ( Addr , Data , C t r l , I n t , i n t A , i n t B ) ;
/ / processor core // interrupt ctrl
15 17
/ / bus
v o i d main ( v o i d ) { par { hw . main ( ) ; i c . main ( ) ; } }
25 } ;
(d) Bus-functional layer
Listing 15: Example of bus-functional model for PE with interrupt controller (continued).
32
1 import ” MyDSP Bus Int ” ;
/ / bus i n t e r r u p t p r o t o c o l
2
3 b e h a v i o r MyDSP ICDetect ( i r e c e i v e 4 { 5 6 7 8 9 10 11
i n t r , out s i g n a l b i t [ 1 ] f l a g )
v o i d main ( v o i d ) { while ( true ) { intr . receive ( ) ; flag = 1; } }
12 } ;
(a) Interrupt detection logic 1 import ” MyDSP Bus ” ;
/ / bus p r o t o c o l
2
3 b e h a v i o r MyDSP ICCtrl ( IMyDSP Bus Slave bus ,
out s i g n a l b i t [ 1 ] I n t )
4 5 { 6 7 8
v o i d main ( v o i d ) { while ( true ) { w h i l e ( ! ISR ) w a i t ( ISR ) ;
9
Int = 1; i f ( ISR [ 0 ] ) bus . r c v A c k I n t r ( 0 ) ; e l s e i f ( ISR [ 1 ] ) bus . r c v A c k I n t r ( 1 ) ; Int = 0;
10 11 12 13 14 15 16 17
s i g n a l b i t [ 2 ] ISR ,
/ / wait for i n t e r r u p t / / signal interrupt condition / / wait f o r acknowledge . . . / / . . . and s e n d v e c t o r / / reset interrupt condition
} }
18 } ;
(b) Control logic
Listing 16: Example of interrupt controller model.
33
1 import ” MyDSP Bus ” ;
/ / bus p r o t o c o l
2
3 import ” MyDSP ICDetect ” ;
// detection logic // controller
4 import ” MyDSP ICCtrl ” ;
5
6 b e h a v i o r MyDSP IC ( i n 7 8 9 10 11 12 { 13 14 15 16 17
signal signal in signal out s i g n a l in signal in signal
bit bit bit bit bit bit
[31:0] [31:0] [2] [1] [1] [1]
Addr , Data , Ctrl , Int , intA , intB )
19 21 22 23 25
/ / bus p r o t o c o l / / interrupt protocol
s i g n a l b i t [ 2 ] ISR = 0 ;
// status register
MyDSP ICDetect i n t A d e t e c t ( d e t e c t A , ISR [ 0 ] ) ; MyDSP ICDetect i n t B d e t e c t ( d e t e c t B , ISR [ 1 ] ) ;
// detection logic
MyDSP ICCtrl c t r l ( bus , ISR , I n t ) ;
/ / control
27 28 29 30 31 32 33 34 35 36
interrupts
MyDSP Bus Slave b u s ( Addr , Data , C t r l ) ; MyDSP Bus IntDetect detectA ( intA ) ; MyDSP Bus IntDetect d e t e c t B ( intB ) ;
24 26
//
n o t e PE BF BUS = { { ” bus ” , ” portA ” , ” s l a v e ” } , { ” detectA ” , ” portA ” , ” masterIntA ” } , { ” detectB ” , ” portA ” , ” masterIntB ” } };
18 20
/ / PE b u s
v o i d main ( v o i d ) { par { c t r l . main ( ) ; i n t A d e t e c t . main ( ) ; i n t B d e t e c t . main ( ) ; } }
37 } ;
(c) Interrupt controller model
Listing 16: Example of interrupt controller model (continued).
34
bf_adapter_channel = channel pe_bf_adapter_name pins interfaces_opt ’{’ internal_definitions_opt ’}’ ’;’
IP_Net_Adapter
pins =
IP_BF_Adapter
_PE_BF_BUS _PE_BF_BUS
’(’ pin_list ’)’
pin_list = pin | pin_list ’,’ pin pin =
_PE_IP_ADAPTER _PE_IP_ADAPTER _PE_BF_BUS _PE_BF_BUS
pin_direction signal bit_sign bit_vector pin_name
pin_direction = | in | out | inout bit_sign = | signed | unsigned
IP_Net IP_BF
bit_vector = bit ’[’ const_expression ’:’ const_expression ’]’ | bit ’[’ const_expression ’]’
(a) Refined network model
IP_Net_Adapter
Figure 20: Format of bus-functional IP adapters.
IP_BF_Adapter
hal_behavior = behavior pe_hal_name port_list_opt implements_interface_opt ’{’ hal_body_list ’}’ ’;’
_PE_BF_BUS _PE_BF_BUS
hal_body_list = hal_body | hal_body_list hal_body
_PE_IP_ADAPTER _PE_IP_ADAPTER _PE_BF_BUS _PE_BF_BUS
hal_body = note_definition | protocol_channel_instance | interrupt_handler_method | hal_main_method
IP_RTL
interrupt_handler_method = void handler_name ’(’ void ’)’ ’{’ ’}’ | void handler_name ’(’ unsigned ’)’ ’{’ ’}’
IP_BF (b) Wrapped RTL model
hal_main_method = void main ’(’ void ’)’ ’{’ ’}’
Figure 19: Example of bus-functional IP model.
Figure 21: Format of hardware abstraction layer (HAL) for bus-functional PE models. 35
all system architecture. In the databases, such centralized arbiters are part of bus-functional PE models as required. Logically, arbiters are considered communication elements (CEs) and as such their format has to conform to the general format of bus-functional CE models (see Section 4.2). In the case of arbiters as part of bus-functional PE models, specifically the CE ARBITER annotation has to be attached and true. Generally, arbiters can be included in bus-functional models for programmable PEs (CPUs). If a CPU drives a bus that requires a centralized arbiter, the CPU’s busfunctional model has to included a corresponding arbiter model. Typically, arbiters are part of the additional busfunctional layer needed for interrupt handling, and they are instantiated in that layer next to the CPU’s interrupt controller model. Arbiters then connect to the arbitration wires both for the internal CPU core and for other externally supported bus masters. Listing 17 shows an example of such a CPU model with integrated arbiter. The CPU’s external bus interface includes request and grant pins for connection of an external bus masters. These external arbitration lines and the internal arbitration signals coming from the CPU core itself connect to the instance of the CPU bus arbiter. The arbiter is instantiated next to and runs in parallel with the CPU hardware core and interrupt controller models. Internally, the arbiter (Listing 18) then contains the required instances and corresponding annotations of bus arbitration protocol implementations (from the bus database) that connect to the CPU’s arbitration pins. The arbiter model then uses these protocol instances to grant and release bus requests depending on its internal arbitration algorithm. Note that arbiter models and protocols are a special case in the sense that, aside from the arbitration protocol instances, the arbiter model can internally access arbitration pins and wires arbitrarily. Nevertheless, each arbitration pin has to be connected to at least one protocol instance.
1 import ” MyCPU Bus Arbiter ” ; 2
3 b e h a v i o r MyCPU Arbiter ( i n 4 5
s i g n a l b i t [ 1 ] Request ,
6 7 { 8 9 10 11 12 13
Cycle-Accurate PE Models
out s i g n a l b i t [ 1 ] Grant )
CE ARBITER = t r u e ;
n o t e CE BF BUS = { { ”m1” , ” p o r t A ” , ” a r b i t e r 0 ” } , { ”m2” , ” p o r t A ” , ” a r b i t e r 1 ” } };
14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
3.5
note
s i g n a l b i t [ 1 ] Req , o u t s i g n a l b i t [ 1 ] Gnt , in
32
MyCPU Bus Arbiter m1 ( Req , Gnt ) ; MyCPU Bus Arbiter m2 ( R e q u e s t , G r a n t ) ; v o i d main ( v o i d ) { while ( true ) { i f ( Req ) { m1 . g r a n t ( ) ; m1 . r e l e a s e ( ) ; } e l s e i f ( Request ) { m2 . g r a n t ( ) ; m2 . r e l e a s e ( ) ; } else { w h i l e ( ! Req && ! R e q u e s t ) w a i t ( r i s i n g Req , r i s i n g R e q u e s t ) ; } } }
33 } ;
For PEs with fixed functionality (i.e. programmable PEs with fixed communication functionality or IPs with fixed computation and communication functionality) the PE database has to contain a cycle-accurate implementation model of the PE in addition to the (mandatory in those cases) bus-functional PE model. At its interface, a cycleaccurate model has to match exactly the interface of its corresponding bus-functional model. Hence, a cycle-accurate model is a SpecC behavior with ports of signal bitvector type representing pins and the general format of cycleaccurate models is the same as for bus-functional models
Listing 18: Example of arbiter model.
36
1 import ”MyCPU HW” ;
/ / processor core // interrupt controller 3 import ” MyCPU Arbiter ” ; / / a r b i t e r
2 import ”MyCPU IC” ; 4
5 b e h a v i o r MyCPU BF ( 6 7 8 9 10 11 12 { 13 14 15
note
signal signal signal in signal out s i g n a l in signal in signal
bit bit bit bit bit bit bit
[31:0] [31:0] [2] [1] [1] [1] [1]
Addr , Data , Ctrl , Request , Grant , intA , intB )
17 19 20 21 22 23 24 25 26 27
// arbitration //
interrupts
PE HAL MODEL = ”MyCPU HAL” ;
s i g n a l b i t [ 1 ] I n t , Req , Gnt ;
/ / i n t e r n a l wires
MyCPU HW hw ( Addr , Data , C t r l , Req , Gnt , I n t ) ; MyCPU IC i c ( Addr , Data , C t r l , I n t , i n t A , i n t B ) ; MyCPU Arbiter a r b i t e r ( Req , Gnt , R e q u e s t , G r a n t ) ;
/ / processor core // interrupt ctrl // arbiter
16 18
/ / bus
v o i d main ( v o i d ) { par { hw . main ( ) ; i c . main ( ) ; a r b i t e r . main ( ) ; } }
28 } ;
Listing 17: Example of bus-functional model for CPU with arbiter.
37
shown in Figure 17. Directions, types, names, and order of ports have to be the same as in the corresponding busfunctional model. For cycle-accurate PEs that support both pin-accurate and transaction-level bus interfaces, pins of the cycleaccurate PE model are internally only allowed to be accessed by and connected to instances of bus protocol implementations/models from the bus database. In the same manner and format (see Figure 18) as for bus-functional models (Section 3.1.1), cycle-accurate PE models have to supply PE BF BUS annotations that provide a list of all protocol implementations from the bus database instantiated inside that model. A cycle-accurate model has to have an external or internal body providing a clock cycle accurate simulation model of the PE implementation. Therefore, compared to the bus-functional model, the pin interface is the same but the timing is refined and more accurate. For programmable PEs, the cycle-accurate model has to implement an instruction set simulation (ISS) that takes the name of the object code for the processor as a parameter and executes the instructions therein cycle by cycle. For IPs, the cycle-accurate model in SpecC has to correspond to the RTL description of the IP that has to be available in the form of synthesizable (soft core) or gate-level (hard core) HDL (e.g. VHDL or Verilog) code. 3.5.1
ISS (line 17 and line 17), the instruction set model simulates one clock cycle of the ISS (line 23) in an endless loop (line 20). In each cycle, the model drives the ISS’s asynchronous inputs (line 21) and it checks for any I/O instructions executed in the ISS. In case of external bus reads (line 25) or bus writes (line 29), the model simulates a corresponding bus cycle via calls to the PE’s bus protocol model (line 12) imported from the bus protocol database (line 3). In case of a normal processor cycle, the instruction set model simply advances time on the SpecC side corresponding to the simulated time spent in the ISS (line 33). 3.5.2
IP Models
For IPs with fixed functionality, the cycle-accurate PE model has to provide a RTL description of the IP that can be plugged into the system simulation as is. The body of the cycle-accurate PE behavior can be internal or external where parts or all of the model can be supplied as an external shared library created through the IP mechanism of the SpecC compiler (‘scc’, Section A.1). RTL descriptions for IPs in SpecC can be at any level, e.g. behavioral, FSMD-style, structural or even gate-level RTL descriptions are possible. Furthermore, if an IP model is available in the form of an external simulator that satisfies the requirements, it can be plugged in by providing a SpecC wrapper in the same manner as for ISS models described in Section 3.5.1. In any case, the PE database does not pose any restrictions on the body of cycle-accurate IP models and existing guidelines for RTL modeling can be followed freely.
Instruction Set Models
For an instruction set model, the body of the cycle-accurate PE behavior contains SpecC code that executes an instruction set simulation of the processor’s object code. The instruction set simulation reads instructions from the supplied object file and executes them cycle by cycle while simulating their effects on the pins of the PE model. Instruction set models can trade of accuracy in terms of timing observed at the PE’s pins versus simulation speed depending on the granularity of simulated cycles. Existing instruction set simulators (ISS) for PEs can be plugged into the SpecC simulation as long as they provide a C level API that allows hooks into the simulation flow to observe and manipulate the PE pins. The cycleaccurate SpecC behavior in the PE database acts as a wrapper around calls to the ISS API and gets later linked against the ISS libraries to create the co-simulation executable. The wrapper code advances simulation time and drives and samples pins on the SpecC side by controlling the ISS such that both sides can be synchronized on events at the PE pin interface. Listing 19 shows an example of such a simple SpecC instruction set model wrapper around an existing ISS for the PE example from Listing 14. After initialization of the
4 Communication Elements In a design, several different protocols may be used for inter-PEs data transfers and for PEs to communicate with the outside world. In this situation communication elements (CE) have to be used to interface different communication protocols. In SCE, we distinguish between two different kinds of CEs, namely, bridges and transducers. Bridges are simple, light-weighted communication elements used to transparently handle a transaction over two different protocols. Basically, one protocol cycle can contain the other for each data transfer between two PEs. An example is the bridge sitting between an AMBA system bus (ASB) and a peripheral bus (APB). Another example is a memory controller that interfaces between the system bus protocol and the timing diagram of the memory access. Note that a bridge is always a slave on one bus and a master on the other bus. 38
1 # include ” i s s . h”
/ / ISS C i n t e r f a c e
2
3 import ” MyDSP Bus ” ; 4
/ / bus p r o t o c o l
5 b e h a v i o r MyDSP ISS ( o u t
signal inout signal inout signal in signal
6 7 8 9 { 10
note
bit bit bit bit
[31:0] [31:0] [2] [1]
Addr , Data , Ctrl , Int )
PE BF BUS = { { ” p r o t o c o l ” , ” p o r t A ” , ” m a s t e r ” } } ;
11 12 13 14 15
MyDSP Bus Master p r o t o c o l ( Addr , Data , C t r l ) ; v o i d main ( v o i d ) { bit [31:0] data ;
16 17 18 19 20 21
iss startup (); i s s l o a d ( OBJECT NAME ) ;
/ / i n i t i a l i z e ISS / / l o a d program
while ( true ) { iss intr = Int ;
/ / run s i m u l a t i o n / / d r i v e ISS i n p u t
22
iss exec ();
23 24
/ / r u n DSP c y c l e
i f ( i s s I R == MOVEM RD) { / / bus read ? p r o t o c o l . r e a d L o n g ( iss AR , &d a t a ) ; iss DR = data ; } / / bus w r i t e ? e l s e i f ( i s s I R == MOVEM WR) { p r o t o c o l . w r i t e L o n g ( iss AR , i s s D R ) ; } else { / / normal c y c l e w a i t f o r ( 1 e12 / CLOCK FREQUENCY ) ; }
25 26 27 28 29 30 31 32 33 34 35 36
/ / bus p r o t o c o l
} }
37 } ;
Listing 19: Example of instruction set simulation (ISS) PE model.
39
Transducers are used to interface two protocols that are so different that each transaction between two PEs has to be split into two sequential transactions, one on each protocol. Additional synchronization mechanisms such as interrupt or polling and additional storage may be needed to facilitate the splitting. For example, the universal-asynchronous-receiver-transmitter (UART) is a kind of transducer that interfaces between serial and parallel communication protocols. Unlike a bridge, a transducer can be a master and/or slave on either bus. In SCE, bridges are provided to designers as IP components while transducers will be automatically generated during the design process. Communication elements are represented by SpecC behaviors in the CE database. For each CE model, a corresponding behavior declaration needs to exist in the database. The CE database can contain different CE models at varying levels of abstraction corresponding to the steps in the design flow. At minimum, behavioral CE models used for CE allocation are required to exist for each CE (Section 4.1). In other words, all bridges and transducers must have their behavioral models stored in the database. In addition, bridges must also have their bus-functional models in database for use after communication synthesis (Section 4.2). The CE behavioral models provide templates that will be filled automatically during the design process.
4.1
ce_behavior = behavior ce_name ports_opt interfaces_opt body_opt ’;’ ports_opt = | ’(’ ’)’ | ’(’ channel_port_list ’)’ channel_port_list = channel_port | channel_port_list ’,’ channel_port channel_port = interface_name | interface_name port_name interfaces_opt = | implements interface_list body_opt = | ’{’ internal_declarations_opt ’}’
Figure 23: Format of CE behaviors. describe basic information about the corresponding processing element. In detail, the following annotations are supported:
CE Behaviors
CE LIBRARY Name describing the CE database the behavior is a member of. Used to distinguish between CE and other behaviors, i.e. required for CE behaviors.
Behavioral CE models are the basic models of CEs inside SCE and the CE behaviors represent the CEs available in the database. Therefore, for each CE there must be at least a behavioral model and the set of CE behaviors defines the list of CEs in the CE database. CE behaviors are used for CE allocation and they define the basic characteristics like attributes and parameters for a CE and all of its lowerlevel models. Furthermore, the SpecC code of behavioral CE models can describe high-level functional aspects of the CE in case all or part of the CE’s functionality is predefined and fixed. 4.1.1
CE CATEGORY Name of the category the CE belongs to. CE categories are mandatory and are used to classify CEs into different groups for CE allocation and selection. CE COMMENT Brief description of the CE that will be used and displayed as an aid during selection and allocation.
General Format
CE COMPONENTS List of names of actual components that are part of the platform in case of a platform CE. If the annotation does not exist, the CE is a regular component, not a platform. See Section 2.2.1.
A CE behavior is created through a special SpecC behavior declaration or definition. The format of CE behaviors is shown in Figure 23. The name of the SpecC behavior defines the name of the CE component. CE behaviors carry a number of annotations for general database management and for attributes (Section 4.1.2). Table 25 lists the general annotations that are attached to CE behaviors for database management and in order to
CE BF MODEL Name of the behavior providing a busfunctional model of the CE. The named behavior has to exist in the CE database. Required for bridges. See Section 4.2. 40
Name CE LIBRARY CE CATEGORY CE COMMENT CE COMPONENTS CE BF MODEL CE BF BUS
Description Name of parent CE database Name of CE category CE description List of components for platform CE Name of bus-functional CE model Name(s) of the CE’s bus protocol(s) Table 25: General annotations for behavioral CE models.
ce_bus = ’{’ bus_list ’}’ bus_list = port | bus_list ’,’ port port =
’{’ port_name ’}’ | ’{’ port_name ’,’ bus_name ’}’ | ’{’ port_name ’,’ bus_name ’,’ protocols ’}’ | ’{’ port_name ’,’ bus_name ’,’ protocols ’,’ addresses ’}’
protocols = protocol | protocols ’,’ protocol protocol = protocol_name | ’{’ protocol_name_list ’}’ protocol_name_list = protocol_name | protocol_name_list ’,’ protocol_name addresses = ’{’ address_list ’}’ address_list = address | address_list ’,’ address address = address_value | ’{’ start_address ’,’ end_address ’}’
Figure 24: Format of CE behavior CE BF BUS annotations.
41
Type String String String String String String
Default – ”” ”” – – –
CE BF BUS List of logical bus ports (each representing a set of pins) for CEs with pre-defined interfaces. The format of the annotation is shown in Figure 24 (equivalent to the corresponding annotation at PE behaviors, see Figure 8). A logical port in the list is defined by its name, the name of its corresponding bus from the bus database (see Section 5.1), the name(s) of data transfer protocol instances used to connect to the bus, and an optional (range of) external bus addresses supported by the component port. Data transfer protocol instances have to match the names defined for the port’s bus in the bus database (see BUS PROTOCOL annotations, Section 5.1.1). Ports can use multiple protocol instances each (e.g. connecting as both master and slave). For each instance either a specific name or a list of possible names to select from has to be given.
Note that using adjustable attributes for these annotations will define the amount of flexibility available in the CE template. 4.1.3
bridge_interface = interface interface_name ’{’ ’}’ ’;’
Figure 25: Format of CE behavior bridge interfaces. In the behavioral model, a bridge implements a channel interface that can be called by the master PE. The bridge interface in the database has to be empty and acts as a template that will be filled as part of the design flow in SCE. See Figure 25 for the general format of bridge interface definitions where a bridge CE behavior implements such an interface. In addition, the bridge interface must have a number of general annotations for database management (Table 27):
If the annotation is not given, it is assumed that the PE’s interface can be defined freely during connectivity selection. If no bus name is given for a port, the port will be allowed to connect to any bus. Finally, if no bus protocol instances are given, the corresponding port will be allowed to connect to the given bus in any form (e.g. as any master and/or slave).
CE BRIDGE Boolean flag to distinguish bridge interfaces from other normal interfaces. True for bridge interface templates.
Note that a complete, fixed list of ports, busses, protocol instances and addresses is required for CEs that have a bus-functional model (see CE BF MODEL above). Specifically, this is the case for bridge type CEs. A bridge has to have exactly two ports (one master and one slave port) where mandatory address ranges for each port define the address mapping performed by the bridge for transfers between master and slave sides.
An example of a bridge behavior is shown in Listing 21. The bridge behavior MyBridge implements the bridge interface IMyBridge. As required, the bridge interface template is empty and has the proper annotation attached. Attached to the bridge behavior are the normal general annotations which mark the behavior as a communication behavior in the “Bridge” category, define two ports where “p1” connects to MBus as a slave with address range from 2048 through 2560, and “p2” connects to SRAM Bus as a master with address range from 0 through 1024. It also provides a bus-functional model in the form of the MyBridge BF behavior of the CE database (since the bridge has a fixed, pre-defined pin-level interface). Since the bridge does not provide any functionality, the bridge’s CE behavior has an empty main method.
Listing 20 shows an example of a simple CE behavior. The behavior defines a CE named MyCE that is part of the “communication” library and belongs to the “Transducer” category in that database. The CE has a pre-defined interface with two ports, where the “SIO” port connects to a serial protocol RS232 from the bus database as a DCE and port “GBus” connects to a Toshiba GBus as a master. Note that a bus-functional model is not required for a transducer. 4.1.2
Bridges
4.2
Attributes
Bus-Functional CE Models
As we mentioned earlier, bridges must have their busfunctional models stored in the database. A bus-functional CE model accurately describes the CE interface at the pinlevel and it provides a simulation-model of the CE. Bus-functional models can be thought of as additional communication layers that wrap around the CE behavioral model. A bus-functional model can consist of several layers of behaviors that create a hierarchy or tree of behavior instantiations. At minimum, a top-level bus-functional
Basic characteristics and metrics of CEs are described through attribute annotations attached to the CE behaviors. Attribute annotations can be given using the format defined previously in Section 2.2. Specifically, the following attributes can be attached to CEs (Table 26): CE COST Cost of the CE. The cost unit depends on the database (e.g. price or area). 42
1 b e h a v i o r MyCE ( ) ;
2 n o t e MyCE . CE LIBRARY
= ” communication ” ;
4 n o t e MyCE . CE COMMENT
= ”UART” ; = { { ” SIO ” , ” RS232 ” , ”DCE” } , { ” GBus ” , ” T o s h i b a G B u s ” , ” m a s t e r ” } } ;
3 n o t e MyCE . CE CATEGORY = ” T r a n s d u c e r ” ; 5 n o t e MyCE . CE BF BUS 6
Listing 20: CE behavior example.
Name CE COST
Description Cost
Unit
Type double
Default 0.0
Type bool
Default false
Table 26: CE behavior attribute annotations.
Name CE BRIDGE
Description Flag for bridge interface templates Table 27: Bridge interface annotations.
1 i n t e r f a c e IMyBridge { 2 3 };
note
CE BRIDGE = t r u e ;
4
5 b e h a v i o r MyBridge ( ) 6 7 { 8 9 10 11 12 13 14 15 16
implements IMyBridge note note note note note
CE LIBRARY = 1 ; CE CATEGORY = ” B r i d g e ” ; CE BF COMMENT = ” Memory CE BF BUS = { { ” p1 ” , { ” p2 ” , CE BF MODEL = ” MyBridge
controller ”; ” GBus ” , ” s l a v e ” , { {2048 u , 2560 u}} } , ”SRAM Bus” , ” m a s t e r ” , { {0u , 1024 u}} } } ; BF ” ;
v o i d main ( v o i d ) { }
17 } ;
Listing 21: Example of CE behavior for a bridge.
43
layer has to exist that provides a pin-accurate model of the CE. Through this layer and its optional sublayer instance hierarchy, the bus-functional CE model describes the communication behavior of the CE at its pins and it has to provide the same functionality as the CE’s behavioral model.
bf_bus = ’{’ bus_list ’}’ bus_list = interface | bus_list ’,’ interface
bf_behavior = behavior ce_bf_name pins body_opt ’;’ pins =
interface = | ’{’ inst_name ’,’ port_name ’,’ protocol ’}’ protocol = protocol_name | ’{’ protocol_name_list ’}’
’(’ pin_list ’)’
pin_list = pin | pin_list ’,’ pin pin =
protocol_name_list = protocol_name | protocol_name_list ’,’ protocol_name
pin_direction signal bit_sign bit_vector pin_name
Figure 27: Format of bus-functional CE BF BUS annotations.
pin_direction = | in | out | inout
the bus-functional CE model. Internally, pins of a bus-functional CE model are only allowed to be accessed by and connected to instances of bus protocol bit_sign = implementations/models from the bus database. Fur thermore, every pin has to eventually be connected to | signed at least one such protocol instance. Inside the hierar| unsigned chy of bus-functional CE model behaviors, the annotation has to be attached to all behaviors that are endbit_vector = points for pins of the CE. For each such behavior, the bit ’[’ const_expression ’:’ const_expression ’]’ annotation has to provide a list of all protocol imple| bit ’[’ const_expression ’]’ mentations from the bus database instantiated inside that behavior. body_opt = | ’{’ internal_declarations_opt ’}’
The format of the annotation is shown in Figure 27. For each instance, its name, the name of the logical port it belongs to, and the name of a corresponding protocol instance in the bus database (defining the connectivity of pins to bus wires) has to be given. The logical port name has to match a port name defined in the behavioral CE model ( CE BF BUS annotation, see Section 4.1.1). The logical port in the behavioral CE model defines a corresponding bus, and bus database protocol instance names and types in the annotation have to match names and types defined in the bus database for that bus (see BUS PROTOCOL annotations, Section 5.1.1). A reference to a bus database protocol instance can either be given as a specific name or as a list of names to select from in case the CE can be connected in either of those ways shown in the bus database.
Figure 26: Format of bus-functional CE models. The general format of bus-functional CE models is shown in Figure 26. The outer bus-functional layer is given as a SpecC behavior definition with an internal or external body, i.e. the body can optionally be supplied as an external library. The name of the bus-functional layer behavior defines the name of the bus-functional CE model and has to match the corresponding annotation at the CE behavior (see Section 4.1.1, CE BF MODEL annotation). Finally, bus-functional CE behaviors have to have a list of ports of bitvector signal type representing the pins of the CE. Bus-functional CE behaviors have a set of general purpose annotations for database and design flow management (Table 28):
CE ARBITER Boolean flag to distinguish arbiter components, which are part of CPU bus-functional models in
CE BF BUS List of bus interface instances used inside 44
Name CE BF BUS CE ARBITER
Description List of internal bus protocol instances Flag to distinguish arbiters from regular CEs
Type Figure 27 bool
Default – false
Table 28: Bus-functional CE model annotations. the PE database (see Section 3.4.5), from regular CEs, i.e. bridges and transducers. True for arbiters inside CPU models.
specific. The bus functional model uses pins and wires, whereas the TLM model uses an abstract communication. Each protocol layer can have two separate sides with different implementations for bus masters and bus slaves. The different models of the two protocol layers for bus models are stored as SpecC channels or behaviors (for passive or active protocol models, respectively). Each channel or behavior provides a protocol implementation for one single PE connected to the bus, i.e. each connected PE implements a bus protocol by creating internal instances of the required protocol models. Protocol layer models connect to the bus wires through ports of the model and pins of the PE. Higher-level models are stacked on top of each other via interfaces implemented by each model where a model calls the methods of the model beneath it via ports of corresponding interface type.
An example of a simple bus-functional CE model for a memory controller is shown in Listing 22. The model has only one top-level bus-functional layer with an internal body that implements the memory controller’s functionality (real code omitted here for the sake of space). Communication is modeled accurately through instances of the actual bus protocol and memory access timings from the bus database. When composing the system, the bus-functional CE model connects to the busses corresponding to the ports defined in the behavioral CE model through its internal protocol instances. For example, it connects to the bus corresponding to port “GBus” as slave type through its gBus protocol instance.
At the top-level of the bus database, all channels and behaviors that are part of the same bus model are then grouped together under a single, top-level bus channel that acts as a container representing the overall bus protocol in the bus database.
5 Bus Protocols The bus database contains models of busses including associated protocols where the term “bus” refers to communication structures in general, e.g. networks and their protocols. Models taken out of the bus database are used to implement and synthesize communication inside the PEs connected to the busses of the system. Bus models in the bus database consist of a stack of layers. At the bottom of the stack, the protocol layer is connected to the actual physical bus fabric (consisting of wires, switches, muxes, etc.), and it implements the bus primitives defined by the bus protocol for data transfers, synchronization and arbitration. On top of the protocol layer, the media access layer provides an abstraction of external communication into data links and memory accesses by using and combining bus primitives to regulate media accesses and slice abstract data into bus words. Note that even though these layers are loosely based on the OSI reference model, they do not necessarily match the OSI definitions exactly. The database distinguishes two levels of abstraction for a bus protocol model: the bus functional protocol model, which is a pin accurate and cycle accurate description that will be used for synthesis, and the Transaction Level Model (TLM), which models the bus protocol abstract of pins and wires and provides high simulation speeds. The models of the same bus share the same media access layer implementation. Only their implementation of the protocol layer is
A generic example of a bus model including all possible bus components is depicted in Figure 28. Each aspect will be described individually in the following sections. Section 5.1 starts with the container channel that represents a bus protocol in the bus database. It is followed by a description of the protocol layer for the data. arbitration and synchronization (interrupt) protocols in Section 5.2. The more abstract implementation of the protocol layer for the TLM is described in Section 5.3. Lastly, Section 5.4 describes the media access layer that sits on top of either protocol layer implementation.
5.1
Bus Channels
Bus channels represent bus protocols in the bus database. For each bus in the bus database there must be one bus channel and the set of bus channels defines the list of bus protocols available in the database. Bus channels are used for bus allocation and they act as a container for all protocol models and other information like attributes and parameters associated with a bus. 45
1 b e h a v i o r SRAM Control BF ( 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
in in out in in in out in in in in in out
signal signal signal signal signal signal signal signal signal signal signal signal signal signal out s i g n a l out s i g n a l out s i g n a l
unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned
bit bit bit bit bit bit bit bit bit bit bit bit bit bit bit bit bit
[ 3 5 : 0 ] GA, [ 6 3 : 0 ] GDOUT, [ 6 3 : 0 ] GDIN , [ 7 : 0 ] GBE, [ 0 : 0 ] GRD, [ 0 : 0 ] GWR, [ 0 : 0 ] GACK, [ 0 : 0 ] GBURST, [ 0 : 0 ] GLAST , [ 0 : 0 ] GCACHE, [ 0 : 0 ] GID , [ 0 : 0 ] GBSTART, [ 1 8 : 0 ] A, [ 7 : 0 ] IO , [ 0 : 0 ] CS , [ 0 : 0 ] OE , [ 0 : 0 ] WE)
19 { 20 21 22 23 24 25 26 27 28 29 30 31
T o s h i b a G B u s S l a v e gBus (GA, GDOUT, GDIN , GBE, GRD, GWR, GACK, GBURST, GLAST , GCACHE, GID , GBSTART ) ; MasterKM684002A 15 mBus (A, IO , CS , OE , WE) ; n o t e CE BF BUS = { { ” gBus ” , ” GBus ” , ” s l a v e ” } , { ”mBus” , ”SRAM Bus” , ” m a s t e r ” } }; v o i d main ( ) { / / f u n c t i o n a l i t y code here . . . }
32 } ;
Listing 22: Example of bus-functional CE model.
46
Interrupt Detect Interrupt Detect
Interrupt Generate
IntN
Interrupt Generate
IntA
Figure 28: Generic example of bus model.
47
Slave
Req/ Grant
SlaveMem
Bus fabric
Arbiter
Master
MAC layer (Slave)
SlaveProtocol
Arbitration MasterProtocol
MasterLink
Transaction Level Model (TLM)
MasterMem
Protocol layer
SlaveLink
MAC layer (Master)
5.1.1
General Format
A bus channel is created through a special SpecC channel definition. The general format of bus channels in shown in Figure 29. The name of the bus channel defines the name of the bus protocol in the bus database. A bus channels does not have any ports but it can implement interfaces to optionally expose bus communication interfaces instantiated internally as described below for documentation and readability purposes. bus_channel = A bus channel has to have an internal body that defines channel bus_name no_port_opt the bus fabric and the protocol stacks for implementation implements_interface_opt of the bus protocol inside partners connected to and com’{’ bus_body_list ’}’ ’;’ municating via the bus. At minimum, the bus fabric has to consist of a set of bus wires. Bus wires are defined by inno_port_opt = stances of variables of signal bitvector type with optional | ’(’ ’)’ initializers defining default values for driving a bus wire. In general, however, the bus fabric can be built out of an bus_body_list = arbitrarily connected set of wires and behavior instances. bus_body For example, for a mux-based bus architecture, the bus fab| bus_body_list bus_body ric will consist of properly connected wires and behaviors modeling the multiplexers of the bus. bus_body = Protocol stacks are given as instances of channels or benote_definition haviors describing protocol models at different layers. For | wire_definition each protocol model associated with the bus, an instance | instance_declaring_list | method_definition of that channel or behavior has to exist in the bus channel. Mappings of wires to ports of low-level instances and wire_definition = of instances at lower layers to ports of instances of higher signal bit_sign bit_vector wire_name layers thereby defines the proper connectivity to assemble initializer_opt ’;’ protocol stacks inside PEs where the bus channel has to provide complete stacks for all possible ways of connectbit_sign = ing components supported by the bus. In addition to the definition of the communication hi| signed erarchy implementation, bus channels also carry a num| unsigned ber of annotations for general database management, atbit_vector = tributes (Section 5.1.2), and optional parameters (see Secbit ’[’ const_expression ’:’ const_expression ’]’ tion 2.2.3). | bit ’[’ const_expression ’]’ General annotations for database management store basic information about the protocol organization (Table 29). initializer_opt = Specifically, the following general annotations are attached to bus channels: | ’=’ const_expression BUS LIBRARY Name describing the bus database the channel is a member of. Used to distinguish between bus and other channels, i.e. required for bus protocol channels.
Figure 29: Format of bus channels.
BUS CATEGORY Name of the category the bus belongs to. Bus categories are mandatory and are used to classify busses into different groups for bus allocation and selection. BUS COMMENT Brief description of the bus that will be 48
Name BUS LIBRARY BUS CATEGORY BUS COMMENT BUS COMPONENTS BUS CLOCK PORT BUS ADDR PORT BUS DATA PORT BUS MASTER PROTOCOL BUS SLAVE PROTOCOL BUS MASTER TLM BUS SLAVE TLM BUS MASTER INT BUS SLAVE INT BUS MASTER ACCESS BUS SLAVE ACCESS BUS MASTER LINK BUS SLAVE LINK BUS MASTER MEM BUS SLAVE MEM
Description Name of parent bus database Name of bus category Bus description List of components for platform bus Name of the bus clock wire Name(s) of the bus wire(s) carrying addresses Name(s) of the bus wire(s) carrying data Name(s) of data transfer protocol master model instance(s) Name(s) of data transfer protocol slave model instance(s) Name(s) of transaction-level master model instance(s) Name(s) of transaction-level slave model instance(s) Name(s) of synchronization protocol receiver instance(s) Name(s) of synchronization protocol sender instance(s) Name(s) of bus request model instance(s) of the arbitration protocol Name(s) of bus grant model instance(s) of the arbitration protocol Name(s) of data link master model instance(s) Name(s) of data link slave model instance(s) Name(s) of memory access model instance(s) Name(s) of memory server model instance(s)
Type String String String String String String String String String String String String String String String String String String String
Default – ”” ”” – – – – – – – – – – – – – – – –
Table 29: General annotations for bus protocol channels.
Name BUS MASTER LINK METHOD BUS MASTER MEM METHOD BUS SLAVE LINK METHOD BUS SLAVE MEM METHOD
Description Names of read and write methods to the master’s link media access layer Names of read and write methods to the master’s memory media access layer Names of read and write methods to the slave’s link media access layer Names of the access methods to the slave’s memory media access layer
Type String[2] String[2] String[2] String[3]
Table 29: General annotations for bus protocol channels (continued).
49
Default {”masterLinkRead”, ”masterLinkWrite”} {”masterMemRead”, ”masterMemWrite”} {”slaveLinkRead”, ”slaveLinkWrite”} {”slaveMemServe”, ”slaveMemSrvWrite”, ”slaveMemSrvRead”}
used and displayed as an aid during selection and allocation.
or a complex annotation with a list of strings pointing to objects instantiated inside the bus channel. The named instance(s) have to exist inside the bus channel. Format and cardinality of the annotation have to match the BUS MASTER PROTOCOL annotation. Required for all busses. See Section 5.3.
BUS COMPONENTS List of names of actual components that are part of the platform in case of a platform bus. If the annotation does not exist, the bus is a regular component, not a platform. See Section 2.2.1.
BUS SLAVE TLM Name(s) of the channel or behavior instance(s) providing the implementation(s) and defining the way(s) to connect transaction-level protocol models of bus slaves. Either a single string or a complex annotation with a list of strings pointing to objects instantiated inside the bus channel. The named instance(s) have to exist inside the bus channel. Format and cardinality of the annotation have to match the BUS SLAVE PROTOCOL annotation. Required for busses that distinguish between bus masters and slaves. See Section 5.3.
BUS CLOCK PORT Name of the variable representing the bus clock wire, if any. Required for synchronous bus protocols. Undefined in case of an asynchronous bus protocol. BUS ADDR PORT Name(s) of the variable(s) representing the wire(s) over which addresses are communicated. Either a single string or a complex annotation with a list of strings. Required for busses that support addressing. BUS DATA PORT Name(s) of the variable(s) representing the wire(s) over which data is communicated. Either a single string or a complex annotation with a list of strings. Required for all busses.
BUS MASTER INT Name(s) of the channel or behavior instance(s) providing the implementation(s) and defining the possible ways of connecting synchronization protocol layer(s) for bus masters (i.e. event detection on the receiver side). Either a single string or a complex annotation with a list of strings pointing to objects instantiated inside the bus channel. The named instance(s) have to exist inside the bus channel. Required for busses that support synchronization. See Section 5.2.3.
BUS MASTER PROTOCOL Name(s) of the channel or behavior instance(s) providing the implementation(s) and defining the possible ways of connecting data transfer protocol layer(s) of bus masters. A single string for busses that support an arbitrary number of masters all connecting in the same manner. Otherwise, a complex annotation with a list of strings enumerating all possible, unique bus master connections. Strings point to objects instantiated inside the bus channel, and the named instances have to exist inside the bus channel. Required for all busses. See Section 5.2.2.
BUS SLAVE INT Name(s) of the channel or behavior instance(s) providing the implementation(s) and defining the possible ways of connecting synchronization protocol layer(s) for bus slaves (i.e. event generation on the sender side). Either a single string or a complex annotation with a list of strings pointing to objects instantiated inside the bus channel. The named instance(s) have to exist inside the bus channel. Required for busses that support synchronization and distinguish between bus masters and slaves. See Section 5.2.3.
BUS SLAVE PROTOCOL Name(s) of the channel or behavior instance(s) providing the implementation(s) and defining the possible ways of connecting data transfer protocol layer(s) of bus slaves. A single string for busses that support an arbitrary number of slaves all connecting in the same manner. Otherwise, a complex annotation with a list of strings enumerating all possible, unique bus slave connections. Strings point to objects instantiated inside the bus channel, and the named instances have to exist inside the bus channel. The named instance(s) have to exist inside the bus channel. Required for busses that distinguish between bus masters and slaves. See Section 5.2.2.
BUS MASTER ACCESS Name(s) of the channel or behavior instance(s) providing the implementation(s) and defining the possible ways of connecting arbitration protocol(s) for bus accesses by bus masters. Either a single string or a complex annotation with a list of strings pointing to objects instantiated inside the bus channel. The named instance(s) have to exist inside the bus channel. Required for busses that support multiple masters attached to the same bus. See Section 5.2.4.
BUS MASTER TLM Name(s) of the channel or behavior instance(s) providing the implementation(s) and defining the way(s) to connect transaction-level protocol models of bus masters. Either a single string
BUS SLAVE ACCESS Name(s) of the channel or behavior instance(s) providing the implementation(s) and 50
defining the possible ways of connecting arbitration protocol(s) for regulating bus accesses inside arbiters. Either a single string or a complex annotation with a list of strings pointing to objects instantiated inside the bus channel. The named instance(s) have to exist inside the bus channel. Required for busses where centralized arbiters are needed to regulate among conflicting accesses by different masters attached to the bus. See Section 5.2.4.
match the BUS SLAVE PROTOCOL annotation. See Section 5.4.3. BUS MASTER LINK METHOD Names of the methods to access the link style media access layer on the master side. It is an array of two names: the read method name and the write method name. The named methods have to exist in all link media access layer channels (see Section 5.4.2). If annotation is not defined, the defaults as in Table 29 are applied.
BUS MASTER LINK Name(s) of the channel instance(s) providing the implementation(s) and defining the connectivity of media access layer(s) for data links inside bus masters. Either a single string or a complex annotation with a list of strings pointing to objects instantiated inside the bus channel. The named instance(s) have to exist inside the bus channel. Required for all busses. Format and cardinality of the annotation have to match the BUS MASTER PROTOCOL annotation. See Section 5.4.2.
BUS MASTER MEM METHOD Names of the methods to access the memory style media access layer on the master side. It is an array of two names: the read method name and the write method name. The named methods have to exist in all memory media access layer channels (see Section 5.4.3). If annotation is not defined, the defaults as in Table 29 are applied. BUS SLAVE LINK METHOD Names of the methods to access the link style media access layer on the slave side. It is an array of two names: the read method name and the write method name. The named methods have to exist in all link media access layer channels (see Section 5.4.2). If annotation is not defined, the defaults as in Table 29 are applied.
BUS SLAVE LINK Name(s) of the channel instance(s) providing the implementation(s) and defining the connectivity of media access layer(s) for data links inside bus slaves. Either a single string or a complex annotation with a list of strings pointing to objects instantiated inside the bus channel. The named instance(s) have to exist inside the bus channel. Format and cardinality of the annotation have to match the BUS SLAVE PROTOCOL annotation. Required for busses that distinguish between bus masters and slaves. See Section 5.4.2.
BUS SLAVE MEM METHOD Names of the methods to access the memory style media access layer on the slave side. It is an array of three strings: the method to serve read and write requests, the method to serve write requests only, and the method to server read requests only. The named methods have to exist in all memory media access layer channels (see Section 5.4.3). If annotation is not defined, the defaults as in Table 29 are applied.
BUS MASTER MEM Name(s) of the channel instance(s) providing the implementation(s) and defining the connectivity of media access layer(s) for external memory accesses inside bus masters. Either a single string or a complex annotation with a list of strings pointing to objects instantiated inside the bus channel. The named instance(s) have to exist inside the bus channel. Required for busses that support shared memories. Format and cardinality of the annotation have to match the BUS MASTER PROTOCOL annotation. See Section 5.4.3.
Note that different protocol model annotations can point to the same behavior or channel instance, i.e. a protocol implementation can provide more than one of the mandatory or optional functionalities within the restrictions noted in the rest of this Chapter 5. An example of a bus channel is shown in Listing 23. The bus channel defines a bus protocol named MyDSP Bus that is part of the “busses” library and belongs to the “Processor” category (the example being the protocol for the MyDSP processor from the PE database bus-functional examples, see Section 3.4). The bus channel annotations provides pointers to the different instances implementing the layers of the bus protocol model described in the following sections. The bus channel example contains variable instances defining the basic bus wires (address bus Addr, data bus Data, and control lines Ctrl) and two built-in interrupt lines (intA and
BUS SLAVE MEM Name(s) of the channel instance(s) providing the implementation(s) and defining the connectivity of media access layer(s) for serving memory accesses on the memory side. Either a single string or a complex annotation with a list of strings pointing to objects instantiated inside the bus channel. The named instance(s) have to exist inside the bus channel. Required for busses that support shared memories. Format and cardinality of the annotation have to 51
1 import ” MyDSP Bus Models ” ;
/ / bus i m p l e m e n t a t i o n s
2
3 c h a n n e l MyDSP Bus ( ) { 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
n o t e BUS LIBRARY = ” b u s s e s ” ; n o t e BUS CATEGORY = ” P r o c e s s o r ” ; n o t e BUS COMMENT = ” Bus e x a m p l e ” ; n o t e BUS ADDR PORT = ” Addr ” ; n o t e BUS DATA PORT = ” D a t a ” ; n o t e BUS MASTER PROTOCOL = { ” m a s t e r ” } ; n o t e BUS SLAVE PROTOCOL = ” s l a v e ” ; n o t e BUS MASTER TLM = { ” t l m ” } ; n o t e BUS SLAVE TLM = ” t l m ” ; n o t e BUS MASTER INT = { ” m a s t e r I n t A ” , ” m a s t e r I n t B ” } ; n o t e BUS SLAVE INT = { ” s l a v e I n t A ” , ” s l a v e I n t B ” } ; n o t e BUS MASTER LINK = ” m a s t e r L i n k ” ; n o t e BUS SLAVE LINK = ” s l a v e L i n k ” ; n o t e BUS MASTER MEM = ” masterMem ” ; n o t e BUS SLAVE MEM = ” slaveMem ” ; s i g n a l b i t [ 3 1 : 0 ] Addr , D a t a ; / / bus w i r e s signal bit [2] C t r l = 00 b ; signal bit [1] i n t A = 0b , i n t B = 0b ; / / i n t e r r u p t l i n e s
23 24
/ / t r a n s a c t i o n −l e v e l model
MyDSP Bus TLM
tlm ;
MyDSP Bus Master MyDSP Bus MasterLink MyDSP Bus MemAccess MyDSP Bus IntDetect MyDSP Bus IntDetect
m a s t e r ( Addr , Data , C t r l ) ; masterLink ( master ) ; masterMem ( m a s t e r ) ; masterIntA ( intA ) ; masterIntB ( intB ) ;
MyDSP Bus Slave MyDSP Bus SlaveLink MyDSP Bus MemServe MyDSP Bus IntGenerate MyDSP Bus IntGenerate
s l a v e ( Addr , Data , C t r l ) ; slaveLink ( slave ) ; slaveMem ( s l a v e ) ; slaveIntA ( intA ) ; slaveIntB ( intB ) ;
25 26 27 28 29 30 31 32 33 34 35 36 37 } ;
/ / master stack
/ / slave stack
Listing 23: Bus channel example.
52
intB). On top of the wires, protocol stacks for the master and slave side of the bus are defined by instantiating all the channels in the proper hierarchy. Protocol layer instances connect directly to the wires for the mandatory data transfer protocols on the master and slave side. The bus supports only a single bus master (master), and no access/arbitration protocol is implemented. On the other hand, an arbitrary number of slaves can be connected to the bus (slave). In addition to the pin-accurate model, the bus provides a transaction-level model of the bus protocol (tlm). On top of either protocol, media access layer instances for links (masterLink, slaveLink) connect to the bus protocol implementations to use the bus primitives provided by them. The bus supports shared memory communication and it defines the corresponding media access layer instances (masterMem for performing memory accesses from the master and slaveMem for serving memory accesses by the memory slave). In both cases, link and memory type communication is provided through read and write methods of the corresponding channels. Finally, the bus defines a built-in synchronization protocol and provides interrupt protocol instances for interrupt generation on the slave side (slaveIntX) and interrupt detection on the master side (masterIntX), respectively. 5.1.2
BUS DATA WIDTH Number of bits in bus data words (e.g. number of wires in the data bus or bitwdith of data part in bus frames). Determines the maximal amount of data transfered in a single regular bus cycle. BUS CHAR WIDTH Number of bits in a basic bus character for memory accesses where bus characters are memory words aligned at unit address boundaries (one bus character per address), i.e. width of smallest addressable memory unit. BUS ALIGNMENT Boundary at which whole bus data words are aligned in the bus address space, i.e. the address of a any part of a bus word modulo the alignment determines the address of the corresponding whole bus data word. Note that bus character width multiplied by the bus alignment must not necessarily be equal to the bus data word width in case memory accesses use only partial data words, for example. 5.1.3
Weight Tables
Weight tables of buses are described through weight table annotations attached to the bus channels. Weight table annotations can be given using the format defined previously in Section 2.2.4. Specifically, the weight annotations can be attached to buses are listed in Table 31. Each one is used by at least one design metrics after mapping system channels to system buses. The weight annotations and examples of their represented design metrics are:
Attributes
Basic characteristics and metrics of busses and protocols are described through attribute annotations attached to the bus channels. Attribute annotations can be given using the format defined previously in Section 2.2.2. Specifically, the following attributes can be attached to bus channels (Table 30):
BUS WEIGHT TRAFFIC STATIC Each item in the weight table represents the occupied bus data words by a storage unit (such as a variable) of the system channel with a certain item type and data type on the bus.
BUS BANDWIDTH Maximal bandwidth of the bus, i.e. throughput of the bus at 100% utilization. BUS COST Cost of the bus. The cost unit depends on the database (e.g. price or area).
This is used to compute the static traffic. One design metric represents the port width of the system channel. It equals to the traffic when each port of the channel is accessed once.
BUS CLOCK PERIOD Period of the bus clock in case of a synchronous bus protocol (i.e. if BUS CLOCK PORT is defined). BUS CLOCK DUTY Duty cycle (percent of a clock period in which the clock is high) of the bus clock in case of a synchronous bus protocol (i.e. if BUS CLOCK PORT is defined).
BUS WEIGHT TRAFFIC DYNAMIC Each item in the weight table represents the occupied bus data words by a storage unit (such as a variable) of the system channel with a certain item type and data type on the bus.
BUS ADDR WIDTH Number of bits in bus addresses (e.g. number of wires in the address bus or bitwidth of address field in bus frames). Determines the size of the bus address space.
This is used to compute the dynamic traffic. One design metric represents the dynamic traffic of the design. It equals to the amount of traffic going through the ports of the system channel during simulation. 53
Name BUS BANDWIDTH BUS CLOCK PERIOD BUS CLOCK DUTY BUS COST BUS ADDR WIDTH BUS DATA WIDTH BUS CHAR WIDTH BUS ALIGNMENT
Description Max. throughput Bus clock period Bus clock duty cycle Cost Address bus width Data bus width Memory character width Bus word address alignment
Unit bits/s ps % bits bits bits addr
Type double ullong double double uint uint uint uint
Default 0.0 0ull 0.5 0.0 8u 0u 8u 1u
Unit words words
Type double double
Default 0.0 0.0
Table 30: Bus channel attribute annotations. Name BUS WEIGHT TRAFFIC STATIC BUS WEIGHT TRAFFIC DYNAMIC
Metric Static traffic Dynamic traffic Table 31: Bus channel weight annotations.
Besides the weight annotation, the item header annotation and data header annotation are also required. The header annotations are displayed in Table 32.
5.2
quires an acknowledge from slave to master to complete a transfer. In both cases, the protocol layer model defines a set of methods and exports them through an implemented interface such that higher layers can use protocol layer services for communication by calling appropriate methods as needed. Internally, a protocol layer channel or behavior models the corresponding protocol for driving and sampling the bus wires through their ports of bitvector signal type. The list of ports has to match a subset of the list of bus wires such that protocol layer models can be connected to the wires through pins of the bus-functional PE.
Protocol Layer
Protocol layer models provide primitives for atomic bus transactions at their interfaces and they describe the basic timing of events (value changes) on the wires of the bus for each primitive. Timing diagrams of bus transactions are represented through state machines and associated timing constraints defining the possible sequences of driving and sampling bus wires. Protocol layer models are used in the design flow to provide models of the protocol behavior on the wires of the bus both for system simulation and for synthesis of protocol implementations in actual hardware. In general, a bus can have separate protocols for basic data transfers, synchronization, and arbitration. A protocol model provides a description for implementation of the protocol in a PE connected to the bus’ wires. Each protocol can have separate models with different implementations for bus master and bus slave type PEs. 5.2.1
5.2.2
Data Transfer Protocol
The mandatory data transfer protocol is the core of the bus and it describes primitives for transferring native bus words distinguished by bus addresses. It has to provides methods for all atomic bus cycles available over the core bus, including special types like burst mode, etc. In case of a master/slave arrangement (separate models for master and slave side), the master side is actively initiating bus cycles and the slave slide can only passively listen on the bus for the start of a cycle to participate in. Consequently, methods on the slave side are considered blocking and only return when the transfer has been completed successfully with the corresponding master. In order to enable polling, methods on the master side, on the other hand, must not block even if no corresponding slave is available to successfully complete the transfer (note that in order to satisfy this requirement, active slaves might be necessary to answer and decline a transfer if no data is available through higher layers). In case there is no distinction between masters and
General Format
The general format of protocol layer models is shown in Figure 30. Protocol layer models are defined as either SpecC channels for passive models or SpecC behaviors for active models. In case of active models, the behavior defines a main method that has to be executed concurrently with the main computation inside a PE for busses where a PE needs to constantly participate in the protocol. For example, an active slave side might be necessary to answer and decline polling requests in case of a protocol that re54
Name BUS WEIGHT TRAFFIC HEADER DATATYPE BUS WEIGHT TRAFFIC HEADER ITEMTYPE
Type in Table 8 in Table 7
Default – –
Table 32: Header annotations for traffic metrics.
1 i n t e r f a c e IMyDSP Bus Master 2 { 3 4
protocol_model = protocol_channel | protocol_behavior
5 6
v o i d r e a d B y t e ( b i t [ 3 1 : 0 ] A, b i t [ 7 : 0 ] ∗D ) ; v o i d readWord ( b i t [ 3 1 : 1 ] A, b i t [ 1 5 : 0 ] ∗D ) ; v o i d r e a d L o n g ( b i t [ 3 1 : 2 ] A, b i t [ 3 1 : 0 ] ∗D ) ; v o i d w r i t e B y t e ( b i t [ 3 1 : 0 ] A, b i t [ 7 : 0 ] D ) ; v o i d w r i t e W o r d ( b i t [ 3 1 : 1 ] A, b i t [ 1 5 : 0 ] D ) ; v o i d w r i t e L o n g ( b i t [ 3 1 : 2 ] A, b i t [ 3 1 : 0 ] D ) ;
7 8 9
protocol_channel = 10 } ; channel protocol_name pins 11 implements interface_list 12 i n t e r f a c e IMyDSP Bus Slave ’{’ internal_declarations_opt ’}’ ’;’ 13 { 14
b i t [ 1 ] l i s t e n ( b i t [ 3 1 : 0 ] ∗A, b i t [ 3 1 : 0 ] M,
18
v o i d serveReadWord ( b i t [ 1 5 : 0 ] D ) ; void serveReadLong ( b i t [ 3 1 : 0 ] D) ;
protocol_behavior = 15 b i t [ 1 ] W, b i t [ 1 ] WM) ; behavior protocol_name pins 16 implements interface_list 17 void serveReadByte ( b i t [ 7 : 0 ] D) ; ’{’ internal_declarations_opt ’}’ ’;’ pins =
19
’(’ pin_list ’)’
pin_list = pin | pin_list ’,’ pin pin =
20 21 22 23 24 } ;
v o i d s e r v e W r i t e B y t e ( b i t [ 7 : 0 ] ∗D ) ; v o i d s e r v e W r i t e W o r d ( b i t [ 1 5 : 0 ] ∗D ) ; v o i d s e r v e W r i t e L o n g ( b i t [ 3 1 : 0 ] ∗D ) ;
Listing 24: Example of a data transfer protocol interface.
pin_direction signal bit_sign bit_vector pin_name
pin_direction = | in | out | inout
slaves (no separate slave protocol model(s) supplied, i.e. slave model(s) are assumed to be the same as the master model(s)), the single set of data transfer protocol models acts both as master and slave where for each transfer the sending side is assumed to be the master and the receiving side the slave. Apart from that, the same restrictions for bit_sign = the sending (master) and receiving (slave) methods apply. | signed Listing 24 and Listing 25 show an example of a data | unsigned transfer protocol model. The data transfer protocol interfaces shown in Listing 24 provides primitives for reading bit_vector = and writing data operands of different sizes from/to the bus bit ’[’ const_expression ’:’ const_expression ’]’ in one shot. Since bus addresses have to be aligned cor| bit ’[’ const_expression ’]’ rectly, the slice of addresses accepted by each primitive depends on the size of the operand. In order to support Figure 30: Format of protocol layer models. memory type PEs, the protocol on the slave side supports split transactions with separate primitives for listening on the bus for a range of addresses (determined by a mask) and for serving corresponding bus requests. The example protocol is defined as two separate passive 55
1 c h a n n e l MyDSP Bus Slave ( 2
1 c h a n n e l MyDSP Bus Master (
3
2
4
3 4 5 6 { 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 } ;
out s i g n a l b i t [ 3 1 : 0 ] signal bit [31:0] out s i g n a l b i t [ 2 ] implements IMyDSP Bus
Addr , Data , Ctrl ) Master
v o i d r e a d L o n g ( b i t [ 3 1 : 2 ] A, b i t [ 3 1 : 0 ] ∗D) { do { l 1 : Addr = A @ 00 b ; C t r l = 01 b ; waitfor (10000); l 2 : ∗D = D a t a ; C t r l = 00 b ; } timing { range ( l 1 ; l 2 ; 1 0 0 0 0 ; ) ; } } v o i d w r i t e L o n g ( b i t [ 3 1 : 2 ] A, b i t [ 3 1 : 0 ] D) { do { l 1 : Addr = A @ 00 b ; Data = D; C t r l = 11 b ; waitfor (10000); l 2 : C t r l = 00 b ; } timing { range ( l 1 ; l 2 ; 1 0 0 0 0 ; ) ; } } //
5 6 { 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
...
35 36 37
(a) Master side
38 } ;
in
signal bit [31:0] signal bit [31:0] in signal bit [2] implements IMyDSP Bus
Addr , Data , Ctrl ) Slave
b i t [ 1 ] l i s t e n ( b i t [ 3 1 : 0 ] ∗A, b i t [ 3 1 : 0 ] M, b i t [ 1 ] W, b i t [ 1 ] WM) { l1 : wait ( r i s i n g C t r l ) ; i f ( ( ( Addr & M) ! = ∗A) | | ( C t r l [ 1 ] & WM ! = W) ) goto l1 ; ∗A = Addr ; return C t r l [ 1 ] ; } v o i d s e r v e W r i t e L o n g ( b i t [ 3 1 : 0 ] ∗D) { do { l1 : waitfor (5000); l 2 : ∗D = D a t a ; } timing { range ( l 1 ; l 2 ; ; 1 0 0 0 0 ) ; } } v o i d s e r v e R e a d L o n g ( b i t [ 3 1 : 0 ] D) { do { l1 : waitfor (5000); l 2 : Data = D; } timing { range ( l 1 ; l 2 ; ; 1 0 0 0 0 ) ; } } //
...
(b) Slave side
Listing 25: Example of data transfer protocol model.
56
models in the form of channels for the master side (Listing 25(a)) and the slave side (Listing 25(b)). Both sides implement the corresponding data transfer protocol interfaces IMyDSP Bus Master and MyDSP Bus Slave shown previously. Internally, the sequence of statements in the methods drive and sample the Addr, Data, and Ctrl wires of the bus through ports of the channels. Furthermore, the protocol state machines are enclosed in do-timing constructs to specify the constraints on timing that have to be obeyed when implementing the protocol. 5.2.3
1 import ” i r e c e i v e ” ;
Synchronization Protocol
As explained in the previous section, the data transfer protocol generally only supplies inherent one-way synchronization from master to slave. However, in order to implement reliable communication with guaranteed data delivery, two-way synchronization between communication partners is required. Therefore, a bus can supply an optional, distinct synchronization protocol to efficiently send events from slave to master. Usually, this means an interrupt protocol and interrupt wires through which a slave can send interrupts to a master. In the same manner as data transfer protocols (see Section 5.2.2), interrupt protocols can be arranged as separate models for master side and slave side, or as one common model acting as both master (when sending) and slave (when receiving). If the synchronization protocol is event-based (e.g. edge-sensitive signals), the master and slave sides have to implement the i receive and i send interfaces out of the standard SpecC channel library to receive and send events, respectively. On the other hand, if the synchronization protocol is state-based (e.g. levelsensitive signals), master and slave sides have to implement the standard SpecC channel interfaces i semaphore and i critical section to query and set the synchronization state, respectively. If the synchronization protocol annotations in the bus channel point to the data transfer protocol model(s) or data link media access model(s) (see Section 5.4.2), two-way synchronization with blocking transfers on both sides has to be implemented as part of the data transfer protocol or data link media access layer, respectively, and no separate synchronization protocol is available or necessary. Similarly, if no synchronization protocol is supplied, no event transfer mechanism is available as part of the bus. An example of a basic synchronization protocol to send interrupts from a slave to a master is shown in Listing 26. On the master side (Listing 26(a)), the interrupt detection logic channel receives events by recognizing rising edges on the interrupt line connected to its port. On the slave side (Listing 26(b)), the interrupt generation logic channel sends events by creating a pulse on the interrupt line
2
3 channel MyDSP Bus IntDetect (
in signal bit [1] i n t r ) implements i r e c e i v e
4 5 6 7 { 8 9 10 11
void r e c e i v e ( void ) { wait ( r i s i n g i n t r ) ; }
12 13 } ;
(a) Interrupt detection logic 1 import ” i s e n d ” ; 2
3 channel MyDSP Bus IntGenerate (
out s i g n a l b i t [ 1 ] i n t r ) implements i s e n d
4 5 6 7 { 8 9 10 11 12
void send ( void ) { i n t r = 1; waitfor (5000); i n t r = 0; }
13 } ;
(b) Interrupt generation logic
Listing 26: Example of synchronization protocol model.
57
5.3
through its port.
5.2.4
Transaction-Level Models
The Transaction-Level Model (TLM) of a bus is a replacement for the previously described protocol layer (see Section 5.2). It implements the same interfaces as the protocol layer and provides the same services. Unlike the protocol layer, it models communication abstract of pins and wires and achieves a significant higher simulation performance. For this document the TLM implementation of the protocol layer will be referred to as the TLM. The TLM provides interfaces for transferring bus transactions as primitives. The timing simulation of a TLM is done internally through state machines. Communication between bus nodes is achieved abstract of pins and wires, using mechanisms similar to the standard channel implementations (e.g. the high-level double handshake channel). In comparison to the previous described protocol layer, the TLM provides a higher simulation performance, usually at the cost of a reduced timing accuracy. As described previously, a protocol layer may include different protocols for basic data transfers, synchronization and arbitration. The TLM as well has to implement the interfaces to the same services as provided by the protocol layer. It has to provide the same functional behavior. The TLM may have a lower accuracy in terms of timing information, since it is at the discretion of the model designer to simplify parts of the model internal timing behavior. The following section describes the general format of the TLM. The subsequent sections describe more about the functional behavior and give an example of a TLM.
Arbitration Protocol
If the bus supports multiple masters connected to the bus, it has to supply an arbitration protocol that is used to regulate accesses to the shared bus wires. In a centralized arbitration scheme, the master side of the arbitration protocol instantiated in each master communicates with the slave side of the arbitration protocol instantiated in an additional arbiter component attached to the bus. In a distributed arbitration scheme, there is no slave side of the arbitration protocol and the master sides of the protocol in each master regulate accesses among themselves. The master side of the arbitration protocol can either be provided as a separate protocol layer model or it can be a built-in part of the data transfer protocol in which case the arbitration master annotation ( BUS MASTER ACCESS, see Section 5.1.1) points back to the data transfer protocol model. In case of a separate arbitration protocol, the master side arbitration protocol model has to implement the i semaphore interface out of the standard SpecC channel library for acquiring and releasing access to the bus where the attempt() method has to provide feedback about whether an acquired bus needs to be released. In either case, arbitration has to be made available for each PE that will act as a data transfer protocol master if multiple masters sharing the bus are supported. Listing 27 shows an example of a bus channel for a bus that supports multiple masters on the bus through arbitration. As defined by the BUS MASTER PROTOCOL annotation and corresponding protocol channel instances in the example, the bus supports two masters, master0 and master1, that are connected to the bus wires in the manner shown inside the channel. Correspondingly, two separate complete protocol stacks on the master side are instantiated and defined (through annotations) for the bus. On the master side, the bus data transfer protocol channels include the necessary protocol implementations for participation in the bus’ arbitration protocol. As such, no separate master arbitration protocol implementations are required and the corresponding annotation ( BUS MASTER ACCESS) points back to the data protocol instances (master0 and master1). On the other hand, for implementation of the arbitration protocol on the arbiter side ( BUS SLAVE ACCESS), the bus provides corresponding protocol channel instances. In this example, an arbiter protocol channel that implements listening for, granting and releasing of bus requests from a single master (Listing 28) is meant to be instantiated inside the arbiter once for each master (instances arbiter0 and arbiter1).
5.3.1
General Format
The general format of the TLM is shown in Figure 31. The TLM can be defined as one or more SpecC channels. The limitation of channels was made, since a passive bus simulation achieves generally a better performance. The same set of interfaces as exported by the protocol layer have to be implemented by the TLM. It has to be transparent for a higher layer, whether the protocol channel or the TLM is called. The TLM models the functional behavior of the bus protocol by using one or more channels. In case multiple SpecC channels are implemented for a single bus protocol, the individual channels have to be connected by ports – not by wires. The previously introduced example MyCPU Bus will be extended include a TLM. Listing 29 indicates the portions of the bus channel definition needed for the TLM. The annotation BUS MASTER TLM points to the master side implementation of the TLM protocol (in this example the instances tlmMaster0, line 13, and tlmMaster1, line 16). The annotation BUS SLAVE TLM points to the slave side implementation (tlm, line 10). Each master uses an 58
1 import ” MyCPU Bus Models ” ;
/ / bus i m p l e m e n t a t i o n s
2
3 c h a n n e l MyCPU Bus ( ) { 4 5 6 7 8 9 10 11 12 13 14 15
// ... n o t e BUS MASTER PROTOCOL = { ” m a s t e r 0 ” , ” m a s t e r 1 ” } ; n o t e BUS SLAVE PROTOCOL = ” s l a v e ” ; n o t e BUS MASTER ACCESS = { ” m a s t e r 0 ” , ” m a s t e r 1 ” } ; n o t e BUS SLAVE ACCESS = { ” a r b i t e r 0 ” , ” a r b i t e r 1 ” } ; n o t e BUS MASTER LINK = { ” m a s t e r L i n k 0 ” , ” m a s t e r L i n k 1 ” } ; n o t e BUS SLAVE LINK = ” s l a v e L i n k ” ; // ... s i g n a l b i t [ 3 1 : 0 ] Addr , D a t a ; signal bit [2] C t r l = 00 b ; signal bit [2] Req , G r a n t ;
/ / bus w i r e s // arbitration lines
16 17 18
MyCPU Bus Arbiter MyCPU Bus Arbiter
a r b i t e r 0 ( Req [ 0 ] , G r a n t [ 0 ] ) ; a r b i t e r 1 ( Req [ 1 ] , G r a n t [ 1 ] ) ;
MyCPU MyCPU // ... MyCPU MyCPU // ...
Bus Master Bus MasterLink
m a s t e r 0 ( Addr , Data , C t r l , Req [ 0 ] , G r a n t [ 0 ] ) ; masterLink0 ( master0 ) ;
Bus Master Bus MasterLink
m a s t e r 1 ( Addr , Data , C t r l , Req [ 1 ] , G r a n t [ 1 ] ) ; masterLink1 ( master1 ) ;
19 20 21 22 23 24 25 26 27 28 29 30 } ;
MyCPU Bus Slave MyCPU Bus SlaveLink // ...
s l a v e ( Addr , Data , C t r l ) ; slaveLink ( slave ) ;
Listing 27: Example of bus channel with support for multiple masters.
59
1 i n t e r f a c e IMyCPU Bus Arbiter { 2 3 4 5 }; 6
void r e q u e s t ( void ) ; void g r a n t ( void ) ; void r e l e a s e ( void ) ;
7 c h a n n e l MyCPU Bus Arbiter ( i n 8 9 10 { 11 12 13 14 15 16 17 18 19 20 21 22
s i g n a l b i t [ 1 ] Req , out s i g n a l b i t [ 1 ] Grant ) implements I M y C P U B u s A r b i t e r
void r e q u e s t ( void ) { w h i l e ( ! Req ) w a i t ( r i s i n g Req ) ; } void g r a n t ( void ) { Grant = 1; } void r e l e a s e ( void ) { w h i l e ( Req ) w a i t ( f a l l i n g Req ) ; Grant = 0; }
23 } ;
Listing 28: Example of arbiter bus protocol.
1 import ” MyCPU Bus Models ” ;
/ / bus i m p l e m e n t a t i o n s
2
3 c h a n n e l MyCPU Bus { 4 5 6 7 8 9 10
// ... n o t e BUS MASTER TLM = { ” t l m M a s t e r 0 ” , ” t l m M a s t e r 1 ” } ; n o t e BUS SLAVE TLM = ” t l m ” ; // ...
MyCPU Bus Protocol TLM Arb t l m A r b ; / ∗ a r b i t r a t i o n p r o t o c o l ∗ / MyCPU Bus Protocol TLM t l m ( t l m A r b ) ; / ∗ t l m p r o t o c o l , m a s t e r + s l a v e ∗ /
11 12 13 14 } ;
M y C P U B u s P r o t o c o l T L M I d e n t t l m M a s t e r 0 ( tlm , 0u ) ; M y C P U B u s P r o t o c o l T L M I d e n t t l m M a s t e r 1 ( tlm , 1u ) ;
Listing 29: Bus channel with TLM.
60
TLM_channel = channel TLM_name ports_opt implements interface_list ’{’ internal_declarations_opt ’}’ ’;’ ports_opt = | ’(’ port_list ’)’
5.3.3
port_list = port | port_list ’,’ port port =
Synchronization
For busses with separate synchronization protocols (see Section 5.2.3) the bus TLM must not include a synchronization implementation. Instead, standard handshake channels from the standard handshake database will be used as a synchronization protocol TLMs. Hence no additional implementation is required as part of the bus TLM. For busses in which synchronization is part of the data transfer protocol, the bus TLM will have to provide an equivalent implementation. Thus, as part of the bus TLM implementation, a model of the inherent synchronization that provides the same execution semantics as the protocol layer has to be included.
interface_name internal_name
Figure 31: Format of TLM channels. own instance of MyCPU Bus Protocol TLM Ident, which is done for identification purposes during arbitration. Each of these instances uses the common TLM protocol, which is also used by all slaves for the bus access. The tlm channel uses the services of the arbitration channel (tlmArb, line 9). In this example the separation was done for code organization. The following sections describe each protocol within the protocol layer. Even though they are described separately, they may be implemented in the same channel. 5.3.2
The bus timing is achieved by a waitfor statement in the slave side. Once the bus transaction is finished, the addressed slave acknowledges the transfer by setting the ack event. The bus access is regulated by the arbitration protocol, which is called at the beginning and in the end of each master bus access.
5.3.4
Arbitration
For bus protocols with multiple masters, the bus access has to be regulated through arbitration as part of the bus TLM. As with the data transfer, the modeling for the arbitration is performed abstract of wires. In the simplest case an arbitration may be performed by using the mutex from the standard library. This fast and simple arbitration then differs from the protocol implementation and the timing accuracy for the bus model will suffer. A more timing accurate modeling of the arbitration protocol models the same arbitration as the physical protocol. For this modeling of the arbitration the identity of the requesting master has to be known. However, for a call into a channel the identity is not know, unless explicitly passed. As a solution the requesting masters identity has to be passed explicitly for each bus request. To achieve that, an individual adapter instance is instantiated for each master. This adapter instance implements the master side of the protocol. It calls the TLM channel simulating the bus and its calls include the masters identity. This scheme is named identity through connectivity and reflects the identity definition of a physical implementation. Figure 32 shows the connection scheme. In the MyCPU Bus example the identity is defined by instances of MyCPU Bus Protocol TLM Ident, see lines 12 - 16 in Listing 30 for the instantiation and Listing 31 for the implementation. In the example the arbitration is implemented in a separate channel. This separation is done only for the purpose of code organization. In most cases both data transfer and
Data Transfer
The main part of a bus TLM deals with the data transfer. The internal data transfer within the data transfer protocol is at the discretion of the model designer. Typically a memcpy is used for the transfer and events come to use for synchronization between the bus nodes. The internal usage of bit vectors should be avoided, due to their high simulation effort. Listing 30 shows an example implementation of a TLM data transfer protocol. A single channel is used, implementing both the master and slave interface as defined for the protocol layer in Listing 24. In the shown example it was not possible to avoid bit vectors. Their usage is dictated by the interface definition. In this implementation all slaves do wait for an event of busReq. Once a master starts a bus transaction it sets the channel variables for busAddr and busCtrl according to the transfer. After that it sets the event busReq which triggers execution of all pending slaves (in the listen method). Each slave compares the busAddr with the own range and only the one with the matching range proceeds. Depending on busCtrl the upper layer calls either the write or read function, in which the according bus transaction is performed. 61
1 import ” IMyCPU Bus ” ;
2 import ” M y C P U B u s P r o t o c o l T L M I d e n t ” ; 3 import ” MyCPU Bus Arbiter TLM ” ;
4
5 c h a n n e l MyCPU Bus Protocol TLM ( IMyCPU Bus TLM Arb a r b ) 6 7 { 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
implements I M y C P U B u s M a s t e r I d e n t , IMyCPU Bus Slave
u n s i g n e d b i t [ 3 1 : 0 ] busAddr , b u s D a t a ; unsigned b i t [ 1 : 0 ] busCtrl ; event busReq , a c k ; / ∗ MASTER s i d e i m p l e m e n t a t i o n ∗ / v o i d r e a d L o n g ( b i t [ 3 1 : 2 ] A, b i t [ 3 1 : 0 ] ∗D, u n s i g n e d i n t m a s t e r I d ) { arb . a c q u i r e ( m a s t e r I d ) ; /∗ r e q u e s t t h e bus ∗/ busAddr = A @ 00 b ; b u s C t r l = 01 b ; n o t i f y busReq ; / ∗ wake up p e n d i n g s l a v e s ∗ / wait ack ; /∗ wait u n t i l slave performed write ∗/ ∗D = b u s D a t a ; arb . r e l e a s e ( m a s t e r I d ) ; /∗ r e l e a s e t h e bus ∗/ } v o i d w r i t e L o n g ( b i t [ 3 1 : 2 ] A, b i t [ 3 1 : 0 ] D, u n s i g n e d i n t m a s t e r I d ) { arb . acquire ( masterId ) ; /∗ r e q u e s t t h e bus ∗/ busAddr = A @ 00 b ; b u s C t r l = 11 b ; busData = D; n o t i f y busReq ; / ∗ wake up p e n d i n g s l a v e s ∗ / wait ack ; /∗ wait u n t i l slave performed write ∗/ arb . r e l e a s e ( m a s t e r I d ) ; /∗ r e l e a s e t h e bus ∗/ }
Listing 30: Example of data transfer protocol TLM.
!
#" $% $"$
' ( &
!
"
#" % !% $"$
' ( &
Figure 32: Master identity through connectivity.
62
" %
33 34 35 36 37 38
/ ∗ SLAVE s i d e i m p l e m e n t a t i o n ∗ / /∗ l i s t e n t o t h e bus f o r a matching bus t r a n s a c t i o n ∗/ b i t [ 1 ] l i s t e n ( b i t [ 3 1 : 0 ] ∗A, b i t [ 3 1 : 0 ] M, b i t [ 1 ] W, b i t [ 1 ] WM) { do { w a i t ( busReq ) ; / ∗ w a i t u n t i l m a s t e r i n i t i a t e s b u s t r a n s a c t i o n ∗ / } w h i l e ( ( ( busAddr & M) ! = ( ∗A & M) ) | | ( ( b u s C t r l [ 1 ] ) & M ! = W) ) ;
39
∗A = busAddr ; return b u s C t r l [ 1 ] ;
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
} / ∗ s e r v e a w r i t e i n i t a t e d by t h e m a s t e r , h e n c e a r e a d f o r s l a v e ∗ / v o i d s e r v e W r i t e L o n g ( b i t [ 3 1 : 0 ] ∗D) { waitfor (5000); /∗ simulate access time ∗/ ∗D = b u s D a t a ; / ∗ r e a d b u s d a t a ∗ / n o t i f y ( ack ) ; / ∗ i n d i c a t e m a s t e r we a r e done ∗ / } / ∗ s e r v e a r e a d i n i t a t e d by t h e m a s t e r , h e n c e a w r i t e f o r s l a v e ∗ / v o i d s e r v e R e a d L o n g ( b i t [ 3 1 : 0 ] D) { waitfor (5000); /∗ simulate access time ∗/ busData = D; /∗ w r i t e data t o bus ∗/ n o t i f y ( ack ) ; / ∗ i n d i c a t e m a s t e r we a r e done ∗ / }
57 } ;
Listing 30: Example of data transfer protocol TLM (continued).
1 import ” IMyCPU Bus ” ; 2
3 i n t e r f a c e IMyCPU Bus Master Ident { 4 5 6 }; 7
void readLong ( b i t [ 3 1 : 2 ] addr , b i t [ 3 1 : 0 ] ∗ data , unsigned i n t m a s t e r I d ) ; void writeLong ( b i t [ 3 1 : 2 ] addr , b i t [ 3 1 : 0 ] data , unsigned i n t m a s t e r I d ) ;
8 /∗ channel adds master
i d e n t i f i c a t i o n ( needed f o r a r b i t r a t i o n ) ∗/ MyCPU Bus Protocol TLM Ident ( IMyCPU Bus Master Ident protTlm , in unsigned i n t m a s t e r I d ) implements IMyCPU Bus Master
9 channel 10 11 12 { 13 14 15 16 17 18 19
void readLong ( b i t [ 3 1 : 2 ] addr , b i t [ 3 1 : 0 ] ∗ d a t a ) { protTlm . readLong ( addr , data , m a s t e r I d ) ; } void writeLong ( b i t [ 3 1 : 2 ] addr , b i t [ 3 1 : 0 ] d a t a ) { protTlm . writeLong ( addr , data , m a s t e r I d ) ; }
20 21 } ;
Listing 31: Adapter channel for defining master identity.
63
accesses to shared memories connected to the bus. Mandatory data link models provide primitives to create point-topoint logical links for exchanging data between two communication partners attached to the bus. Optional memory access models are required if the bus supports shared memories and addressing of and access to PE storage. In both cases, media access layer models can consist of separate implementations for use in bus master and bus slave type PEs.
1 i n t e r f a c e IMyCPU Bus TLM Arb { 2 3 4 5 };
void a c q u i r e ( unsigned i n t masterNr ) ; void r e l e a s e ( unsigned i n t masterNr ) ; bool a t t e m p t ( unsigned i n t masterNr ) ;
Listing 32: Interface for the TLM arbitration channel. arbitration will be implemented in a single channel, which is beneficial for high execution performance. Listing 32 shows the interface of the arbitration channel. Listing 33 shows an actual implementation of the arbitration. This example makes use of a passive arbitration. A bus state is kept (in grantedMaster), and a master that requests the bus while it is idle immediately gains bus access. At the release of the bus, the request lines (in request[]) are checked again, and the bus is granted to the highest requester. In case no master is requesting the bus, the status of the bus is set back to idle.
5.4
5.4.1
General Format
mac_model = mac_channel | mac_behavior mac_channel = channel mac_name ’(’ port_list ’)’ implements interface_name ’{’ internal_declarations_opt ’}’ ’;’ mac_behavior = behavior mac_name ’(’ port_list ’)’ implements interface_name ’{’ internal_declarations_opt ’}’ ’;’
Media Access Layer
Media access layer models abstract accesses to the actual physical medium through the protocol into canonical interfaces for regulated, non-conflicting exchange or communication of data of arbitrary size and type. Hence, the media access layer regulates conflicting bus accesses in case the bus supports multiple masters through the bus arbitration protocol, and it slices data chunks into bus words or frames that are transmitted using the primitives (and possibly choosing among modes) of the bus data transfer protocol. Note that in the presence of a synchronization protocol that is part of the bus, the media access layer does not employ this protocol to implement any additional synchronization. For cases where the bus does not contain an inherent synchronization protocol (as is the case, for example, with most bit-serial bus protocols), the media access layer can optionally implement synchronization using special primitives, if available, of the underlying data transfer protocol in combination with an active media access layer model. In this case, the media access layer provides fully blocking transfers with built-in two-way synchronization. In the general case, however, the media access layer simply inherits the synchronization semantics from the underlying data transfer protocol and any additional synchronization will be implemented using the synchronization protocol, if available, or via other means (e.g. polling in a master/slave arrangement or through special data messages). The media access layer consists of two parts, models for implementation of bi-directional data links and models for
Figure 33: Format of media access layer models. The general format of media access layer models is shown in Figure 33. In the same manner as protocol layer models (see Section 5.2.1), active or passive media access layer models can be created through SpecC behavior or channel definitions, respectively. Media access models connect to underlying protocol layer models for data transfers and arbitration through ports of corresponding interface type. For use by higher-level models, a media access model has to define a set of methods in its body and export them through an implemented interface. Since they will be accessed and used by automatically generated code, media access layer interfaces have to adhere to a certain canonical format. As defined in Figure 34, a media access layer interface defines a set of methods for transferring a block of data over the bus using a bus address to distinguish between different logical connections made over the same physical bus. Consequently, a media access method has no return value and takes three parameters: an (optional) bus address of integral type corresponding to the range of addresses available on the bus (or no such parameter for busses with zero address width), a pointer to a data block, and the size of the data block in bytes. A media access layer interface has to define methods for reading and writing a block of data from/to the bus where the names of 64
1 import ” IMyCPU Bus TLM Arb ” ; 2 # d e f i n e MAX MASTERS 2 3
4 c h a n n e l MyCPU Bus Protocol TLM Arb ( ) 5 6 7 8 9 10 11 12
implements IMyCPU Bus TLM Arb event awaitGrant ; b o o l r e q u e s t e d [MAX MASTERS ] ; u n s i g n e d i n t g r a n t e d M a s t e r = −1;
/ ∗ r e q u e s t t h e bus , b l o c k u n t i l g r a n t e d ∗ / void a c q u i r e ( unsigned i n t masterNr ) { r e q u e s t e d [ masterNr ] = true ; /∗ s e t the request ” l i n e ”
13 15 16 17 18 19 20 22 23 24 25 26 27 28
} / ∗ r e l e a s e t h e b u s and g r a n t i t t o t h e n e x t w a i t i n g m a s t e r ∗ / void r e l e a s e ( unsigned i n t masterNr ) { unsigned i n t i ; r e q u e s t e d [ masterNr ] = f a l s e ; /∗ r e l e a s e r e q u e s t ” l i n e ” ∗/ g r a n t e d M a s t e r = −1; / ∗ s t a r t w i t h no g r a n t e d m a s t e r ∗ / f o r ( i = 0 ; ! r e q u e s t e d [ i ] && i < MAX MASTERS ; i + + ) ; / ∗ f i n d h i g h e s t p r i o ∗ /
29
i f ( i = 4 ; l e n −= 4 , p += 4 ) p r o t o c o l . writeLong ( addr [ 3 1 : 2 ] , (∗ p ) [ 7 : 0 ] @ ( ∗ ( p + 1 ) ) [ 7 : 0 ] @ (∗( p +2))[7:0] @ (∗( p +3))[7:0]); f o r ( ; l e n ; l e n −−, p ++) p r o t o c o l . w r i t e B y t e ( a d d r , ∗p ) ;
11 12 13 14 15 16 17 18 19 20 21
} void masterLinkRead ( unsigned long addr , void ∗ data , unsigned long l e n ){ u n s i g n e d char ∗ p ; bit [31:0] l ; bit [7:0] b ;
22
f o r ( p = ( u n s i g n e d char ∗ ) d a t a ; l e n >= 4 ; l e n −= 4 , p += 4 ) { p r o t o c o l . r e a d L o n g ( a d d r [ 3 1 : 2 ] , &l ) ; ∗p = l [ 3 1 : 2 4 ] ; ∗ ( p + 1 ) = l [ 2 3 : 1 6 ] ; ∗ ( p + 2 ) = l [ 1 5 : 8 ] ; ∗ ( p +2)= l [ 7 : 0 ] ; } f o r ( ; l e n ; l e n −−, p ++) { p r o t o c o l . r e a d B y t e ( a d d r , &b ) ; ∗p = b ; }
23 24 25 26 27 28 29 30 31
}
32 } ;
Listing 35: Example of master media access layer data link model.
69
1 import ” M y D S P B u s P r o t o c o l ” ;
2 import ” IMyDSP Bus Access ” ;
/ / physical layer / / MAC i n t e r f a c e
3
4 c h a n n e l MyDSP Bus SlaveLink ( IMyDSP Bus Slave p r o t o c o l ) 5 6 { 7 8 9
implements I M y D S P B u s A c c e s s S l a v e L i n k
void s l a v e L i n k W r i t e ( unsigned long addr , void ∗ data , unsigned long l e n ){ b i t [ 3 1 : 0 ] a , d ; u n s i g n e d char ∗ p ; a = addr ;
10
f o r ( p = ( u n s i g n e d char ∗ ) d a t a ; l e n >= 4 ; l e n −= 4 , p += 4 ) { p r o t o c o l . l i s t e n (&a , 0xFFFFFFFF , 1b , 1b ) ; d = (∗ p ) [ 7 : 0 ] @ ( ∗ ( p + 1 ) ) [ 7 : 0 ] @ ( ∗ ( p + 2 ) ) [ 7 : 0 ] @ ( ∗ ( p + 3 ) ) [ 7 : 0 ] ; p r o t o c o l . serveReadLong ( d ) ; }
11 12 13 14 15 16
f o r ( ; l e n ; l e n −−, p ++) { p r o t o c o l . l i s t e n (&a , 0xFFFFFFFF , 1b , 1b ) ; p r o t o c o l . serveReadByte (∗ p ) ; }
17 18 19 20 21 22 23 24 25
} void slaveLinkRead ( unsigned long addr , void ∗ data , unsigned long l e n ){ u n s i g n e d char ∗ p ; b i t [ 3 1 : 0 ] l , a ; b i t [ 7 : 0 ] b ; a = addr ;
26
f o r ( p = ( u n s i g n e d char ∗ ) d a t a ; l e n >= 4 ; l e n −= 4 , p += 4 ) { p r o t o c o l . l i s t e n (&a , 0xFFFFFFFF , 0b , 1b ) ; p r o t o c o l . s e r v e W r i t e L o n g (& l ) ; ∗p = l [ 3 1 : 2 4 ] ; ∗ ( p + 1 ) = l [ 2 3 : 1 6 ] ; ∗ ( p +2)= l [ 1 5 : 8 ] ; ∗ ( p +3)= l [ 7 : 0 ] ; }
27 28 29 30 31 32
f o r ( ; l e n ; l e n −−, p ++) { p r o t o c o l . l i s t e n (&a , 0xFFFFFFFF , 0b , 1b ) ; p r o t o c o l . s e r v e W r i t e B y t e (&b ) ; ∗p = b ; }
33 34 35 36 37 38
}
39 } ;
Listing 36: Example of slave media access layer data link model.
70
1 import ” M y D S P B u s P r o t o c o l ” ; 2
3 import ” IMyDSP Bus Access ” ;
/ / physical layer / / MAC i n t e r f a c e
4
5 c h a n n e l MyDSP Bus MemAccess ( IMyDSP Bus Master p r o t o c o l ) 6 7 { 8 9
implements IMyDSP Bus Access Master Mem
v o i d masterMemWrite ( u n s i g n e d l o n g a d d r , v o i d ∗ d a t a , u n s i g n e d l o n g l e n ) { u n s i g n e d char ∗p ;
10
f o r ( p = ( u n s i g n e d char ∗ ) d a t a ; l e n && ( a d d r % 4 ) ; p ++ , l e n −−) p r o t o c o l . w r i t e B y t e ( a d d r ++ , ∗p ) ; f o r ( ; l e n >= 4 ; p += 4 , l e n −= 4 ) p r o t o c o l . writeLong ( addr [31:2]++ , (∗ p ) [ 7 : 0 ] @ ( ∗ ( p + 1 ) ) [ 7 : 0 ] @ (∗( p +2))[7:0] @ (∗( p +3))[7:0]); f o r ( ; l e n ; p ++ , l e n −−) p r o t o c o l . w r i t e B y t e ( a d d r ++ , ∗p ) ;
11 12 13 14 15 16 17 18 19 20 21 22 23
} v o i d masterMemRead ( u n s i g n e d l o n g a d d r , v o i d ∗ d a t a , u n s i g n e d l o n g l e n ) { u n s i g n e d char ∗p ; bit [31:0] l ; bit [7:0] b ;
24
f o r ( p = ( u n s i g n e d char ∗ ) d a t a ; l e n && ( a d d r % 4 ) ; p ++ , l e n −−) { p r o t o c o l . r e a d B y t e ( a d d r ++ , &b ) ; ∗p = b ; } f o r ( ; l e n >= 4 ; p += 4 , l e n −= 4 ) { p r o t o c o l . r e a d L o n g ( a d d r [ 3 1 : 2 ] + + , &l ) ; ∗p = l [ 3 1 : 2 4 ] ; ∗ ( p + 1 ) = l [ 2 3 : 1 6 ] ; ∗ ( p + 2 ) = l [ 1 5 : 8 ] ; ∗ ( p +3)= l [ 7 : 0 ] ; } f o r ( ; l e n ; p ++ , l e n −−) { p r o t o c o l . r e a d B y t e ( a d d r ++ , &b ) ; ∗p = b ; }
25 26 27 28 29 30 31 32 33 34 35 36 37
}
38 } ;
Listing 37: Example of master media access layer memory access model.
71
1 import ” M y D S P B u s P r o t o c o l ” ;
2 import ” IMyDSP Bus Access ” ;
/ / physical layer / / MAC i n t e r f a c e
3
4 c h a n n e l MyDSP Bus MemServe ( IMyDSP Bus Slave p r o t o c o l ) 5 6 { 7
implements IMyDSP Bus Access Slave Mem void
memServe ( u n s i g n e d l o n g a d d r , v o i d ∗ d a t a , u n s i g n e d l o n g l e n , bool readEnable , bool w r i t e E n a b l e ) { b i t [ 3 1 : 0 ] a , m, d ; unsigned b i t [ 1 ] t , write , writeMask ; unsigned long i; u n s i g n e d char ∗ p ; a = addr ; m = ( len −1); m = ˜m;
8 9 10 11 12 13 14 15 16
write = writeEnable ; w r i t e M a s k = ! ( w r i t e E n a b l e && r e a d E n a b l e ) ;
17 18 19
t = p r o t o c o l . l i s t e n (&a , m, w r i t e , w r i t e M a s k ) ;
20 21
i f ( ( a d d r = a − a d d r ) >= l e n ) return ; l e n −= a d d r ; p = ( u n s i g n e d char ∗ ) d a t a + a d d r ;
22 23 24 25 26
if ( t ) { p r o t o c o l . s e r v e W r i t e L o n g (&d ) ; f o r ( i = 0 ; ( i < 4 ) && l e n ; i ++ , l e n −−, p ++) { ∗p = d ; d ” , {{{ ” s t a t u s ” } , { ” == ” , {{{ ” s t a t u s ” } , { ” ! = ” , {{{ ” s t a t u s ” } , { ”
