161 | | TLM2.0 uses the notion of local time to allow temporal decoupling, that is the possibility for an initiator to be ahead |
162 | | in time without synchronization. The temporal barrier associated to a model is called the time quantum in TLM2.0 and |
163 | | is relative to the global simulation time. When the time quantum is reached, it is reset to 0. In the PDES paradigm, |
164 | | the timestamps are absolute and this technique can not be used directly. |
165 | | |
166 | | To respect the PDES principle, the initiator has its own local time, and runs independently of other initiators. This |
167 | | assertion is very strong and has a deep impact on the models: '''The global SystemC time can not be used'''. This |
168 | | local time is very similar to the local time proposed by the TLM2.0 standard, but it operates in a very different way |
169 | | because it does not rely on the global simulation time. |
170 | | |
346 | | There is actually two fully independent networks for VCI command packets and VCI response packets. There is a routing function for each input |
347 | | port, and an arbitration function for each output port, but the two networks are not symmetrical : |
348 | | * 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. |
| 336 | According to PDES, a packet P emitted by an initiator reaches the correct target when it is safe to do so, i.e. when the |
| 337 | interconnect is sure that no initiator will send a packet with a timestamp lesser than the timestamp of P. This temporal |
| 338 | filtering operation can be factorized, when all the connected active initiators have sent at least one message to the interconnect. |
| 339 | These messages are stored in a centralized data structure. This structure stores tree information: the packet, the timestamps and the current initiator activity. After elaboration of the simulator, the activity information for each initiator is set to true. For example, a coprocessor will send a message with '''m_soclib_command''' set to '''TLMT_INACTIVE''' in the beginning of the simulation. Therefore, when all slots of this centralized structure are |
| 340 | filled with real or null messages with their associated timestamps, a temporal filtering iteration can occur. |
| 341 | |
| 342 | The arbitration process must take into account the actual state of the VCI initiators: For example a DMA coprocessor that has not yet been activated |
| 343 | will not send request and should not participate in the temporal filtering and arbitration process. As a general rule, each VCI initiator must define an '''active''' boolean flag, |
| 344 | defining if it should participate to the arbitration. This '''active''' flag is always set to true for general purpose processors. |
| 345 | |
| 346 | |
| 347 | There is actually two fully independent networks for VCI command packets and VCI response packets. |
| 348 | |
| 349 | The two networks are not symmetrical : |
| 350 | * There is one processing thread for each output port (i.e. one processing thread for each VCI target). Each processing thread is modeled by a SC_THREAD, and contains a dedicated message fifo and a local time. This time represents the target local time. |
357 | | == F.2) Arbitration Policy == |
358 | | |
359 | | As described above, there is one '''cmd_arbitration''' thread associated to each VCI target. This thread is in charge of selecting one timed request between |
360 | | all possible requesters, and to forward it to the target. According to the PDES principles, the arbitration thread must select the request with the smallest timestamp. |
361 | | The arbitration process must take into account the actual state of the VCI initiators: For example a DMA coprocessor that has not yet been activated |
362 | | will not send request and should not participate in the arbitration process. As a general rule, each VCI initiator must define an '''active''' boolean flag, |
363 | | defining if it should participate to the arbitration. This '''active''' flag is always set to true for general purpose processors. |
364 | | Any arbitration thread receiving a timed request is resumed. It must obtain an up to date timing & activity information for all its input channels before making any decision. |
365 | | To do that, the '''m_local_time''' and '''m_activity_status''' variables of all VCI initiators are considered as public variables, that can be accessed (read only) by all arbitration threads. |
366 | | The arbitration policy is the following : The arbitration thread scans all its input channels, and selects the smallest time between the active initiators. |
367 | | If there is a request, this request is forwarded to the target, and the arbitration thread local time is updated. |
368 | | If there is no request from this initiator, the thread is descheduled and will be resumed when it receives a new request. |
369 | | |
370 | | For efficiency reasons, in this implementation, each arbitration thread constructs - during elaboration of the simulation - two local array of pointers (indexed |
371 | | by the input channel index) to access the '''m_local_time''' and '''m_activity_status''' variables of all VCI initiators. To get this information, each arbitration thread |
372 | | uses the '''nb_transport_bw()''' function on all its VCI target ports, with a dedicated value for the phase called '''soclib::tlmt::TLMT_INFO'''. The payload argument refers to the same |
373 | | '''tlmt_vci_payload''' object as the two other phase values ('''soclib::tlmt::TLMT_CMD''' and '''soclib::tlmt::TLMT_RSP'''). |
374 | | |
375 | | {{{ |
376 | | for (size_t i=0;i<m_nbinit;i++) { |
377 | | phase = soclib::tlmt::TLMT_INFO; |
378 | | m_RspArbCmdRout[i]->p_vci->nb_transport_bw(payload, phase, rspTime); |
379 | | m_array[i].ActivityStatus = payload.get_activity_ptr(); |
380 | | m_array[i].LocalTime = payload.get_local_time_ptr(); |
381 | | } |
382 | | }}} |
383 | | |
384 | | As the net-list of the simulated platform mus be explicitely defined before constructing the LocalTime and ActivityStatus arrays, the vgmn hardware component |
385 | | provides an utility function '''fill_time_activity_arrays()''' that must be called in the SystemC top-cell, before starting the simulation. |
386 | | |
387 | | |
| 359 | The command network handles the two following tasks: |
| 360 | |
| 361 | * Temporal filtering and arbitration of the requests from the initiators. |
| 362 | This task is activated when all the connected initiators have sent at least one message to the interconnect. |
| 363 | The task computes the list of the messages that can actually |
| 364 | be sent to the targets according to PDES. The list contains all the messages which timestamp belongs to the time interval [T, T+ interconnect_delay], where T is the smallest timestamp of all the messages in the interconnect. Priority between |
| 365 | initiators with the same local time is computed using a traditional round-robin algorithm. The temporal filtering and arbitration task is executed in the context of the initiator that sends a new (possibly null) message. |
| 366 | |
| 367 | * Routing of a filtered request packet to the correct target. Each target runs under the control of a processing thread and |
| 368 | has a dedicated message fifo. The routing wakes up the processing thread of the |
| 369 | corresponding target, that empties the message fifo filled by the temporal filtering. The behavioral function of the target |
| 370 | is executed in the context of the processing thread. |
| 371 | |