RE: disable and the Initiialization Phase

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.