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.