RE: sc_event naming: Cadence position on proposed extension

Bishnupriya,

In writing this up, I've uncovered a few more issues.

Precisely when does the breakpoint come between static events and dynamic events? I have chosen the start of the initialization phase. In other words, an event created during start_of_simulation would be a static event, but an event created by a process would be a dynamic event.

Does sc_find_event() return events with implementation-defined names, or only hierarchically named events? To me, it should only return hierarchically named events, but I don't have a compelling argument.

Same question for sc_name_exists(). Does it include or exclude implementation-defined names? If its hierarchical-names-only, should we rename it to sc_hierarchical_name_exists()?

What should sc_event::basename() return for an implementation-defined name? The whole name? Part of the name? Something unrelated to name()?

1666-2005 says: "There shall be a single global namespace for hierarchical names. Each sc_object shall have a unique nonempty hierarchical name. An implementation shall not add any names to this namespace other than the hierarchical names of sc_objects explicitly constructed by an application"

I propose to append   " and the hierarchical names of hierarchically named events."

Does this forbid hierarchically-named kernel events? How about the events within predefined channels? Other kernel events? We have agreed that kernel events should not clutter the name hierarchy, but are they forbidden from doing so?

We need to finalize the rules for implementation-defined names. I propose: "... shall be a legal name as described in [...] but shall contain one or more characters that is not in the recommended character set for application-defined hierarchical names, that is, one or more characters that is not an upper or lower case letter, a decimal digit, an underscore, or a period character."

John A

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

    
John,
 
Thinking more about the name "in_hierarchy", I'm now inlcined towards this name compared to "has_hierarchical_name" because I feel the term "hierarchical_name" may not be as clear to a user in conveying what exactly is meant - there is scope of confusing with "has_name". The user may think "has_hierarchical_name" is the same thing as "has_name". in_hierarchy" at least steers clear of the name and allows the user to think in a clearer context.
 
My 2 cents.
 
-Bishnupriya
    
      From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Tuesday, November 30, 2010 1:44 AM
To: Bishnupriya Bhattacharya
Cc: john.aynsley@doulos.com; Martin.Janssen@synopsys.com; P1666 Technical WG
Subject: RE: sc_event naming: Cadence position on proposed extension

   
Bishnupriya,

I fully agree that unlike static user-defined events, static kernel events need not be in the hierarchy - it's implementation-defined.

I fully agree that the spec should be predicated on in_hierarchy(), not has_parent().

Re. the choice of name "in_hierarchy", has_name() would be wrong, has_parent() would be wrong, is_child() would be wrong. Maybe has_hierarchical_name() is quite close? Or name_style() == SC_HIERARCHICAL or SC_IMPLEMENTATION_DEFINED, but I think that's OTT.

John A

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

          
John,
 
I think we are on the same page. Comments below.
            
              From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Monday, November 29, 2010 7:02 PM
To: Bishnupriya Bhattacharya
Cc: Martin.Janssen@synopsys.com; P1666 Technical WG
Subject: RE: sc_event naming: Cadence position on proposed extension

       
       
Bishnupriya,

Re. sc_event() I was assuming as per your spec, i.e. user-defined static events are always hierarchically named. 
 
[ok]

Re. sc_event(const char*)  (non-null name) I think we should put the user in control i.e. the event is always hierarchically named. (An implementation could give a warning if it wanted) 
 
[ok]

Re. hierarchically named events with an implementation-defined basename, I was thinking of kernel events. But we have already ruled out allowing primitive channels to be proper parents, so we would expect implementations to chose the other route (get_parent() == 0) for kernel events. Hence the implementation might as well be required to call sc_gen_unique_name for all hierarchically named events to guarantee uniqueness. 
 
[agreed]

sc_event::get_parent_object() does not exactly determine whether an event is hierarchically named in the sense that it would fail for a top-level event. So I would be in favor of bool sc_event::in_hierarchy().ÿ
ÿ
[agreed.ÿShould we explore a better name?]

