|   | 64 | 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 '''rspReceived()''' in the example), will be executed each time a VCI response packet is received on the '''p_vci''' port. The function name is not constrained, but the arguments must respect the following prototype: | 
                  
                          |   | 65 | {{{ | 
                  
                          |   | 66 | void  rspReceived(vci_rsp_t  *rsp, | 
                  
                          |   | 67 |                sc_time  time) | 
                  
                          |   | 68 | }}}  | 
                  
                          |   | 69 | The informations transported by a VCI command packet are defined below: | 
                  
                          |   | 70 | {{{ | 
                  
                          |   | 71 | class vci_rsp_t { | 
                  
                          |   | 72 | vci_command_t  cmd;  // VCI transaction type | 
                  
                          |   | 73 | uint32_t  length;  // number of words in the packet | 
                  
                          |   | 74 | bool  eop;  // end of packet marker | 
                  
                          |   | 75 | uint32_t  srcid;  // SRCID VCI | 
                  
                          |   | 76 | uint32_t  trdid;  // TRDID VCI | 
                  
                          |   | 77 | uint32_t  pktid;  // PKTID VCI | 
                  
                          |   | 78 | } | 
                  
                          |   | 79 | }}} | 
                  
                          |   | 80 | The actions executed by the call-back function depend on the transaction type ('''cmd'''  field), as well as the '''pktid''' and '''trdid''' fields. In the proposed example : | 
                  
                          |   | 81 |  * In case of of a blocking read , the call-back function updates the local time, and activates the suspended threadwith the by the '''notify()''' method. | 
                  
                          |   | 82 |  * In case of a non-blocking write, the call-back function does nothing. | 
                  
                          |   | 83 |   | 
                  
            
                      
                        | 68 |   | == C.5) TLM-T initiator example == | 
                      
                      
                        |   | 94 | The SystemC simulation engine behaves as a cooperative, non-preemptive multi-tasks system. Any thread in the system must stop execution after a given time, in order to allow the other threds to execute. With the proposed approach, a TLM-T initiator will never stop if it does not execute blocking communication (such as a processor that has all code and data in the L1 caches). This can block the simulation. | 
                      
                        |   | 95 |  | 
                      
                        |   | 96 | To solve this problem, 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 stops. The '''lookahead''' parameter allows the system designer to bound the de-synchronization between threads.  | 
                      
                        |   | 97 | A small value for this parameter result in a better timing accuracy for the simulation, but implies a larger number of context switch, and a slower simulation speed.  | 
                      
                        |   | 98 |  | 
                      
                        |   | 99 | == C.4) TLM-T initiator example == |