RE: Named events

Martin,

You put it well, but the fact remains that it feels odd an object is allowed to parent events but not parent objects. I don't say that as a negative. It has been a common theme for event naming - as I have said before and John too, we are running into these oddities because an elegant/ideal solution is not possible when we are retrofitting.

-Bishnupriya

________________________________
From: Martin Janssen [mailto:Martin.Janssen@synopsys.com]
Sent: Thursday, November 18, 2010 7:15 PM
To: Bishnupriya Bhattacharya
Cc: john.aynsley@doulos.com; Martin Janssen; Philipp A. Hartmann; P1666 Technical WG
Subject: Re: Named events

Hi Bishnupriya,

It's not really that we're changing parenting rules, we're extending them
for something new, namely "visible" (named) events. In that respect, the
issue of event parents (new) and object parents (existing) can be treated
separately.

For getting to a closure on event naming, I wouldn't include object parenting
rules changes. But we can make it a separate topic if you want.

-Martin

On 2010-11-18 14:20, Bishnupriya Bhattacharya wrote:
Martin, John,

Ok, so it seems we are proposing to change parenting rules in SystemC. In that case, I would like to explore if we can remove the limitations of the proposal.

Why are we restricting objects to only parent events? Why are we not allowing objects to own any other objects?

Note, I'm not necessarily proposing that we should - I'm just trying to explore possibilities. Certainly, one can think of use cases - user defined objects may own other objects like signals, and it will be nice if they had a intuitive hierarchical name, just like channel events.

Well, the difficulty of course is in generally identifying the parent object. For sc_event, it seems the parent object will be identified by means of the new ctor

  sc_event(const char* name, sc_object* parent);

What if we add a similar ctor to sc_object also?

  sc_object(const char* name, sc_object* parent);

At least new (to be defined in the future) or user-defined sc_objects could benefit and have nice hierarchical names.

I suppose to really complete the task and extend to existing sc_objects, we would need to add a similar ctor to all existing sc_objects like sc_signal, sc_fifo etc. Maybe add "sc_object* parent" as an optional last argument to all ctors?

We could possibly say only elaboration time sc_objects go thru this naming - dynamic objects stay nameless?

Just thinking aloud here...........

Again, I'm not necessarily proposing we go this route, but since it seems we are going some ways, I think it makes sense to explore if we can go a little more and make it more usable and generally applicable.

I'm probably asking for it, but I do think we should have this discussion and close one way or another.

Thanks,
-Bishnupriya

________________________________
From: john.aynsley@doulos.com<mailto:john.aynsley@doulos.com> [mailto:john.aynsley@doulos.com]
Sent: Thursday, November 18, 2010 5:50 PM
To: Martin Janssen
Cc: Bishnupriya Bhattacharya; Martin Janssen; Philipp A. Hartmann; P1666 Technical WG
Subject: Re: Named events

My take is that the Cadence proposal of leaving the naming of kernel events implementation-defined is less than ideal. I agree that events within primitive channels should be named using some standardized mechanism in order for the event-naming proposal to be complete. Allowing sc_events (and only sc_events) to have arbitrary sc_objects as parents seems like a reasonable solution (in a situation where we have agreed there are no ideal solutions).

Given that an sc_event is not an sc_object, it is not inconsistent that only sc_events can have arbitrary sc_objects as parents.

John A

From: Martin Janssen <Martin.Janssen@synopsys.com><mailto:Martin.Janssen@synopsys.com>
To: Bishnupriya Bhattacharya <bpriya@cadence.com><mailto:bpriya@cadence.com>
Cc: Martin Janssen <Martin.Janssen@synopsys.COM><mailto:Martin.Janssen@synopsys.COM>, "john.aynsley@doulos.com"<mailto:john.aynsley@doulos.com> <john.aynsley@doulos.com><mailto:john.aynsley@doulos.com>, "Philipp A. Hartmann" <philipp.hartmann@offis.de><mailto:philipp.hartmann@offis.de>, P1666 Technical WG <systemc-p1666-technical@eda.org><mailto:systemc-p1666-technical@eda.org>
Date: 18/11/2010 10:46
Subject: Re: Named events

________________________________

Hi Bishnupriya, John,

I have to disagree with Bishnupriya's view. The naming scheme we propose does not
lead to any clashes with user event/objects names. For example, "top.sig.event"
(instead of "top.event" or "top.sig->event") cannot be a legal name right now for any object,
given that top is a module and sig a primitive channel. So we're basically extending the
namespace in areas that weren't reachable before.

Wrt to polluting the "global" namespace, I don't see why events in the predefined SystemC
primitive channels have to be treated differently from events in user defined primitive
channels. Treating (naming) them as we propose doesn't impose any constraints
on the user. And we certainly don't have to go out of our way to explain unnatural special
cases in the naming scheme. Things like "explicit kernel events" are artificial distinctions
that shouldn't go into the LRM.

