Changes between Version 78 and Version 79 of Writing Rules/Tlmt


Ignore:
Timestamp:
Nov 16, 2008, 2:57:08 PM (15 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Writing Rules/Tlmt

    v78 v79  
    2626The interested user should also look at the [WritingRules/General general SoCLib rules].
    2727
    28 = B) Single VCI initiator and single VCI target =
     28= B) VCI initiator and VCI target =
    2929
    3030Figure 1 presents a minimal system containing one single VCI initiator, '''my_initiator''' , and one single
     
    8282arrays pointers and its associated size in bytes.
    8383
    84 Dedicated VCI accessors are used to define the VCI transaction type, that can either be '''set_read()''' (for read command),
    85 '''set_write()''' (for write command),'''set_locked_read()''' (for atomic locked read),
    86 and '''set_store_cond()''' (for atomic store conditional). The '''set_src_id()''', '''set_trd_id()''' and '''set_pkt_id()''' functions
     84Dedicated VCI accessors are used to define the VCI transaction type, that can either be '''set_read()''' (for VCI read command),
     85'''set_write()''' (for VCI write command),'''set_locked_read()''' (for VCI atomic locked read),
     86and '''set_store_cond()''' (for VCI atomic store conditional). The '''set_src_id()''', '''set_trd_id()''' and '''set_pkt_id()''' functions
    8787respectively set the VCI source, thread and packet identifiers.
    8888
    89 NB : The byte array approach defined by TLM2.0 can degrade the simulation speed,
    90 as the existing SoCLib models use uint32_t arrays to model both the embedded memory and the caches...
    91 Experiments are currently in progress to evaluate the performance degradation incurred by this byte formatting.
    92 It is therefore  possible that the types of the '''m_data''' and '''m_byte_enable''' of the '''tlmt_vci_transaction'''
     89NB : The char array approach defined by TLM2.0 can degrade the simulation speed,
     90as the existing SoCLib models use uint32_t arrays to model both the embedded memories and the caches...
     91Experiments are currently in progress to evaluate the performance degradation incurred by this char <-> uint formatting.
     92It is therefore  possible that the types of the data and byte_enable fields of the '''tlmt_vci_transaction'''
    9393will be changed to '''uint32*''' .
    9494
     
    104104and '''getLocalTime()'''.
    105105{{{
    106   sc_core::sc_time m_localTime;                     // the initiator local time
     106  sc_core::sc_time m_local_time;                     // the initiator local time
    107107  ...
    108108  void addLocalTime(sc_core::sc_time t);            // add an increment to the local time
     
    111111}}}
    112112
    113 The boolean member variable '''m_activity''' indicates if the initiator is currently active.
     113The boolean member variable '''m_activity_status''' indicates if the initiator is currently active.
    114114It is used by the arbitration threads contained in the '''vci_vgmn''' interconnect, as described in section F.
    115115The corresponding access functions are '''setActivity()''' and '''getActivity()'''.
    116116{{{
    117   bool m_activity;
     117  bool m_activity_status;
    118118  ...
    119119  void setActivity(bool t);                         // set the activity status (true if the component is active)
     
    123123The '''execLoop()''' method, describing the initiator behaviour must be declared as a member function.
    124124
    125 The '''my_initiator''' class must define a call-back function to handle the VCI response packets.
    126 
    127 Finally, the it must contain a member variable '''p_vci_init''', of type '''tlmt_simple_initiator_socket'''.
    128 This member variable represents the VCI initiator port.
     125The '''my_initiator''' class contains a member variable '''p_vci_init''', of type '''tlmt_simple_initiator_socket''', representing the VCI initiator port.
     126
     127It must also define an interface function to handle the VCI response packets.
    129128
    130129== D.2) Sending a VCI command packet ==
     
    141140
    142141The first argument is a pointer to the payload, the second represents the phase, and the third
    143 argument contains the initiator local time.
     142argument contains the initiator local time. The return value is not used in this TLM-T implementation.
    144143
    145144The '''nb_transport_fw()''' function is non-blocking.
     
    150149== D.3) Receiving a VCI response packet ==
    151150
    152 To receive a VCI response packet, a call-back function must be defined as a member function of the
    153 class '''my_initiator'''. This call-back function (named '''vci_rsp_received()''' in the example), must be linked to
     151To receive a VCI response packet, an interface function must be defined as a member function of the
     152class '''my_initiator'''. This function (named '''vci_rsp_received()''' in the example), must be linked to
    154153the '''p_vci_init''' port, and is executed each time a VCI response packet is received on the '''p_vci_init''' port.
    155154The function name is not constrained, but the arguments must respect the following prototype:
     
    160159      sc_core::sc_time                   &time);       // response time
    161160}}}
    162 The return value (type tlm::tlm_sync_enum)  is not used in this tlmt implementation, and must be sytematically set to tlm::TLM_COMPLETED.
    163 
    164 In the general case, the actions executed by the call-back function depend on the transaction type defined in the payload
    165 ('''m_command''', '''m_pktid''' and '''m_trdid''' fields).
    166 For sake of simplicity, the call-back function proposed in the example below does not make any distinction between transaction types.
     161The return value (type tlm::tlm_sync_enum)  is not used in this TLM-T implementation, and must be sytematically set to tlm::TLM_COMPLETED.
     162
     163In the general case, the actions executed by the interface function depend on both the phase argument, and on the transaction type (defined in the payload).
     164For sake of simplicity, the interface function proposed below does not make any distinction between transaction types.
    167165
    168166== D.4) Initiator Constructor ==
    169167
    170168The constructor of the class '''my_initiator''' must initialize all the member variables, including
    171 the '''p_vci_init''' port. The '''vci_rsp_received()''' call-back function being executed in the context of the thread sending
    172 the response packet, a link between the '''p_vci_init''' port and this call-back function must be established.
     169the '''p_vci_init''' port. The '''vci_rsp_received()''' function being executed in the context of the thread sending
     170the response packet, a link between the '''p_vci_init''' port and this interface function must be established.
    173171
    174172The constructor for the '''p_vci_init''' port must be called with the following arguments:
     
    204202= E) VCI target modeling =
    205203
    206 In the proposed example, the '''my_target''' component handles all VCI commands in the same way, and there is no error management.
     204In this example, the '''my_target''' component handles all VCI command types in the same way, and there is no error management.
    207205
    208206== E.1) Member variables & methods ==
     
    210208The class '''my_target''' inherits from the class '''sc_core::sc_module'''. The class '''my_target''' contains a member
    211209variable '''p_vci_target''' of type '''tlmt_simple_target_socket''', representing the VCI target port.
    212 It contains a call-back function to handle the received VCI command packets, as described below.
     210It contains an interface function to handle the received VCI command packets, as described below.
    213211
    214212== E.2) Receiving a VCI command packet ==
    215213
    216 To receive a VCI command packet, a call-back function must be defined as a member function of the class '''my_target'''.
    217 This call-back function (named '''vci_cmd_received()''' in the example), is executed each time a VCI command packet is received on
     214To receive a VCI command packet, an interface function must be defined as a member function of the class '''my_target'''.
     215This function (named '''vci_cmd_received()''' in the example), is executed each time a VCI command packet is received on
    218216the '''p_vci_target''' port. The function name is not constrained, but the arguments must respect the following prototype:
    219217{{{
     
    223221    sc_core::sc_time                   &time);        // time
    224222}}} 
     223The return value (type tlm::tlm_sync_enum)  is not used in this TLM-T implementation, and must be sytematically set to tlm::TLM_COMPLETED.
    225224
    226225== E.3) Sending a VCI response packet ==
    227226
    228 To send a VCI response packet the call-back function '''vci_cmd_received()''' use the '''nb_transport_bw()''' method, that is a member function of
     227To send a VCI response packet the call-back function '''vci_cmd_received()''' uses the '''nb_transport_bw()''' method, defined by TLM2.0, that is a member function of
    229228the class '''tlmt_simple_target_socket''', and has the same arguments as the '''nb_transport_fw()''' function.
    230229Respecting the general TLM2.0 policy, the payload argument refers to the same '''tlmt_vci_transaction''' object for both the '''nb_transport_fw()''' and '''nb_transport_bw()''' functions,
    231 and the associated call-back functions. The set_response_status field must be documented for all transaction types, but only two values are used in this TLM-T implementation:
     230and the associated interface functions. Only two values are used for the '''response_status''' field in this TLM-T implementation:
    232231 * TLMT_OK_RESPONSE
    233232 * TLMT_ERROR_RESPONSE
     
    235234
    236235{{{
     236       tlm::tlm_sync_enum vci_cmd_received (
     237           soclib_vci_types::tlm_payload_type &payload,   
     238           soclib_vci_types::tlm_phase_type   &phase
     239           sc_core::sc_time                   &time)
     240        {       
     241       ...
    237242        payload.set_response_status(soclib::tlmt::TLMT_OK_RESPONSE);
    238243        phase = soclib::tlmt::TLMT_RSP;
    239244        time = time + (nwords * UNIT_TIME);
    240245        p_vci_target->nb_transport_bw(payload, phase, time);
     246        }
    241247}}}
    242248
     
    244250
    245251The constructor of the class '''my_target''' must initialize all the member variables, including
    246 the '''p_vci_target''' port. The '''vci_cmd_received()''' call-back function being executed in the context of the thread sending
     252the '''p_vci_target''' port. The '''vci_cmd_received()''' function being executed in the context of the thread sending
    247253the command packet, a link between the '''p_vci_target''' port and the call-back function must be established.
    248254The '''my_target''' constructor must be called with the following arguments:
     
    262268}}}
    263269
    264 = F) VCI Interconnect modelling =
     270= F) VCI Interconnect modeling =
    265271
    266272The VCI interconnect used for the TLM-T simulation is a generic interconnection network, named '''!VciVgmn'''.
    267273The two main parameters are the number of initiators, and the number of targets. In TLM-T simulation,
    268 we don't want to reproduce the cycle-accurate behavior of a particular interconnect. We only want to simulate the contention in
     274we don't want to reproduce the detailed, cycle-accurate, behavior of a particular interconnect. We only want to simulate the contention in
    269275the network, when several VCI intitiators try to reach the same VCI target.
    270 Therefore, the network is actually modeled as a complete cross-bar : In a physical network such as the multi-stage network described
    271 in Figure 2.a, conflicts can appear at any intermediate switch. In the '''!VciVgmn''' network described in Figure 2.b, conflicts can
    272 only happen at the output ports. It is possible to specify a specific latency for each input/output couple. As in most physical
    273 interconnects, the general arbitration policy is round-robin.
     276 In a physical network such as the multi-stage network described in Figure 2.a, conflicts can appear at any intermediate switch.
     277The '''!VciVgmn''' network, described in Figure 2.b, is modeled as a cross-bar, and conflicts can only happen at the output ports.
     278It is possible to specify a specific latency for each input/output couple. As in most physical
     279interconnects, the general arbitration policy for each output port is round-robin.
    274280
    275281[[Image(tlmt_figure_2.png, nolink)]]
     
    279285 There is actually two fully independent networks for VCI command packets and VCI response packets. There is a routing function for each input
    280286 port, and an arbitration function for each output port, but the two networks are not symmetrical :
    281  * For the command network, the arbitration policy is distributed: there is one arbitration thread for each output port
    282  (i.e. one arbitration thread for each VCI target). Each arbitration thread is modeled by a SC_THREAD, and contains a local clock.
     287 * For the command network, the arbitration policy is distributed: there is one arbitration thread for each output port (i.e. one arbitration thread for each VCI target). Each arbitration thread is modeled by a SC_THREAD, and contains a local time. This time represents the target local time.
     288  
    283289 * For the response network, there are no conflicts, and there is no need for arbitration. Therefore, there is no thread
    284290 (and no local time) and the response network is implemented by simple function calls.