Changes between Version 27 and Version 28 of Writing Rules/Tlmt
- Timestamp:
- Jan 7, 2008, 2:08:12 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Writing Rules/Tlmt
v27 v28 137 137 vci_param::data_t m_data[8]; // local buffer 138 138 vci_cmd_t m_cmd; // paquet VCI commande 139 sc_event m_rsp_received // synchronisation signal 139 140 140 141 //////// thread … … 145 146 m_cmd.cmd = VCI_CMD_READ; 146 147 p_vci.cmdSend(&m_cmd, m_time.getTime()); // lecture bloquante 147 p_vci.wait();148 wait(m_rsp_resceived); 148 149 … 149 150 m_cmd.cmd = VCI_CMD_WRITE; … … 166 167 if(cmd == VCI_CMD_READ) { 167 168 m_time.set_time(rsp_time + length); 168 p_vci.notify() ;169 m_rsp_received.notify(SC_ZERO_TIME) ; 169 170 } 170 171 } // end rspReceived() … … 284 285 Interrupts are asynchronous events that are not transported by the VCI network. 285 286 286 As illustrated in Figure 5, each interrupt line is modeled by a specific point to point, uni-directional channel. It use two ports of type '''! IrqOutPort''' and '''!IrqinPort''' that must be declared as member variables of the source and destination modules respectively.287 As illustrated in Figure 5, each interrupt line is modeled by a specific point to point, uni-directional channel. It use two ports of type '''!SynchroOutPort''' and '''!SynchroInPort''' that must be declared as member variables of the source and destination modules respectively. 287 288 288 289 [[Image(tlmt_figure_5.png, nolink)]] … … 290 291 == F.1) Source modeling == 291 292 292 The source module (named '''my_source''' in this example) must contain a member variable '''p_irq''' of type '''! IrqOutPort'''. To activate, or desactivate an interruption, the source module must use the '''irqSend()''' method, that is a member function of the '''!IrqOutPort''' class. Those interrupt packets transport both a Boolean, and a date. The '''irqSend()''' prototype is defined as follows :293 {{{ 294 void irqSend( bool val, uint32_t time)293 The source module (named '''my_source''' in this example) must contain a member variable '''p_irq''' of type '''!SynchroOutPort'''. To activate, or desactivate an interruption, the source module must use the '''synchroSend()''' method, that is a member function of the '''!SynchroOutPort''' class. Those interrupt packets transport both a Boolean, and a date. The '''synchroSend()''' prototype is defined as follows : 294 {{{ 295 void synchroSend( bool val, uint32_t time) 295 296 }}} 296 297 … … 298 299 299 300 The destination module (named here '''my_processor''') must contain a member variable '''p_irq''' of type 300 '''! IrqInPortt''', and a call-back function (named here '''irqReceived()''' that is executed when an interrupt packet is received on the '''p_irq''' port.301 '''!SynchroInPortt''', and a call-back function (named here '''synchroReceived()''' that is executed when an interrupt packet is received on the '''p_irq''' port. 301 302 302 303 A link between the '''p_irq''' port and the call-back function mus be established by the port constructor in the constructor of the class '''my_processor''' : 303 304 {{{ 304 p_irq(“irq”, this, &my_processor:: irqReceived)305 p_irq(“irq”, this, &my_processor::synchroReceived) 305 306 }}} 306 307 307 308 In the Parallel Discrete Event Simulation, the pessimistic approach suppose that any PDES process is not allowed to update his local time until he has received messages on all input ports with dates larger than his local time. 308 309 309 Therefore, a SC_THREAD modeling the behavior of a processor containing an '''! IrqInPort''' should in principle wait a dated packet on this interrupt port before executing instructions. Such behavior would be very inefficient, and could create dead-lock situations.310 Therefore, a SC_THREAD modeling the behavior of a processor containing an '''!SynchroInPort''' should in principle wait a dated packet on this interrupt port before executing instructions. Such behavior would be very inefficient, and could create dead-lock situations. 310 311 311 312 The recommended policy for handling interrupts is the following: 312 * The call-back function ''' irqReceived()''' sets the member variables '''m_irqpending''' and '''m_irqtime''', when a interrupt packet is received on the '''p_irq''' port.313 * The call-back function '''synchroReceived()''' sets the member variables '''m_irqpending''' and '''m_irqtime''', when a interrupt packet is received on the '''p_irq''' port. 313 314 * The '''execLoop()''' thread must test the '''m_irqpending''' variable at each cycle (i.e. in each iteration of the infinite loop). 314 315 * If there is no interrupt pending, the thread continues execution. If an interrupt is pending, and the interrupt date is larger than the local time, the thread continues execution. If the interrupt date is equal or smaller than the local time, the interrupt is handled. … … 321 322 class my_processor : tlmt::BaseModule { 322 323 public: 323 IrqInPort p_irq;324 SynchroInPort p_irq; 324 325 325 326 // constructor 326 327 my_processor (sc_module_name name, 327 328 uint32_t lookahead) : 328 p_irq(“irq”, this, &my_initiator:: irqReceived),329 p_irq(“irq”, this, &my_initiator::synchroReceived), 329 330 m_time(0), 330 331 tlmt::BaseModule(name) … … 364 365 365 366 // call-back function 366 void irqReceived(bool val, sc_time time)367 void synchroReceived(bool val, sc_time time) 367 368 { 368 369 m_irqpending = val;