Re: sc_event naming: Cadence position on proposed extension

All,

Just to be clear, this is not a "vote" at all in any official sense, just
a straw poll to get a sense of how the whole WG stands on this issue.

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com
Cc:
systemc-p1666-technical@eda.org
Date:
23/11/2010 16:21
Subject:
Re: sc_event naming: Cadence position on proposed extension

John,

since it would be sad to drop this feature, I would prefer
"Option 2", especially leaving the names of internal kernel events
implementation defined. "Option 3" requires more intrusive changes to
the language and should be left for future versions.

But of course, this is not a vote since OFFIS doesn't have one. :-)

Thanks,
  Philipp

On 23/11/10 17:11, john.aynsley@doulos.com wrote:
> All,
>
> So we seem to be splitting into a few camps re. the event naming
proposal.
>
> In our timed-honored tradition, let's take a straw poll just to see
where
> everybody stands on this issue.
>
> * Option 1 - Do nothing. Do not include event naming in this round of
> standardization
> * Option 2 - The Cadence proposal. Add named events, but named events
can
> only be children of modules or processes, not arbitrary sc_objects.
> * Option 3 - The Synopsys proposal. Extend 2 such that sc_events, but
only
> sc_events, can be children of arbitrary sc_objects
> * Option 4 - Something else.
>
> "Votes" please (not legally binding)
>
> I already have (but feel free to change your "vote")
> * Option 1 - Tor
> * Option 2 - Bishnupriya, John, Jerome
> * Option 3 - Martin
>
> This is getting urgent, so please respond!
>
> Thanks
>
> John A
>
>
>
>
> From:
> Martin Janssen <Martin.Janssen@synopsys.com>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>
> Cc:
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date:
> 23/11/2010 14:01
> Subject:
> Re: sc_event naming: Cadence position on proposed extension
>
>
>
> John,
>
> A lot of nice words from Bishnupriya, but the only objection against our

> extension
> proposal is hierarchical naming of objects, which is not part of our
> proposal, and
> for good reason.
>
> But does this mean that we should do a lousy job on hierarchical event
> naming?
> Or, put differently, should we treat events as first class citizens or
> not?
>
> Let's take a look at the current objects types. We have modules and
> processes,
> which are the most important object types when modeling and simulating
> with
> SystemC. Their hierarchical name is just perfect, and also in other
> regards we
> can say that these object types are indeed first class citizens. The
other
> object
> types, such as ports, exports, primitive channels, are already in the
> "poor objects"
> (or second class citizens) category.
>
> Enter named events. We already decided not to make them objects, but to
> treat them somehow like objects. In which of the two above categories
> (first
> class citizens or second class citizens) do events belong? Bishnupriya
is
> saying that we should put them with the second class citizens, and do as
> poor a job at naming them. But events _are_ first class citizens that
> belong
> with modules and processes. During simulation processes and events are
> at center stage.
>
> So my question is: why not treat events as we do modules and processes?
>
> An implementation that has been out there for 2 years, on its own,
cannot
> be
> enough reason for unamended standardization.
>
> -Martin
>
>
> On 2010-11-22 11:35, Bishnupriya Bhattacharya wrote:
> 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
>
----------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>

-- 
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://offis.de/en/
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.