RE: Named events

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

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