Changes between Version 3 and Version 4 of TLMDT

Timestamp:

May 2, 2011, 8:45:17 PM (13 years ago)

Author:

gioja

Comment:

--

TLMDT

@@ +1 @@
+[[PageOutline]]
+
 = TLMDT Modeling for tightly interdependent architectures with several levels of interconnections =
 == 0. Introduction
@@ -23 +25 @@
 The VCI Transactions representation mostly remains the same. Two new concepts are introduced for optimization and performance gain. They both got default value which will allow to skip this aspect for convenience. However, this will, in some cases, increase the part of PDES communication (compared to the VCI one) and slow down the simulation.
 === 1.1. Blocking type
+Basically, when an initiator sends a blocking transaction, it needs to be stopped and it waits the 'response caught' event to be awaken. When the response to the blocking transaction is caught, if the initiator is mono-transactionnal, or handled as such, its time is updated with the response's one. In case of a multi-transactionnal initiator, another transaction could be sent before the response's time, so the component needs to simulate those cycles too.
+
+Sometimes, the response treatment of a transaction doesn't impact the continuation of the simulation. In this case, it's a waste of energy to wait for a response which could be neglected, thus the initiator could pursue its treatment. The transaction can be tagged as non-blocking.
+
+However, when an initiator sends a transaction, it needs to be stored until the response comes back. In practice, the data structure which stores the requests has a fixed maximum size. When the buffer is full, a response needs to be caught in order to free a slot, thus the initiator needs to be stopped and it waits the 'response caught' event from any of these transactions to be awaken. This is an alternative to the non-blocking transactions which is more precise ,especially when the buffer is often full, but more difficult to implement. This type of transaction is called conditionaly-blocking
+
+The blocking type of a transaction is a 2 bits data stored in its payload extension. If blocking type is not specified by the user, it is considered as blocking.
+{{{#!c++
+tlm::tlm_generic_payload *payload_ptr = new tlm::tlm_generic_payload();
+soclib_payload_extension *extension_ptr = new soclib_payload_extension();
+
+//Fill the transaction with the necessary datas
+...
+
+//Set the transaction as blocking - 2 methods
+extension_ptr->set_blocking();
+extension_ptr->set_blocking_type(BLOCKING);
+
+//Set the transaction as non-blocking - 2 methods
+extension_ptr->set_non_blocking();
+extension_ptr->set_blocking_type(NON_BLOCKING);
+
+//Set the transaction as conditionaly-blocking - 2 methods
+extension_ptr->set_cond_blocking();
+extension_ptr->set_blocking_type(COND_BLOCKING);
+
+//Send the transaction the usual way
+...
+}}}
+
 === 1.2. Primarity
 A VCI Transaction can either be primary or secondary. The VCI transaction is primary only if it is not related to another transaction. That is to say when the response will be caught and treated, no response to another transaction will be sent. A pure Initiator will only send primary transactions while a Target-Initiator will be able to send both.
 
-The Primarity of a transaction is a boolean stored in its payload extension. If no primarity is specified by the user, it is considered as primary.
+The Primarity of a transaction is a boolean stored in its payload extension. If primarity is not specified by the user, it is considered as primary.
 {{{#!c++
 tlm::tlm_generic_payload *payload_ptr = new tlm::tlm_generic_payload();