Re: sc_event naming: Cadence position on proposed extension

Hi John,

> *Can everyone now live with that?*

We can.

I assume that sentences in the IEEE 1666-2005 LRM such as (p94) "An implementation
shall not add any names to this namespace other than the hierarchical names of sc_objects
explicitly constructed by an application" will be rephrased to include that kernel events are an
exception to this rule and can be added by an implementation plus that their name and hierarchy
are implementation dependent.

-Martin

On 2010-11-24 13:15, john.aynsley@doulos.com wrote:
> All,
>
> Here is an updated summary of the event naming proposal now on the table:
>
> * Events are not sc_objects
>
> * All static events are named (the default constructor generates a name)
> * Dynamic events can be named or unnamed
> * Kernel events can be named or unnamed, and the names are implementation-defined
>
> * Named events have a parent in the object hierarchy (which can only be a module or a process)
> * Add a method sc_event::get_parent_object() to return this parent (null for unnamed events)
> * The prefix to each event's name is the hierarchical name of the event's parent
> * An event name shall not clash with an object name (sc_gen_unique_name is called iteratively)
>
> * Add methods get_child_events, get_top_level_events, and sc_find_event that mirror the methods of the object hierarchy
>
> * Add a method sc_name_exists(const char*) that returns true if the name is in either the object or the event namespace
>
> *Can everyone now live with that?*
>
> I have one question regarding the constraints on implementation-defined kernel names. Do they have to be legal names?
> If so, there might be a risk of a clash with a subsequent user-defined name, which would then get given a suffix from
> sc_gen_unique_name. If not, the only way to create an illegal name would be to include a space character (the AZaz09_
> character set for string names is recommended, but not obligatory).
>
> I would vote for implementation-defined kernel names being legal names. The kernel could always include separators
> such as -> or / that are unlikely to be used by an application. Moreover, as I read the LRM, I think we could allow
> implementation-defined hierarchical event names to include extra '.' characters since these would not technically be
> embedded in string names (arguments passed to ctors) but would be part of the hierarchical name of a new kind of event
> object.
>
> To clarify, when you construct an sc_object or an sc_event you pass in a string name that must not contain dots. But
> an implementation-defined kernel event name could include extra dot separators, I think.
>
> 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 17:27
> Subject: Re: sc_event naming: Cadence position on proposed extension
>
>
> ------------------------------------------------------------------------------------------------------------------------
>
>
>
> Hi John,
>
> To avoid further delays in the process, I'll change my vote to option 2
> provided it states that kernel event naming is implementation-defined,
> as Bishnupriya proposed in an earlier email.
>
> One more question: How is a vendor supposed to experiment with
> developing a sane object/event naming and parent/child relationship
> hierarchy while remaining compliant with the 2010 standard if the '.'
> character in the name is an error? (not only for kernel event naming)
>
> -Martin
>
>
> On 2010-11-23 17:35, Bishnupriya Bhattacharya wrote:
> John, Martin,
>
> Comments below.
>
> -Bishnupriya
>
> ------------------------------------------------------------------------------------------------------------------------
> *From:* _owner-systemc-p1666-technical@eda.org_
> <mailto:owner-systemc-p1666-technical@eda.org>[_mailto:owner-systemc-p1666-technical@eda.org_] *On Behalf Of *Martin
> Janssen*
> Sent:* Tuesday, November 23, 2010 7:31 PM*
> To:* _john.aynsley@doulos.com_ <mailto:john.aynsley@doulos.com>*
> Cc:* _systemc-p1666-technical@eda.org_ <mailto:systemc-p1666-technical@eda.org>*
> 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?
>
> >>> [bpriya: The logic presented above does not make any sense to me. With the SNPS extension proposal, how are events
> getting treated the same as modules and processes? Today, the only thing that distinguishes modules/processes from
> other objects is that modules/processes can be parents, owning children. The SNPS extension is *not* proposing that
> events be able to own children. It is proposing that objects be able to own events, which actually creates
> inconsistency between events and other objects, including processes - e.g. when an object instantiates an event and a
> process inside it, the event will get a *nicer* hierarchical name "mymod.myobj.myevent" compared to the process's name
> "mymod.myproc". How is that treating events like processes? On the contrary, it pegs events at a notch higher than
> processes (and all other objects for that matter) as "gold class citizens" perhaps.]
>
> An implementation that has been out there for 2 years, on its own, cannot be
> enough reason for unamended standardization.
>
> >>> [bpriya: Cadence has never presented this as the rationale either for standardization of the Cadence proposal, or
> for vetoing the SNPS extension proposal. The Cadence proposal has been presented early in this round, and it has been
> scrupulously explained technically and thoroughly debated. The fact that an implementation exists and has been tested
> by users is always considered a positive for anything but non-trivial proposals, and especially so for unchartered
> territory.
>
> Cadence has pushed back on standardizing the SNPS extension in this round because it creates a clear inconsistency in
> the hierarchy for events and objects, and at this last minute, there isn't the time for technical discussions in p1666
> (and for experimental implementations) in order to explore if this inconsistency can be removed/minimized. Cadence
> does not support standardizing something half-baked that leaves obvious, unanswered questions in the users' mind. That
> is not a prudent strategy. Following precedence, this rightfully belongs to the LWG for further exploration, and can
> be presented in the next round if so deemed.]
>
> -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 <http://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.