RE: sc_event naming: Cadence position on proposed extension

Bishnupriya,

I think I understand your intent. I can't say I entirely agree.

No problem with your option 1) or option 3).

With option 2), I do agree that the SNPS extension proposal does not contradict the LRM wording "An implementation shall not add any names to this namespace other than the hierarchical names of sc_objects explicitly constructed by an application, and hierarchically named events"

But, the SNPS extension proposal specifically contradicts the new LRM rule that the parent of an sc_event can only be a module instance or a process instance. Allowing the parent to be any sc_object is not a superset, it's a contradiction. I am not trying to prevent experimentation. just to be clear what the proposed standard says. If an implementation bends the standard, it might break application code that assumes a parent (of an sc_object or an sc_event) can only be a module or process.

Also, if an implementation chooses to make a kernel event a hierarchically named event, then by doing so it DOES place that kernel event in a user-reachable part of the namespace, such as by creating "mymod.mysig_posedge". That would be a hierarchically named event, its parent would be a module (P1666 would not allow the parent to be a primitive channel), and the name is user-reachable. (The alternative would be that we mandate that all kernel events shall have implementation-defined names, and not be in the hierarchy.)

John A

-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: Bishnupriya Bhattacharya <bpriya@cadence.com>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 12/02/2010 06:13PM
Cc: P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: RE: sc_event naming: Cadence position on proposed extension

    
There could be an option 3) where the name of the kernel event is just like in option 2) but the implementation does not put the kernel event in the hierarchy - instead parent() is null. Then the name becomes implementation-defined, however this option is ruled out if we specify the rule (no pun intended) that implementation-defined names have to include a special char.          
 
-Bishnupriya
    
      From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Bishnupriya Bhattacharya
Sent: Thursday, December 02, 2010 10:51 PM
To: john.aynsley@doulos.com
Cc: P1666 Technical WG
Subject: RE: sc_event naming: Cadence position on proposed extension

   
   
John,
 
This is how I see it.
 
For kernel events, there are 2 choices
 
1) An implementation can choose not to put them in hierarchy, then name is implementation-defined with a special char etc. This clearly does not add anything to global namespace of hierarchically named objects and events.
 
2) An implementation can choose to put them in extended hirearchy according to SNPS extension proposal. Then the parent of a kernel event is an object and its name is a proper hierarhcial name constituted from its parent object's name. This does add names to the global namespace of objects and events, but not to the user-reachable parts of it. Does this violate the LRM wording "An implementation shall not add any names to this namespace other than the hierarchical names of sc_objects explicitly constructed by an application, and hierarchically named events"? I don't think it does. What the implementation is doing here is use an extended definition of hierarchy than what the LRM lays down - but it is a superset not a contradiction. Neither does it affect the user in terms of restricting the set of available hierarchical names for user-defined objects/events.
 
My point is there is no third choice where an implementation can place a kernel event in user-reachable parts of the namespace, which rules out kernel events in top level or under user-defined module or process - e.g. "mymod.mysig_posedge". This should be spelled out in the LRM to ensure that users do not have to worry about lurking kernel events when naming their own events and objects.   
 
Are we on the same page now?
 
-Bishnupriya         
        
          From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Thursday, December 02, 2010 9:14 PM
To: Bishnupriya Bhattacharya
Cc: P1666 Technical WG
Subject: RE: sc_event naming: Cadence position on proposed extension

     
Bishnupriya,

You write: [I think we are ok here. For kernel events, we decided that it is implementation defined whether they are added to hierarchy or not, so the above wording is not violated. In the sc_event section, we do need to add though that even if hierarchically named, kernel events cannot take up user-reachable parts of the namespace => hierarchical naming according to the SNPS extension is ok because that will not clash with any user-defined object or event name, but it is not ok to put a kernel event in top-level or under a user-defined module or under a user-defined process.]

I'm not sure whether we are on the same page here. Since the parent of a hierarchically named event can only be a module instance or a process instance, as things stand a hierarchically-named kernel event is sure to be in a user-reachable part of the namespace! That's one reason an implementation may chose an implementation-defined name instead. Are you talking about a possible future extension where an event may have a parent that is not a module or process instance?

John A

-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
     To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 12/02/2010 09:07AM
Cc: P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: RE: sc_event naming: Cadence position on proposed extension

              
John,
ÿ
Comments below.
                
                  From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Thursday, December 02, 2010 4:00 AM
To: Bishnupriya Bhattacharya
Cc: P1666 Technical WG
Subject: RE: sc_event naming: Cadence position on proposed extension

         
         
                                 
             
               <SNIP>
             
         
     

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