Des Autom Embed Syst (2012) 16:93–113 DOI 10.1007/s10617-012-9089-7
Exploiting UML based validation for compliance checking of TLM 2 based models Vaibhav Jain · Anshul Kumar · Preeti Panda
Received: 6 January 2012 / Accepted: 21 June 2012 / Published online: 13 July 2012 © Springer Science+Business Media, LLC 2012
Abstract SoC system designers commonly employ SystemC based Transaction level modeling (TLM) for its early software development usage and its analysis capabilities. TLM helps in realizing a SoC using virtual prototyping by integration of SoC components at different abstraction levels. The TLM 2 standard introduces interoperability rules for the models that may have been developed independently. However, neither SystemC compiler nor TLM library supports checking of such rules and manually debugging interoperability errors in such models could be a major problem. This provides motivation for developing automatic compliance checking techniques which can detect and report such errors. As the models are refined to incorporate detailed intercommunication protocols among the system components, the need for compliance checking extends to these protocols as well. In this paper, we present an efficient UML based compliance checking technique for TLM 2 models which supports static, dynamic and protocol-specific rule checking. Keywords Transaction level modeling · TLM compliance checking · UML based validation
1 Introduction SystemC based Transaction level modeling offers development of virtual models of SoC at various levels of timing accuracy and simulation speed [1]. For example, a loosely-timed (LT) model offers the software development and performance analysis use case and speeding up simulation by restricting itself to limited timing information. On the other hand, an approximately-timed (AT) model supports architecture analysis with more precise timing V. Jain () · A. Kumar · P. Panda Indian Institute of Technology, Delhi 110016, India e-mail:
[email protected] A. Kumar e-mail:
[email protected] P. Panda e-mail:
[email protected]
94
V. Jain et al.
information but compromising with the simulation speed. One of the main goals of OSCI TLM 2 standard is to ensure interoperability among transactional models. The standard introduces rules that help in maintaining interoperability during integration of transactional models coming from various sources [2]. The TLM rules can not be checked statically by SystemC compiler and the TLM library does not supports any run-time compliance checking. However, manually detecting violation of such rules and identifying their source poses a big challenge. Therefore, automatic compliance checking with a view to verify transactional models against the TLM rules is quite desirable. The usual approach is to rely on external TLM protocol checkers plugged into a model. An open source TLM protocol checker is also available now [3]. A TLM protocol checker dynamically detects and reports errors, if any, found in a transactional model during simulation. A TLM protocol checker is implemented as a SystemC module and can be used along with a SystemC model during simulation. A copy of protocol checker needs to be inserted between every pair of TLM modules and inspects each transaction passed through it. However, this online checking strategy incurs an overhead to overall execution time due to increased context switching during simulation resulting from these additional concurrent modules (checkers) that are introduced. Penalty for online checking varies with the level of abstraction of transactional models. We present an approach based on UML for development and compliance checking of TLM based models. UML, a well-known language for modeling software and systems, has recently shown a lot of promise as an entry level language for SoC development. For example, UML profiles like SysML [4] and MARTE [5] target towards SoC design. In order to serve this need, special UML profiles have been developed for SystemC modeling at UML level and code generation [6, 7]. The SATURN [8] design flow also contributes towards SystemC and C based co-simulation and synthesis. On the other hand, Habibi et al. [9] suggested generating SystemC model by transforming a UML model into an intermediate representation of Abstract State Machine (ASM) and later mapping it to SystemC, without the use of a special profile. Use of TLM with SystemC is of significant interest to SoC designers. However, none of these approaches have explicit support for TLM. Prompted by lack of TLM support in existing UML based frameworks, we recently introduced a SysML profile for TLM 2 [10]. In that work, we observed that apart from providing support for SystemC based TLM code generation; this profile makes it possible to check static TLM rules. To do this, we augmented our profile with static rules expressed as constraints in OCL (Object Constraint Language) [11]. While these rules get statically checked before code generation, the remaining rules still need to be checked dynamically, though the burden of dynamic compliance checking is reduced. We have also addressed the problem of checking TLM dynamic rules in an efficient manner [12]. Our solution is based on use of sequence diagrams which are commonly used in UML based frameworks for describing test cases and for generation of assertions. In our approach, a UML sequence diagram captures the transactions recorded during simulation of a TLM 2 model and TLM rules are expressed as OCL or Java expressions. A sequence diagram validation against the TLM rules results in an off-line TLM compliance checking on the sequence of messages representing transactions captured during simulation. In addition to providing a better visual aid to the model developers, our approach reduces compliance checking overhead in comparison to the protocol checker based approach. The virtual models that require greater amounts of accuracy leads to a TLM model refinement till a cycle-accurate TLM model is built to facilitate evaluation of the communication architecture. Therefore, after testing a system model with the TLM base protocol at LT and AT levels, the user-specific communication protocols like AMBA [13], OCP [14] can be introduced in a system model where these protocols are implemented over TLM framework.
Exploiting UML based validation for compliance checking of TLM 2
95
However, the compliance checking of such models will involve verification of base protocol rules as well as the detailed bus protocol rules. Putting additional online checkers for the detailed bus protocols has high overheads. In this paper, we show that our offline checking approach for base TLM protocol can be extended to check detailed bus protocol in order to reduce these overheads. Integrating compliance checking of TLM rules and bus protocol rules can improve the efficiency further if some of the base protocol rules subsume TLM rules.
2 Overall strategy for compliance checking of TLM 2 based models The TLM rules can be categorized into static and dynamic rules. A static rule enforces restriction on a TLM concept related to its structure and its interconnections and can be verified during modeling time. In contrast, a dynamic rule enforces a restriction on an execution or runtime instance of a TLM concept and can be verified during simulation time using TLM compliance checking. The existing approach shown in the Fig. 1 uses a TLM protocol checker between every pair of TLM modules, in a SystemC model. A TLM protocol checker performs single-hop checking and multiple-hop checking of the transactions exchanged between TLM modules. In “single-hop checking”, any violation of TLM rules between a pair of TLM modules is detected. In “multiple-hop checking”, path violations occurring between every pair of initiator/target modules, which may involve multiple interconnect modules are detected and reported. Figure 2 illustrates our UML based framework for compliance checking of TLM 2 based models. The proposed framework can be divided into three phases: static rule checking, SystemC code generation and dynamic rule checking. In the static rule checking phase, a UML based transactional model is developed using a SysML based TLM profile. TLM static rules are expressed as OCL constraints which is part of the SysML profile. With the help of a UML modeling tool which consists of a OCL toolkit, a TLM model is validated against the static rules. If there is no violation, a SystemC executable code can be obtained from a XML document which represents a TLM model using an XSLT based code generation technique. The static rule checking and the code generation work is proposed in [10]. Next, in the dynamic rule checking phase, an execution trace is generated from the simulation of a SystemC based TLM model. The execution trace contains a record of all the transactions executed between TLM modules. With the help of a UML model, a sequence diagram generator generates a UML sequence diagram from the execution trace. All the transactions exchanged between TLM modules are captured as messages in the sequence
Fig. 1 Existing strategy for TLM compliance checking
96
V. Jain et al.
Fig. 2 UML based framework for compliance checking of TLM 2 models
diagram. After this, with the help of a UML modeling tool, a rule checker performs sequence diagram validation based on the TLM dynamic rules expressed as Java assertions as proposed in [12]. Although the design-flow of our approach emphasizes on developing an initial UML model with the help of a TLM profile. However, existing SystemC components can be used with our proposed approach. During code generation, the code generator ignores the code generation of such model elements as SystemC code is already available. However, for the purpose of trace generation, we need to instrument the existing component’s code if the existing component is a TLM component. This will allow recording appropriate message in the trace file. During rule checking, the execution trace is validated against the reference model which also includes the model elements for existing SystemC components reflected as an “artifact”. In this paper, we are also introducing verification of a bus protocol model which is implemented over TLM in the dynamic rule checking phase of the proposed framework. The compliance checking of such protocols involves verification of phase sequences and checking of extension attributes which are declared using TLM extension. A protocol specification includes phase specification and its attribute specification. If we use the existing approach for compliance checking then, we would require an additional checker for bus protocol between every pair of TLM modules in a model. On other hand, we have expressed phase specification using UML protocol state machine (PSM) rules as OCL constraints and at-
Exploiting UML based validation for compliance checking of TLM 2
97
tribute rules as Java assertions which are based on the UML sequence diagram. Here, we are using an unified strategy for compliance checking as TLM rules and other protocol rules are expressed over a UML sequence diagram. For sequence diagram generation and validation, we are using the same strategy proposed in [12].
3 UML based approach for TLM static rule checking TLM 2 provides a strict framework to model the interactions between blocks as shown in Fig. 3. A TLM 2 model may consists of a number of TLM modules like initiators, interconnects and targets. An initiator starts a transaction through initiator port, an interconnect which acts as a bridge/router and consists of initiator and target sockets and a target component which services memory-based read/write transaction requests through target sockets. The communication between these components takes place along the forward and backward paths. A static rule enforces restriction on a TLM concept related to its structure and its application. For example, the rules concerning the initiator socket connection or the methods that can be realized by an initiator module can be considered as structural rules. We have identified 24 such static rules in the TLM 2 standard. SystemC compiler and SystemC based UML profiles ignore most of these rules. In order to confirm this, we handcrafted a TLM 2 model and introduced violations of all the 24 static rules. The model was compiled and tested to find out the stage at which various violations were detected. Table 1 shows results of this experiment. It was found that only 6 of the violations were detected at compile time, elaboration time and simulation time and the majority of the rules were ignored.
Fig. 3 TLM 2 framework used for system model
Table 1 TLM rule checking report Stage
Violation count
Example
Compile Time
2
Two sockets must share the same BUSWIDTH
Elaboration Time
2
initiator socket must be connected to target socket
2
b_transport should not be called from a method
Simulation Time Ignored
18
Initiator can not realize b_transport method
98
V. Jain et al.
Fig. 4 TLM profile relationship with other profiles
Table 2 TLM profile stereotypes TLM concepts
Stereotypes
Base stereotype(s)
Referenced profile
Modules
Initiator
Block
SysML
Interconnect
sc_module
SystemC
TLM_initiator_socket
FlowPort
SysML
TLM_target_socket
sc_port
SystemC
sc_interface
SystemC
sc_method
SystemC
sc_connector
SystemC
Target Sockets
... Interfaces
TLM_blk_forward_if TLM_non_blk_fw_if ...
Transport methods
b_transport nb_transport_fw ...
TLM Path
TLM_block_fw_path TLM_nb_fw_path ...
Payload Object
TLM_generic_payload
ItemFlow
SysML
TLM Phase
TLM_phase
Enumeration
UML
...
...
...
...
3.1 A SysML profile for TLM 2 A UML Profile is a set of extensions to UML using the built-in extension facilities provided by UML. A UML profile is developed by extending the UML metamodel [15] and introducing domain specific concepts into it, mainly in form of stereotypes. Our profile for TLM is based on the SysML and TLM 2 specification as shown in the Fig. 4. Table 2 shows examples of the stereotypes defined in the TLM profile corresponding to TLM 2 concepts. All OCL constraints representing TLM static rules are added into the TLM profile. Table 3 shows examples of TLM static rules expressed as OCL constraints incorporated into the TLM profile.
Exploiting UML based validation for compliance checking of TLM 2
99
Table 3 Examples of TLM rules expressed as OCL constraints Constraint element
TLM rule
OCL constraint
Initiator
Initiator can not realize b_transport method
self.base_Class.ownedOperation→forAll (e|not e.oclIsKindOf (b_transport))
b_transport
b_transport should not be called from method process
self.base_StateMachine.class.extension →exists(e|e.ownedEnd.type.name ’sc_method’)
nb_trans_fw
nb_transport_fw should be realized by Target
self.base_Operation.featuringClassifier →exists (e|e.oclIsKindOf(Target))
nb_bw_path
nb_transport_bw shall be called on backward path
self.realizingMessage→forAll(e| e.ownedEnd.type.name=’nb_trans_bw’)
TLM_dbg
TLM_dbg shall not call wait directly
self.base_StateMachine.region. subvertex→select(oclIsKindOf(State)) → forAll(s:State|s.oclIsKindOf(wait))
Fig. 5 Example of a model violating TLM rules
3.2 TLM static rules validation Now, with the help of the UML modeling tool, MagicDraw [16], a TLM model designed using proposed TLM profile can be validated against all TLM static rules expressed as OCL constraints. During model validation, the tool reports the violations of the OCL constraints found in the model. In order to demonstrate this, we took a TLM mixed model which consists of: a LT initiator “cpu”, a AT initiator “jpeg decoder” and a AT target “memory”. Here, we deliberately introduced some violations in the model. The tool highlights all the model elements of the TLM 2 model which violate TLM static rules as shown in the Fig. 5. Table 4 shows the outcome of the model validation performed on this model. For example, one of the error messages, states that “Initiator must have a TLM initiator socket”. According to TLM standard, for the correct behavior of the system, an Initiator module must have a TLM initiator socket which is missing from the CPU module.
4 UML based approach for TLM dynamic rule checking In a TLM 2 model, an initiator forwards a memory read/write request to a target module. The request may go through an interconnect module which may typically act as an arbiter or a
100
V. Jain et al.
Table 4 Result of model validation performed on a model shown in Fig. 5 Model element
Error message
CPU[Model]
Initiator must be a Block classifier
JPEG_Decoder[Model]
Initiator realizes blocking transport call
Path[CPU-Memory]
Initiator socket missing on non-blocking forward path
Memory[Model]
Target realizes non-blocking backward call
Path[CPU-JPEG_Decoder]
Initiator and Target socket missing on blocking path
router. An initiator generates a transaction object and passes it as an argument of a transport method call. An interconnect component, if present, typically decodes the address of a target stored in the payload object and makes another transport method call to a target. The request finally reaches to a target on a forward path. A target sends back the read/write response on the same path from where the request was made. These requests represent transactions which are exchanged between TLM components and are passed through TLM core interfaces. The modules interact using TLM transport methods. The set of TLM transport methods, denoted by O, for AT coding style is {nb_transport_fw, nb_transport_bw, get_dir_mem_ptr, transport_dbg, invalidate_mem_ptr}. These methods return TLM status values. The set of status values ω = {TLM_accepted, TLM_updated, TLM_completed}. Payload objects are exchanged between TLM components as parameters of transport method calls during model execution. A payload object p, consists of a fixed set of payload attributes like addresss, command, length, etc. We denote attributes of p as p1 , p2 , . . . , pk . 4.1 Sequence diagram representation The trace of TLM model execution is captured as a sequence of messages T and represented as a sequence diagram. The modules or components of the model are represented as lifeline objects in the sequence diagram. Each message M in the trace defines an instance of communication between lifelines. A message M is represented as a tuple my , mz , o, p, id, θ, δ where my is the transmitter and mz is the receiver of a message M. A message can be of two types: send and reply. A send message has an operation o ∈ O where o = φ, while a reply message has o = φ. The set of operation O comprises of TLM transport methods O and their replies. A message M also consists of arguments p, id, θ and δ where p is a payload object and id is its identifier, θ ∈ {begin_req, end_req, begin_resp, end_resp} is a phase argument and δ is a delay parameter. 4.2 Sequence diagram generation We have developed a Java application which parses the trace of TLM transactions and generates an XML document which represents a UML sequence diagram. The main activities in a UML sequence diagram generation from a trace can be described, as follows: – The execution trace generated from the simulation is parsed, where each line represents a transaction executed between TLM modules (components). – TLM modules participating in a transaction are added as lifeline objects in the sequence diagram.
Exploiting UML based validation for compliance checking of TLM 2
101
– All transport method calls map to message calls in the sequence diagram. Each message is attached to an event type “CallEvent” and each return from a method call is represented as a reply message. – A payload object is passed as an argument of a call/reply message, and represents an “instance specification” of a TLM payload class declared in a UML model. – The value of a payload’s attribute is stored as a “value specification” of an “instance specification” of a TLM payload class. 4.3 TLM validation using sequence diagram TLM compliance checking involves checking rules between every pair of communicating TLM components. An initiator generates a payload object and sends a memory read/write operation request to a target. A payload object, before reaching a interconnect/target component, needs to be checked depending upon the modifiability/default value rules for a payload object. A target component modifies a payload object by serving the read/write request and sends back the reply to an initiator. A payload object, before reaching to initiator’s end, needs to be inspected which is modified by an interconnect/target component. Figure 6 shows a scenario of transactions exchanged between TLM modules depicted using a UML sequence diagram. The model consists of 3 TLM modules; an initiator, an interconnect and a target. The figure also depicts a UML based TLM dynamic validation process which can be divided into two phases: – In the pre-checking phase, a transaction object, generated or reused by an initiator module, is inspected before reaching the interconnect/target module. For example, the payload objects p1 and p2 that are passed as arguments to a b_transport method, are inspected during pre-checking. In this phase, the default value rule and the other initialization rules for a transaction object’s attribute are checked. Each message call in a sequence diagram is inspected in the pre-checking phase. – In the post-checking phase, a transaction object, modified by a target module, is inspected while responding to the read/write request made by an initiator module. For example, reply messages carrying payload objects p3 and p4 are inspected during post-checking. In Fig. 6 UML sequence diagram depicting transactions of a TLM model
102
V. Jain et al.
Table 5 TLM rule types and checking strategies Checking phase
Rule name
Pre-checking phase
initialization check
payload attribute
phase-sequence check
phase attribute
accessibility check
payload attribute
Post-checking phase
Both
Parameters involved
delay annotation check
delay attribute
response-path check
forward &backward paths
exclusion check
request and response flags
this phase, the modifiability rule and the path-checking rules applicable for a transaction object’s attribute are inspected. Each reply message in a sequence diagram is inspected during the post-checking phase. The pre-checking and post-checking phase validation is realized by declaring constraints on a call message and reply message of a sequence diagram. Each transaction object is passed as an argument of the message element of the sequence diagram and represents the instancespecification of a transaction payload class. The valuespecification for each attribute of an instancespecification represents the value of a transaction object’s attribute at a time instant. The TLM compliance checks or rules consist of five classes of rules. – Attribute Checks: A set Rα is a collection of TLM rules as shown in the Table 5. A rule ri ∈ Rα can be represented as a tuple of k, k exp where k is a payload attribute and k exp is the expected value of the kth attribute of a payload object p i.e. pk defined in the TLM standard. – initialization check verifies whether payload attributes are correctly initialized or not. The current value of a payload attribute is compared with the expected value of a payload attribute. These checks are performed during pre-checking phase. – accessibility-check verifies whether payload attributes are accessed by authorized TLM modules or not. It is performed during post-checking on attributes of a payload object. It essentially compares the current value of the payload object’s attribute pk with the original value of that payload attribute set by an initiator component. – response-path checks are also performed during post-checking on a payload object p, where a sequence of components traversed on backward path from target to initiator is compared with the traversed components on a forward path from initiator to target. The aim is to verify whether p has followed the same backward path as forward path. – phase-sequence checks verify whether the TLM base protocol phase transitions, i.e. begin_req → end_req → begin_resp → end_resp, are followed during transactions execution. A phase-sequence check compares the current phase value associated with a payload object p, with the expected phase value according to TLM base protocol. – exclusion checks are used to verify that no new request or response can be made through a socket if there is already a pending request or response made through that socket. – delay annotation checks ensure that the implementation of transport methods modify the effective local time in non-decreasing fashion between a transport call and its return. It compares the value of a delay argument passed during a transport call and its updated value after return.
Exploiting UML based validation for compliance checking of TLM 2
103
In order to perform these special checks, we are introducing the following terms: – Fid : A sequence of TLM components m1 , m2 , . . . , mn which are traversed on a forward call to a transport method for a payload object p ∈ P , identified by id. A TLM component m1 corresponds to an initiator component and mn is of type target . – Hid : A tuple consisting of θ, δ, p for a payload object identified by id. Here θ ∈ L is the previous phase value in a sequence of phase transitions, δ is the value of a delay parameter passed during a transport call, and p represents the original copy of payload attributes and used during accessibility checks. – Em : A tuple of freq or fres consisting of request or response flags with respect to a module m type. If m is an initiator, request flag is used and when m is a target , response flag is used. These flags are used during exclusion checks. A request flag is set when a new request is initiated by an initiator and when the request is accepted by target the flag value is cleared and a similar strategy is used for updating the response flag. – valid(θ, θ ): This function validates the sequencing of current phase value with respect to previous phase value θ according to TLM base protocol rule. The proposed algorithm for the TLM compliance checking, based on a sequence diagram validation is as follows: The basic idea of the algorithm is to inspect every message in trace T of the sequence diagram and carry out all applicable checks. First, if the source of M is an initiator and current phase is begin_req, then a payload object’s copy is stored in Hid , and the path for p i.e. Fid is initialized as shown in lines 2–4. In lines 6–17, pre-checks are performed on M, if M is a call message. In pre-checking, initialization, phase-sequence and request-exclusion checks are performed. In a request-exclusion check, if the current phase value is begin_req and the initiator s request flag is set, a new transaction request from initiator produces an error as shown in lines 7–8. If the flag is not set, the request flag for source of M is set in line 9. In a phase-sequence check, the current phase value is compared with the expected phase value according to TLM base protocol as illustrated in line 11. Next, if current phase value is end_resp, then response flag for target of the M is cleared as shown in lines 12–13. Next, in an initialization check shown in lines 14–16, the current value of p’s attribute is compared with the expected value of the payload attribute for each payload attribute. In case of a mismatch, an error is reported. From lines 17–19, the next expected phase value, delay value and path for p is updated. In post-checking, accessibility, response-path and response-exclusion checks are performed. In response-exclusion check illustrated in lines 22–23, if the current phase value is begin_resp and the response flag is set for the source of M, then an error is reported. Otherwise, response flag is set for the source. Next, if current phase value is end_req, then the request flag for target of M is cleared. In a accessibility-check illustrated in lines 28–30, p’s attribute value is compared with the value of same attribute in the original copy of p for each payload attribute. Next, a response-path check is performed by comparing the target of M with the last element of Fid . In line 32, a delay-annotation check is performed where the delay value before making a transport call is compared with the returned delay value. Finally in line 33, the last element is removed from Fid . Table 6 shows examples of different types of dynamic rules that the algorithm 1 looks for any of these violations. The advantages offered by our validation strategy over the existing SystemC based strategy are following:
104
V. Jain et al.
Algorithm 1 Sequence Diagram Validation 1: for each message M = my , mz , o, p, id, θ, δ in T do 2: if θ == “begin_req” && my ∈ I then
I is set of initiator 3: Hid .p = p;
save original copy in Hid 4: Fid = φ;
initialize Fid 5: if o ∈ O then
perform pre-checks on call messages 6: if θ == “begin_req” then 7: if Em .freq then
m = my 8: throw exclusion-request error; 9: Em .freq = true;
update request flag & m = my 10: else 11: if θ = valid(θ, Hid .θ ) then throw phase-sequence error; 12: if θ == “end_resp” then 13: Em .fres = false;
m = mz 14: for each attribute k ∈ p do 15: if k = k exp then 16: throw initialization-check error; 17: Hid .θ = θ ;
update current phase in Hid 18: Hid .δ = δ;
update delay in Hid 19: append(Fid ,my );
append forward path for p 20: else
perform post-checks on reply messages 21: if θ == “begin_resp” then 22: if Em .fres then
m = my 23: throw exclusion-response error; 24: Em .fres = true;
update response flag & m = my 25: else 26: if θ == “end_req” then 27: Em .freq = false;
update request flag & m = mz 28: 29: 30: 31: 32: 33:
for each attribute k ∈ p do if Hid .pk = pk then throw accessibility-check error; if Fid .last = mz then throw response-path error; if Hid .δ > δ then throw delay-annotation error; Fid .pop;
remove last element from Fid
– It eliminates the need of using a separate protocol checking module between every pair of TLM components as we can validate the interactions between components off-line by defining constraints on the message element of a sequence diagram. – It also eliminates the need of inspecting the rules locally, which is used in the existing conformance checking strategy. The strategy offers a comprehensive or a global view of the whole simulation trace and minimizes the need for maintaining multiple copies of a transaction object. – It facilitates the user to view the transactions executed in the model visually using a UML sequence diagram. It further helps in viewing exactly a source of error in the execution trace of a model in case of a TLM rule violation found during TLM dynamic validation.
Exploiting UML based validation for compliance checking of TLM 2
105
Table 6 TLM dynamic rule examples Rule types
Rule examples
IEEE-1666 LRM Ref
initialization
If the byte enable pointer is non-0, the byte enable length shall be non-0
14.14 f
phase-sequence
The full sequence of phase transitions for a given transaction through a socket is: BEGIN_REQ → END_REQ → BEGIN_RESP → END_RESP
15.2.3 b
accessibility
The data length attribute shall be set by the initiator to the number of bytes to be read or written and shall not be modified by interconnect component or target
11.3.4 k
delay-annotation
The nb_transport method may itself increase the value of the time argument, but shall not decrease the value
11.1.3.1 d
response-path
In the case of the base protocol, the forward and backward paths should pass through the exactly same sequence of components and sockets in opposing order
11.1.2.4 b
exclusion
An initiator or interconnect component shall not send a new transaction through a given socket with phase BEGIN_REQ until it has received END_REQ or BEGIN_RESP from the immediately preceding transaction
15.2.6 e
5 UML based approach for bus protocol checking over TLM In order to define a user-specified protocol, TLM provides an extension mechanism which permits adding new attributes to the TLM generic payload (gp).1 An extension to the gp could be ignorable or non-ignorable. The ignorable extension permits any component other than the component that added the extension, to ignore it as if it is not present. The ignorable extension can be used for debugging and simulation purposes. On the other hand, the nonignorable extension bounds every component to act upon it, if present. It can be used to model the details of a specific protocol. Hence, we are using a non-ignorable extension for modeling user-specified protocol. In addition to payload extensions, defining a communication protocol over a TLM framework requires introducing additional phases and phase transitions. Figure 7 shows an example where four phases of AMBA protocol {bus_req, bus_grant, bus_req_stop, bus_ungrant} are added to the phases of TLM base protocol i.e. {begin_req, end_req, begin_resp, end_resp}. Extending the payload attributes requires initialization and accessibility rules for the additional attributes to be defined. The specification consists of a attribute name, its recommended initial value and suggests TLM components who can modify that attribute. It also includes the expression for extension check(s) to be performed on the attribute. Table 7 shows an example of the AMBA-PV AHB protocol attributes specification. The example shows specification of the two AHB attributes m_size and m_length. The first check expression describes a rule that “the maximum number of bytes allowed to transfer within a burst”. The second expression suggests that “the permissible length of a transaction with burst type of WRAP”. 1 A standard transaction object.
106
V. Jain et al.
Fig. 7 Example of AHB phase transitions as extension to TLM phase transitions Table 7 Attribute initialization/accessibility rules Attribute name
Initial value
Modifiable by Int. Tar.
Extension check expression(s)
m_size
0
no
no
set {1,2,4,8,16,32,64,128}
m_length
0
no
no
(m_burst==AMBA_PV_WRAP)→set{4,8,16}
We have represented attribute and phase rules as java assertions and used the sequence diagram validation to perform compliance checking of such communication protocols.
6 Experimental results We have evaluated our proposed strategy for dynamic rule checking and rule checking of a bus protocol over TLM with the help of two case studies. 6.1 Case study I Figure 8 shows the system model of a DPF extracted from [22]. The system contains a CPU which acts as an initiator and generates memory read requests and sends it to the JPEG Decoder. The JPEG Decoder acts as an initiator and a target and forwards a request to the Memory, a target module, to get the encoded JPEG image stored in the memory. The Memory responds with the image data to the JPEG Decoder. The JPEG Decoder decodes the image and sends a write request to the Display controller which is a target module. There
Exploiting UML based validation for compliance checking of TLM 2
107
Fig. 8 TLM model example (a digital photo frame)
is a system bus which is an interconnect module between all the initiators and targets. We represented the DPF model using different TLM coding styles and using TLM concepts like direct memory interface (DMI) and temporal decoupling (TD). We have used MagicDraw, for designing an initial UML model with the TLM profile and used an XSLT based translator, for generating executable SystemC code. We simulated the SystemC model and generated an execution trace containing all the transactions with the help of the reporting library. The sequence diagram generator, which is a Java utility, parses the execution trace and generates a UML sequence diagram containing each transaction as an interaction between TLM components. We developed a Java plugin using MagicDraw API for the validation. With the MagicDraw tool support, we performed a sequence diagram validation against the TLM dynamic rules expressed in Java. Finally, the tool reported any violation of TLM rules found in the model. 6.1.1 Calculating protocol checking overhead In the existing SystemC based strategy, the protocol checking overhead, PCTime can be calculated as the difference between the execution times of a transactional model using external protocol checkers IPTime and the same model without including protocol checkers WPTime , over given number of transactions as shown in Eq. (1). PCTime = IPTime − WPTime
(1)
Using our off-line protocol checking strategy, the total time for performing compliance checking through a sequence diagram can be calculated as shown in Eq. (2). PCTime = TGTime + SGTime + SV Time
(2)
TGTime is the execution trace generation time which is an overhead for writing transactions in the file. SGTime is the sequence diagram generation time and SV Time is the sequence diagram validation time, the actual time spent on checking TLM dynamic rules over a sequence diagram. 6.1.2 Results We have performed the experiment on six variants of DPF TLM 2 model. DPF LT is a loosely-timed model which uses blocking transport calls. DPF AT 1-phase, AT 2-phase
108 Table 8 Rule checking on different TLM models
Table 9 Protocol checking overhead on DPF models
V. Jain et al. Transport methods
Coding styles
Avg rule-checks/call
b_transport
lt
23
nb_transport_fw
at
21
nb_transport_bw
at
17
get_direct_mem
lt/at
6
transport_dbg
lt/at
3
Model
LT
AT_1P
AT_2P
AT_4P
LT_TD
Overhead(%)
52.27
42.83
50.36
53.04
49.29
and AT 4-phase models are approximately-timed models using non-blocking calls, making memory read/write requests depending on the number of TLM phases allowed. In the DPF LT model with DMI, an initiator accesses memory directly using pointer and bypass the normal path of multiple b_transport method calls. The DPF LT model with TD allows each thread to work at local time quantum and synchronize with other threads at global quantum of 500 ns. Table 8 reports the average number of rules checked per transport method call by protocol checker across different TLM models based on the TLM transport method used. The six DPF models that we have developed cover all the rules described in the TLM protocol checker. Table 9 shows the results indicating the percentage of time spent on protocol checking in comparison to the total simulation time across DPF TLM models. The result confirms that protocol checking accounts for approximately half of the simulation time. Figure 9 shows the performance comparison between the existing SystemC based strategy for TLM compliance checking and our proposed compliance checking strategy on a DPF transactional model. The graphs show plots of execution times of protocol checker and the total execution time spent by our proposed UML based strategy including TGTime , SGTime and SV Time with varying number of transactions. For all DPF models, TGTime , SGTime and SV Time contribute approximately 20 %, 40 % and 40 % respectively in overall TLM compliance time calculated using our strategy. 6.2 Case study II We have evaluated the proposed compliance checking strategy over a TLM AMBA-PV model shown in Fig. 10. The AMBA-PV model focuses on high-level, functionally accurate, transaction modeling and targeted at LT coding style of TLM 2. The model consists of the following components: a TLM master, which generates transaction requests, a TLMAMBA bridge converting a TLM request to an AMBA request, an AMBA decoder which decodes the address and forwards the request appropriately. An AMBA-TLM bridge which converts an AMBA request back to a TLM request and a TLM slave, which act as a target and serves a memory read/write request. We have used AMBA-TLM toolkit [17] which provides various TLM based AMBA components and a AMBA-PV protocol checker. For compliance checking, we have used TLM base protocol checkers between a TLM-AMBA bridge, a TLM master and a TLM slave.
Exploiting UML based validation for compliance checking of TLM 2
109
Fig. 9 Comparison of TLM compliance checking strategies
We have found 4 AMBA-PV rules that put extra restrictions on the TLM 2 standard payload attributes. Table 10 shows a payload attribute and the applicable AMBA-PV and TLM rules on it.
110
V. Jain et al.
Fig. 10 A TLM based AMBA model
Fig. 11 Unified Protocol Checker Strategy
Table 10 Rules applicable on Payload attributes Payload attribute
AMBA-PV rule
TLM rule
Data length
it must be greater than or equal to burst size times the burst length
it must not be set to 0
Streaming width
it must be equal to the burst size for a fixed burst
it must be set to a value greater than 0
Byte pointer
it must be null for read transactions
it may or may not be null
Byte enable length
it shall be a multiple of the burst size on write transactions
if the byte enable ptr is not 0, it must be greater than 0
Here, the TLM rules mentioned in the table enforce generic checks on the payload attributes in comparison to AMBA checks which can be ignored during AMBA-PV compliance checking. Therefore, we are using a unified protocol checker which performs less number of checks by ignoring the generic checks and reduces the module overhead in overall compliance checking time. A unified protocol checker as shown in the Fig. 11, combines verification of TLM and AMBA properties and is plugged in between TLM-AMBA bridge and AMBA decoder and vice-versa. We have implemented a UML based and SystemC based unified checker based on AMBA-PV and TLM base protocol.
Exploiting UML based validation for compliance checking of TLM 2
111
Table 11 Comparison of SystemC & UML based approach for compliance checking Model size protocol used
#Trans
2 Masters/1 Slave AHB Protocol
Separate checking
Unified checking
UML checking
100
99
98
70
500
484
479
375
1000
971
956
635
5000
5066
4889
3376
10000
11095
10775
6760
20000
22328
21385
15118
100
212
195
142
500
989
953
659
1000
2110
1996
1312
4 Masters/2 Slaves AHB Protocol
5000
11348
10889
6728
10000
22300
21641
14923
20000
44972
44079
29551
Compliance checking time in (ms)
6.2.1 Results The results of Table 11 shows a comparison of compliance checking time on the AMBATLM model discussed above using SystemC based approaches and our proposed UML based approach. In the table, CPU times are taken on an Intel Core2 Duo (2.53 GHz) under Fedora Linux. First column refers to the model size, and the AMBA protocol used and second column states the number of transactions for which the model is simulated. Columns 3–4 in the table depict the compliance checking time using SystemC and UML based strategy respectively. The results highlights an improvement of 28–37 % in compliance checking time by our proposed UML unified strategy (col. 5) over SystemC based unified strategy (col. 4) for the AMBA-PV model. The results also shows a small improvement of 5–7 % in compliance checking time using unified checking over separate protocol checking strategy (col. 3) for TLM and AMBA protocols.
7 Related work For performing verification of SystemC/TLM descriptions, several approaches have been suggested among which majority of them employ assertion-based verification at ESL. In most cases, system properties to be verified are expressed as assertions written in languages like PSL (Property Specification Language) or System Verilog. These assertions are checked using static (model checking) or dynamic (simulation based) techniques. Although SystemC lacks formal semantics, work by [9, 19, 20], employ model checking which rely on an intermediate representation where a SystemC/TLM design is translated into a formal language description which is well suited for verification. However, apart from state explosion issues, these approaches rely on abstraction techniques and hence only limited designs can be processed. The work presented in this paper rather focuses on dynamic verification using simulation based approach rather than static verification. Niemann [23] proposed a simulation-based
112
V. Jain et al.
approach but it is restrictive in application and does not account the parameter values of transactions. In [24], a specialized language is defined which uses complex specification to describe TLM behaviour. In another work, ferro [21] suggested effective way of using global variables in PSL assertions for dynamic verification but its scope is limited to a small set of properties. However, in all the approaches discussed, the support for TLM 2 is limited. Recently, with the introduction of TLM checker from Doulos [3], it becomes possible to verify a TLM model against the TLM 2 rules and some of the tool vendors like Synopsys and Jeda favours this approach. However, the scope of the checker is limited to the TLM base protocol checker. TLM also supports protocol specific modeling where new protocols can be defined using TLM extension mechanism. Bawadekji [18] proposed an approach for verifying userspecific protocol based on TLM which is based on protocol sequence graph. However, it can only be applied in verifying the protocol sequences and ignores the verification of protocol attributes which significantly contributes in rule checking. Some of the SystemC front-end tools like AccurateC [25], KaSCPar [26] and Pinapa [27] offer facility to analyze existing SystemC design and perform rule checking but would be limited to TLM rule checking only and can not be applied to other protocol specific checking. With the recent developments, there is lot of interests among SoC community for UML. In [28], UML is used for modeling the component specification and later test scenarios and coverage metrics can be derived from the UML model for the SoC verification. But, the approach used a usecase specification for modeling and thus restrictive in modeling capabilities. Habibi [9] recommended use of UML sequence diagram by annotating it with the PSL statements to automate the generation of properties. In our view, UML can be applied to SoC domain beyond modeling, and UML based validation methodologies can be exploited for the verification of TLM properties. To the best of our knowledge, there is no work proposed on UML based TLM compliance checking.
8 Conclusions and future directions In this article, we show how UML can be used effectively for compliance checking of transactions models based on TLM 2. We have proposed a novel automatic compliance checking technique for TLM 2 models based on a UML profile and sequence diagram. The proposed strategy shows an improvement of around 32–46 % over the existing SystemC based compliance checking strategy, on the overall time spent on performing TLM compliance checking. For compliance checking of specific protocol over TLM, our UML based unified strategy also shows an efficiency of 28–37 % over SystemC based strategies. In the future, we aim at automating the generation of protocol rules based on the protocol specification. We are also looking at TLM model refinement process which will allow easy transition from model at one abstraction level to another abstraction level like U ntimed to LT or LT to AT . This work will contribute towards our present UML based framework for TLM, which currently supports static, dynamic and protocol-specific verification of TLM 2 based models.
References 1. Cai L, Gajski D (2003) Transaction level modeling: an overview. In: 1st IEEE/ACM/IFIP international conference on hardware/software codesign and system synthesis, CODES+ISSS 2003, CA, USA 2. Accellera Systems Initiative (2011) IEEE 1666-2011 language reference manual
Exploiting UML based validation for compliance checking of TLM 2
113
3. TLM-2.0 Base Protocol Checker (2012) Doulos. http://www.doulos.com/knowhow/systemc/TLM2/ base_protocol_checker 4. Object Management Group (OMG) (2012) SysML v1.2 Specification 5. Object Management Group (OMG) (2012) UML Profile for MARTE specification 6. Object Management Group (OMG) (2012) UML Profile for SoC v1.1 Specification 7. Riccobene E et al (2009) SystemC/C-based model-driven design for embedded systems. ACM Trans Embedded Comput Syst 8(4). doi:10.1145/1550987.1550993 8. Mischkalla F, He D, Müller W (2010) Closing the gap between UML-based modeling, simulation and synthesis of combined HW/SW systems. In: Proc design, automation and test in Europe, DATE 2010. IEEE Press, New York, pp 1201–1206 9. Habibi A, Tahar S (2006) Design and verification of SystemC transaction-level models. IEEE Trans Very Large Scale Integr (VLSI) Syst 14(1):57–68 10. Jain V, Kumar A, Panda P (2011) A SysML profile for development and early validation of TLM 2.0 models. In: 7th int conf modelling foundations and applications (ECMFA’2011). Springer, Berlin, pp 299–311 11. Object Management Group (OMG) (2012) UML 2.2 OCL specification 12. Jain V, Kumar A, Panda P (2011) A UML based approach for dynamic validation of TLM 2 models. In: Proc 14th int forum on specification and design languages (FDL’11). IEEE Press, New York, pp 1–8 13. ARM Ltd (2012) AMBA Protocol Specification. http://www.arm.com 14. Open Core Protocol International Partnership (OCP-IP) (2012) A SystemC OCP transaction level communication channel. www.ocpip.org 15. Object Management Group (OMG) (2012) UML 2.0 superstructure and infrastructure specification 16. The MagicDraw tool (2012) No Magic Inc. http://www.nomagic.com 17. Carbon Design Systems (2012) TLM-2 for AMBA protocol solution. http://portal. carbondesignsystems.com 18. Bawadekji M, Große D, Drechsler R (2011) TLM protocol compliance checking at the electronic system level. In: 14th int symp on desi and diag of elec circ & syst (DDECS’11), pp 435–440 19. Moy M, Maraninchi F, Maillet-Contoz L (2005) LusSy: an open tool for the analysis of systems-on-achip at the transaction level. Des Autom Embed Syst 10(2–3):73–104 20. Karlsson D, Eles P, Peng Z (2006) Formal verification of SystemC designs using a Petri-net based representation. In: Proc DATE’06 21. Ferro L, Pierre L (2009) ISIS: Runtime verification of TLM platforms. In: Proc forum on specification design languages (FDL’09) 22. A Digital Picture Frame Solution (2011) Texas Instruments Inc. http://focus.ti.com/docs/solution/folders/ print/471.html 23. Niemann B, Haubelt C (2006) Assertion-based verification of transaction level models. In: Proc ITG/GI/GMM workshop, February 2006 24. Ecker W, Esen V, Hull M (2007) Implementation of a transaction level assertion framework in SystemC. In: Proc design automation test in Europe, pp 894–899 25. Actis Design (2012) AccurateC—static code analysis for SystemC 26. KaSCPar—Karlsruher SystemC Parser Suite (2012) http://www.greensocs.com/projects/KaSCPar 27. Pinapa—A SystemC front-end (2012) http://greensocs.sourceforge.net/pinapa 28. Zhu Q, Oishi R, Hasegawa T, Nakata T (2004) System-on-chip validation using UML and CWL. In: Proc 2nd IEEE/ACM/IFIP international conference on hardware/software codesign and system synthesis (CODES+ISSS), pp 92–97
