Re: Summary of minor issues

John, All,

We have some comments. I write them in the following citation:

At 31 Mar 2010 12:18:11 +0100 john.aynsley@doulos.com wrote:

[snip]

> * 4.5.2 It is unclear whether or not sc_set_stop_mode() is meant to be
> called during simulation. The LRM says nothing. The OSCI implementation
> reports a warning if it is called during simulation. Should we rule that
> it is an error to call sc_set_stop_mode() during simulation, or should it
> be allowed and supported?
>
> TENTATIVE CONCLUSION: Make it an error to call sc_set_stop_mode() during
> simulation, which presumably means after start_of_simulation() ???

We agree with your tentative conclusion. But we are wondering that the
definition of "during simulation" may be ambiguous. If the LRM includes
it, please let us know where it is. Or if it is ambiguous, the LRM
should include its definition.

For examples:
  After calling sc_start(): during simulation?
  In the start_of_simulation(): during simulation?

>
>
> * 5.2.9 The LRM does not make it clear whether or not a trailing

[snip]

> * 5.5.7 It is not crystal clear whether the following is legal:
>
> sc_process_handle h1, h2;
> SC_FORK
> h1 = sc_spawn(...),
> h2 = sc_spawn(...)
> SC_JOIN
>
> CONCLUSION: Make this legal.

We agree with your conclusion. In addition to it, the order of their
function call need to be described. "Implementation defined" is also
fine.

>
>
> * 6.27 and 6.29 The classes sc_mutex and sc_semaphor are derived from
> sc_prim_channel, implying that they cannot be instantiated during
> simulation. This is an unnecessary restriction which prevents the dynamic
> creation of mutexes and semaphores for use in synchronizing dynamic
> processes.
>
> TENTATIVE CONCLUSION: Change the LRM to make these classes derived from
> sc_object, instead of sc_prim_channel. (This introduces a minor backward
> incompatibility - in the unlikely event of someone having derived from one
> of these classes and used request_update/update.)
>

In our understanding, this change makes modules enable to access
sc_mutex and sc_semaphor without through sc_port. Is it correct?
We are wondering that this change may have negative influence on
interoperability of user models. Any comments?

[snip]

Best regards,
Hiroshi Imai
Chair of SystemC WG, JEITA

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.