Changes between Version 62 and Version 63 of Writing Rules/Tlmt

Timestamp:

Nov 15, 2008, 4:59:00 PM (15 years ago)

Author:

alain

Comment:

--

Writing Rules/Tlmt

@@ -257 +257 @@
 {{{
         payload.set_response_status(soclib::tlmt::TLMT_OK_RESPONSE);
-        phase = soclib::tlmt::TLMT_VCI_RSP;
+        phase = soclib::tlmt::TLMT_RSP;
         time = time + (nwords * UNIT_TIME);
         p_vci_target->nb_transport_bw(payload, phase, time);
@@ -311 +311 @@
 == E.2) Arbitration Policy ==
 
-As described above, there is one arbitration thread associated to each VCI target. This thread
-== E.3)  General Initiators and Targets synchronization ==
-
-As described in sections B & C, each VCI initiator TLM-T module contains a thread and a local clock. But, in order to increase the TLM-T simulation 
-speed,  the VCI targets are generally described as reactive call-back functions. Therefore, there is no thread, and no local clock in the TLM-T 
-module describing a VCI target. For a VCI target, the local clock is actually the clock associated to the corresponding arbitration 
-thread contained in the '''!VciVgmn''' module.
+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 LocalTime and ActivityStatus of all VCI initiators are considered as global variables, that can be accessed (for 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 not, 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 LocalTime and ActivityStatus variables of the corresponding VCI initiators. To get this information, each arbitration thread 
+uses the ''nb_transport_bw()''' function on all its VCI target ports, with a a dedicated phase called '''soclib::tlmt::TLMT_INFO'''. The payload argument refers to the same 
+'''tlmt_vci_transaction''' object as the two other phases (TLMT_CMD and 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].activity = payload.get_activity_ptr();
+    m_array[i].time = payload.get_local_time_ptr();     
+}
+}}}
+
+As the net-list of the simulated pltform mus be explicitely defined before constructing those 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.
+