Changes between Version 96 and Version 97 of Writing Rules/Tlmt

Timestamp:

Mar 2, 2009, 4:17:52 PM (17 years ago)

Author:

alinevieiramello@…

Comment:

--

Writing Rules/Tlmt

@@ -21 +21 @@
 the TLM2.0 library, but can also be used also with others simulation engines, especially distributed, parallelized simulation engines.
 
-The pessimistic PDES algorithm used relies on temporal filtering. An active component is only allowed to process when it
+The pessimistic PDES algorithm used relies on temporal filtering of the incoming messages. An active component is only allowed to process when it
 has sufficient timing information on its input ports. For example, an interconnect is only allowed to let a packet reach
 a given target only when all the initiators that are connected to it have sent at least one packet with their local times.
@@ -159 +159 @@
 This class inherits from the standard SystemC '''sc_core::sc_module''' class, that acts as the root class for all TLM-T modules.
 
-TLM2.0 uses the notion of local time to allow temporal decoupling, that is the possibility for an initiator to be ahead
-in time without synchronization. The temporal barrier associated to a model is called the time quantum in TLM2.0 and
-is relative to the global simulation time. When the time quantum is reached, it is reset to 0. In the PDES paradigm, 
-the timestamps are absolute and this technique can not be used directly.
-
-To respect the PDES principle, the initiator has its own local time, and runs independently of other initiators. This
-assertion is very strong and has a deep impact on the models: '''The global SystemC time can not be used'''. This
-local time is very similar to the local time proposed by the TLM2.0 standard, but it operates in a very different way
-because it does not rely on the global simulation time.
-    
 The initiator local time is contained in a member variable named '''m_local_time''', of type '''sc_core::sc_time'''. The
 local time can be accessed with the following accessors: '''addLocalTime()''', '''setLocalTime()''' 
@@ -338 +328 @@
 The '''!VciVgmn''' network, described in Figure 2.b, is modeled as a cross-bar, and conflicts can only happen at the output ports. 
 It is possible to specify a specific latency for each input/output couple. As in most physical 
-interconnects, the general arbitration policy for each output port is round-robin.
+interconnects, the general arbitration policy is round-robin.
 
 [[Image(tlmt_figure_2.png, nolink)]]
@@ -344 +334 @@
 == F.1) Generic network modeling ==
 
- There is actually two fully independent networks for VCI command packets and VCI response packets. There is a routing function for each input 
- port, and an arbitration function for each output port, but the two networks are not symmetrical :
- * For the command network, the arbitration policy is distributed: there is one arbitration thread for each output port (i.e. one arbitration thread for each VCI target). Each arbitration thread is modeled by a SC_THREAD, and contains a local time. This time represents the target local time.
+According to PDES, a packet P emitted by an initiator reaches the correct target when it is safe to do so, i.e. when the 
+interconnect is sure that no initiator will send a packet with a timestamp lesser than the timestamp of P. This temporal
+filtering operation can be factorized, when all the connected active initiators have sent at least one message to the interconnect.
+These messages are stored in a centralized data structure. This structure stores tree information: the packet, the timestamps and the current initiator activity. After elaboration of the simulator, the activity information for each initiator is set to true. For example, a coprocessor will send a message with '''m_soclib_command''' set to '''TLMT_INACTIVE''' in the beginning of the simulation.  Therefore, when all slots of this centralized structure are
+filled with real or null messages with their associated timestamps, a temporal filtering iteration can occur. 
+
+The arbitration process must take into account the actual state of the VCI initiators: For example a DMA coprocessor that has not yet been activated
+will not send request and should not participate in the temporal filtering and arbitration process. As a general rule, each VCI initiator must define an '''active''' boolean flag,
+defining if it should participate to the arbitration. This '''active''' flag is always set to true for general purpose processors.
+
+
+There is actually two fully independent networks for VCI command packets and VCI response packets. 
+
+The two networks are not symmetrical :
+ * There is one processing thread for each output port (i.e. one processing thread for each VCI target). Each processing thread is modeled by a SC_THREAD, and contains a dedicated message fifo and a local time. This time represents the target local time.
   
