Changes between Version 23 and Version 24 of Writing Rules/Tlmt

Timestamp:

Dec 27, 2007, 11:22:57 AM (16 years ago)

Author:

alain

Comment:

--

Writing Rules/Tlmt

@@ -267 +267 @@
 
 As described in Figure 4, when a VCI command packet - sent by the corresponding arbitration thread - is received by a VCI target, two synchronization mechanisms are activated :
- * A VCI response packet with a date is sent to the source initiator, through the '''VciVgmn''' response network. The corresponding date can be used to update the initiator local clock.
- * The '''cmdReceived()''' call-back function returns a date to the arbitration thread. This date is used to update the arbitration thread local time.  
+ * The '''cmdReceived()''' function sends a VCI response packet with a date to the source initiator, through the '''!VciVgmn''' response network. The corresponding date can be used to update the initiator local clock.
+ * The '''cmdReceived()''' function returns a date to the arbitration thread. This date is used to update the arbitration thread local time.  
 
 [[Image(tlmt_figure_4.png, nolink)]]
@@ -297 +297 @@
 }}}
 
-In the Parallel Discrete Event Simulation, the pessimistic approach suppose that any PDES process can update his local time only when he has received messages  on all input ports with dates larger than his local time.
-Therefore, a SC_THREAD modeling the behavior of a module containing an '''!IrqInPort''' should in principle wait a dated packet on this port before executing instruction and updating the local time. Such behavior would be very inefficient, and could create dead-lock situations.
+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.
+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.
 
 The recommended policy for handling interrupts is the following:
@@ -329 +329 @@
 private:
     tlmt_Time  m_time;  // local clock 
-    bool  m_irqset;  // pending interrupt request
+    bool  m_irqpendig;  // pending interrupt request
     sc_time  m_irqtime;  // irq date
     uint32_t  m_counter;  // iteration counter
@@ -340 +340 @@
         ...
         // test interrupts
-        if (m_irqset && (m_irqtime <= m_time.getTime())) {
+        if (m_irqpending && (m_irqtime <= m_time.getTime())) {
                                         // traitement interrupt 
                                         }
@@ -357 +357 @@
      void  irqReceived(bool val, sc_time time) 
     {
-    m_irqset = val;
+    m_irqpending = val;
     m_irqtime = time;
     } // end irqReceived()