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.