RE: sc_event naming: Cadence position on proposed extension

John,

I'm fine with kernel events being entirely implementation-defined, and no provision of being in hierarchy. Option 1) or 3) suffices for that with the caveat that for 3) to be valid, LRM cannot mandate the rule that implementation-defined names always have a special char.

I also feel strongly that kernel events should not be a part of existing hierarchy

  - this is absolutely necessary from use model perspective so as the user does not get restricted by kernel event names when naming their own events/objects
  - no one has asked for this feature; the SNPS extension proposal specifically does NOT ask for this feature

So I do not see any rationale for keeping kernel events in *current* hierarchy. If this is what you had in mind when keeping the provision for kernel events to be in hierarchy, then I did not understand your proposal, and do not agree on this provision.

What I was thinking as the rationale for letting kernel events be in hierarchy was from the viewpoint of an implementation adopting the SNPS extension proposal.

In light of the above discussion, I propose that kernel events be mandated not to be in current hierarchy, and their names be left implementation-defined. Further the LRM does NOT mandate that implementation-defined names have a special char outside the recommended character set - it only says that implementation-defined names *may* have a special char outside the recommended character set. This allows implementation-defined names like

  - "mymod.mysig->posedge"
     and
  - "mymod.mysig.posedge" as per the SNPS extension proposal

-Bishnupriya

________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, December 03, 2010 10:12 AM
To: Bishnupriya Bhattacharya
Cc: P1666 Technical WG
Subject: 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<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.