Re: disable and the Initiialization Phase

Bishnupriya, John,

sorry for not being clear. I'll try to clarify my point.

If I understand John correctly, he didn't like the fact that disabled
processes may get executed during initialisation. You have proposed to
change this to honour the disabled state, if it is set early enough.

  The re-execution of a disabled thread happens upon reset() as well.
And since resetting a process is related to initialisation, I think the
behaviour should be consistent. I really like to have few rules to
remember... ;-)

The steps that are performed upon reset are:
 1. kill thread, unwind stack
 2. reset dynamic sensitivity
 3. start thread from beginning, run until first wait()

  As defined currently, disabled processes can be (asynchronously) reset
and perform all three steps, even though they are disabled. This is
different from the initialisation phase, if processes are skipped, even
though they would have been initialised otherwise.

  If a disabled process is reset, it should perform steps 1+2
immediately. The question is, should it run until the first wait?
Especially, if this is skipped for disabled processes during the
initialisation?

From the spec:
  "reset() shall nullify any “state” the target process may have built
up during simulation, and restore it to its “state” at time 0."

So what is this state at time 0?

 - dont_initialize is NOT set
   -> the "first wait" boundary inside the process' function
 - dont_initialize IS set
   -> outside of the process' function

  If we define the behaviour of disabled processes under init and reset
according to this original/reset state at time 0, the behaviour could be
the following for disabled processes:

Initialisation:
 - d_i is set -> do not schedule/start process
 - d_i not set -> run to first wait, then stay disabled (step 3)
   (Sorry, John ;-) )

Reset:
 - always unwind immediately, restore sensitivity (steps 1+2)
 - d_i is set -> do not start process function
 - d_i not set -> run to first wait, then stay disabled (step 3)

This way, the interaction of init/reset and disabled processes seems to
be more consistent: A reset restores the process to its state at time 0,
and even disabled processes are initialised properly.

What do you think?

Thanks,
  Philipp

On 03/09/10 12:36, Bishnupriya Bhattacharya wrote:
> Philip,
>
> I'm afraid I lost you here.
>
> What John was pointing out was a valid discrepancy, and I've proposed a fix in the other email thread. Please review the fix and let us know if you find anything not lining up.
>
> Thanks,
> -Bishnupriya
>
> -----Original Message-----
> From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
> Sent: Thursday, September 02, 2010 11:23 PM
> To: john.aynsley@doulos.com
> Cc: Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
> Subject: Re: disable and the Initiialization Phase
>
> Bishnupriya, John,
>
> doesn't this extend to the interaction between disable() and kill/reset()? Don't know, if this has been revised as well (otherwise sorry for the noise), but I've seen the following:
>
> "A suspended or disabled process can be killed or reset and an exception can be also be thrown in it. But these shall not lift the suspension or the disability."
>
> I think, this is fine and very useful.
>
> "For example, if a suspended or disabled thread is reset, it shall restart from the beginning, and after it yields to the kernel via a
> wait() statement, the thread shall go back to its suspended or disabled state."
>
> This is the same as in the initialisation case, isn't it?
>
> I think, we should keep it consistent. Either run disabled processes until the first wait() in both init and reset, or only unwind disabled processes in the reset case and restart them once they get enabled again.
>
> If I understand it correctly, the motivation is to ensure that processes are in a well defined state, e.g. by driving stable output signals. This could be a reasonable rationale.
>
> Thanks,
> Philipp
>
> On 02/09/10 16:54, john.aynsley@doulos.com wrote:
>> Bishnupriya,
>>
>> The revised spec says:
>>
>> "Disabling a process before simulation has started (e.g., from one of
>> the callback phases), or before the process has executed for the first
>> time, shall have the following behavior:
>> ? If the process was declared with dont_initialize(), then the
>> disable shall take effect immediately, and the process shall not be
>> eligible to run again until it is enabled
>> ? If the process was not declared with dont_intialize(), then that
>> implies the process has already been scheduled to run for the first
>> time, and the disable shall take effect only after the first default
>> execution of the process "
>>
>> That I don't like! LRM 4.2.1.1 says that processes are made runnable
>> during the initialization phase, which occurs after elaboration. If a
>> process is disabled during elaboration, I see no reason why it should
>> execute during initialization. That would seem to contradict the rule
>> that a process cannot get added to the set of runnable processes while
>> it is disabled (Scheduling Insights para 3).
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS
R&D Division Transportation | FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.