Re: disable and the Initiialization Phase

John,

just some quick, final comments below. Basically, I'm fine with any
decision, since there seems to be no "golden" solution.

On 09/09/10 18:04, john.aynsley@doulos.com wrote:
[snip]

> * A process runs to its first wait during initialization even though it
> has been disabled (surprise!)

And what state it's in, after it gets enabled? Does it run its
initialisation immediately? Otherwise, the process needs an additional
(init) cycle, before it enters its regular behaviour (surprise?)

> * dont_initialize modifies the effect of a reset such that the process
> does not get re-executed from the top (surprise!)

Please note, that this was intended to apply to disabled processes only.
 Then its not so surprising, is it? Maybe disabled processes should
never run to their first wait() upon reset, and only do their unwinding
then?

Thanks,
  Philipp

> For me, "initialization" are "reset" are not instances of the same
> category of behavior.
>
> So on balance I agree with Bishupriya and would vote to keep the rules as
> they are.
>
> John A
>
>
>
> From:
> Bishnupriya Bhattacharya <bpriya@cadence.com>
> To:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> Cc:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>,
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date:
> 08/09/2010 13:12
> Subject:
> RE: disable and the Initiialization Phase
>
>
>
> Philip,
>
> If I understand right, you are saying that initialisation should have same
> effect as reset(), and you make the particular case for disable() and
> initialisation. Specifically you are asking "a disabled process can be
> reset, why can't it be initialised"?
>
> What about suspend()? What about the other constructs? I guess you would
> say all process control constructs should not affect initialisation (ar at
> least the ones that are less powerful than reset()), and those constructs
> should take effect after initialisation.
>
> I don't feel convinced enough with this rationale to change the rules.
> Also, I think users will be more suprised with this rule than the existing
> ones.
>
> The way I see it, conceptually initialisation and reset are similar, but
> not exactly equivalent. reset() is a construct that the user explicitly
> issues, whereas initialisation is something that happens implicitly.
> reset() should be more powerful than initialisation. User-issued explicit
> suspend/disable can overrule initialisation, while user-issued reset() has
> higher priority and hence can overrule disable/suspend. That feels right
> to me.
>
> Thanks,
> -Bishnupriya
>
> -----Original Message-----
> From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
> Sent: Friday, September 03, 2010 5:56 PM
> To: Bishnupriya Bhattacharya
> Cc: john.aynsley@doulos.com; systemc-p1666-technical@eda.org
> Subject: 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/
>
>
>
>
>

-- 
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.