Changes between Version 4 and Version 5 of TLMDT
- Timestamp:
- May 3, 2011, 4:18:25 AM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TLMDT
v4 v5 25 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. 26 26 === 1.1. Blocking type 27 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. 27 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. If the initiator doesn't progress on its time while waiting the response, it is called Passive_Sync. On the contrary, it is called Active_Sync. The machanisms of this concept are detailed later on this page. 28 28 29 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.29 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. Such a non-blocking transaction does not prevent the initiator to exceed the defined time quantum if the synchronization timer is reseted when it is sent. 30 30 31 31 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 32 32 33 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.33 The blocking type of a transaction is a 2 bits data (char) stored in its payload extension. If blocking type is not specified by the user, it is considered as blocking. 34 34 {{{#!c++ 35 35 tlm::tlm_generic_payload *payload_ptr = new tlm::tlm_generic_payload(); … … 53 53 //Send the transaction the usual way 54 54 ... 55 56 //Retrieve the information 57 extension_ptr->get_cond_blocking(); //returns char 58 extension_ptr->is_blocking(); //returns bool 59 extension_ptr->is_non_blocking(); //returns bool 60 extension_ptr->is_cond_blocking(); //returns bool 55 61 }}} 56 62 … … 76 82 //Send the transaction the usual way 77 83 ... 84 85 //Retrieve the information 86 extension_ptr->get_primarity(); //returns bool 87 extension_ptr->is_primary(); //returns bool 88 extension_ptr->is_secondary(); //returns bool 78 89 }}} 90 79 91 == 2. PDES Messages 80 92 === 2.1. PDES Activity message … … 106 118 Usage : 107 119 {{{#!c++ 108 //active the initiator and inform to interconnect 109 m_pdes_activity_status->set(true); 110 sendActivity(); 111 }}} 120 //active the initiator and inform to interconnect 121 m_pdes_activity_status->set(true); 112 122 113 {{{#!c++ 114 //desactive the initiator and inform to interconnect 115 m_pdes_activity_status->set(false); 116 123 //desactive the initiator and inform to interconnect 124 m_pdes_activity_status->set(false); 125 126 sendActivity(); 117 127 }}} 118 128 119 129 === 2.2. PDES Null_command 130 The Null_command is a message with does not require a response. His only goal is to deliver a temporal information, in order to preserve the synchronization between components. Mostly, the initiator doesn't stop when the null_command message is sent, except if it is waiting for the response from another transaction. This messages allows the different components to respect their time quantums. It is also used to perform the Active_Sync on initiators. 131 {{{#!c++ 132 tlm::tlm_generic_payload *payload_ptr = new tlm::tlm_generic_payload(); 133 soclib_payload_extension *extension_ptr = new soclib_payload_extension(); 134 135 extension_ptr->set_null_command(); 136 // set the extension to tlm payload 137 payload_ptr->set_extension (extension_ptr); 138 //set the tlm phase 139 phase = tlm::BEGIN_REQ; 140 //set the local time to transaction time 141 time = m_pdes_local_time->get(); 142 //send a message with command equals to PDES_ACTIVE or PDES_INACTIVE 143 p_vci_init->nb_transport_fw(*payload_ptr, phase, time); 144 145 //Retrieve information 146 extension_ptr->is_null_command(); 147 }}} 148 120 149 === 2.3. PDES Null_response 121 150 === 2.4. PDES Sync transaction 151 === 2.5. Passive_Sync / Active_Sync 122 152 123 153 == 3. Efficient time modeling in a multi-transactionnal VCI Component
