John,
this is only a minor inconsistency. I don't feel too strongly about
this change as well. Especially since there's no reason for an
implementation not to support this as an extension, since it would
require an explicit check to prohibit this. ;-)
I think, you can safely close this issue, if no-one else speaks up.
Greetings from Oldenburg,
Philipp
On 15/01/11 19:47, john.aynsley@doulos.com wrote:
>
> [Philipp wrote]
> 5.4.2 end_of_elaboration (2nd enum, (d)) With the unification of
> SC_THREAD and SC_CTHREAD, is there still a reason to explicitly forbid
> SC_CTHREAD during end_of_elaboration? It certainly works with the
> reference simulator.
>
> [bpriya wrote: I won’t term it as unification of SC_THREAD, and
> SC_CTHREAD; the process control constructs make SC_THREADs be a superset
> of SC_CTHREADs, such that SC_CTHREADs could be deprecated. But as long
> as SC_CTHREAD is there, it is distinct from SC_THREAD, and legitimately
> falls under a different category. For this particular case, I don’t feel
> strongly, but am more inclined to retain current behavior, where
> SC_CTHREAD is not allowed in this callback.]
>
>
> I agree with Bishnupriya, including the "I don't feel strongly" bit. Any
> other opinions?
-- Philipp A. Hartmann Hardware/Software Design Methodology Group OFFIS Institute for Information Technology R&D Division Transportation · FuE-Bereich Verkehr Escherweg 2 · 26121 Oldenburg · Germany · http://www.offis.de/ Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Jan 15 12:29:56 2011
This archive was generated by hypermail 2.1.8 : Sat Jan 15 2011 - 12:29:57 PST