- * For the response network, there are no conflicts, and there is no need for arbitration. Therefore, there is no thread 
- (and no local time) and the response network is implemented by simple function calls.
-
-This is illustrated in Figure 3 for a network with 2 initiators and three targets :  
+ * For the response network, there are no conflicts, and therefore there is no thread 
+ (and no local time). The response network is implemented by simple function calls.
+
+This scheme is illustrated in Figure 3 for a network with 2 initiators and three targets :  
 
 [[Image(tlmt_figure_3.png, nolink)]]
 
-== F.2) Arbitration Policy ==
-
-As described above, there is one '''cmd_arbitration''' thread associated to each VCI target. This thread is in charge of selecting one timed request between
-all possible requesters, and to forward it to the target. According to the PDES principles, the arbitration thread must select the request with the smallest timestamp. 
-The arbitration process must take into account the actual state of the VCI initiators: For example a DMA coprocessor that has not yet been activated
-will not send request and should not participate in the arbitration process. As a general rule, each VCI initiator must define an '''active''' boolean flag,
-defining if it should participate to the arbitration. This '''active''' flag is always set to true for general purpose processors.
-Any arbitration thread receiving a timed request is resumed. It must obtain an up to date timing & activity information for all its input channels before making any decision.
-To do that, the '''m_local_time''' and '''m_activity_status''' variables of all VCI initiators are considered as public variables, that can be accessed (read only) by all arbitration threads.  
-The arbitration policy is the following : The arbitration thread scans all its input channels, and selects the smallest time between the active initiators.
-If there is a request, this request is forwarded to the target, and the arbitration thread local time is updated. 
-If there is no request from this initiator, the thread is descheduled and will be resumed when it receives a new request.
-
-For efficiency reasons, in this implementation, each arbitration thread constructs - during elaboration of the simulation - two local array of pointers (indexed
-by the input channel index) to access the '''m_local_time''' and '''m_activity_status''' variables of all  VCI initiators. To get this information, each arbitration thread 
-uses the '''nb_transport_bw()''' function on all its VCI target ports, with a dedicated value for the phase called '''soclib::tlmt::TLMT_INFO'''. The payload argument refers to the same 
-'''tlmt_vci_payload''' object as the two other phase values ('''soclib::tlmt::TLMT_CMD''' and '''soclib::tlmt::TLMT_RSP''').
-
-{{{
-for (size_t i=0;i<m_nbinit;i++) {
-    phase   = soclib::tlmt::TLMT_INFO;
-    m_RspArbCmdRout[i]->p_vci->nb_transport_bw(payload, phase, rspTime);
-    m_array[i].ActivityStatus = payload.get_activity_ptr();
-    m_array[i].LocalTime = payload.get_local_time_ptr();        
-}
-}}}
-
-As the net-list of the simulated platform mus be explicitely defined before constructing the LocalTime and ActivityStatus arrays, the vgmn hardware component 
-provides an utility function '''fill_time_activity_arrays()''' that must be called in the SystemC top-cell, before starting the simulation.
-
-
+The command network handles the two following tasks:
+
+ * Temporal filtering and arbitration of the requests from the initiators. 
+This task is activated when all the connected initiators have sent at least one message to the interconnect. 
+The task computes the list of the messages that can actually
+be sent to the targets according to PDES. The list contains all the messages which timestamp belongs to the time interval [T, T+ interconnect_delay], where T is the smallest timestamp of all the messages in the interconnect. Priority between
+initiators with the same local time is computed using a traditional round-robin algorithm. The temporal filtering and arbitration task is executed in the context of the initiator that sends a new (possibly null) message.
+ 
+ * Routing of a filtered request packet to the correct target. Each target runs under the control of a processing thread and
+has a dedicated message fifo. The routing wakes up the processing thread of the
+corresponding target, that empties the message fifo filled by the temporal filtering. The behavioral function of the target
+is executed in the context of the processing thread.
+