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] *On Behalf Of *Martin
> Janssen
> *Sent:* Tuesday, November 23, 2010 7:31 PM
> *To:* john.aynsley@doulos.com
> *Cc:* 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 hierarchyat 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. Itis 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.