So instead of creating more special cases, let's go for the natural extension to the current
hierarchy naming scheme as proposed by us. As we have already started in the direction
of adding a new type of children to objects, why not go all the way _and_ give them the
appropriate names?

To summarize the implications of our proposal on design hierarchy (and therefore
hierarchical naming):
- any sc_object can have sc_event children
- sc_events are proper leaf nodes in the design hierarchy, that is, they cannot
 have any sc_object or sc_event children themselves. (this may be stating the obvious)
- the events in the predefined SystemC primitive channels are treated no different
 than other statically or dynamically created events.
- an sc_event child is named the same as an sc_object child, that is, use '.' as
 separator between it's own basename and the prefix (parent) name.

-Martin

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

Martin makes a valid point about the usefulness of naming kernel events like signal's posedge_event, for debugging purposes.

At the same time, there is the difficulty that the "owner" of these events (the channel) is not considered the parent by SystemC rules whereby only modules and processes can be parents. Also, ideally, the user wouldn't want to be constrained by these kernel events polluting the global namespace, and possibly clashing with his own event/object names.

The Cadence proposal explores a different solution to this issue, rather than trying to drastically change things in the SystemC language by allowing objects to be parents, etc. The Cadence proposal does actually provide leeway to an implementation to usefully name these events, at least for identification purposes, if an implementation so desires. The proposal states that these kernel events should not appear in the global namespace and compete with user-defined object and event names, which is a good thing. However, sc_event::name() when invoked on these kernel events is at liberty to return something "useful" that uniquely identifies such an event.

What name exactly is returned by an implementation is left undefined. One possibility is to prefix the owner's basename to the name of the event to form the event's basename e.g. "mysig_posedge". Since the full hierarchical name cannot pollute the global namespace, name() cannot return something like "top.mysig_posedge"; instead, the implementation can specialise the kernel event's name by introducing a special character that is illegal in a sc_object name, e.g. "top.mysig->posedge". Note that this fulfils the objective of tagging these kernel events with an identifiable name, e.g. to appear in the sensitivity list of a process (as in Martin's use case), but at the same time stays within existing SystemC semantics, and leaves the global namespace unpolluted, and does not affect performance.
I would vote not to attempt any fundamental semantic change like allowing objects to own children in order to accommodate naming kernel events - instead leave it upto the implementation to accomplish that within the bounds of the Cadence proposal. If will likely be useful if the LRM provides a recommendation or merely a discussion as above on how to assign an "useful" name to kernel events.
Thoughts?

Thanks,
-Bishnupriya
________________________________
From: Martin Janssen [mailto:Martin.Janssen@synopsys.com]
Sent: Wednesday, November 17, 2010 7:43 PM
To: john.aynsley@doulos.com<mailto:john.aynsley@doulos.com>
Cc: Martin Janssen; Bishnupriya Bhattacharya; Philipp A. Hartmann; P1666 Technical WG
Subject: Re: Named events

Hi John,

[JA] Right now, only modules and processes can have children. As you rightly say, primitive channels are neither. If we go down the line you propose, I guess we should think about sc_objects having children in general.
So far in this discussion we have come to two types of children, sc_objects and sc_events.
For sc_objects as parents I would indeed allow sc_events as children, but not sc_objects.
Or do you see a compelling reason to allow the latter as well?

-Martin

On 2010-11-17 15:01, john.aynsley@doulos.com<mailto:john.aynsley@doulos.com> wrote:
Martin,

Comments below.

John A

From: Martin Janssen <Martin.Janssen@synopsys.com><mailto:Martin.Janssen@synopsys.com>
To: "Philipp A. Hartmann" <philipp.hartmann@offis.de><mailto:philipp.hartmann@offis.de>
Cc: Bishnupriya Bhattacharya <bpriya@cadence.com><mailto:bpriya@cadence.com>, "john.aynsley@doulos.com"<mailto:john.aynsley@doulos.com> <john.aynsley@doulos.com><mailto:john.aynsley@doulos.com>, P1666 Technical WG <systemc-p1666-technical@eda.org><mailto:systemc-p1666-technical@eda.org>
Date: 17/11/2010 13:18
Subject: Re: Named events

________________________________

All,

I think Bishnupriya's proposal is the cleanest. I do have a few
remarks/questions on that and one extension proposal.

First the remarks/questions:

1) Maybe I misunderstood, but why would sc_core::sc_gen_unique_name()
   have to be called more than once on an sc_object or sc_event?
   The whole purpose of sc_core::sc_gen_unique_name() is to generate
   a unique name in one shot.

   I think it would be sufficient to say that an sc_event's basename is
   generated from calling sc_core::sc_gen_unique_name(seed, true).

[JA] This comes straight out of the LRM. sc_gen_unique_name is blind to the space of user-defined names, so may need to be called iteratively in case of name clashes with names it did not generate itself.

