| 129 | | === 2.2. PDES Null_command |
| 130 | | The Null_command is a message with does not require a response. Its 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 a transaction. This messages allows the interconnects to respect their time quantums, regarding to its targets. It is also used to perform the Active_Sync on initiators. The message scope is local, it cannot be routed or redirected. Receiving a null_command awakes the target if it is waiting. Initiators and interconnects can send Null_commands. |
| | 129 | === 2.2. PDES Nolock_command |
| | 130 | The Nolock_command is a message which does not require a response. Its only goal is to deliver a temporal information, in order to preserve the lockfree feature. When such a message is initiated, some others will have to be sent in order to reach the bottom of the architecture. This allows to locally broadcast a temporal information across different level of interconnection in order to prevent a possible lock. The initiator needs to wait when a Nolock_command message is sent. It is used to perform the Active_Sync on initiators. The message scope is local, it cannot be routed or redirected. Receiving a nolock_command awakes the target if it is waiting. Initiators, Local interconnects and Target-Initiators can send Nolock_commands. |
| 150 | | === 2.3. PDES Null_response |
| 151 | | The Null_response is a message which transits on networks like a VCI responses. Only transactions which are blocking or conditionnaly blocking needs to receive Null_responses. The meaning of this message is : "The response to the associated VCI transaction won't be caught before this time". The Null_response is part of the Passive/Active_Sync mechanisms. It is used to predict the future of simulation. The only useful data contained in the Null_response is the temporal information. When an initiator receives a Null_response instead of a VCI response, it allows itself to pursue its treatment, neglecting the need of the VCI response, until the Null_response time. In order to properly aim the right transaction on the right initiator, the VCI transaction is reused for the Null_response. When the Null_response is sent, only the target of this message is awaken. Multiple Null_responses can be sent for a single VCI transaction. Successives Null_response's time related to the same transaction needs to grow. |
| 152 | | |
| 153 | | Interconnects and targets can generate and transmit the Null_responses. Null_responses are useful for preventing deadlocks related to synchronization. For performance optimizations, an interconnect can neglect generating a Null_response when the associated transaction is primary. Since Null_response allows to release parallelism of the simulation, it seems important to send it with the highest time possible. |
| | 150 | === 2.3. PDES Sync_response |
| | 151 | The Sync_response is a message which transits on networks like a VCI responses. Only transactions which are blocking or conditionnaly blocking needs to receive Sync_responses. The meaning of this message is : "The response to the associated VCI transaction won't be caught before this time". The Sync_response is part of the Passive/Active_Sync mechanisms. It is used to predict the future of simulation. The only useful data contained in the Sync_response is the temporal information. When an initiator receives a Sync_response instead of a VCI response, it allows itself to pursue its treatment, neglecting the need of the VCI response, until the Sync_response time. In order to properly aim the right transaction on the right initiator, the VCI transaction is reused for the Sync_response. When the Sync_response is sent, only the target of this message is awaken. Multiple Sync_responses can be sent for a single VCI transaction. Successives Sync_response's time related to the same transaction needs to grow. |
| | 152 | |
| | 153 | Interconnects and targets can generate and transmit the Sync_responses. Sync_responses are useful for preventing deadlocks related to synchronization. For performance optimizations, an interconnect can neglect generating a Sync_response when the associated transaction is primary. Since Sync_response allows to release parallelism of the simulation, it seems important to send it with the highest time possible. |
| 168 | | extension_ptr->is_null_response(); |
| 169 | | }}} |
| 170 | | |
| 171 | | === 2.4. PDES Sync transaction |
| 172 | | The Sync transaction is composed of a command and a response. It is used by initiators which went ahead their quantum, in order to keep the synchronization between initiators connected on the same interconnect. The transaction's scope is local. Its response is sent when it is arbitrated on the interconnect. This means that every other initiators connected to this interconnect got a higher time, so it can pursue its treatment until the next quantum. |
| | 168 | extension_ptr->is_sync_response(); |
| | 169 | }}} |
| | 170 | |
| | 171 | === 2.4. PDES Sync_request |
| | 172 | The Sync_request is composed of a command and a response. It is used by initiators which went ahead their quantum, in order to keep the synchronization between initiators connected on the same interconnect. The transaction's scope is local. Its response is sent when it is arbitrated on the interconnect. This means that every other initiators connected to this interconnect got a higher time, so it can pursue its treatment until the next quantum. |
| 206 | | According to the TLMDT for SOCLIB specification, an initiator which sends a blocking request will be completely locked until the response comes back. However, targets are not ever only reactive and won't ever immediately answer to a request, possibly waiting another request which could be handled before the first one, due to the target structure. In this case, if the initiator doesn't transmit a greater time information than the one of its last request, the related interconnect won't be able to route any other request to the waiting target. The null_response is the message which allows to inform an initiator that it needs to increase its own time up to the one in the message. |
| 207 | | |
| 208 | | There are two methods for handling the null_responses. |
| 209 | | 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. |
| 210 | | |
| 211 | | 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. |
| | 209 | According to the TLMDT for SOCLIB specification, an initiator which sends a blocking request will be completely locked until the response comes back. However, targets are not ever only reactive and won't ever immediately answer to a request, possibly waiting another request which could be handled before the first one, due to the target structure. In this case, if the initiator doesn't transmit a greater time information than the one of its last request, the related interconnect won't be able to route any other request to the waiting target. The sync_response is the message which allows to inform an initiator that it needs to increase its own time up to the one in the message. |
| | 210 | |
| | 211 | There are two methods for handling the sync_responses. |
| | 212 | 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 sync_response is caught is to send a nolock_command to the interconnect with the same time information as the sync_response. This doesn't even need to wake up the initiator. This method is called Passive_Sync. |
| | 213 | |
| | 214 | The second one is dedicated for advanced multitransactionnal components modeling. There is a gap between the sync_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 sync_response is caught, the initiator is woken up and is allowed to pursue its treatment until a new transaction is sent or the sync_response time is matched, resulting in the sending of a nolock_command. This method is called Active_Sync. |
| | 215 | |
