313 | | As described above, there is one arbitration thread associated to each VCI target. This thread |
314 | | == E.3) General Initiators and Targets synchronization == |
315 | | |
316 | | As described in sections B & C, each VCI initiator TLM-T module contains a thread and a local clock. But, in order to increase the TLM-T simulation |
317 | | speed, the VCI targets are generally described as reactive call-back functions. Therefore, there is no thread, and no local clock in the TLM-T |
318 | | module describing a VCI target. For a VCI target, the local clock is actually the clock associated to the corresponding arbitration |
319 | | thread contained in the '''!VciVgmn''' module. |
| 313 | 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 |
| 314 | 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. |
| 315 | 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 |
| 316 | 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, |
| 317 | defining if it should participate to the arbitration. This '''active''' flag is always set to true for general purpose processors. |
| 318 | 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. |
| 319 | To do that, the LocalTime and ActivityStatus of all VCI initiators are considered as global variables, that can be accessed (for read only) by all arbitration threads. |
| 320 | The arbitration policy is the following : The arbitration thread scans all its input channels, and selects the smallest time between the active initiators. |
| 321 | If there is a request, this request is forwarded to the target, and the arbitration thread local time is updated. |
| 322 | If not, the thread is descheduled and will be resumed when it receives a new request. |
| 323 | |
| 324 | For efficiency reasons, in this implementation, each arbitration thread constructs - during elaboration of the simulation - two local array of pointers (indexed |
| 325 | by the input channel index) to access the LocalTime and ActivityStatus variables of the corresponding VCI initiators. To get this information, each arbitration thread |
| 326 | uses the ''nb_transport_bw()''' function on all its VCI target ports, with a a dedicated phase called '''soclib::tlmt::TLMT_INFO'''. The payload argument refers to the same |
| 327 | '''tlmt_vci_transaction''' object as the two other phases (TLMT_CMD and TLMT_RSP). |
| 328 | |
| 329 | {{{ |
| 330 | for (size_t i=0;i<m_nbinit;i++) { |
| 331 | phase = soclib::tlmt::TLMT_INFO; |
| 332 | m_RspArbCmdRout[i]->p_vci->nb_transport_bw(payload, phase, rspTime); |
| 333 | m_array[i].activity = payload.get_activity_ptr(); |
| 334 | m_array[i].time = payload.get_local_time_ptr(); |
| 335 | } |
| 336 | }}} |
| 337 | |
| 338 | As the net-list of the simulated pltform mus be explicitely defined before constructing those LocalTime and ActivityStatus arrays, the vgmn hardware component |
| 339 | provides an utility function '''fill_time_activity_arrays()''' that must be called in the SystemC top-cell, before starting the simulation. |
| 340 | |