P1666 review issues from JEITA

Hiroshi,

Here is my response to your review issues, excluding those issues for
which I consider further discussion is definitely required. Of course, you
are free to dispute the issues below where I consider no change is
required.

My comments are marked [JA] below

John A

1 5.5.3 p.29 2nd paragraph
"sc_set_stop_mode" .
Also, we'd like to confirm the intent of this change from the current
LRM."

[JA] The intent is that the old LRM did not specify whether
sc_set_stop_mode is allowed to be called during simulation.

2 6.2.13 p.45 5th paragraph
It is difficult to understand the second sentence. Does it means that the
order of reset is implementation defined?

[JA] I think the meaning is fairly clear, but I will try to enhance the
wording. This sentence just spells out the consequences of the async
reset, namely
- async_reset_signal specifies (directly or indirectly) an object of type
sc_signal
- The reset occurs when that signal changes to its active value
- Signals actually change value in the update phase
- The reset is not executed in the update phase, but in the following
evaluation phase
- The actual call to reset() gets scheduled along with anything else due
to run in that same evaluation phase, and thus is run in non-deterministic
order. Asynchronous resets do not take priority over other processes due
to run in the same delta.

3 6.5.2 p.62
"The purpose of the namespace ""sc_unnamed"" should be described.
We imagine that this class can be used to set vendor specific classes, and
so on. If our understanding is correct, the intent of adding vendor
specific classes, etc. in the LRM should be described."

[JA] No, the only purpose of sc_unnamed is to provides the placeholders
_1, _2, ... from Boost, which can be used when calling sc_bind. I will add
a remark which says exactly that.

4 6.5.6 p.61 10th paragraph
We don't understand the content of this paragraph? What is "_1, _2, _3"?

[JA] See 3 above. The details are described in the Boost documentation,
not IEEE 1666.

5 6.6.6.1 p.74
"The following cases of calling ""resume"" do not seem to be descrived
clear.
(1) If ""resume"" are called multi processes at the same simulation time,
what happens?

[JA] If h.resume() is called from multiple processes, the process
associated with h is resumed only once ("resume on a process that is not
suspended shall have no effect"). If multiple processes are resumed, they
all become runnable in the same evaluation phase (in arbitrary order)

(2) If ""suspend"" and ""resume"" are successively called to the process
during wait, when does it become runnable? For example, wait(100) -> calls
""suspend"" after 10 ns -> calls ""resume"" after 50 ns, then does process
become runnable after 40 ns?"

[JA] See the 1st para describing resume. The sensitivity of the process
would NOT have caused it to become runnable while it was suspended, and
hence the process will NOT become runnable when it is resumed.

6 6.6.6.1 p.74 1st paragraph of "resume"
"The explanation of timing of resume seems to be inconsistent with the
explanation in ""suspend"".
In ""resume"", ""the process instance shall be made runnable in the
current evaluation phase"".
In ""suspend"", ""the process instance shall become runnable in the next
evaluation phase in which resume is called""."

[JA] With resume, given the conditions are satisfied ("if and only if
..."), the target process is indeed made runnable in the current
evaluation phase (the evaluation phase in which resume is called) and will
be selected to run in non-deterministic order.

[JA] With suspend, if the process is currently runnable, it will be
removed from the set of runnable processes, and hence will not run in the
evaluation phase in which suspend is called (assuming it has not run
already). The phrase "next evaluation phase" refers to the conditions for
subsequently resuming that same process after it has been suspended.

7 6.6.6.1 p.74 - 75
The difference between suspend/resume and disable/enable is difficult to
understand from the explanation in the LRM. Use cases can be helpful to
understand these functions and purposes.

[JA] I agree the difference between suspend/resume and disable/enable is
difficult to understand, as are the semantics of process control in
general. I could spend some time including further examples in the LRM. I
could also spend some time writing an introduction to the process control
methods and clarifying the rules, since I am not particularly satisfied
with the text as it stands.

8 6.6.6.2 p.78
Use cases of sync_reset_on/sync_reset_off are helpful to understand these
functions and purposes.

[JA] sync_reset_on/off simply give a procedural interface to switch sync
reset on or off, as opposed to specifying a reset signal.

9 6.6.6.4 p.81 Table 2
The "enable" row of Table 2 shows "The current evaluation phase". Is this
correct? Should it be "The next evaluation pahse"?

[JA] It is correct, but it has to be read in the right context. The
earliest time at which a call to enable() can affect the target process is
indeed in the current evaluation phase. For example, a subsequent
immediate notification within the current evaluation phase could make the
target process runnable in the current evaluation phase. On the other
hand, the earliest time at which a call to disable() can affect the target
process is the next evaluation phase (the phase following the current
evaluation phase).

10 6.6.6.4 p.81 4th paragraph
The reason of the priorities among kill, reset, and so on, should be
described.

[JA] I am not sure there is a compelling rationale. We just needed to make
a choice. Bishnupriya?

11 6.6.7 p.82 1st paragraph
In the CLARIFICATION sentences, LRM says, "if the most recently created
process instance was not within the current module, ..., an implementation
may return either a handle to the most recently created process instance
or an invalid handle". In this case, returning only "an invalid handle"
seems to be sufficient. If not, the reason or explanation should be
described.

[JA] This is a corner case that we missed from IEEE 1666-2005. It is
unimportant to the user (because we are talking about calling
sc_get_current_process_handle() from a context where there is no process,
i.e. a callback), but we thought it important not to overconstrain the
implementation by being too specific. All this says is that the user can
rely on sc_get_current_process_handle() not to crash.

12 6.10.4 p.95 5th paragraph
LRM says, "when a hierarchically named event is constructed, if a empty
string is passed as a constructor argument, the string name shall be set
to "event"". It seems to be inconsistent with that event should have
hierarchical name, or we may misread.

[JA] See the 2nd para. When constructed during elaboration, every event
shall be hierarchically named, even if constructed using sc_event() or
sc_event("").

13 9.5 p.424 - 433
More examples of sc_vector can be helpful to understand its convenience
instead of using vector of stl. Also, examples of sc_assemble_vector are
helpful.

[JA] There are examples showing
* Vector-of-ports
* Vector-of-exports
* Vector-of-signals
* Vector-of-modules, including custom constructor arguments
* Binding vector-of-ports to vector-of-signals, with and without iterators
* sc_assemble_vector as the port in a bind operation
* sc_assemble_vector as the export in a bind operation
What else would you like?

14 10.1 p.438 1st paragraph
Since three compliances belong to different category; a) is about
simulator implementation, b) and c) are about models, a) and b)/c) are
explained in the different paragraph.

[JA] You are correct, and that is one of the objectives in making the
distinction between these terms. I will add a remark to the introductory
paragraph.

15
To enable dynamic process, we must define the macro
"SC_INCLUDE_DYNAMIC_PROCESSES". But the definition and the explanation are
not given in the LRM. They should be in the LRM.

[JA] The following are definitely features of the OSCI PoC simulator, not
the IEEE standard
* SC_INCLUDE_DYNAMIC_PROCESSES
* SC_INCLUDE_FX
* SC_FX_EXCLUDE_OTHER
* SC_DEPRECATION_WARNINGS
* sc_report_handler::set_actions("/IEEE_Std_1666/deprecated", ...)
* DEBUG_SYSTEMC
* SC_SIGNAL_WRITE_CHECK DISABLE

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