RE: sc_event_and_list and sc_event_or_list

Given that sc_event_and_lists and sc_event_or_lists already exist, I don't think there should be much performance overhead in changing minor aspects of them, such as allowing for a public constructor at the very least. These lists already act as containers so I don't think taking a look at how these containers can be made a little more user friendly would negatively affect the performance of sc_events themselves.

Being able to name sc_events and look up sc_events by name is another aspect that should have zero performance impact on the simulation.

Best regards,

Tor Jeremiassen

---
Tor Jeremiassen, Ph.D.
Simulation and Modeling CTO
SDO Foundational Tools
Texas Instruments                    Ph:    281 274 3483
P.O. Box 1443, MS 730                Fax:   281 274 2703
Houston, TX 77251-1443               Email: tor@ti.com<mailto:tor@ti.com>
________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Thursday, March 11, 2010 11:20 AM
To: Stuart Swan
Cc: Alan Fitch; owner-systemc-p1666-technical@eda.org; systemc-p1666-technical@eda.org; Jeremiassen, Tor
Subject: RE: sc_event_and_list and sc_event_or_list
I echo Stuarts comments. That is why things are as they are.
On the other hand, I would agree that users often ask for this feature. If anyone wants to seriously propose this enhancement, I suggest that the onus should be on them to prove that it can be implemented without any complications or inefficiencies (by doing so).
John A
From:
Stuart Swan <stuart@cadence.com>
To:
Alan Fitch <alan.fitch@doulos.com>, "Jeremiassen, Tor" <tor@ti.com>
Cc:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
10/03/2010 20:27
Subject:
RE: sc_event_and_list and sc_event_or_list
Sent by:
owner-systemc-p1666-technical@eda.org
________________________________
All-
Regarding Alan's comment below about having the ability to
know which event triggered a process, this discussion came up in
the original work we did when designing SystemC 2.0.
The argument then (made by me and perhaps others) was that we wanted
to keep events as light weight as possible, with the least amount
of functionality that we could get away with, since any extra bookkeeping
etc related to events might slow down all simulations (even those
that didn't use the fancy features).
In most cases, if you need "fancy events", you probably should be thinking about
using a particular channel that encapsulates the specific functionality you want.
As an example of the difficulties: assume we wanted have the ability to have a process
determine which event triggered it. If you go dig thru the event scheduling code
in OSCI systemc with the intent to implement this feature, you soon realize that
there are all sorts of questions: e.g. if process p is sensitive to event a or b
and event a is triggered, but before p runs event b triggers, then which event triggered the
process ? both ?  In my opinion you can model such things using your own channels and keep
these sorts of issues outside of the core simulator.
-Stuart
>-----Original Message-----
>From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf
>Of Alan Fitch
>Sent: Wednesday, March 10, 2010 2:37 AM
>To: Jeremiassen, Tor
>Cc: systemc-p1666-technical@eda.org
>Subject: Re: sc_event_and_list and sc_event_or_list
>
>Jeremiassen, Tor wrote:
>> All,
>>
>>
>>
>> A long time frustration with writing SystemC is the fact that
>> sc_event_and_list and sc_event_or_list cannot be instantiated as objects
>> since their constructors are private. The way it seems to be intended to
>> work is that event "and" and "or" lists are to be static in nature (at
>> the call site), and not able to be created in any more dynamic manner.
>> This is an unfortunate shortcoming. In fact, there is an idiom
>> frequently used in SystemC models that partially work around that by
>> returning a reference to an sc_event_or_list (or sc_event_and_list) that
>> is a local (stack allocated) variable in a function - which, even though
>> it works, seems to be a dubious programming practice.
>>
>>
>>
>> I think the language would greatly benefit from allowing the user to
>> create containers of events that are treated as or-lists and and-lists,
>> build them dynamically as they see fit, and pass the container to
>> wait(), and any other function that takes events. This would greatly
>> improve the expressiveness of SystemC and will make it much easier to
>> model cases where the number of events aren't known at elaboration time,
>> and/or may change during simulation.
>>
>>
>>
>
>Also, perhaps if the sc_event_or_list and sc_event_and_list were
>replaced with or re-implemented as some kind of container, presumably we
>could add a system for figuring out which event triggered a process.
>
>
>
>regards
>Alan
>
>
>
>
>--
>Alan Fitch
>Senior Consultant
>
>Doulos - Developing Design Know-how
>VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
>Services
>
>Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
>1AW, UK
>Tel:  + 44 (0)1425 471223                                  Email: alan.fitch@doulos.com
>Fax:  +44 (0)1425 471573                                  http://www.doulos.com<http://www.doulos.com/>
>
>------------------------------------------------------------------------
>
>This message may contain personal views which are not the views of
>Doulos, unless specifically stated.
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.