LRM draft review (excluding TLM2)

Some proofreading of the latest SystemC standard,

regards
Alan

page 5
For consistency, should there be a definition of the event hierarchy?

Section 4.1 says
"The term during elaboration or simulation includes every phase from the
construction of the module
hierarchy up to and including the final delta cycle."

However Section 5 point h) says simulation includes destruction of the
module hierarchy,
i.e. after the final delta cycle.

In section 5.2, does the paragraph starting "The scheduler can execute a
spawned or unspawned
process..." need updating due to the introduction of the new process
control functions?

Section 5.4.4 item d) notify should be notify() for consistency with
section 5.4.3 item g)
See also section 5.5.2 item d)

Section 5.5.3. I don't understand the sentences
"Function sc_set_stop_mode may be called during elaboration or from one
of the callbacks before_end_of_elaboration, end_of_elaboration, or
start_of_simulation. It shall be an error to call function
sc_set_stop_mode from the scheduler other than from one of these three
callbacks."

Why say "Function sc_set_stop_mode may be called during elaboration *or*
..." then say it is an error to call the function outside the three
named callbacks? Isn't the clause before the *or* redundant?

p56 table 1
"start_of_simuluation" should be
"start_of_simulation"
"end_of_simuluation" should be
"end_of_simulation"

p56
This sentence
"When called from before_end_of_elaboration, sc_get_status shall return
SC_BEFORE_END_OF_ELABORATION even when called from the constructor of a
module (or other object) called directly or indirectly
frombefore_end_of_elaboration."

didn't read properly to me? Should there be an "or" in front of "called
directly"?

section 6.1.1
Does header file systemc now add sc_unnamed as well?
Similarly 6.1.2

p60
There are a whole lot of functions declared in a different style e.g.

   void next_trigger(const sc_time&, sc_event_or_list const &);

I think this is inconsistent. Either the whole standard should be
changed to that style e.g.

   void next_trigger(sc_time const &, sc_event_or_list const &);

or (easier!)

these functions should be written in the old-fashioned
   void next_trigger(const sc_time&, const sc_event_or_list &);

Otherwise it will just confuse people.
Same on p72ff section 6.2.17
Same in section 6.2.18
Same in section 6.9.2, 6.9.4
Same in section 6.15.2

Section 6.2.21
Would it be worth adding a note describing why get_child_events exists?
I.e. why it was decided that sc_events are not derived from sc_object?
Also perhaps a note needs adding to 6.3.4 - in Note 1 it talks about the
"object hierarchy" - but I think this excludes sc_event i.e. "object
hierarchy" is only referring to classes derived from
sc_object

6.6.6
I'd like to have a simple summary of the process control functions in
the introduction, e.g. what they are (each pair) and the intent behind
the use of each pair. Perhaps just Table 2 in section 6.6.6.4 would be ok?

6.8.2
The "=" signs in the member function declarations don't look bold.

6.12.2
The indentation of
   virtual void bind(IF&);
is broken.

7.4.2
There isn't a description of the function
virtual sc_writer_policy get_writer_policy() const;
Though I've realised there is in section 7.3.3, but 7.3.3 doesn't
actually say what get_writer_policy() should do in a derived class
(though it's obvious it should return the value of the template argument).

7.5.3
refers back to the member function definitions in 7.4, but there isn't
one for get_writer_policy()
But see 7.3.3.

9.2.4
"indicitive" should be
"indicative"

9.5.9
"refered" should be
"referred"

-- 
Alan Fitch
Senior Consultant
Doulos – Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services
Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 
1AW, UK
Tel:  + 44 (0)1425 471223		Email: alan.fitch@doulos.com	
Fax:  +44 (0)1425 471573		http://www.doulos.com
------------------------------------------------------------------------
This message may contain personal views which are not the views of 
Doulos, unless specifically stated.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.