RE: sc_event_and_list and sc_event_or_list

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
>
>------------------------------------------------------------------------
>
>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.