Changes between Version 109 and Version 110 of Writing Rules/Tlmt


Ignore:
Timestamp:
Mar 2, 2009, 7:55:40 PM (15 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Writing Rules/Tlmt

    v109 v110  
    1717we don't use the SystemC global time, as each PDES process involved in
    1818the simulation has its own local time. PDES processes (implemented as SC_THREADS) synchronize through
    19 messages piggybacked with time information.
    20 Models complying to these rules can be used with the "standard" OSCI simulation engine (SystemC 2.x) and
     19messages piggybacked with time information. This timing information is actually the absolute locat time of the sender.
     20Models complying to these TLM-T rules can be used with the "standard" OSCI simulation engine (SystemC 2.x) and
    2121the TLM2.0 library, but can also be used also with others simulation engines, especially distributed, parallelized simulation engines.
    2222
    23 The pessimistic PDES algorithm used relies on temporal filtering of the incoming messages. An active component is only allowed to process when it
    24 has sufficient timing information on its input ports. For example, an interconnect is only allowed to let a packet reach
    25 a given target only when all the initiators that are connected to it have sent at least one packet with their local times.
    26 Several experiments have been realized to identify the best way to perform this temporal filtering. The previous
    27 implementation relied on sollicited null message, i.e. the interconnect asks all the initiators for their times. This
    28 solution only impacts the way the interconnect is written, and the initiators are not aware of the interconnect requests.
    29 The experiments have shown that this technique simplifies the writing of the initiator models but also has a strong
    30 impact on the simulation time, as the interconnect spends much of its effort consulting the time of the initiators
    31 and not passing packets from initiators to targets. The induced overhead is about 90%.
    32 
    33 The solution retained is now to strictly follow the Chandy-Misra pessimistic algorithm and to reverse the synchronization
    34 process by letting the initiators transmit their local time to others according to their own null message policy. The
    35 interconnect is much simpler to write, but the initiators have to be modified in order to handle explicitely the
    36 sending of null messages. The performance of the simulation is therefore directly linked to the number of generated null
    37 messages. When writing an initiator model, this number directly corresponds to the period that separates the sending of two successive null messages.
     23The pessimistic PDES algorithm relies on temporal filtering of the incoming messages. A PDES process that has N input channels
     24is only allowed to process when it has timing information on all its input ports. For example, an interconnect is only allowed to let a
     25command packet reach a given target when all the initiators that can address this target have sent at least one timed message.
     26To solve this issue the PDES algorithm uses ''nul message''. A null message contain no data, but only a time information.
     27Moreover, all processes can be in two modes : active & non-active. Only processes that are active participate to the temporal filtering.
     28
     29A first implementation of TLMT used sollicited null messages, but the final solution uses direct null-messages, that strictly
     30follow the Chandy-Misra pessimistic algorithm. Each process cannot run independantly without sending a timed message
     31for a time larger that a predefined value, called the SYNCHRONIZATION_TIME_QUANTUM. When this time quantum is elapsed,
     32the process must send a null message on its output ports.
    3833
    3934The models described with the writing rules defined herein are syntactically compliant with the TLM2.0 standard, but do
    40 not respect its semantics. In particular, the third parameter of the transport functions is considered to be an absolute
     35not respect its semantics. In particular, the third time parameter of the transport functions is considered to be an absolute
    4136time and not relative to a global simulation time that does prevail anymore.
    4237 
    … …  
    5954
    6055The VCI communication channel is a point-to-point bi-directional channel, encapsulating two separated uni-directional
    61 channels: one to transmit the VCI command packet, one to transmit the VCI response packet.
     56channels: one to transmit the VCI command packet in the '''nb_transport_fw()''' function, one to transmit the VCI response packet
     57in the nb_transport_bw() function.
    6258
    6359= C) VCI Transaction in TLM-T =
    … …  
    7268  unsigned int          m_pkt_id;
    7369}}}
    74 The '''m_soclib_command''' data member supersedes the command of the TLM2.0 generic payload. This is why the parameter to
    75 the '''set_command()''' of a generic payload is always set to '''tlm::TLM_IGNORE_COMMAND'''. Up to seven values can be assigned
     70The '''m_soclib_command''' data member supersedes the command of the TLM2.0 generic payload. The parameter to
     71the '''set_command()''' of a generic payload is always set to '''tlm::TLM_IGNORE_COMMAND'''. Seven values can be assigned
    7672to '''m_soclib_command'''. These values are:
    7773{{{
    … …  
    8783The '''VCI_READ_COMMAND''' (resp. '''VCI_WRITE_COMMAND''') is used to send a VCI read (resp. write) packet command.
    8884The '''VCI_LINKED_READ_COMMAND''' and '''VCI_STORE_CONDITIONAL_COMMAND''' are used to implement atomic operations. The
    89 latter 3 values are not directly related to VCI but rather to the PDES simulation algorithm used. The '''TLMT_NULL_MESSAGE''' value is used whenever an initiator needs to send its local time to the rest of the platform for synchronization purpose.
    90 The '''TLMT_ACTIVE''' and '''TLMT_INACTIVE''' values are used to inform the interconnect that the corresponding initiator must be taken into account during PDES time filtering or not. A programmable component such as a DMA controller, until it
     85latter 3 values are not directly related to VCI but rather to the PDES simulation algorithm. The '''TLMT_NULL_MESSAGE''' value is used whenever an initiator needs to send its local time to the rest of the platform for synchronization purpose.
     86The '''TLMT_ACTIVE''' and '''TLMT_INACTIVE''' values are used to inform the interconnect that the corresponding initiator must be taken into account in the
     87temporal  filtering or not. A programmable component such as a DMA controller, until it
    9188has been programmed and launched should not participate in the PDES time filtering. At the beginning of the simulation,
    92 all the initiators are considered to be active, and therefore send at least one synchronization message.   
     89all the initiators send at least one synchronization message.   
    9390
    9491The data members of the '''soclib_payload_extension''' can be accessed through the following access functions:
    … …  
    122119}}}
    123120
    124 To build a new VCI packet, one has to create a new generic payload and a soclib payload extension, and to call
     121To build a new VCI packet, one has to create a generic payload and a soclib payload extension, and to call
    125122the appropriate access functions on these two objects. For example, to issue a VCI read command, one should write
    126123the following code:
    … …  
    232229}}}
    233230
    234 == D.5) Time quantum parameter ==
     231== D.5) Local Time Representation & Synchronization ==
    235232
    236233The SystemC simulation engine behaves as a cooperative, non-preemptive multi-tasks system. Any thread in the system must stop execution
    237 after at some point, in order to allow the other threads to execute. With the proposed approach, a TLM-T initiator will never stop if
    238 it does not execute blocking communication (such as a processor that has all code and data in the L1 caches).
    239 
    240 To solve this issue, it is necessary to define -for each initiator module- a '''time quantum''' parameter. This parameter defines the maximum
    241 delay that separates the sending of two successive null messages. The '''time quantum''' parameter allows the system designer
    242 to bound the de-synchronization time interval between threads.
    243 
    244 A small value for this parameter results in a better timing accuracy for the simulation, but implies a larger number of context switches,
    245 and a slower simulation speed.
    246 
    247 This time quantum parameter is implemented using the '''!QuantumKeeper''' construct already available in TLM2.0. The main
    248 difference comes from the fact that this class is just used to manage the synchronization interval between two null
    249 messages. More precisely, the '''sync()''' function of '''!QuantumKeeper''' is not used directly, because it implicitely
    250 calls a '''wait(x)''' statement (x being a time delay, which is valid in TLM2.0 but forbidden in the presented
    251 distributed time approach). The only needed part in this function is the '''reset()''' feature.
     234 at some point, in order to allow the other threads to execute. Moreover each PDES process must send null message periodically.
     235
     236To solve this issue, it is necessary to define -for each initiator module- a '''synchronization time quantum''' parameter. This parameter defines
     237the maximum delay between two successive timed messages. When this time quantum is elapsed, the component send a null message,
     238and the corresponding thread is descheduled.
     239
     240This time quantum mechanism is implemented in the '''pdes_local_time''' class.
     241For each initiator, the time quantum value is a parameter defined as a constructor argument.
     242The three members methods are...
    252243
    253244