RE: P1666 review issues from Bishnupriya

Thanks. Done. Closed.

John A

-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 01/17/2011 05:54PM
Subject: RE: P1666 review issues from Bishnupriya

         
  John,
   
  Comments embedded below on 3 open issues.
   
  Thanks,
  -Bishnupriya
   
  
  From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
 Sent: Thursday, January 13, 2011 9:11 PM
 To: Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
 Subject: P1666 review issues from Bishnupriya
     
  Bishnupriya,
 
 Here is my response to your review issues.
 
 My comments are marked [JA] below
 
 John A
 
 
 1) pg 17:
 "5.2.1.2 Evaluation phase
 CLARIFICATION: From the set of runnable processes, select a process instance, remove it from the set, and only then trigger or resume its execution. Run the process instance immediately and without interruption up to the point where it either returns or calls the function wait ADDITION: or calls the member function suspend of a process handle associated with the process instance itself."
  
 The last addition is not completely true. If a method process suspends itself, it still continues to the end.
 
 [JA] Agreed. Good catch. Fixed.
 
 
 2) pg 73, "If the include_descendants argument has the value false,"...
  
 This should say if include_descendants has the value SC_NO_DESCENDANTS
 
 [JA] Agreed. Fixed.
 
  
 3) more examples are needed for process control; they are rather cryptic otherwise.
 Need to provide intuition behind difference between suspend-resume and disable-enable using clocked threads example
 
 [JA] Agreed. I will work on this, given time.
 
 
 4) pg 75 "By the process instance being resumed while it is in the synchronous reset state"  
  
 Here and elsewhere, is there scope for confusion with process control construct resume()? Can some other word be used?
 
 [JA] The issue is that the terms "resume" and "resumed" are already firmly established in the LRM to describe what happens when a process awakes. I tried to deal with this by editing the glossary entry for "resume". I am not opposed to working on a better solution, but no obvious one springs to mind. I suppose I could try to replace resume by wake up, resumes by awakes, resumed by awoken, and so on.
 
 
 5) pg 77, reset() mentions "sc_unwind_exception may be caught provided it is immediately re-thrown."
  
 This should be moved to kill(), as that is where the concept is first introduced.
 
 [JA] For starters, I will replicate this statement under "kill". But I would like to try to restructure the descriptions of kill, reset, and sc_unwind_exception altogether.
 
 
 6) pg 77, "Calling reset before the process has first executed is permitted, but shall have no effect."
  
 Is this true? Shouldn’t reset() notify the event returned by reset_event()?
 
 [JA] Good question. I wrote this statement before we added reset_event.
 Quote: "The reset event shall be scheduled using an immediate notification in the evaluation phase in which the explicit or implicit call to reset occurs."
 Quote: "it shall be an error to create an immediate notification during elaboration or from one of the callbacks before_end_of_elaboration, end_of_elaboration, or start_of_simulation."
 That seems to infer that if reset() is called prior to the initialization phase, the reset_event() should indeed not be notified. If this is the case, it needs to be noted in the LRM. What about if reset() is called during the initialization phase but before a process has first executed?
 
 
  [bpriya: Clearly, reset_event cannot be immediately notified during elaboration because immediate notification is outlawed at this time as you point out. Once simulation starts, I believe it will be more consistent to allow reset_event notification, including initialization phase before the process is first notified.]
  
 7) pg75, 76, "A process instance can be reset in one of three ways
  
 - By a call to member function reset of a process handle associated with that process instance, which
 shall reset the underlying process instance immediately
 - By the process instance being resumed while it is in the synchronous reset state
 - By a reset signal specified using async_reset_signal_is attaining its reset value, at which time reset
 shall be called (see 6.2.13)"
  
 For the 2nd bullet should mention reset_signal_is also ... "which can happen by a reset signal specified using reset_signal_is attaining its reset value".
 
 [JA] Note that the term "synchronous reset state" is defined 6 lines down. Do you still think it necessary to elaborate point 2?
 
  [bpriya: yes I believe that will benefit the writing by making this 3 bullets complete in itself. Or a reference to the definition of “synchronous reset state” 3 lines down should also do.]
   
 8) pg 79, "If a process throws an exception to itself, then on return from throw_it, control shall pass to a catch block in that function."
  
 The throw_it() call does not really return, within that call the exception is thrown, so maybe it’s better to say "if a process throws an exception to itself, the throw_it() call shall never return, and control shall pass to a catch block in the function".
  
 [JA] Agreed. I will change the wording.
 
 
 9) pg 82, "When called during simulation, sc_get_current_process_handle shall return a handle to the currently executing spawned or unspawned process instance, if any. If there is no such process instance, sc_get_current_process_handle shall return an invalid handle. CLARIFICATION: When called from sc_main, sc_get_current_process_handle shall return an invalid handle."
 �
 The last line intends to say that when called from sc_main *during simulation*, sc_get_current_process_handle shall return an invalid handle. It
,s probably best to spell that out explicitly to eliminate any chance of confusion.
 
 [JA] Okay. That begs the question of what should happen when sc_get_current_process_handle is called from sc_main during elaboration. I guess we want the same rules as for the callbacks above, right?
 
 [bpriya: yes that
,s right.]
 
 10) pg 126, "sc_object& operator= ( const sc_object& );
 The assignment operator shall not modify the hierarchical name or the parent of the destination
 object in the object hierarchy. In other words, the destination object shall retain its current position in the object hierarchy. Attributes and children of the destination object shall not be modified. operator= shall return a reference to *this."
 �
 I
,m sure this has been discussed and I don
,t remember, but what is the rationale for this operator=? If all these properties are not modified, then what is modified? It will benefit the reader I think to include the rationale here.
 
 [JA] See Philipp's explanation
 
 
 11) pg 412, "The enumeration sc_verbosity provides the values of indicitive verbosity levels that may be passed"...
 �
 Typo should be
+indicative
,.
 
 [JA] Fixed.
    

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