RE: Named events

John,

I will take this into internal discussions inside Cadence, and post back.

Thanks,
-Bishnupriya

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

Bishnupriya, All,

My two cents...

I started going there too (objects as parents to other objects). But we would then end up with the need for a mechanism to identify the parent of an sc_object. We have the sc_module_name and sc_process_* mechanisms in SystemC that do this "automatically" versus the explicit ctor argument in the SystemVerilog methodologies. I think it would be rather ugly to have both side-by-side in SystemC (implicit parent and explicit parent)

Dynamic instantiation of the module hierarchy has been on my mind for years. I have had users request it for applications like

while(...) {
        sc_start();
        tweak_the_structure();
}

Using an sc_object to group a bunch of other sc_objects as children would get some way toward that, but it feels like opening Pandora's Box to me.

In summary, I am on the same page as Martin.

John A

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

________________________________

Bishnupriya,

I've thought about this during the sc_vector proposal, since this would
be an obvious candidate for wrapping objects hierarchically as well.
During the discussion, we decided that this might not be a good idea,
since it could break user/tool expectations and traversal code.
Elaboration of designs, e.g. for synthesis/analysis would be more
difficult as well.

 Despite nicer names and potentially nice semantical grouping, the
model can for instance no longer rely on the fact, that a port's parent
is a module. Instead, you would need to search the hierarchy upwards.

 So I would expect that the addition of arbitrary objects as parents
would require quite some changes throughout the LRM and might break
existing code. I think, we should leave this for some future version of
the standard, probably after having experimented with such things inside
some implementations.

Greetings from Oldenburg,
Philipp

On 18/11/10 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]
> 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>
> 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<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.
>
>
>
>
>

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