ÿÿÿÿÿÿÿ Note ev.get_parent_object() != 0 ÿ=> ev.in_hierarchy()
ÿ ÿ ÿ ÿ but ÿ ÿev.get_parent_object() == 0 && ev.in_hierarchy() could hold for a top-level eventÿ
       
ÿ[indeed]

Re. allowing dots in implementation-defined basenames, I agree this is unnecessary given the above.ÿ
ÿ
[ok good]

Re. kernel events, I still say "as per sc_event()". In other words, whether the event appears in the hierarchy is implementation-defined, but if it does appear in the hierarchy then it shall be a child of its parent module or process instance, so an implementation may wish to take the alternative route. The LRM gives both the user and the implementation an escape hatch to avoid having events with a unique hierarchical name, but the user and implementation still have the choice.ÿ
ÿ
[ok, but just to make explicit oneÿdifferenceÿwith sc_event() - statically created kernel events also areÿsubject to the same implementation-defined rules - in other words statically created kernel events are not forced to be in hierarchy.]

One question: how should we distinguish implementation-defined names? Is "at least one character outside [A-Za-z0-9_.]" okay?ÿ

[well, there is no fulproof way to prevent collision, but I think it is reasonably unlikely to collide if we mandate a special char at beginning and end, like "%mymod.myproc.event_0%"]
ÿÿ
REVISED PARTIAL SPECÿ
ÿ
[agree with your revised spec below, exceptÿto change conditional from testing ev.parent() to testing ev.in_hierarchy(), and mandate what ev.parent() should return based on what ev.in_hierarchy() returns.]
ÿ
-Bishnupriya

ev.name() ÿis always a non-empty string and a well-formed name

If ev.parent() != 0 then
ÿ - ev is a member of ev.parent()->get_child_events()
ÿ - ev.name() == ev.parent()->name() '.' ev.basename()
ÿ - ev.name() is unique in the object hierarchy
ÿ - ev.basename() is seeded with ctor arg or with "event"

If ev.parent() == 0 then
ÿ - ev.name() is well-formed and implementation-defined

- We keep the current recommendation that application-defined string names should use the character set [A-Za-z0-9_]

- We add a recommendation (or a hard rule) that implementation-defined names should include one or more characters outside the set [A-Za-z0-9_], or should start with some specific character we choose (e.g. '%'), or some similar rule (TBD)

Constructor sc_event(const char* arg)
ÿ - ev.parent() != 0
ÿ - ev.basename() seeded from arg
ÿ - ev.name() guaranteed unique in object hierarchy

Constructor sc_event()
ÿ Either (the only choice for user-defined static events)
ÿ ÿ - ev.parent() != 0
ÿ ÿ - ev.basename() seeded with "event"
ÿ ÿ - ev.name() guaranteed unique in object hierarchy
ÿ or (on a case-by-case basis)
ÿ ÿ - ev.parent() == 0
ÿ ÿ - ev.basename() == implementation-defined

Kernel events
ÿ - as per sc_event()

John A

                                     From: Bishnupriya Bhattacharya <bpriya@cadence.com> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com> Cc: "Martin.Janssen@synopsys.com" <Martin.Janssen@synopsys.com>, P1666 Technical WG <systemc-p1666-technical@eda.org> Date: 28/11/2010 18:02 Subject: RE: sc_event naming: Cadence position on proposed extension
              

John,
ÿ
I think we are converging. Hopefully another iteraion and we will be done.
ÿ
I've made specific comments below to your last two mails.

              From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Sunday, November 28, 2010 2:10 PM
To: Bishnupriya Bhattacharya
Cc: john.aynsley@doulos.com; Martin.Janssen@synopsys.com; P1666 Technical WG
Subject: RE: sc_event naming: Cadence position on proposed extension

Bishnupriya,

For sc_event(), Either/or meant that the implementation can chose on a case-by-case basis.
ÿ
[ok. But the LRM needs to specify what the cases are. Is that implied? e.g. for static events, sc_event() will always place it in hierarchy, etc.] ÿ

