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()
  - ev.name() == ev.parent()->name() '.' ev.basename()
  - ev.name() is unique in the object hierarchy
  - ev.basename() can still be implementation-defined

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

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_]

- We add a rule that implementation-defined basenames may include embedded dots

- 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)

Summary:

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

Constructor sc_event()
  Either
    - ev.parent() != 0
    - ev.basename() == implementation-defined
    - ev.name() guarenteed unique in object hierarchy
  or
    - ev.parent() == 0
    - ev.basename() == implementation-defined

Kernel events
  - as per sc_event()

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?

Let's take a look at the current objects types. We have modules and processes,
which are the most important object types when modeling and simulating with
SystemC. Their hierarchical name is just perfect, and also in other regards we
can say that these object types are indeed first class citizens. The other object
types, such as ports, exports, primitive channels, are already in the "poor objects"
(or second class citizens) category.

Enter named events. We already decided not to make them objects, but to
treat them somehow like objects. In which of the two above categories (first
class citizens or second class citizens) do events belong? Bishnupriya is
saying that we should put them with the second class citizens, and do as
poor a job at naming them. But events _are_ first class citizens that belong
with modules and processes. During simulation processes and events are
at center stage.

So my question is: why not treat events as we do modules and processes?

>>> [bpriya: The logic presented above does not make any sense to me. With the SNPS extension proposal, how are events getting treated the same as modules and processes? Today, the only thing that distinguishes modules/processes from other objects is that modules/processes can be parents, owning children. The SNPS extension is *not* proposing that events be able to own children. It is proposing that objects be able to own events, which actually creates inconsistency between events and other objects, including processes - e.g. when an object instantiates an event and a process inside it, the event will get a *nicer* hierarchical name "mymod.myobj.myevent" compared to the process's name "mymod.myproc". How is that treating events like processes? On the contrary, it pegs events at a notch higher than processes (and all other objects for that matter) as "gold class citizens" perhaps.] ÿ

An implementation that has been out there for 2 years, on its own, cannot be
enough reason for unamended standardization.

>>> [bpriya: Cadence has never presented this as the rationale either for standardization of the Cadence proposal, or for vetoing the SNPS extension proposal. The Cadence proposal has been presented early in this round, and it has been scrupulously explained technically and thoroughly debated. The fact that an implementation exists and has been tested by users is always considered a positive for anything but non-trivial proposals, and especially so for unchartered territory.
ÿ
Cadence has pushed back on standardizing the SNPS extension in this round because it creates a clear inconsistency in the hierarchy for events and objects, and at this last minute, there isn't the time for technical discussions in p1666 (and for experimental implementations) in order to explore if this inconsistency can be removed/minimized. Cadence does not support standardizing something half-baked that leaves obvious, unanswered questions in the users' mind. That is not a prudent strategy. Following precedence, this rightfully belongs to the LWG for further exploration, and can be presented in the next round if so deemed.] ÿ

-Martin

On 2010-11-22 11:35, Bishnupriya Bhattacharya wrote:
John, All,
ÿ
Over the past few days, within Cadence, we have carefully reviewed the SNPS extension to the Cadence event naming proposal. Our position is as below. There is strong agreement within Cadence on this position, including from Stuart .
ÿ
First, about allowing objects to parent other objects, there are certainly issues (as several of you have pointed out) if we try for an ambitious scheme to arbitrarily change the object hierarchy at run-time. However, that is not our intent. We're trying to explore if we can carve out a small subset that will be useful. We're not envisaging a dynamic module hierarchy. Any object hierarchy changes will be restricted to elaboration time only. ÿ
ÿ
So, what is the motivation? One thing that comes to mind is a natural grouping of things to better express the intent of a class, and prevent "leakage" of internal implementation objects to the outside of this class.
Consider an aggregate class like the TLM2 simple_target_socket. It has a number of other objects and events inside it - these are all internal implementation artifacts of this socket. Today all of these internal objects/events end up in the parent module's scope. The output of get_child_objects() and get_child_events() on a target module that owns a simple_target_socket is given below.
ÿ
top.target.socket
top.target.socket_port_0
top.target.m_peq_0
top.target.b2nb_thread_0
top.target.peq_with_cb_and_phase_0
top.target.fec_0
top.target.event_0
top.target.event_1
top.target.event_2
top.target.event_3
Everything besides the target socket itself, does not really belong to the parent module's scope; the rest is useless clutter that a user never wants to see. It is safe to say that the simple_target_socket class does not intentionally want to expose these internal implementation artifacts, but today it has no choice but to do so. With the SNPS extension proposal, the events will now go out of this list - the poor objects will be left behind
ÿ
top.target.socket
top.target.socket_port_0
top.target.m_peq_0
top.target.b2nb_thread_0
top.target.peq_with_cb_and_phase_0
top.target.fec_0
ÿ
This is not consistent. It does not feel right that events will end up with the property that they can be grouped more hierarchically, but objects can't. As things stand today (or rather I should say with the Cadence proposal), things are not perfect, but at least an user can expect consistency when constructing an user-defined object wrt scope of internal objects and events. With the SNPS extension, that is no longer true. It is as if events have become more of a first class citizen than objects. ÿ ÿ
ÿ
We all agree that a proper "fix" for this - such that objects can also be children of other objects in some restricted, but useful fashion - is not simple. Many issues need to be considered, especially wrt adjusting existing object's ctor, and other issues that Philip has raised. Realistically speaking there isn't time in this round to consider all the ramifications, and arrive at a solution (or conclude one is not possible).
ÿ
Given that, we feel it will be inappropriate to only standardize the object-owning-events feature, and leave things in a half-baked state. We do not buy the argument that since this feature pertains to event naming it will make it to this round - we DO need to consider the ramifications of proposed solutions to the rest of the ecosystem. We feel it is more appropriate for the LRM to leave kernel event naming as implementation-defined in this round, and include this feature as an addition in the next round if it is so deemed. We're opposed to rushing something into the LRM that leaves things in an inconsistent state without having the time to consider the complete problem.
ÿ
Leaving this aspect implementation-defined in p1666-2010 allows each vendor (including the OSCI ref sim) to experiment with developing a sane object/event naming and parent/child relationship hierarchy while remaining compliant with the 2010 standard. In 1666-2012 (or whenever the next round is) we can then propose standardizing that which we have previously implemented and tested.
ÿ
We would like to hear what others have to say on this topic.
ÿ
Thanks,
-Bishnupriya
ÿ ----------------------------------------------------------------------------------------------------------------------------------------------------
ÿ ÿBishnupriya Bhattacharya ÿ | ÿ Software Architect - Virtual System Platform ÿ | ÿ Cadence
ÿ ÿP: +91.80.4184.1197 ÿ www.cadence.com
----------------------------------------------------------------------------------------------------------------------------------------------------
ÿ

-- 
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. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.