Changes between Version 71 and Version 72 of Writing Rules/Tlmt

Timestamp:

Nov 15, 2008, 6:39:02 PM (15 years ago)

Author:

alain

Comment:

--

Writing Rules/Tlmt

@@ -90 +90 @@
 Experiments are currently in progress to evaluate the performance degradation incurred by this byte formatting.
 It is therefore  possible that the types of the '''m_data''' and '''m_byte_enable''' of the '''tlmt_vci_transaction'''
-will be changed to '''uint32*''' in a near future.
+will be changed to '''uint32*''' .
 
 = D) VCI initiator Modeling =
 
-== D.1) Member variables ==
+== D.1) Member variables & methods ==
 
 In the proposed example, the initiator module is modeled by the '''my_initiator''' class. 
@@ -122 +122 @@
 The '''execLoop()''' method, describing the initiator behaviour must be declared as a member function. 
 
-Finally, the class '''my_initiator''' must contain a member variable '''p_vci_init''', of type '''tlmt_simple_initiator_socket'''. 
+The '''my_initiator''' class must define a call-back function to handle the VCI response packets.
+
+Finally, the it must contain a member variable '''p_vci_init''', of type '''tlmt_simple_initiator_socket'''. 
 This member variable represents the VCI initiator port. 
 
 == D.2) Sending a VCI command packet ==
 
-To send a VCI command packet, the '''execLoop()''' method must use the '''nb_transport_fw()''' method, that is a member 
-function of the '''p_vci_init''' port. The prototype of this method is the following:
+To send a VCI command packet, the '''execLoop()''' method must use the '''nb_transport_fw()''' method, defined by TLM2.0, 
+that is a member function of the '''p_vci_init''' port. The prototype of this method is the following:
 {{{
 
   tlm::tlm_sync_enum nb_transport_fw            
   ( soclib_vci_types::tlm_payload_type &payload,      // VCI payload pointer
-    soclib_vci_types::tlm_phase_type   &phase,       // transaction phase (TLMT_CMD)
+    soclib_vci_types::tlm_phase_type   &phase,        // transaction phase (TLMT_CMD)
     sc_core::sc_time                   &time);        // local time
 }}}
 
-The first argument is a pointer to the payload, the second represents the phase (TLMT_CMD in this case), and the third
+The first argument is a pointer to the payload, the second represents the phase, and the third
 argument contains the initiator local time.
 
@@ -148 +150 @@
 
 To receive a VCI response packet, a call-back function must be defined as a member function of the 
-class '''my_initiator'''. This call-back function (named '''vci_rsp_received()''' in the example),
-is executed each time a VCI response packet is received on the '''p_vci_init''' port. The function name is not 
-constrained, but the arguments must respect the following prototype:
+class '''my_initiator'''. This call-back function (named '''vci_rsp_received()''' in the example), must be linked to
+the '''p_vci_init''' port, and is executed each time a VCI response packet is received on the '''p_vci_init''' port. 
+The function name is not constrained, but the arguments must respect the following prototype:
 {{{
   tlm::tlm_sync_enum vci_rsp_received              
@@ -159 +161 @@
 The return value (type tlm::tlm_sync_enum)  is not used in this tlmt implementation, and must be sytematically set to tlm::TLM_COMPLETED.
 
-In the general case, the actions executed by the call-back function depend on the response transaction type ('''m_command''' field), as well as 
-the '''pktid''' and '''trdid''' fields.
+In the general case, the actions executed by the call-back function depend on the transaction type defined in the payload
+('''m_command''', '''m_pktid''' and '''m_trdid''' fields).
 For sake of simplicity, the call-back function proposed in the example below does not make any distinction between transaction types.
 
@@ -169 +171 @@
 the response packet, a link between the '''p_vci_init''' port and this call-back function must be established. 
 
-The '''my_initiator''' constructor for the '''p_vci_init''' object must be called with the following arguments:
+The constructor for the '''p_vci_init''' port must be called with the following arguments:
 {{{
   p_vci_init.register_nb_transport_bw(this, &my_initiator::vci_rsp_received);
@@ -181 +183 @@
 
 To solve this issue, it is necessary to define -for each initiator module- a '''lookahead''' parameter. This parameter defines the maximum 
-number of cycles that can be executed by the thread before it is automatically stopped. The '''lookahead''' parameter allows the system designer 
+number of cycles that can be executed by the thread before it is descheduled. The '''lookahead''' parameter allows the system designer 
 to bound the de-synchronization time interval between threads.