For sc_event(const char* nm) I propose a non-null string arg implies the event is hierarchically named, even for a dynamic event, but only because that is what you wrote in your original spec. If you want all dynamic events to be implementation-defined in this respect regardless of ctor arg, my proposal could be changed accordingly. But I thought the ideas was that if the user passes a string name as an sc_event ctor arg, they wo uld get what they asked for and accept the performance hit. I am not opposed to the change, but I think the WG should discuss it.

[you are right of course. My original spec had indeed proposed that sc_event ctor called with explicit string arg should always appear in hierarchy even for dynamic events. Now, I'm in two minds on this one - does it make sense to leave this decision for dynamic events to the implementation so that it can balance out any possible performance issues? I will go by what the WG consensus is on this topic.]
ÿ
ÿ[please see more comments below to previous mail.]

John A

[snip]
ÿ
              
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Saturday, November 27, 2010 7:58 PM
To: Bishnupriya Bhattacharya
Cc: john.aynsley@doulos.com; Martin.Janssen@synopsys.com; P1666 Technical WG
Subject: RE: sc_event naming: Cadence position on proposed extension

Bishnupriya,

I am generally aligned with your goals. However, I do have some other concerns. I would like a consistent set of rules that will not surprise casual users and that can be reasoned about.

Hence, I would like the following (pseudocode) to hold:

ev.name() ÿis always a non-empty string and a well-formed name

If ev.parent() != 0 then
ÿ- ev is a member of ev.parent()->get_child_events()
[ok]
ÿ- ev.name() == ev.parent()->name() '.' ev.basename()
[ok]
ÿ- ev.name() is unique in the object hierarchy
[ok]
ÿ- ev.basename() can still be implementation-defined
[why does this need to be implementation-defined? If ev appears in the hierarchy, its basename is either seeded by "event" or by the user provided string arg. Is this implementation defined to accommodate the SNPS extension of naming kernel events as child of owning object? I think that is better accommodated by an implementation allowing an event's parent to be a sc_object other than module/process (need not be in LRM, but implementation can do its own superset), and this maintains a normal, legal basename for the event. Note that for "mymod.mysig.posedge", we do not want that this kernel event is a child of "mymod", and it's basename is "mysig.posedge", if that is what is being implied.] ÿ

If ÿev.parent() == 0 then
ÿ- ev.name() is well-formed and implementation-defined
[ok]
ÿ
[one comment. I'm ok with using sc_event::parent() to determine if an event is in the hierarchy or not, but it might be cleaner if we add an explicit API like "bool sc_event::in_hierarchy()" or something better named.] ÿ

Now for well-formed names. I agree with you that it would be nice for dynamic events and kernel events to have unique names without reference to the regular hierarchical namespace. But the current rules for legal names seem reasonable to me. I don't want to allow pathological names. So I propose:

- We keep the current recommendation that application-defined string names should use the character set [A-Za-z0-9_]
[ok]
- We add a rule that implementation-defined basenames may include embedded dots
[this I'm not sure we need - see my comment above.]
- We add a recommendation (or a hard rule) that implementation-defined names should include one or more characters outside the set [A-Za-z0-9_], or should start with some specific character we choose (e.g. '%'), or some similar rule (TBD)
[ok.]

Summary:

Constructor sc_event(const char* arg)
ÿ- ev.parent() != 0
[ok, except for my dynamic event comment] ÿ
ÿ- ev.basename() seeded from arg
[ok]
ÿ- ev.name() guarenteed unique in object hierarchy
[ok]

Constructor sc_event()
ÿEither
[this choice is mandatory for user-defined static events, and is implementation-defined for dynamic events]
ÿ ÿ- ev.parent() != 0
[ok]
ÿ ÿ- ev.basename() == implementation-defined
[not sure what this means. The basename will be seeded by "event", wouldn't it? just like for sc_signal() etc.]
ÿ ÿ- ev.name() guarenteed unique in object hierarchy
[ok]
ÿor
[this choice is implementation-defined for dynamic events]
ÿ ÿ- ev.parent() == 0
[ok]
ÿ ÿ- ev.basename() == implementation-defined
[ok]

Kernel events
ÿ- as per sc_event()
[I assume you mean how to name kernl event and whteher it appears in hierarchy is implementation defined, like sc_event() ctor. Agreed, except that I think it is important to mention that kernel event should not clutter *current* hierarchy and appear as child of module/process - this is not what SNPS extension proposes either, so that should be ok I think.] ÿ
ÿ
Are we coming close?
ÿ
Thanks,
-Bishnupriya

Does that work?
ÿ
John A

-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 11/25/2010 06:59PM
Cc: Martin Janssen <Martin.Janssen@synopsys.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Subject: RE: sc_event naming: Cadence position on proposed extension

John,
ÿ
First a warning. This is long and complex! I apologise but hopefully I've covered all the scenarios necessary to drive to a conclusion.
ÿ
I think we need to look at dynamic events and kernel events together, and endeavour to come up with a consistent set of rules for both.
ÿ
First note that all events *could* have a parent. But what is important is that it is not a 2-way list, i.e. all events do not appear in child list of it's parent => you won't see all events in the desig hierarchy because top-down hierarchy traversal won't find all events.
ÿ
For dynamic events, the proposal is
ÿ
- an implementation is free to choose whether to place a dynamic event in the hierarchy or not (i.e. make it visible to parent or not)
- if implementation chooses to place in hierarchy
ÿ ÿ=> event automatically gets a hierarchical, legal name
ÿ ÿ=> name can clash with other user-defined event/object name
- What happens if implementation chooses not to place a dynamic event in the hierachy?
ÿ ÿ- does the event have a name()? if so, what is the name()?
ÿ ÿ=> note by not placing in hierarchy it is already guaranteed that ÿname (if any) will not clash with user-defined event/object name in the sense that user will never see a warning from name clash
ÿ ÿ- according to cadence proposal it is upto the implementation again to determine what it returns for name()
ÿ ÿ- you propose we should make the rule, if not in hierarchy then no name, but this is not good because there can be legitimate use cases where dynamic events appear in sensitivity list of processes, just like kernel events and there is a requirement to print some kind of name that identifies the event
ÿ
ÿ ÿ void run() { // SC_THREAD
ÿ ÿ ÿ sc_event e1;
ÿ ÿ ÿ e1.notify(100, SC_NS);
ÿ ÿ ÿ wait(e1);
ÿ ÿ ÿ// this is pathological; in reality it will be something like run() passes e1 to spawned thread which waits on e1
ÿ ÿ ÿ // and run() notifies e1 at some later point based on some condition
ÿ ÿ }
ÿ
ÿ - suppose we do keep the output of name() implementation-defined, then next consideration is does name() have to be legal? I would say "no". From the use model perspctive it is beneficial to provide unique names for everything, including things in design hierarchy and things not in design hierarchy. It becomes difficult/complex for an implementation to generate a legal name but be able to distinguish from other user-defined object/event names, especially for a dynamic event. In this case, there is not the benefit of an object sitting in between (as happens typically for the kernel event case), so obvious legal names chosen by an implementation can easily clash with user-defined names - "clash" not in the sense that it will generate a warning, but in the practical sense that two names can be identical, then how will user know which object/event is being referred to from the name?
ÿ
It will be beneficial from user's perspective if the LRM says "If an implementation chooses not to place a dynamic event in the design hierarchy, then name() returns an implementation-defined string. It is recommended that for unique identification purposes, an implementation guarantees that the name of an event that does not appear in the deisgn hierarchy is not the same as the name of any object/event in the design hierarchy, or any object/event not in the design hierarchy". The easiest way (and maybe only way) to accomplish this is to return an illegal name (perhaps also appending an incremented global counter to every name). I am also ok if the LRM says nothing on this topic but simply lets the implementation choose an implementation defined name, although I would prefer if the LRM mandates/recommends uniqueness as that will be beneficial to user.
ÿ
Why this complexity? Things would have been much simpler if all events were placed in design hierarchy and had legal names, but we cannot do that for dynamic events because of performance reaons. The other option is to let non-hierarchy events have null names, but that does not fulfil use case reqmnt. - e.g. print sensitivity list of process. Hence the necessity to pick up the complexity.
ÿ
Next kernel events.
ÿ
- the proposal is that kernel events (static or dynamic) will not be placed in *current* design hierarchy; rationale is users do not care to see kernel events cluttering up their design hierarchy
- it is desirable for kernel event to have a name for same reason as dynamic event (can appear in process senisitivity list)
- kernel event name is implementation defined, and similar to dynamic events it will be good to have unique name
- as far as legality of name is concerned, if an implementation chooses the SNPS extension proposal, there is a way to provide unique legal names to kernel events owned by an object. But all kernel events are not owned by an object, and an implementation may not choose to adopt the SNPS extension proposal. So, for the most general use case, LRM should not mandate that kernel event names be legal - this also makes the rules be the same between kernel events and dynamic events.
ÿ
Coming from all this, one choice can be that LRM mandates sc_event::name() always returns a non-empty string for all events. This is generally a useful feature. Then there are two cases.
ÿ
1) for events that appear in design hierarchy the name is automatically a legal name
ÿ ÿ - all static events appear in design hierarchy
ÿ ÿ - dynamic events may or may not appear (implementation defined)
ÿ ÿ - kernel events do not appear (in *current* design hierarchy, implementation can have a superset of LRM specified hierarchy, e.g. the SNPS extension proposal) ÿ ÿ ÿ
ÿ
2) for events that do not appear in design hierarchy the name is implementation defined
ÿ ÿ - not obligated to be legal name
ÿ ÿ - ok to obligate that prefix contains hierarchical name of parent
ÿ ÿ - obligated/recommended to be unique (from names in design hierarchy and from names not in design hierarchy) ÿ
ÿ ÿ - perhaps can add if user provides a string basename as ctor argument then name() should use the user-provided string in the final name - e.g.
ÿ
ÿ ÿ void run() { // SC_THREAD
ÿ ÿ ÿ wait(10, SC_NS);
ÿ ÿ ÿ sc_event e1("myevent");
ÿ ÿ ÿ cout << e1.name() << endl; // legal to print something like "mymod.run. myevent_0"
ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ// not legal to print "mymod.run. event_0" as user-provided string is not used
ÿ ÿ }
ÿ
I'm also ok if LRM does not specify what sc_event::name() will return for not-in-hierarchy event, but leaves the whole thing implementation-defined, although I will prefer if LRM lays down the rules in 2) as IMO that will be beneficial to user. ÿ
ÿ
Are we converging?
ÿ
Thanks,
-Bishnupriya
              
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Thursday, November 25, 2010 4:40 PM
To: Bishnupriya Bhattacharya
Cc: Martin Janssen; systemc-p1666-technical@eda.org
Subject: RE: sc_event naming: Cadence position on proposed extension

Bishnupriya,

Yes, what you say all makes sense, but I still have some issues.

I would propose that the implementation-defined name shall be a legal name, which I think means
ÿ ÿ ÿ ÿ- Name non-empty
ÿ ÿ ÿ ÿ- No space characters anywhere in the name
ÿ ÿ ÿ ÿ- Dots allowed, but not at the beginning or the end of the name or next to other dots

My reason for this is to reduce the chances of breaking any existing application code

I am okay with the rule that the implementation-defined name shall not clash with a user-defined name. But I think the only way the implementation can guarantee this is, as you say, to put the name in a part of the namespace that is unreachable to the application. As far as I can see, this implies that the implementation-defined name shall have a prefix that is either the name of ÿthe kernel object being constructed or the name of an sc_object whose construction has already finished. Do you agree? In which case, for clarity, I think we should spell this out in the LRM. (At least, I don't see why we wouldn't.)

John A

                                     From: Bishnupriya Bhattacharya <bpriya@cadence.com> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>, Martin Janssen <Martin.Janssen@synopsys.com> Date: 25/11/2010 10:26 Subject: RE: sc_event naming: Cadence position on proposed extension

John,
ÿ
Comments below.

              From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Wednesday, November 24, 2010 5:46 PM
To: systemc-p1666-technical@eda.org; Martin Janssen; Bishnupriya Bhattacharya
Subject: Re: sc_event naming: Cadence position on proposed extension

All,

Here is an updated summary of the event naming proposal now on the table:

* Events are not sc_objects

* All static events are named (the default constructor generates a name)
* Dynamic events can be named or unnamed
* Kernel events can be named or unnamed, and the names are implementation-defined

* Named events have a parent in the object hierarchy (which can only ÿbe a module or a process)
* Add a method sc_event::get_parent_object() to return this parent (null for unnamed events)
* The prefix to each event's name is the hierarchical name of the event's parent
* An event name shall not clash with an object name (sc_gen_unique_name is called iteratively)

* Add methods get_child_events, get_top_level_events, and sc_find_event that mirror the methods of the object hierarchy

* Add a method sc_name_exists(const char*) that returns true if the name is in either the object or the event namespace

Can everyone now live with that? ÿ
ÿ
Ok with me.
ÿ
One clarification needs to be added for kernel event names. Kernel event names are implementation defined, but they shall not clash with that of user-defined objects and events. This can be ensured in different ways (as you discuss below) - making the kernel event name be illegal, or introducing extra hierarchy with "." for kernel event name. Essentially this is to rule out implementation defined names being something like "mymod.mysig_posedge" which can easily clash with an user-defined object/event in mymod.
ÿ
I have one question regarding the constraints on implementation-defined kernel names. Do they have to be legal names? If so, there might be a risk of a clash with a subsequent user-defined name, which would then get given a suffix from sc_gen_unique_name. If not, the only way to create an illegal name would be to include a space character (the AZaz09_ character set for string names is recommended, but not obligatory).

I would vote for implementation-defined kernel names being legal names. The kernel could always include separators such as -> or / that are unlikely to be used by an application. Moreover, as I read the LRM, I think we could allow implementation-defined hierarchical event names to include extra '.' characters since these would not technically be embedded in string names (arguments passed to ctors) but would be part of the hierarchical name of a new kind of event object.

To clarify, when you construct an sc_object or an sc_event you pass in a string name that must not contain dots. But an implementation-defined kernel event name could include extra dot separators, I think.

yes, I think it is ok for an implementation to compose a name with the "." character, as long as the ctor string argument does not include "." and the name does not clash with user-defined names. e.g. the SNPS extension proposal that uses names like "mymod.mysig.posedge" would be ok since there is no way a user-defined object/event would end up with same name - the namespace "mymod.mysig" is unreachable for user-defined events/objects.
ÿ
However, I do not think that these details should be included in the LRM. This is the part that is implementation-defined. What the LRM should include is that the implementation is obliged to choose a name that does not clash with a user-defined object/event.
ÿ
Does that make sense?
ÿ
-Bishnupriya

Thanks,

John A

                                     From: Martin Janssen <Martin.Janssen@synopsys.com> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com> Cc: "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org> Date: 23/11/2010 17:27 Subject: Re: sc_event naming: Cadence position on proposed extension

Hi John,

To avoid further delays in the process, I'll change my vote to option 2
provided it states that kernel event naming is implementation-defined,
as Bishnupriya proposed in an earlier email.

One more question: How is a vendor supposed to experiment with
developing a sane object/event naming and parent/child relationship
hierarchy while remaining compliant with the 2010 standard if the '.'
character in the name is an error? (not only for kernel event naming)

-Martin

On 2010-11-23 17:35, Bishnupriya Bhattacharya wrote:
John, Martin,

Comments below.

-Bishnupriya

              From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Martin Janssen
Sent: Tuesday, November 23, 2010 7:31 PM
To: john.aynsley@doulos.com
Cc: systemc-p1666-technical@eda.org
Subject: Re: sc_event naming: Cadence position on proposed extension

John,

A lot of nice words from Bishnupriya, but the only objection against our extension
proposal is hierarchical naming of objects, which is not part of our proposal, and
for good reason.

But does this mean that we should do a lousy job on hierarchical event naming?
Or, put differently, should we treat events as first class citizens or not?

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