Re: sc_event naming: Cadence position on proposed extension

I do not feel strongly on any of the options; although, I do see the benefit
of named events. I could go with 1, 2, or 3 with a slight preference towards
2 because 3 can be added later and I feel something is better than nothing
in this case.

On Tue, Nov 23, 2010 at 10:11 AM, <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
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

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