Re: sc_event naming: Cadence position on proposed extension

Bishnupriya, All,

I think we agree that none of the proposals on the table are ideal, and
that the place to explore experimental features is the OSCI LWG, not the
IEEE. The question then is whether anything on the table is ready to go
into 1666.

I guess we have a consensus to add sc_event(const char* nm). Beyond that
things immediately get murky because we have agreed there is no nice way
to integrate event names with object names. The question is whether we can
be sufficiently sure what SystemC might look like in the future to put
anything into 1666 now, and balance that against the user-demand for a
solution right now.

On balance, I would vote to go with the Cadence proposal. But I would also
be okay to leave named events out of 1666-2011 altogether.

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>,
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
22/11/2010 10:35
Subject:
sc_event naming: Cadence position on proposed extension

John, All,
 
Over the past few days, within Cadence, we have carefully reviewed the
SNPS extension to the Cadence event naming proposal. Our position is as
below. There is strong agreement within Cadence on this position,
including from Stuart .
 
First, about allowing objects to parent other objects, there are certainly
issues (as several of you have pointed out) if we try for an ambitious
scheme to arbitrarily change the object hierarchy at run-time. However,
that is not our intent. We're trying to explore if we can carve out a
small subset that will be useful. We're not envisaging a dynamic module
hierarchy. Any object hierarchy changes will be restricted to elaboration
time only.
 
So, what is the motivation? One thing that comes to mind is a natural
grouping of things to better express the intent of a class, and prevent
"leakage" of internal implementation objects to the outside of this class.

Consider an aggregate class like the TLM2 simple_target_socket. It has a
number of other objects and events inside it - these are all internal
implementation artifacts of this socket. Today all of these internal
objects/events end up in the parent module's scope. The output of
get_child_objects() and get_child_events() on a target module that owns a
simple_target_socket is given below.
 
top.target.socket
top.target.socket_port_0
top.target.m_peq_0
top.target.b2nb_thread_0
top.target.peq_with_cb_and_phase_0
top.target.fec_0
top.target.event_0
top.target.event_1
top.target.event_2
top.target.event_3
Everything besides the target socket itself, does not really belong to the
parent module's scope; the rest is useless clutter that a user never wants
to see. It is safe to say that the simple_target_socket class does not
intentionally want to expose these internal implementation artifacts, but
today it has no choice but to do so. With the SNPS extension proposal, the
events will now go out of this list - the poor objects will be left behind
 
top.target.socket
top.target.socket_port_0
top.target.m_peq_0
top.target.b2nb_thread_0
top.target.peq_with_cb_and_phase_0
top.target.fec_0
 
This is not consistent. It does not feel right that events will end up
with the property that they can be grouped more hierarchically, but
objects can't. As things stand today (or rather I should say with the
Cadence proposal), things are not perfect, but at least an user can expect
consistency when constructing an user-defined object wrt scope of internal
objects and events. With the SNPS extension, that is no longer true. It is
as if events have become more of a first class citizen than objects.
 
We all agree that a proper "fix" for this - such that objects can also be
children of other objects in some restricted, but useful fashion - is not
simple. Many issues need to be considered, especially wrt adjusting
existing object's ctor, and other issues that Philip has raised.
Realistically speaking there isn't time in this round to consider all the
ramifications, and arrive at a solution (or conclude one is not possible).

 
Given that, we feel it will be inappropriate to only standardize the
object-owning-events feature, and leave things in a half-baked state. We
do not buy the argument that since this feature pertains to event naming
it will make it to this round - we DO need to consider the ramifications
of proposed solutions to the rest of the ecosystem. We feel it is more
appropriate for the LRM to leave kernel event naming as
implementation-defined in this round, and include this feature as an
addition in the next round if it is so deemed. We're opposed to rushing
something into the LRM that leaves things in an inconsistent state without
having the time to consider the complete problem.
 
Leaving this aspect implementation-defined in p1666-2010 allows each
vendor (including the OSCI ref sim) to experiment with developing a sane
object/event naming and parent/child relationship hierarchy while
remaining compliant with the 2010 standard. In 1666-2012 (or whenever the
next round is) we can then propose standardizing that which we have
previously implemented and tested.
 
We would like to hear what others have to say on this topic.
 
Thanks,
-Bishnupriya
 
----------------------------------------------------------------------------------------------------------------------------------------------------

     Bishnupriya Bhattacharya | Software Architect - Virtual System
Platform | Cadence
     P: +91.80.4184.1197 www.cadence.com
----------------------------------------------------------------------------------------------------------------------------------------------------

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