Changes between Version 8 and Version 9 of TLMDT

Timestamp:

May 17, 2011, 10:23:47 AM (13 years ago)

Author:

gioja

Comment:

--

TLMDT

@@ -207 +207 @@
 
 There are two methods for handling the null_responses.
-The first and easiest one is to continue to consider that an initiator is fully locked until the real response is caught. This way, the only thing to do when a null_response is caught is to send a null_command to the interconnect with the same time information as the null_message. This doesn't even need to wake up the initiator. 
+The first and easiest one is to continue to consider that an initiator is fully locked until the real response is caught. This way, the only thing to do when a null_response is caught is to send a null_command to the interconnect with the same time information as the null_response. This doesn't even need to wake up the initiator. This method is called Passive_Sync.
+
+The second one is dedicated for advanced multitransactionnal components modeling. There is a gap between the null_response time and the initiator one. During this gap, there can be some useful cycles to simulate which can also initiate a transaction. In order to prevent this eventual request to be delayed, the cycles in the gap need to be simulated. When a null_response is caught, the initiator is woken up and is allowed to pursue its treatment until a new transaction is sent or the null_response time is matched, resulting in the sending of a null_command. This method is called Active_Sync.
 == 3. Efficient time modeling in a multi-transactionnal VCI Component
+Mostly, a multi-transactionnal component is composed of several threads in its CABA model. Those threads are used to model various behaviors, such as the control of access to a material resource or the resource usage by a dataflow.
+
+In a CABA simulation, a multi-thread component is effective because threads advance their time all together. The only issue which can occur is in case of concurrent accesses on a single material resource. In a TLMDT simulation, the possible desynchronization between threads has to be taken into account. This induce the need of a strong synchronization between each threads in order to prevent accidental transaction's reordering. Moreover, the cost of this synchronisation isn't negligible.
+
+However, in TLMDT a component is modeled using a single thread. In order to represent the multi-thread function, every CABA thread is modeled by a timer in the TLMDT model. The internal modeling of a component will then be divided into two major sections. The first one will represent a scheduler whose job is to determine which action can be computed, while the second one will perform the elected action treatment. When a treatment is started, it won't be stopped unless it is over or an access to a shared material resource is requested.
 == 4. VCI Initiator modeling
+The initiators need to be modeled using Active_Sync or Passive_Sync and should consider the primarity and blocking_type mechanisms. For anything else, the initiators remain unchanged.
 == 5. VCI Target-Initiator (decoupled) modeling
+A decoupled Target-Initiator component can be seen as two components, a regular target and a regular initiator. The interesting part is the interactions between those two. When the target receives a message, it is transmitted to the initiator which will instantly send an activity message if it was inactive. The initiator part will pursue its treatment until it has nothing else to do but to wait and then send an inactivity message.
 == 6. VCI Target-Initiator (coupled) modeling
+A coupled Target-Initiator acts like a simple initiator but needs to consider the input timer and some suppositions on the capabilities of the next incoming transaction. It cans also generate null_responses. 
 == 7. VCI Target modeling
+There are no changes in the target modeling.
 == 8. VCI Local Crossbar modeling
+The interconnects are the most modified component with the "TLMDT for tightly interdependent architectures with several levels of interconnections" specification. The Local Crossbar has to handle the new synchronisation protocol. It has a time quantum (Δqlc), which determine the maximum allowed desynchronization for each target.
+
+Pseudo code : 
+
+{{{#!c++
+//Global Synchronisation
+// T = Time - Δ = quantum 
+If (T.global_input + Δqlc < T.local_crossbar)
+   If (null_command of vci_transaction received from global crossbar)
+      T.global_input = T.local_crossbar
+Else If(arbitration ok : Req = handled request)
+   T.local_crossbar = T.Req
+   //Local Synchonisation
+   For every local target
+      if(T.local_target + Δqlc < T.local_crossbar)
+         send a null_command to the target
+         T.local_target = T.local_crossbar
+   //Global Synchronisation
+   If (T.global_input + Δqlc < T.local_crossbar)
+      send a null_command to the global_crossbar
+   //Initiators Synchronisation
+   Else If (Req.type == Sync_request)
+      send the response to this transaction
+   //Cluster Unlock
+   Else If (Req.type == Null_command && input != global_input)
+      send a Null_command to every local target and global crossbar
+   //Routing
+   Else If (Req.type == vci_transaction && input == global_input)
+      T.global_input = T.local_crossbar
+      Routage
+   Else If (Req.type == vci_transaction && input != global_input)
+      Routage
+Else //arbitration ko
+   send a null_response for any non primary blocking or conditionnaly blocking request for which the interconnect did not sent one before.
+   wait for a new incoming transaction
+}}}
 == 9. VCI Global Crossbar modeling
+The Global Crossbar is even more impacted than the local crossbar because of the release of synchronisation on it in order to break the strong global dependencies and ever allow every cluster to feed its targets with times. Its duty is to release all clusters which are not too much in advance (determined by its time quantum - Δqgc) and to route transactions. Considering that a cluster can be released even if another one got a lower timer and that a cluster doesn't need to synchronize with the Global Crossbar until the desynchronization timer reaches a certain value, there will be a loss in precision but this allows an increase in the parallelization of the simulation and a reduced amount of PDES transactions.
+
+Pseudo code :
+
+{{{#!c++
+T.global_crossbar = min(all T inputs)
+For every input
+   If (T.input <= T.global_crossbar + Δqgc)
+      //Synchronization
+      If(Req.type == Null_command)
+         Send back another null_command with the same temporal information.
+      //Routing
+      If(Req.type == vci_transaction)
+         T.Req = T.target_port
+         Routing
+   Else
+      //Init Unlcok
+      If(Req.type == vci_transaction)
+         Send a null_response
+
+}}}
 == 10. Proof of the deadlock free feature
 == 11. Locating the loss in precision