| Version 3 (modified by , 13 years ago) (diff) |
|---|
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
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.
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); //Send the transaction the usual way ...
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); sendActivity();
//desactive the initiator and inform to interconnect m_pdes_activity_status->set(false); sendActivity();
