Changes between Version 18 and Version 19 of Writing Rules/Tlmt

Timestamp:

Dec 27, 2007, 10:59:05 AM (16 years ago)

Author:

alain

Comment:

--

Writing Rules/Tlmt

@@ -87 +87 @@
 == C.3) Initiator Constructor ==
 
-The constructor of the class'''my_initiator''' must initialize all the member variables, including the '''p_vci''' port. The '''rspReceived()''' call-back function being executed in the context of the thread sending the response packet, a link between the '''p_vci''' port and the call-back function must be established. Moreover, the '''p_vci''' port must contain a pointer to the initiator local time.
+The constructor of the class '''my_initiator''' must initialize all the member variables, including the '''p_vci''' port. The '''rspReceived()''' call-back function being executed in the context of the thread sending the response packet, a link between the '''p_vci''' port and the call-back function must be established. Moreover, the '''p_vci''' port must contain a pointer to the initiator local time.
 The '''!VciInitiatorPort''' constructor must be called with the following arguments:
 {{{
@@ -95 +95 @@
 == C.4) Lookahead parameter ==
 
-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.
+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 threads 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). 
 
 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.