Re: Named events

All,

I agree, and I basically like the idea of named (explicit kernel) events
as children of some owning object (like primitive channels).

  But I would prefer to leave it implementation-defined, whether such
events are actually named when created during the simulation. There's
more than just posedge_event, e.g. terminated_event etc.

  Secondly, for some channels (e.g. sc_fifo), the default_event is
redirected to an internal, never-notified event. At present, this is a
shared, top-level event. We should not require, that all events
returned from a channel's interface are in fact descendants of this
particular channel instance.

  Thirdly, I don't see any possibility to extend the "current object"
semantics from modules/processes to arbitrary sc_objects. There's just
no way to trace the execution context correctly, especially not during
simulation.

So, the way to go would be the additional ctors, Martin proposed

 // default parent (current module/process)
 explicit sc_event( const char* name );

 // specific parent (allowed to be NULL to create top-level events?)
 sc_event(const char* name, sc_object* parent );

I would prefer this over implementation-specific naming rules as well,
even if that means, that we need to recurse to all child objects, to
look at the events.

Some post-lunch brainstorming follows: ;-)

Do we want events with a parent object, but without a name?
Something like:

  explicit sc_event( sc_object* parent );

  Events with a parent would then be registered in the parent's child
events, but without a (unique) name. I could imagine to require the
on-demand creation of an appropriate automatic name, though.

  This could be a reasonable trade-off between "debugability" and
performance, since the creation of a (unique) name is probably the
costly part of the construction.

Greetings from Oldenburg,
Philipp

On 18/11/10 13:19, john.aynsley@doulos.com wrote:
> 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>
> To:
> Bishnupriya Bhattacharya <bpriya@cadence.com>
> Cc:
> Martin Janssen <Martin.Janssen@synopsys.COM>, "john.aynsley@doulos.com"
> <john.aynsley@doulos.com>, "Philipp A. Hartmann"
> <philipp.hartmann@offis.de>, P1666 Technical WG
> <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
> 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 wrote:
> Martin,
>
> Comments below.
>
> John A
>
>
> From:
> Martin Janssen <Martin.Janssen@synopsys.com>
> To:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> Cc:
> Bishnupriya Bhattacharya <bpriya@cadence.com>, "john.aynsley@doulos.com"
> <john.aynsley@doulos.com>, P1666 Technical WG
> <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.
>
>
>
>
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://www.offis.de/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.