John,
I had a look at the additions since the last draft, and came up with the
following comments (in addition to the review comments from Nov 30):
5.3.4.2 Function sc_start
"When function sc_start is called with a zero-valued time argument,
the scheduler shall run for one delta cycle,…"
Should there be a warning, if no activity is due in that delta cycle
(sc_pending_activity_at_current_time() == false)?
Otherwise, one can easily run into an endless loop…
"Applications are recommended to call function sc_stop before
returning control from sc_main to ensure that the end_of_simulation
callbacks are called."
Probably add a forward reference to 5.4.4.
5.4.1 before_end_of_elaboration
"The following constructs shall not be used directly within member
function before_end_of_elaboration,…
a) the macro SC_CTOR"
The previous paragraph has been rephrased to restrict the use of
other functions within before_end_of_elaboration.
SC_CTOR _declares_ a constructor (and adds some impl-defined
definitions), it can't be used within a function anyhow. So maybe we
should drop this entire second paragraph here?
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.
SC_CTOR again feels strange.
5.5.2 sc_pause
"It shall be an error to perform any of the following operations while
the simulation is paused:"
For the callbacks, the LRM states that "the following constructs
shall not be used". While there is not a real difference, the current
wording for sc_pause implies that all cases are required to be
detected as an error by the implementation.
At least for the macros SC_CTOR and SC_HAS_PROCESS (item (d)), this
is not possible. But again, it may be better to just drop these two
macros from the list.
6.6.8 sc_is_unwinding
In the example, 'class wait_on_exit' should probably be a 'struct',
since the destructor is otherwise private. Missed it in my original
example.
6.10.2 sc_event - Class definition
Constructor 'sc_event( const char* )' should be 'explicit'.
6.16 sc_object
Shouldn't there be a get_child_events() in sc_object already,
returning an empty event list by default? Otherwise, traversals
require explicit casts to sc_module and/or the creation of a process
handle to obtain child events.
8.10.12.2/8.10.13.2 sc_fxval(_fast) - Class definition
Sorry, my fault. I should have double-checked the LRM last time.
The constructors of sc_fxval(_fast) for the "other" integral types
are already explicit in the reference simulator but not in the LRM:
int64, uint64, sc_(u)int_base, sc_(un)signed
They need to be explicit as well.
9.3.5 sc_report_handler :: report
"The macros SC_REPORT_INFO, SC_REPORT_WARNING, SC_REPORT_ERROR,
SC_REPORT_FATAL,…"
-> SC_REPORT_INFO_VERB missing
Greetings from Oldenburg,
Philipp
On 14/12/10 10:15, john.aynsley@doulos.com wrote:
> Folks,
>
> I have put two versions of the P1666 draft LRM on the Twiki site for
> review:
>
> http://www.eda.org/twiki/pub/P1666/WebHome/1666-2005_Dec_08_12.pdf
> http://www.eda.org/twiki/pub/P1666/WebHome/1666-2005_Dec_08_12_with_labels.pdf
>
> These include all the proposed changes apart from the ongoing discussion
> around the generic payload. There may be one further version to come after
> we have made those changes.
>
> We have not yet updated the front matter (the pages before the Contents),
> and I suggest that in the final LRM we might replace Annex D with a list
> of changes between 1666-2005 and P1666-2011.
>
-- 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://offis.de/en/ 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 Tue Dec 14 05:08:52 2010
This archive was generated by hypermail 2.1.8 : Tue Dec 14 2010 - 05:09:01 PST