| Version 6 (modified by , 14 years ago) (diff) |
|---|
-
TLMDT Modeling for tightly interdependent architectures with several …
- 0. Introduction
- 1. VCI Transactions
- 2. PDES Messages
- 3. Efficient time modeling in a multi-transactionnal VCI Component
- 4. VCI Initiator modeling
- 5. VCI Target-Initiator (decoupled) modeling
- 6. VCI Target-Initiator (coupled) modeling
- 7. VCI Target modeling
- 8. VCI Local Crossbar modeling
- 9. VCI Global Crossbar modeling
- 10. Proof of the deadlock free feature
- 11. Locating the loss in precision
TLMDT Modeling for tightly interdependent architectures with several levels of interconnections
0. Introduction
This document is still under development.
This TLMDT specification is strongly based on the TLMDT for SOCLIB one.
Several rules are preserved :
- Method used to model a VCI / PDES transaction (payload with extension / phase / time)
- Global modeling of the VCI Initiator and VCI Target
- Global description on the interconnect's work
- PDES : activity message
Some others are not :
- PDES : null-message
- PDES : token (not described in the link)
- Interconnect's inner synchronisation mechanisms
This TLMDT specification is needed to prevent deadlocks and to greatly promote performance & parallelization with minor loss to precision on architecture that are not only composed of simple initiators and targets linked through a single network.
List of components' behaviors which exists on TSAR and cannot be efficiently modeled without this specification :
- Multi-transactionnal initiators
- Multiple networks on which a single component can (directly or not) be an initiator for several ports of an interconnect.
- Components which are target and initiator at the same time.
1. VCI Transactions
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. 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.
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.
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 (char) stored in its payload extension. If blocking type is not specified by the user, it is considered as blocking.
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); //Default //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 ... //Retrieve the information extension_ptr->get_cond_blocking(); //returns char extension_ptr->is_blocking(); //returns bool extension_ptr->is_non_blocking(); //returns bool extension_ptr->is_cond_blocking(); //returns bool
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 primarity is not specified by the user, it is considered as secondary.
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 primary - 2 methods extension_ptr->set_primary(); extension_ptr->set_primarity(true); //Set the transaction as secondary - 2 methods extension_ptr->set_secondary(); extension_ptr->set_primarity(false); //Default //Send the transaction the usual way ... //Retrieve the information extension_ptr->get_primarity(); //returns bool extension_ptr->is_primary(); //returns bool extension_ptr->is_secondary(); //returns bool
2. PDES Messages
2.1. PDES Activity message
The PDES activity message remains unmodified. The activity message intends to connect or disconnect an initiator from the interconnect with which it is linked. If the activity of an initiator is true, then the associated centralized buffer slot on the interconnect will be handled for the temporal arbitration, otherwise it won't. The following code is a recall from the linked TLMDT for SOCLIB specification.
send to interconnect the initiator activity status void my_initiator::sendActivity() { tlm::tlm_generic_payload *payload_ptr = new tlm::tlm_generic_payload(); soclib_payload_extension *extension_ptr = new soclib_payload_extension(); tlm::tlm_phase phase; sc_core::sc_time time; // set the active or inactive command if(m_pdes_activity_status->get()) extension_ptr->set_active(); else extension_ptr->set_inactive(); // set the extension to tlm payload payload_ptr->set_extension (extension_ptr); //set the tlm phase phase = tlm::BEGIN_REQ; //set the local time to transaction time time = m_pdes_local_time->get(); //send a message with command equals to PDES_ACTIVE or PDES_INACTIVE p_vci_init->nb_transport_fw(*payload_ptr, phase, time); //wait a response wait(m_rspEvent); }
Usage :
//active the initiator and inform to interconnect m_pdes_activity_status->set(true); //desactive the initiator and inform to interconnect m_pdes_activity_status->set(false); sendActivity();
2.2. PDES Null_command
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 another transaction. This messages allows the different components to respect their time quantums. 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.
tlm::tlm_generic_payload *payload_ptr = new tlm::tlm_generic_payload(); soclib_payload_extension *extension_ptr = new soclib_payload_extension(); extension_ptr->set_null_command(); // set the extension to tlm payload payload_ptr->set_extension (extension_ptr); //set the tlm phase phase = tlm::BEGIN_REQ; //set the local time to transaction time time = m_pdes_local_time->get(); //send a message with command equals to PDES_ACTIVE or PDES_INACTIVE p_vci_init->nb_transport_fw(*payload_ptr, phase, time); //Retrieve information extension_ptr->is_null_command();
2.3. PDES Null_response
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 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.
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.
soclib_payload_extension *extension_ptr; payload_ptr->get_extension(extension_ptr); //Set the Null_response flag - 2 methods extension_ptr->set_null_response(); extension_ptr->set_vci_response(false); //set the tlm phase phase = tlm::BEGIN_RSP; //set the local time to transaction time time = m_pdes_local_time->get(); //send a message with command equals to PDES_ACTIVE or PDES_INACTIVE p_vci_target->nb_transport_bw(*payload_ptr, phase, time); //Retrieve information extension_ptr->is_null_response(); extension_ptr->is_vci_response();
