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

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