Changes between Version 5 and Version 6 of Writing Rules/Transactors

Timestamp:

Feb 24, 2010, 5:11:56 PM (14 years ago)

Author:

alinevieiramello@…

Comment:

--

Writing Rules/Transactors

@@ -23 +23 @@
 The modeling approach for the transactors respects the PDES distributed time representation : The clock signal CK of the CABA component is directly driven by the associated transactor component, depending on the local time  evolution. If there are several CABA components in a given TLM-DT platform, there is no direct coupling between the CABA components (no sc_signal connecting two CABA component controled by two different transactors). 
 
-= C) Modeling =
+= C) Initiator VCI Transactor modeling =
 
+All VCI commands received on the CABA interface are registered in a buffer indexed by the TRDID field. Each entry in this Pending_Transaction_Buffer contains a transaction status, a transaction time, and enough space to store a complete VCI TLM-DT transaction payload. 
+As for any TLM-DT initiator, the behavior() sc_thread associated to the VciInitiatorTransactor is permanently running. It is descheduled twice per simulated cycle to drive the CK signal on the CABA interface. It implement the same look-ahead mechanism as any TLM-DT initiator to send NULL messages with a bounded period when there is no regular (Read or Write) VCI transactions. 
+Regarding the VCI command, the behavior() thread read the command signals (cycle per cycle), on the CABA ports,  and stores a complete transaction payload in the Pending_Transaction_Buffer. When the transaction is completed, the behavior() thread calls the nb_transport_fw() method on the TLM-DT port.
+
+Regarding the VCI response, the interface nb_transport_bw() method updates the status of the proper entry in the Pending_Transaction_Buffer when a response is received on the TLM-DT port. This response is then transmitted (cycle per cycle) by the behaviour() thread on the CABA ports.
+If the VCI initiator can receive interrupts, the transactor provides an optional service of translation : When an IRQ is received on the TLM-DT IRQ port (by the interface nb_transport_fw() method)  this information is registered, and the IRQ is transmited on the IRQ CABA port by the behaviour() thread.
+
+= D) Target VCI Transactor modeling
+All transactions received on the TLM-DT port are registered in a 2 dimensions buffer, indexed by both the VCI SRCID, and VCI TRDID fields. Each entry in this Pending-Transaction_Buffer contains a transaction status, a transaction time, and a pointer on the transaction payload. 
+As any TLM-DT target, the VciTargetTransactor component has a purely reactive behaviour : the behavior() thread is running only when a command is received, and keeps running until the last response to the last pending transaction has been transmited. When it is running,  it is descheduled twice per simulated cycle to drive the CK signal on the CABA interface.
+Regarding the VCI commands received on the TLMDT port, the nb_transport_fw() interface method register the transaction in the Pending_Transaction_Buffer. The behaviour() thread will then send (cycle per cycle) the VCI command on the CABA port.
+Regarding the VCI responses received on the CABA port, the behaviour() thread updates the payload (cycle per cycle). When the transaction is completed, the corresponding entry in the Pending_transaction_buffer is cleared, and the nd_transport_bw() method is called on the TLM-DT port. 
+
+If the VCI target can send interrupts, the transactor provides an optional service of translation : When the behaviour() thread is running (following a VCI command, or NULL message reception) it polls the CABA IRQ port, and calls the nb_transport_fw() method on the IRQ TLM-DT port when the CABA value is modified. 
+
+= E)Implementation =
+For both transactors, each entry in the Pending_transaction_Buffer can be in three different states :
+* '''EMPTY''' : No registered transaction.
+* '''OPEN''' : Command registered, waiting the response. 
+* '''COMPLETED''' : The response has been received
+The main differences between the initiator & target transactors are the following :
+* The Pending_Transaction_Buffer is larger for a target, because it is a two dimensionnal array, indexed by SRCID and TRDID. The target entry is simpler, because each entry contains only a pointer on the transaction payload.
+* The behavior() thread is always runable for an initiator purely reactive for a target : It is not runable when the Pending_Transaction_Buffer is empty.