Dongwan Shin

System-On-Chip Component ModelsAndreas GerstlauerLukai CaiDongwan ShinRainer D¨o merDaniel D.GajskiTechnical Report CECS-03-26August11,2003Center for Embedded Computer SystemsUniversity of California,IrvineIrvine,CA92697-3425,USA(949)824-8919System-On-Chip Component ModelsAndreas GerstlauerLukai CaiDongwan ShinRainer D¨o merDaniel D.GajskiTechnical Report CECS-03-26August11,2003Center for Embedded Computer SystemsUniversity of California,IrvineIrvine,CA92697-3425,USA(949)824-8919{gerstl,lcai,dongwans,doemer,gajski}@AbstractThis 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),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 ing information in this report,specific database formats for diverse SoC designflows can be developed.Specifically,the database format in this report is used successfully in our SoC Design Environment,SCE.Contents1Introduction1 2General Database Format12.1Database Organization (1)2.2Component Format (2)2.2.1Attributes (2)2.2.2Parameters (2)2.2.3Weight Tables (4)2.2.4Item Types for Metric Set (6)2.2.5Data Types for Metric Set (6)2.2.6Default Values (8)3Processing Elements83.1PE Behaviors (8)3.1.1General Format (9)3.1.2Attributes (9)3.1.3Weight Tables (11)3.1.4Memory Tables (11)3.1.5Computation Functionality (11)3.1.6Memory (13)3.2Bus-Functional PE Models (13)3.2.1Bus-Functional Layer (16)3.2.2Hardware Abstraction Layer (16)3.2.3Interrupt Handling (18)3.2.4IP Adapters (20)3.3Cycle-Accurate PE Models (22)3.3.1Instruction Set Models (25)3.3.2IP Models (25)4Bus Protocols254.1Bus Channels (27)4.1.1General Format (27)4.1.2Attributes (29)4.1.3Weight Tables (29)4.2Physical Layer (31)4.2.1General Format (31)4.2.2Data Transfer Protocol (32)4.2.3Synchronization Protocol (32)4.2.4Arbitration Protocol (32)4.3Media Access Layer (34)4.3.1General Format (34)4.3.2Data Links (35)4.3.3Memory Access (35)5RTL Units395.1RTL Behaviors (39)5.1.1General Format (39)5.1.2Attributes (40)5.1.3Operations (42)5.2Examples (42)5.2.1Functional units (42)i5.2.2Storage units (42)5.2.3Busses (42)References42 A Manual Pages54A.1scc-SpecC Compiler (55)A.2sirList of Figures1Format of component attribute annotations (2)annotation (3)2Format of P A R A M E T E R S3Format of item header annotations (4)4Format of data header annotations (7)5Format of weight annotations (7)6Format of PE behaviors (9)7Format of PE behavior memory interfaces (13)8Format of bus-functional PE models (15)9Format of hardware abstraction layer(HAL)for bus-functional PE models (16)10Format of IP adapters (20)11Format of bus channels (27)12Format of physical layer protocol models (31)13Format of media access layer models (34)14Format of media access layer interfaces (36)15Format of RTL unit behavior models (39)16Format of OPERATIONSannotation (41)iiiList of Tables1Example of a profiling table (4)2Example of the operation weight table of a DSP (4)3Example of a weighted result (4)4Example of a traffic weight table (6)5Example of a memory weight table (6)6Item types for operation metric set(operations) (6)7Item types for operation metric set(statements) (7)8Item types for traffic metric set (7)9Item types for memory metric set (7)10Data types for metric sets (8)11An alternative operation weight table of the DSP (8)12General annotations for behavioral PE models (10)13PE behavior attribute annotations (10)14PE behavior weight annotations (12)15Header annotations for operation metrics (12)16Header annotations for traffic metrics (12)17PE behavior memory table annotations (12)18Header annotations for memory tables (12)19Memory interface annotations (14)20Bus-functional PE model annotations (17)21General annotations for bus protocol channels (28)22Bus channel attribute annotations (30)23Bus channel weight annotations (30)24Header annotations for traffic metrics (32)26Classification of RTL units (39)25General annotations for RTL unit behavior (40)27RTL unit data types (40)30RTL unit port types (40)28RTL behavior attribute annotations (41)29RTL unit port attribute annotations (41)31operators in OPERATIONS (43)ivList of Listings1Database organization example (3)2Component attributes example (3)3Parameterized component example (5)4Component weight table example (5)5PE behavior example (10)6Example of PE behavior for IP with given functionality (14)7Example of PE behavior for system memory (14)8Example of bus-functional PE model for simple IP (17)9Example of bus-functional model for programmable PE (19)10Example of bus-functional model for PE with interrupt controller (20)11Example of interrupt controller model (23)12Example of IP adapter model (24)13Example of instruction set simulation(ISS)PE model (26)14Bus channel example (30)15Example of a data transfer protocol interface (33)16Example of data transfer protocol model (33)17Example of synchronization protocol model (34)18Example of media access layer interface (36)19Example of media access layer data link model (37)20Example of media access layer memory access master model (38)21Example of OPERATIONSannotation (43)22Example of RTL unit (44)23Example of3-stage pipelined multiplier (46)24Example of register (49)25Example of registerfile (50)26Example of bus (53)vSystem-On-Chip Component ModelsA.Gerstlauer,L.Cai,D.Shin,R.D¨o mer,Daniel D.GajskiCenter for Embedded Computer SystemsUniversity of California,IrvineIrvine,CA92697-3425,USA{gerstl,lcai,dongwans,doemer,gajski}@AbstractThis report defines and describes a format for models of system components required for system-on-chip(SoC)de-sign.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.Gener-ally,databases are needed for processing elements(PEs), bus and other communication protocols,and RTL units.In this report we aim to provide an exhaustive list of require-ments for components in an automated SoC designflow us-ing 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 ing information in this report,specific database formats for diverse SoC designflows can be developed. Specifically,the database format in this report is used suc-cessfully in our SoC Design Environment,SCE.1IntroductionIn state-of-the-art designflows 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 designflows,the system is gradually synthesized and assembled using system com-ponents taken out of a set of databases.Specifically,an SoC designflow needs to include databases for processing elements(PEs),bus or other communication protocols,and RTL units.The processing element(PE)database contains pro-grammable processors,synthesizable custom hardware components,system memories,IPs,etc.at different levels of abstraction.Such PEs are used during the designflow to implement the computation of the system by mapping computational parts onto PEs taken out of the PE database.The bus protocol database contains timing-accurate de-scriptions of protocols of system busses and other com-munication structures used to implement communication between the different PEs in the system.Finally,the RTL unit database contains register-transfer units like registerfiles,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 de-scription.This report describes and defines a format of databases for use in automated SoC designflows,thereby outlining requirements for modeling components for system design in general.First,Section2defines the general format of the SoC databases.Then,in Section3,Section4,and Sec-tion5the specifics of the PE,bus,and RTL databases are described in detail,respectively.2General Database FormatOur 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 Inter-nal Representation)files using the SpecC compiler(‘scc’, Section A.1).2.1Database OrganizationFor each database,there is exactly one top-level SIRfile.The top-level database SIR acts as a container for all com-ponents stored in the database.The database SIR includes components through import of individual component SIR files where component SIRfiles 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 sep-arate SIRfiponent SIRs will be imported by SCE 1as needed throughout the designflow.Therefore,compo-nent SIRs must be self-contained.Furthermore,in case of parameterizable components,the component source code must be made available as part of the database,too.In case of databases with multiple models of each com-ponent at different levels of abstraction,each model can be stored in a separate SIRfile as long as the top-level database SIR contains all component models through di-rect 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 SCE will import those models when needed in the designflow.The advan-tage of separate componentfiles is that at any stage of the designflow,the system design will not contain any yet un-used component models.Since different models of components out of the differ-ent databases get imported into the same system design throughout the designflow,SIR design(import)names and identifiers defined in the SIRfiles must be unique across all databases and components.Furthermore,identifiers should be chosen appropriately to reduce conflicts with names de-fined in the system design itself.It is highly recommended to use unique prefixes for component names such that nam-ing conflicts are avoided.Listing1shows a simple example for database organi-zation.The database database(Listing1(c))contains two components,Component0and Component1,that are stored in separatefiles component0(Listing1(a))and component1(Listing1(b)),respectively.2.2Component FormatComponents 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 ob-ject.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 function-ality in the databases is for simulation purposes only and does not have to be synthesizable,i.e.apart from the re-strictions of the database format defined in this document, any valid SpecC code can be used.On top of SpecC code to describe functionality,addi-tional 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 at-tributes,parameters,and profiling weight tables.attribute=value|attribute_rangeattribute_range=’{’default_value’,’range_list’}’range_list=range_value|range_list’,’range_valuerange_value=value|’{’min’,’max’}’Figure1:Format of component attribute annotations.2.2.1AttributesComponent attributes describe characteristics or metricsfor a component.Attributes of a component are stored asannotations attached to the component object under differ-ent keys or names as defined by the database.The general format of the value of an attribute annota-tion is defined in Figure1.An attribute is either a simpleannotation giving afixed attribute value or a complex an-notation describing a range of possible values for an ad-justable attribute.For an adjustable attribute,the systemdesigner will be allowed to tune the attribute value duringallocation in the SoC design process within the range de-fined by the annotation.The range of values for an adjustable attribute is givenas a list of possible values.Each entry in the list is eithera single,fixed value or a pair of values defining the lowerand upper boundaries of an interval of values(for numerictypes only).Thefirst entry in the list must be a single valuedescribing a sensible default.In all cases,all values mustbe of the same type as defined by the attribute.Listing2shows an example of component attributeannotations.The annotations define afixed value of2.3for C O S Tand a range of values from0.0 up to60000000.0with a default of60000000.0forC L O C Kg e n’,S e c t i o n A.2)t o g e n e r a t e aimplementations of the component for use in the design asneeded.In case of components with multiple models,onlyparameters defined for the component model used during2(a)component0.sc(b)component1.sc(c)database.scListing1:Database organization example.PEPE FREQUENCY={0.6e+08,{0.0,6e7}};SIRint24Table1:Example of a profiling table. allocation are relevant and parameter values supplied to this model are reused to generate all subsequent models. Components are made parameterizable through the PARAMETERSannotation used by‘sirSIRgen’.For the purpose of inclusion in the database,components should be written in such a way that they compile with de-fault parameter values using the standard SpecC compiler (‘scc’,Section A.1)instead of‘sirDFLT of32for the parameter and uses this value if no value is supplied for BITWIDTH through‘sirfloat +1*4float +1*1223#i f n d e f BITWIDTH4#d e f i n e BITWIDTH BITWIDTHRTSIRDFLT,{{2u,64u}},”Width”,”b i t s”}15};1617void main(void){18sum=a+b;19}20};1behavior DSP();23note DSP.WEIGHT HEADERPE7n o t e DSP.WEIGHT DY6HEint24Table4:Example of a traffic weight table.int432Table5:Example of a memory weight table.lists the supported item and data types,respectively.The format of the values of the item header annotation and the data header annotation are defined in Figure3and Figure4. The available item types and data types are listed in Sec-tion2.2.4and Section2.2.5.Each metric contains one weight annotation.The items in the weight table are stored as one dimensional array rep-resented by a string,as defined in Figure5.Each value must be of integer type.Listing4shows an example of a component weight table annotation,which matches the example described earlier.2.2.4Item Types for Metric SetThe possible values for item types of operation metric sets are listed in Table6and Table7.An operation metric set defines values for basic operations(Table6)and ba-sic statements(Table7)corresponding to weights for the dataflow and controlflow complexity of the code.For the operation metric set,besides the items listed in Table6,each global function can be treated as an indepen-dent operation type.For example,if there is a global func-tion f loat 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 multiply-ing the weight of the entry in the row representing the item type”F1”and in the column representing the data type”float”(returning 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 Table8.The possible values of item types of the memory metric sets are listed in Table9.2.2.5Data Types for Metric SetOperation and traffic metric sets share the same set of pos-sible values of data types,which are listed in Table10. Besides the data types listed in Table10,data type an-notation can also contain three groups of hierarchial dataName Descriptionvoid void operation#1const data access operation#i identifer access operation()parenthesis operationthis”this”pointer access operation[]array access operationf()function call operation.member access operation->member pointer access operationp++post-increment operationp--post-decrement operation[:]bit slice operation++p pre-increment operation--p pre-decrement operation&p address deriving operation*p content deriving operation+x unary plus operation-x negation operation˜not operation!logic not operationsizeof(E)size of operation(on expression) sizeof(T)size of operation(on type)()x 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 operationTable6:Item types for operation metric set(operations).data_header=’"’data_list’"’data_list=data_type|data_list’,’data_typeFigure4:Format of data header annotations.weight=’"’weight_list’"’weight_list=value|weight_list’,’valueFigure5:Format of weight annotations.Name 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 operationTable6:Item types for operation metric set(operations) (continued).Name Description:labeled statement{}compound statement*+expression statementif if statementelse else statementswitch switch statementcase case statementdefault default statementwhile while statementdo do statementfor for statementgoto goto statementcontinue continue statementbreak break statementreturn return statementpar par statementpipe pipe statementexception exception statementtiming timing statementfsm fsm statementfsmd fsmd statementwait wait statementwaitand waitand statementwaitfor waitfor statementnotify notify statementnotifyone notifyone statementTable7:Item types for operation metric set(statements).Name Descriptionin input trafficout output trafficTable8:Item types for traffic metric setName Descriptionlocal local variable storage(stack memory) global global/static variable storage(static andheap memory)Table9:Item types for memory metric setName Descriptionbool boolchar charunsigned char unsigned char short int short intunsigned short int unsigned short int int intunsigned int unsigned intlong int long intunsigned long int unsigned long int long long int long long int unsigned long long int unsigned longlong intfloatfloatdouble doublelong double long doublevoid void(for returnvalue of function) event eventvoid*pointerTable10:Data types for metric sets.types.Bit vector We can define bit vectors with different lengths as different data types.The corresponding data type format is”bit[size]”or”unsigned bit[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.Array We can define arrays with different lengths as dif-ferent data types.The corresponding data type for-mat is basicfloat2*403.1.1General Formatpe_behavior=behavior pe_name ports_opt interfaces_optbody_opt’;’ports_opt=<nothing>|’(’’)’|’(’channel_port_list’)’channel_port_list=channel_port|channel_port_list’,’channel_portchannel_port=interface_name|interface_name port_nameinterfaces_opt=<nothing>|implements interface_listbody_opt=<nothing>|’{’internal_declarations_opt’}’Figure6:Format of PE behaviors.A PE behavior is created through a special SpecC be-havior declaration or definition.The format of PE behav-iors is shown in Figure6.The name of the SpecC behav-ior defines the name of the PE component.For PEs with fixed computation functionality,the PE behavior has ports of abstract,message-passing interface type and an internal or external body(Section3.1.5).PE behaviors carry a number of annotations for general database management,attributes(Section3.1.2),and op-tional parameters(see Section2.2.2).Table12lists the general annotations that are attached to PE behaviors for database management and in order to describe basic information about the corresponding pro-cessing element.In detail,the following annotations are supported:LIBRARY Name describing the PE database the be-havior is a member ed to distinguish between PE and other behaviors,i.e.required for PE behaviors.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 selec-tion.COMMENT Brief description of the PE that will be used and displayed as an aid during selection and al-location.BFPE MODEL Name of the behavior providing a cycle-accurate implementation model of the PE.The named behavior has to exist in the PE database.Required for PEs that have pre-defined,fixed hardware implemen-tation.See Section3.3.Listing5shows 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.In addition,bus-functional and cycle-accurate models MyDSP ISS of the PE are made available.3.1.2AttributesBasic 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 Section2.2.1.Specifically,the following at-tributes can be attached to PEs(Table13):CLOCKPEPEPEPE WIDTH Number of bits in a PE in-struction word,i.e.width of the internal instruction bus.DATAPE WIDTH Number of bits in a basic machine character,i.e.width of smallest addressable unit.DATAName Description Default LIBRARY Name of parent PE database–CATEGORY Name of PE category””COMMENT PE description””BF String PE MODEL Name of cycle-accurate PE model–Table12:General annotations for behavioral PE models.PEPEPE example”;5note MyDSP.BF BF”;6note MyDSP.CA ISS”;Unit Default CLOCK Hz0.0 MIPS Throughput double PE0.0 POWER Power consumption double PE WIDTH Instruction word width uintPE WIDTH Data word width uintPE WIDTH Machine character width uintPE MEMORY Size of internal data memory uintPE MEMORY Size of internal program memory uintPEbeha vior with a certain iteters by a storage unit(suchweight table represents thWEIGHT DYNha vior is accessed once.ior.It equals to the traffimetric represents the portThis is used to compute tthe”char”data type in thetype in the PE.The machisystem beha vior with aacters by a storage unitweight table represents tWEIGHT STAthe design.One design metric represetype in the PE.execute an operation withweight table represents tWEIGHT Dto the PE.ha vior contains after synthsents the number of contrtem beha vior to the PE.Fothe system beha vior contmetric represents the numFor general purpose procetype and data type in the Por control word for an opweight table represents thSName Metric Type PEPEspeeds.The IP model is a black-box model used for sim-ulation 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 inter-nal or external.In the former case,the SIRfile of the PE contains a complete SpecC definition of the PE behaviorincluding its body.In the latter case,the PE database pro-vides a shared library with the PE behavior’s body to be linked against the design for simulation.The shared li-brary 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 fol-lowing interface types out of the standard SpecC channel library:•i receiver,or ityped typedtypedPEBF”behavior of the PE database(since the memory has afixed,pre-defined pin level interface).Since the PE is a pure system memory t can not provide any computational functionality(IP w fixed but empty computation,see Section3.1.5),the mem ory’s PE behavior does not have any ports and themainmethod is empty.3.2Bus-Functional PE ModelsFor PEs withfixed,pre-defined interfaces and communi-cation functionality,the PE database has to contain a bus-functional model of the PE.A bus-functional PE modelaccurately describes the PE interface at the pin-level andit provides a simulation-model of the PE’s communicationaspects on top of any computation functionality as definedby the PE’s behavioral model,if any(see Section3.1).Bus-functional models can be thought of as additional communication layers that wrap around the PE behavioralmodel.A bus-functional model can consist of several lay-ers of behaviors that create a hierarchy or tree of behav-ior instantiations.At minimum,a top-level bus-functionallayer has to exist that provides a pin-accurate model of thePE.Through this layer and its optional sublayer instancehierarchy,the bus-functional PE model describes the com-munication behavior of the PE at its pins and it has to pro-vide the same computational functionality as the PE’s be-havioral model.For IPs withfixed computation and communicationfunctionality the bus-functional IP model provides atiming-and data-accurate descriptions in terms of signalsthat can be observed at the PE’s pins.Bus-functional IPmodels only have to provide a single bus-functional layer。