2) Why do we need special rules on which characters are/aren't allowed
   in sc_event names? Can't we simply refer to the naming rules for
   sc_objects (given that they share the same namespace)?

[JA] I agree we do not need a new set of rules

3) sc_core::get_top_level_events() and sc_core::sc_find_event() are
   named inconsistently. I think that get_top_level_events() should
   have an sc_ prefix, that is, sc_core::sc_get_top_level_events().

[JA] Agreed.

Now the extension proposal:

A) I would like to name explicit kernel events such as
   "const sc_event& sc_signal<bool>::posedge_event()", because of
   user processes that can be sensitive to these events. If we don't
   name these events it becomes very difficult to refer to them e.g.
   when debugging.

B) As far as I can tell, all explicit kernel events are located inside
   primitive channels. In order to be able to distinguish sc_events
   belonging to different primitive channels inside the same module,
   I would like to use the primitive channel's name for the
   hierarchical name (prefix) of an sc_event.

   And maybe we shouldn't stop at primitive channels but allow any
   sc_object (other than module and process) as parent of an sc_event
   to use that sc_object's name to construct the hierarchical name of
   the sc_event.

   This would require something like an additional sc_event c'tor:

       sc_event(const char* name, sc_object* parent);

   This is a simple but less elegant approach. A more elaborate
   solution would keep track of something like the "current sc_object"
   (as we do with module during elaboration and process during
   simulation). I would be happy with the simple approach.

[JA] Right now, only modules and processes can have children. As you rightly say, primitive channels are neither. If we go down the line you propose, I guess we should think about sc_objects having children in general.

What do you think?

-Martin

On 2010-11-16 22:26, Philipp A. Hartmann wrote:
All,

I may have another option for naming events, which at least fixes the
separate, but magically connected namespace issue without sacrificing
the performance.

Technically, the idea is to add a separate (and optional)
sc_event_object* member to sc_event, which is derived from sc_object and
is used for naming events. I'll try to draw a class diagram, hopefully
it works with all mail clients. Consider the following hierarchy:

sc_object
   ^ +---------------------------+
   | | sc_event |
   | 0..1 +---------------------------+
sc_event_object ---- | sc_event_object* m_object |
    ^ +---------------------------+
    | ^
     \ ------+----------- /
             |
        sc_named_event (for convenience)

The behaviour would be the following:

sc_event()
  Leaves the allocation of an sc_event_object to the implementation.
  The sc_event_object could stay NULL for dynamic, unnamed events.

sc_event( const char* )
  Creates an sc_event_object with the requested name in the
  regular object hierarchy. No special rules needed.

sc_object* sc_event::get_object() const // return placeholder
  { return m_object; }

const char* sc_event::[base]name() const
  { return m_object ? m_object->[base]name() : NULL ; }

sc_object* sc_event::get_parent_object() const
  { return m_object ? m_object->get_parent_object() : NULL ; }

The sc_event_object class is only a placeholder in the object
hierarchy, technically implementation defined but with the following
additional interface:

const char * sc_event_object::kind() const
  { return "sc_event"; }

// return represented event (could also return a reference)
sc_event * get_event()
sc_event const * get_event() const

For convenience, an explicit sc_named_event (which always gets an
automatic name) could also be added:

class sc_named_event
: public sc_event_object
, public sc_event
{
public:

  sc_named_event();
  explicit sc_named_event( const char* name );
  ~sc_named_event();

  // disambiguate
  using sc_event_object::basename;
  using sc_event_object::name;
  using sc_event_object::kind;
  using sc_event_object::get_parent_object;
};

With this proposal, events are optionally part of the regular
sc_object hierarchy via the placeholder sc_event_object instances.
Regular traversal and naming expectations hold. Performance should not
be impaired.

I think, the only drawback would be the deviation in the conversion
during traversal. Usually, you can query for the kind() of an object
and do an appropriate dynamic_cast afterwards. With the above proposal,
you would need to do an get_event() to access the actual event instance:

// somewhere in "top.m"
sc_event ev1( "my_event" );
sc_named_event ev2( "my_named_event" );

sc_object* o1 = sc_find_object( "top.sub.my_event" );
sc_object* o1 = sc_find_object( "top.sub.my_named_event" );

// dynamic cast does not work for plain sc_event, need -> get_event()
// sc_event * ep1 = dynamic_cast<sc_event*>(o1); // -> NULL
sc_event * ep1 = dynamic_cast<sc_event_object*>(o1)->get_event();

// for an sc_named_event, usual dynamic_cast would work fine
sc_event * ep2 = dynamic_cast<sc_event*>(o2);

We could probably add corresponding get_child_events() functions that do
this filtering, of course. In that case, the sc_event_object could be
even more restricted to the internal use of the implementation.

Opinions? Could that be a working compromise?

Greetings from Oldenburg,
Philipp

NB: To avoid bouncing, I've snipped the previous discussion.

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