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.

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.

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 primarity is not 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();

2.2. PDES Null_command

2.3. PDES Null_response

2.4. PDES Sync transaction

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