Changes between Version 27 and Version 28 of Writing Rules/Tlmt


Ignore:
Timestamp:
Jan 7, 2008, 2:08:12 PM (16 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Writing Rules/Tlmt

    v27 v28  
    137137    vci_param::data_t m_data[8];        // local buffer
    138138    vci_cmd_t   m_cmd;          // paquet VCI commande
     139    sc_event  m_rsp_received // synchronisation signal
    139140
    140141    //////// thread
    … …  
    145146        m_cmd.cmd = VCI_CMD_READ;
    146147        p_vci.cmdSend(&m_cmd, m_time.getTime());        // lecture bloquante
    147         p_vci.wait();
     148        wait(m_rsp_resceived);
    148149        …
    149150        m_cmd.cmd = VCI_CMD_WRITE;
    … …  
    166167    if(cmd == VCI_CMD_READ) {
    167168        m_time.set_time(rsp_time + length);
    168         p_vci.notify() ;
     169        m_rsp_received.notify(SC_ZERO_TIME) ;
    169170    }
    170171    } // end rspReceived()
    … …  
    284285Interrupts are asynchronous events that are not transported by the VCI network.
    285286
    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.
     287As 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.
    287288
    288289[[Image(tlmt_figure_5.png, nolink)]]
    … …  
    290291== F.1) Source modeling ==
    291292
    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)
     293The 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{{{
     295void  synchroSend( bool  val, uint32_t  time)
    295296}}}
    296297
    … …  
    298299
    299300The 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.
    301302
    302303A 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''' :
    303304{{{
    304 p_irq(“irq”, this, &my_processor::irqReceived)
     305p_irq(“irq”, this, &my_processor::synchroReceived)
    305306}}}
    306307
    307308In 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.
    308309
    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.
     310Therefore, 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.
    310311
    311312The 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.
    313314 * The '''execLoop()''' thread must test the '''m_irqpending''' variable at each cycle (i.e. in each iteration of the infinite loop).
    314315 * 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.
    … …  
    321322class my_processor : tlmt::BaseModule {
    322323public:
    323     IrqInPort           p_irq;
     324    SynchroInPort               p_irq;
    324325               
    325326    // constructor
    326327    my_processor (sc_module_name        name,
    327328                  uint32_t  lookahead) :
    328     p_irq(“irq”, this, &my_initiator::irqReceived),
     329    p_irq(“irq”, this, &my_initiator::synchroReceived),
    329330    m_time(0),
    330331    tlmt::BaseModule(name)
    … …  
    364365
    365366// call-back function
    366      void  irqReceived(bool val, sc_time time)
     367     void  synchroReceived(bool val, sc_time time)
    367368    {
    368369    m_irqpending = val;