Re: Named events

Hi Philipp,

I agree with your first three points.

An event with a parent but without name doesn't seem to make
sense, but default naming (as the default c'tor) would be fine.

-Martin

On 2010-11-18 13:51, Philipp A. Hartmann wrote:
> 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.