Changes between Version 9 and Version 10 of Writing Rules/Tlmt

Timestamp:

Dec 25, 2007, 4:53:50 PM (16 years ago)

Author:

alain

Comment:

--

Writing Rules/Tlmt

@@ -242 +242 @@
 = E) Interconnection network modeling =
 
-= F) Interruption modeling =
+= F) Interrupt modeling =
 
 Interrupts are asynchronous events that are not transported by the VCI network.
@@ -263 +263 @@
 == F.2) Destination modeling ==
 
-In the Parallel Discrete Event Simulation, the pessimistic approach suppose that any PDES can update his local time only when he knows that all messages received on the input ports have dates larger than his local time.
-Therefore, a SC_THRED modeling a 
+The destination module (named here '''my_processor''') must contain a member variable '''p_irq''' of type
+'''!IrqInPortt''', and a call-back function (named here '''irqReceived()''' that is executed when an interrupt packet is received on the '''p_irq''' port.
+
+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''' :
+{{{
+p_irq(“irq”, this, &my_processor::irqReceived),
+}}}
+
+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.
+
+The recommended policy for handling interrupts is the following:
+ * 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.
+ * The '''execLoop()''' thread must test the '''m_irqpending''' variable at each cycle (i.e. in each iteration of the infinite loop).
+ * 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.
+
+Such violation of the the pessimistic parallel simulation create a loss of accuracy on the interrupt handling date. This inaccuracy in the TLM-T simulation is acceptable, as interrupts are asynchronous events, and the timing error is bounded by the '''m_lookahead''' parameter.
 
 == F.3)  Processor with interrupt example ==