Re: Named events

No, no compelling reason. Just musing.

John A

From:
Martin Janssen <Martin.Janssen@synopsys.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>
Cc:
Martin Janssen <Martin.Janssen@synopsys.COM>, Bishnupriya Bhattacharya
<bpriya@cadence.com>, "Philipp A. Hartmann" <philipp.hartmann@offis.de>,
P1666 Technical WG <systemc-p1666-technical@eda.org>
Date:
17/11/2010 14:13
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.