Successfully reported this slideshow.
Transaction Level Modeling: An Overview                                                            Lukai Cai and Daniel Ga...
proposed by SCE [6] that starts design from the system be-havior representing the designs functionality, generates asystem...
+                            Y                                                                         addressll5:0]      ...
Models                             Communication      Computation      Communication            P E interface             ...
ValWnon                                                     dOMl”             which has cycle/pin accurate communication a...
bus protocols, and refine time-accurate bus p r o                         and present the system level design flow and maj...
Upcoming SlideShare
Loading in …5
×

Transaction level modeling an overview

337 views

Published on

Published in: Technology
  • Be the first to comment

Transaction level modeling an overview

  1. 1. Transaction Level Modeling: An Overview Lukai Cai and Daniel Gajski Center for Embedded Computer Systems University of California, lrvine Irvine, CA 92697, USA {lcai,gajski}@cecs.uci.eduABSTRACTRecently, the transaction-level modeling has been widely r eferred t o in system-level design community. However, the . Communicationtransaction-level models(TLMs) are not well defined and theusage of TLMs in the existing design domains, namely mod- A. Speclfhtion modeleling, validation, refinement, exploration, and synthesis, is B. component-assemblymodelnot well coordinated. This paper introduces a TLM taxon- c. Bur-arbilrationmade1omy and compares the benefits of TLMs use.Categories and Subject DescriptorsC.0 [ C o m p u t e r S y s t e m s Organisation]: General U". -6- * timed Appmximate- Cycie- ComputationGeneral Terms timed timedDesign F i g u r e 1: System modeling graphKeywordsTransaction level model, modeling, validation, refinement, TLMs cannot be easily reused, but also the usage of TLMsexploration, synthesis in the existing design domains, namely modeling, validation, refinement, exploration, and synthesis, cannot be systemat-1. INTRODUCTION ically developed. Consequently, the inherent advantages of In order to handle the ever increasing complexity of system. TLMs dont effectively benefit designers. In order t o elim-on-chips (SoCs) and time-termarket pressures, the design inate some ambiguity of TLMs, this paper attempts t o ex-abstraction has been raised to the system level in order t o plicitly define several transaction-level models, each of whichincrease design productivity. This higher level of abstrac- is adopted for different design purpose. It also explores thetion generated large interest in transaction-level modeling, usage of defined TLMs under a general design flow and an-synthesis, and verification [lO][lZ]. alyzes how the TLMs are used in the design domains. In a transaction-level model (TLM), the details of com- This paper is organized as follows: Section 2 reviews themunication among computation components are separated related work; Section 3 defines four TLMs; Section 4 in-from the details of computation components. Communica- troduces the usage of TLMs in different design domains;tion is modeled by channels, while transaction requests take Finally, the conclusion is given in section 5.place by calling interface functions of these channel models.Unnecessary details of communication and computation are 2. RELATED WORKhidden in a TLM and may be added later. TLMs speed up The concept of TLM first appears in system level lan-simulation and allow exploring and validating design alter- guage and modeling domain. [lo] defines the concept ofnatives at the higher level of abstraction. a channel, which enables separating communication from However, the definition of TLMs is not well understood. computation. It proposes four well-defined models at differ-Without clear definition of TLMs, not only the predefined ent abstraction levels in a top-down design flow. Some of these models can be classified as TLMs. However, the capa- bilities of TLMs are not explicitly emphasized. [lZ] broadlyPermission to make digital or hard copies of all or part of this work for describes the TLM features based on the channel conceptpersonal or classmom use is granted without fee pmvided that copies are and presents some design examples. However, the TLMsnot made or distributed for profit or commercial advantage and that copies are not well defined and the usage of TLMs in the existingbear this notice and the full citation on the first page. To copy otherwise, to design domains is not addressed. [lo] [12] also demonstraterepublish,to post an servers or to redistribute to lists. requires pnor specific that both SpecC [3] and SystemC [2] support transactionpermission and/or a fee.CODES+ISSSO3, October 1-3,2003, Newport Beach, Califomia,USA. level modeling using the channel concept.CopMght 2003 A M 1-58113-742-7/03/0010 ...$5.00. C The TLMs can be used in top-down approaches such a s 19
  2. 2. proposed by SCE [6] that starts design from the system be-havior representing the designs functionality, generates asystem architecture from the behavior, and gradually reachesthe implementation model by adding implementation de-tails. In comparison to the topdown approaches, meet-in-the-middle approaches [13] map the system behavior to m "1 = aa:the predefined system architecture, rather than generatingthe architecture from the behavior. An example of meet-in-the-middle approach is VCC 1 1 for architecture estima- 5tion/exploration and N2C [l]for interface synthesis. Un-like above two approaches, bottom-up approaches assem-ble the existing computation components by inserting wrap-pers among them. Bottom-up approaches, such as proposedin [9], focus on component reuse and wrapper generation.All of above three design practices fully or partly cover thedesign from the system behavior to the detailed system im-plementation, which exhibits great potential of employingTLMs. U Some other research groups have applied TLMs in thedesign. [14] adopts TLMs to ease the development of em- F i g u r e 2: The e x a m p l e of specification modelbedded software. [15] defines a TLM with certain proto-col details in a platform-based design, and uses it to inte-grate components a t the transaction level. [ll]implementsco-simulation across-abstraction level using channels, whichimplies the usage of TLM. Each of above research addressesonly one limited aspect of TLMs.3. TRANSACTION LEVEL MODELS In order to simplify the design process, designers gener-ally use a number of intermediate models. The intermedi- Qate models slice the entire design into several smaller design Istages, each of which has a specific design objective. Sincethe models can be simulated and estimated, the result ofeach of these design stages can be independently validated. In order to relate different models, we introduce the sys-tem modeling graph (shown in Figure 1) 181. X-axis in thegraph represents computation and y-axis represents com-munication. On each axis, we have three degrees of timeaccuracy: un-t,imed, approximate-timed. and cycle-timed. Figure 3: The e x a m p l e of c o m p o n e n t - a s s e m b l yUn-timed computation/communication represents the pure modelfunctionality of the design without any implementation de-tails. Approximate-timed computation/communication con-tains system-level implementation details, such as the se- channel concept, which eases to convert C/C++ languagelected system architecture, the mapping relations between to SystemC/SpecC language. Specification model is an uu-processes of the system specification and the processing el- timed model. Figure 2 displays an example of specificationements of the system architecture. The execution time for model. Processes B1, B2B3, and B4 execute sequentially.approximate-timed computatiou/communicatiun is usually 82B3 is a parallel composition of B2 and 83. Variables v f ,estimated a t the system level without cycle-accurate RTL v2 and v3 are used to transfer data among processes. (register transfer level) /ISS (instruction set simulation) level C o m p o n e n t - a s s e m b l y m o d e l . The entities a t the topevaluation (51. Cycle-timed computation/communication con- level of the model represent concurrently executing process-tains implementation details at both system level and the ing elements (PES) and global memories, which commu-RTL/ISS level, such that cycle-accurate estimation can be nicate through channels. A PE can be a custom hard-obtained. ware, a general-purpose processor, a DSP, or an IP. The Inspired by [lo] [12], we define six abstraction models in channels are message passing channels, which only repre-the system modeling graph, which are indicated by circles. sent data transfer or process synchronization between PESAmong them, component-assembly model, bus-arbitration without any bus/protocol implementation. The communi-model, bus-functional model, and cycle-accurate computa- cation part of the model (channel) is un-timed, while com-tion model are TLMs, which are indicated by shaded circles. putation part of the model (PE) is timed by approximately Specification model. It describes the system function- estimating the execution on specific PE. The estimated timeality and is free of any implementation details. This model of computation is computed by system-level estimator suchis similar to the specification model in [lo] and untimed as [SI. The estimated time is annotated into the code byjunctional model in 1121. It can model the data transfer inserting wait statements. Component-assembly model isbetween processes through variable accessing without using the same as architecture model defined in [lo] and belongs 20
  3. 3. + Y addressll5:0] (Arbiter) datal3t:Ol "1 = aa: 1 A "1 + bb CLK 1 . Master interface 2.slave lnisrface addressll5:0] -+ -) 3. Arbiter interface F i g u r e 4: The e x a m p l e of bus-arbitration model daIa[3l:O] ready ack , (b)Cycle accurate time diagramto timed functional model defined in [ 1 2 ] . In compari-son to specification model, component-assembly model ex- F i g u r e 5: Time/cycle a c c u r a t e d i a g r a mplicitly specifies the allocated PES in the system architec-ture and process-twPE mapping decision. The example ofcomponent-assembly model is displayed in Figure 3. PE1,PE2 and PE3 are three allocated PES. cull, cul2, cv2 arethe message-passing channels. Bus-arbitration model. In comparison to component-assembly model, channels between PES in bus-arbitration P (Arbiter)model represent buses, which are called abstract bus chan-nels. The channels still implement data transfer throughmessage passing, while bus protocols can be simplified asblocking and nonblocking 1 0 No cycle-accurate and pin- 1.accurate protocol details are specified. The abstract buschannels have estimated approximate time, which is speci-fied in the channels by one wait statement per transaction. 1. Master interfaceBecause several channels may be grouped to one abstract 2. Slave interfacebus channel, two parameters are added to the interface func- 3. Arbiter interfacetions of channels: logical address and bus priority. Logicaladdress distinguishes interface function calls of different PESor processes; bus priority determines the bus access sequencewhen bus conflict happens. Furthermore, a bus arbiter is in- F i g u r e 6: The e x a m p l e of bus-functional modelserted into the system architecture as a new P E to arbitratethe bus conflict. Master PES, slave PES, and the arbiter callthe functions of different interfaces of the same abstract bus In hus-functional model, the messagopassing channels arechannels. replaced by protocol channels. A protocol channel is time/cycle Figure 4 illustrates an example of busarbitration model accurate and pin-accurate. lnside a protocol channel, wiresrefined from component-assembly model in Figure 3. The of the bus are represented by instantiating correspondingthree channels in component-assembly model are encapsu- variables/signals. Data is transferred following the time/cyclelated into an abstract bus channel representing a system bus. accurate protocol sequence. At its interface, a protocolIn order to access the new channel, the bus masters (PE1 channel provides functions for all abstraction bus transac-and P E 2 ) , the bus slave ( P E 3 ) , and the inserted arbiter tion. A protocol channel is the same as a protocol channel (PE4) use different channel interfaces. of [lo]. We call an abstract bus channel containing a pr* Bus-functional model. I t contains time/cycle accurate tocol channel a detailed bus channel. It should be notedcommunication and approximate-timed computation. Two that in the bus-functional model, it is not necessary to re-types of bus-functional model are specified: time-accurate fine all the abstract bus channels into detailed bus chan-model and cycle-accurate model. Time-accurate model spec- nels. Some abstract bus channels can he refined while othersifies the time constraint of communication, which is deter- are untouched. The refinement process from bus-arbitrationmined by the time diagram of components protocol. For model to the bus-functional model is similar to the proto-example, in Figure 5(a), the time is limited in the time range col insertion introduced in [lo]. Figure 6 illustrates ourbetween 25 and 75. Cycle-accurate model can specify the bus-functional model.time in terms of the bus masters clock cycles, as displayed Cycle-accurate c o m p u t a t i o n model. It contains cycle-in Figure 5(b). The task of refining a time-accurate model accurate computation and approximatotimed communica-to a cycle-accurate model is called protocol refinement. tion. This model can be generated from the bus-arbitration 21
  4. 4. Models Communication Computation Communication P E interface time time scheme Table 1 Characteristics of different a b s t r a c t i o n models : PE1 PE2 /PE3 1. Master interiace B- 2. Slave intsmacs 3.Albite, intslface 4. wrapperF i g u r e 7 The e x a m p l e of cycle-accurate c o m p u t a - :tion modelmodel. In this model, computation components (PES) arepin accurate and execute cycle-accurately. The custom hard- F i g u r e 8: The example of implementation modelware components are modeled at register-transfer level, andgeneral-purpose processors and DSPs are modeled in terms 4. SYSTEM DESIGN WITH TLMSof cycle-accurate instruction set architecture. To enablecommunication between cycle-accurate PES and abstract 4.1 Design Flowlevel interfaces of abstract bus channels, wrappers which The gray solid arrow in Figure 1 represents a well-acceptedconvert data transfer from higher level of abstraction tolower level abstraction are inserted to bridge the PES and design flow. I t goes through models A, C, and F, which r e pthe bus interfaces. Similar to the bus-functional model, it resents system functionality, abstract system architecture, and cycle-accurate system implementation respectively. Amongis not necessary to refine all the PES to the cycleaccuratelevel. Some PES can be refined while others are untouched. them, bus-arbitration model divides the system flow into twoFigure 7 illustrates a cycleaccurate computation model, in stages: system design stage and component design stage.which only PE3 is refined to a time-accurate and pin-accurate System design stage selects/generates system architecturemodel. and maps the system behavior to that architecture. Compo- I m p l e m e n t a t i o n model. I t has both cycleaccurate nent design stage refines/systhezises computation and com- munication components to the cycle accurate level. In gen-communication and cycleaccurate computation. The com-ponents are defined in terms of their register-transfer or eral, different design flows include different models. For ex-instruction-set architecture. The implementation model can ample, [lo] goes through models A, B, D and F, [9]goeshe obtained from the bus-functional model or the cycle- through models A, C, E and F, while 1121 goes throughaccurate computation model. The implementation model is models A, B, C, D and F.the same as the implementation model in [lo] and register- 4.2 Design Domain Definitiontransfer level model in [12]. Figure 8 displays an example In Figure 1, we use arrows t o represent a set of tasks thatof the implementation model. PE1 and PE2 are micro- generate one abstractinn model from the previous one. Fig-processors while PE3 and PE4 are custom-hardwares. ure 9 shows a general design flow with five design domains Table 1 summaries the characteristics of different ahstrac- for generating model B from model A.tion models. Although models indicated by x in Figure 1can also be specified, they will not be discussed in this paper 1. Modeling domain. It deals with languages and stylesbecause they are not commonly used. of writing models. In other words, it deals with semm- 22
  5. 5. ValWnon dOMl” which has cycle/pin accurate communication and ab- stract computation. The same strategy can be easily applied to the sequence A , B, C, D and F. The refinement tasks for the flow which goes through models C, E, and F can be founded in 191, which refines model C to E by producing software and co-simulation wrappers for microprocessors and refines model E to F by producing hardware wrappers among micropr* cessors. 4. Exploration domain. In order to aid designers to make better decisions, the different metrics for poten- tial design decisions should be estimated, based on theFigure 9: A general design flow w i t h five domains Model A and the availability of buses, channels, RTOS, ISS, drivers, arbiters, and other SWJHW components in the estimation library tics of different models used for different design tasks, such as verification, refinement, and synthesis. System Different TLMs require different estimation supports. modeling task can be simplified if the part of model We need to estimate approximate computation time has been predefined as IP and saved in IP library. An for PES in model B, approximate communication time example of modeling is that designers can specify the for abstract bus channels in model C, cycle-accurate Model A using system level design languages such as communication time for detailed bus channels in model SpecC and SystemC. D, and cycle-accurate computation time for PES in model E. For example, 1161 proposes an simulation- The modeling styles of TLMs have been briefly dis- based estimation approach. cussed in section 3. Especially, because communi- cation is completed separated from computation in Furthermore, in order to speed up the simulation and TLM, designers can specify different components of enlarge the exploration space, we can perform architec- one model at different abstraction levels. Such a model ture exploration at bus-arbitration model, which has is called multi-level model. Both SpecC and SystemC both approximatetimed computation and approximate- support TLM modeling. The difference of modeling timed communication. In order to estimate compo- TLMs using SpecC and SystemC is discussed in [8] nents at such an approximate-timed level more accu- rately, we can first refine the components to the cycle 2. Validation domain. Validation asserts that the model accurate level and achieve cycle-accurate estimation represents the system properties faithfully. The cor- by simulation or some other methods. Then we an- rectness of the model can be validated by different notate back this estimation to the component models methods such as simulation and formal verification. at approximate-timed level. Back annotation ensures very fast simulation with cycle-accurate estimation. Validating TLMs can be performed by simulation. For example, SystemC provides a Verification Standard 5. Synthesis domain. Synthesis algorithms perform 1 1 to improve the validation capability with standard 4 automatical exploration and produce optimal solution APIs for transaction-based verification tasks. On the for given constraints and optimization metrics. Syn- other hand, 1 1 proposes a formal verification approach 7 thesis algorithms relieve designers from making deci- that proves the equivalence of models generated through sion decision. However, designers always can override automatic refinement. the algorithms and make their own decision since new Furthermore, validating components through simulat- model generation is separated from decision making. ing multi-level model can dramatically speed up the Synthesis algorithms can he divided into several groups validation time. If we model the component which we where each group contains algorithms for transforma- want to validate at the cycle-accurate level, and model tion of one model to another. the rest of components at the approximate-timed level, then simulation time can be dramatically shorter than C o m p o n e n t assembly (A->B) contains algorithms the time needed for simulating the pure cycle-accurate for selecting PES from PE libraries, mapping of model. Both [14] and 1151 work in this direction. processes in the specification model to the se- lected PES, and selecting real time operating sys- 3. Refinement domain. Every time a new design detail tems (RTOS) for general-purpose processors or is added, the original model must be rewritten or re- DSPs. fined in order to include the new design detail. These design decisions made by the designers or an automat- Communication exploration (B->C) contains al- ical synthesis tool can be incorporated into the new gorithms for producing the bus-topology, deter- model manually or automatically. An automatic r e mining abstract bus protocols, mapping channels finement for the flow which goes through models A, B, to the buses, assigning bus-accessing priorities to D, and F in Figure 1 can b e founded in [IO], which the processes in PES, and determining bus arbi- defines four abstraction models and proposes refining tration mechanism. guidelines. In comparison to our defined models, it has P r o t o c o l refinement (C->D) contains algorithms a bus-functional model (called communication model) that determine the pin-accurate and time-accurate 23
  6. 6. bus protocols, and refine time-accurate bus p r o and present the system level design flow and major design tocols to cycleaccurate bus protocols if required. tasks for generation of each model. The major challenge in PE refinement (D->F) contains algorithms that front of us is to define the semantics of each model in de- synthesize the processes mapped to cycle-accurate tail and formally so that algorithms and tools for modeling, custom hardware to register transfer models, con- verification, refinement, exploration, and synthesis can be vert the processes mapped to general-purpose p r o developed and deployed in industry. cessors or DSPs to ANSI-C code which is ready to be compiled and ready to he linked to the cor- 6. REFERENCES responding cycleaccurate instruction set models. [l]CoWare home page (www.coware.com). PE r e p l a c e m e n t ( C - > E ) contains algorithms that [2] OSCI home page (www.systemc.org). select lower level P E models which have pin-accurate [3] STOC home page (www.specc.org)., interface to replace the higher level P E models, [4] The SystemC Verification Standard, version 1.0 and vice versa, and insert across level wrappers (www.systemc.org). to bridge the lower level P E models and bus- [5] VCC home page abstraction channels. (www.cadence.com/products/vcc.html). C o m m u n i c a t i o n s y n t h e s i s ( E > F ) contains algo- [6] S. Abdi et al. System-On-Chip Environment (SCE): r i t h m that determine the pin-accurate and t i m e Tutorial. Technical Report CECS-TR-02-28, UCI, accurate bus protocols and synthesize channels Sept 2002. and across-level wrappers to cycle-accurate com- [7] S. Abdi et al. Formal Verification of Specification munication coprocessors. Partitioning. Technical Report CECS-TR-08-06, UCI, Mar 2003.4.3 Design Flow Styles [SI L. Cai et al. Comparison of SpecC and SystemC The style of design flows may depend on the companies Languages for System Design. Technical Reportand system design tools. In any case, it becomes easier with CECS-TR-03-11, UCI, May 2003.the usage of well-defined aforementioned TLMs with inter- [9] W. Cesario e t al. Multiprocessor SoC Platforms: amixed application of the three design practices mentioned Component-Based Design Approach. In IEEE %ns.in section 2. on Design and Test, Nov-Dec 2002. The initial version of the design can be designed using [lo] D. Gajski et al. SpecC: Specification Language andtopdown approach. During the implementation process, all Methodology. Kluwer, Jan 2000.the generated models a t different levels are stored in the IP [ll] P. Gerin et al. Scalable and Flexible Cosimulation oflibrary. After this step we have a predefined platform which SoC Designs with Heterogeneous Multi-Processorcan be used further. Target Architectures. In ASPDAC, 2001. The changes in the design can he inserted by rewriting [12] T . Grotker et al. System Design with SystemC.of the specification model. At this stage we have a prede- Kluwer, 2002.fined platform which allows us to apply meet-in-the-middleapproach. Furthermore, we have an accurate estimation of [13] K. Keutzer e t al. System Level Design:the system behavior obtained from the initial version of the Orthogonalization of Concerns and Platform-Baseddesign. Now, the designers only need to estimate the new Design. IEEE Wans. on CAD, Dec 2000.additions of the system behavior. Hence, the component as- 1141 S. Pasricha. Transaction Level Modelling of SoC withsembly and communication exploration for the new design SystemC 2.0. In Synopsys User Group Conference,can be easily made using the generated platform. 2002. After generating the bus-arbitration model for the new [15] P. Paulin et al. StepNP: A System-Level Explorationversion, designers can perform computation or commnnica- Platform for Network Processors. In IEEE Bans. ontion component implementation a t the component design Design and Test, Nov-Dec 2002.stage. For the components that are not updated, designers [E]N. Pazos et al. System Level Performance Estimation.can reuse the pre-designed bucfunctional model and i m p l e In SystemC Methodologies and Applications. Kluwer,mentation model, instead of carrying out refinement from 2003.busarbitration model again. Only the updated componentsneed to be refined. On the other hand, if designers want to replace an oldIP by an new I P for the designed system, bottom-up designcan he exploited. Starting from cycleaccurate computationmodel of the design, designers can replace an old IP andits wrapper with the new I P and its wrapper in the cycleaccurate computation model. Then communication synthe-sis is performed again for the new I P and its wrapper. Start- ing with cycle-accurate computation model saves us severalsynthesis tasks.5. CONCLUSION In order to eliminate the some ambiguity with the transac-tion level model, this paper attempts to define several TLMs 24

×