Re: Named events

Hi John,

I agree with what you're saying.

-Martin

On 2010-11-18 14:00, john.aynsley@doulos.com wrote:
> Just a thought. The main use case we've been discussing is kernel events in primitive channels. Primitive channels can
> only be instantiated during elaboration. So I do not see that the naming of these events will be a performance burden.
> I do not see the need to allow events with a parent but no name.
>
> John A
>
>
>
> From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To: john.aynsley@doulos.com
> Cc: Martin Janssen <Martin.Janssen@synopsys.com>, Bishnupriya Bhattacharya <bpriya@cadence.com>, P1666 Technical WG
> <systemc-p1666-technical@eda.org>
> Date: 18/11/2010 12:51
> Subject: 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.