Re: sc_vector proposal

All,

There's now an updated proposal available on the Twiki at
http://www.eda.org/twiki/pub/P1666/WebHome/p1666-sc_vector.pdf
(thanks John!).

The updated proposal reflects (from our side) the current status of the
discussion, contains open questions, and adds some possible solutions to
some open points.

The most important addition to the proposal is a generic bind() support
already to the sc_vector<T> class. Since sc_vector is a class
templates, such (non-virtual) member functions do not harm, if they are
not used.

The bind() implementation allows element-wise vector-to-vector (or
vector to iterator-range) bindings in a quite flexible way. Consider
the following small example:

  SC_MODULE( some_module ) { sc_in<bool> in; /* ... */ };

  sc_vector< sc_signal<bool> > sigs1( "sigs1", 5 ); // signal vector
  sc_signal<bool> sigs2[5]; // C array

  sc_vector< sc_in<bool> > in_ports( "ports", 10 ); // port vector
  sc_vector< some_module > mods( "mods", 10 ); // module vector

  // bind first half of ports
  sc_vector< sc_in<bool> >::iterator mid = in_ports.bind( sigs1 );

  // bind 2nd half using operator(), starting from 'mid'
  in_ports( sigs2, sigs2 + 5, mid );

  // hierarchical bind, based on a "member-view"
  sc_view( mods, &some_module::in ).bind( in_ports );

AFAICS, still open questions are the following:

- Is the proposed bind() mechanism acceptable?

- Shall we restrict the element types for sc_vector to types derived
  from sc_object?

  PRO: A common function
         std::vector<sc_object*> const & get_elements()
       could be added for raw access, maybe even as
          get_child_objects()
       if the vector adds a level of hierarchy.

  CON: sc_vector<sc_event> may not work with named events, iff they
       will not be derived from sc_object (as it currently looks like)

  CON: sc_vector< some_interface > may not work, which would currently
       be possible with custom Creator functions.

- Shall sc_vector<> add another level of hierarchy to the system?

  PRO: Could help with finding grouped elements during introspection.

  CON: Could break existing hierarchy traversal code, that relies on
       the fact that only modules and processes have children.

- Shall sc_vector<T> be creatable during simulation, iff its elements
  are?

- With the generic bind() support, do we still need specialisations like
  sc_port_vector<T>?

- Anything else?

There's also a small example in the proposal regarding sc_vector and
TLM-2 sockets. Of course, we can provide a proof-of-concept
implementation upon request.

Greetings from Oldenburg,
  Philipp

On 20/10/10 13:29, john.aynsley@doulos.com wrote:
> All,
>
> The next item on the list is the array-of-modules, ports, channels etc.
> Philipp published a detailed proposal several months ago, which I have
> uploaded to the Wiki site for your reference:
>
> http://www.eda.org/twiki/pub/P1666/WebHome/4._p1666-sc_vector_OFFIS.pdf
>
> I've also reproduced the email trail below.
>
> Comments please.
>
> John A
>
>
>
>
> [Philipp]
>
> in parametrisable and generic models, arrays of sub-modules, ports,
> and channels are often needed and widely used. Unfortunately, this
> usually requires the use of pointers and dynamic allocation of the array
> elements in a loop, since e.g. modules are rarely default-constructible.
>
> Frequent questions in public fora and teaching shows, that this causes
> troubles especially for inexperienced SystemC/C++ users. To reduce this
> limitation of SystemC's expressiveness and ease-of-use, we would like to
> propose a container class (working title sc_core::sc_vector), that can
> cover the most frequent use cases out-of-the-box and is extensible for
> more complex scenarios:
>
> // construct vector with 42 modules
> // named "mod_vec_0", "mod_vec_1"...
> sc_vector< my_module > mod_vec( "mod_vec", 42 );
>
> // std::vector-like interface
> mod_vec.size(), mod_vec.begin(), mod_vec[i].name()
>
> We've sent in a more detailed proposal, including additional examples
> and an initial wording for a potential inclusion in the standard, which
> will be added to the document repository at eda.org/systemc, soon. We
> can provide a corresponding proof-of-concept implementation upon request.
>
> An earlier version of this implementation has already been proposed to
> the OSCI LWG earlier this year. There has not yet been any decision
> inside OSCI, but some positive feedback has been given by individual LWG
> members. Since the call for proposed enhancements of IEEE 1666-2005
> ends March 10, we wanted to bring this to the P1666 WG in time, though.
>
> Looking forward to any comments, opinions, and criticism ... ;-)
>
> ----------------------------------------------------------------------------------------
>
> [Jerome]
>
> we have read your proposition and are very favorable to it. As a user
> company
> we have also looked at this SystemC issue and tried to address it.
> Actually what we have put in place [at ST] is a solution that is very
> similar to what your propose.
> I should mention that using "object vectors" for SystemC ports allows to
> be very effective and bug free
> (in contrary to manual pointers array) when modeling components with
> indexed ports or many "grouped"
> ports, and this practice is currently being widely adopted here.
>
> We can bring a further motive/example for standardizing such object
> vector classes over keeping
> using in-house development. Today, there are several companies that
> develop "netlisters" aimed
> at automatically generating the SystemC code instantiating and
> connecting modules, for instance
> starting from an IP-XACT description (in particular for TLM platforms).
> Even if a netlister
> is able to identify a group of ports in the IP-XACT description,
> generating the code to deal with
> the binding of group of ports cannot really be generic as the user could
> have chosen may solutions
> to model the group of ports:
> - Expanding the group as n separate sc_port
> - Exposing an array of sc_port pointers
> - Using an in-house solution similar to the one you are proposing.
>
> The code to perform the binding does not change much from one solution
> to the other,
> but yet there is no universal code to cover everything. In this
> situation the benefit from
> standardization is obvious.
> I would also add that this proposal would also enhance introspection in
> SystemC, as this
> would allow CAD tools to identify groups of ports and also provide added
> value in this area.
>
> Some comments now:
>
> - It would be beneficial for the class sc_port_vector to also provides
> bind() and operator()
> methods that would call bind()/operator() on each element of the vector.
> This would
> eliminate the need for possible buggy for loops once and for all.
>
> - It would indeed be desirable to support derived types, including in
> the sc_port_vector.
> One could then use this container to also support TLM-2.0 sockets. A
> proposal: why not
> standardizing a common container for TLM-2.0 sockets? (this would be a
> variant of
> sc_port_vector/sc_vector + instantiation functor, as sockets are
> basically inheriting from sc_port
> or sc_export).
>
> - A minor remark: check the const and references things. For instance
> sc_vector::init should
> take a const size_type as parameter (even if the semantics is
> pass-by-value this helps the compiler),
> and the Creator functor should be passed at least by reference (if not
> by const reference) to sc_vector::init<Creator>.
>
> - Another question that we are asking ourselves: should the container
> actually used really be implementation-dependent?
> Why not standardizing on STL's std::vector, whose implementation is
> already left to optimizations?
>
> ----------------------------------------------------------------------------------------
>
> Hello Jerome, all,
>
> thanks for your feedback. Some comments below.
>
> On 10/03/10 16:22, Jerome CORNET wrote:
>> On 3/9/2010 9:42 PM, Philipp A. Hartmann wrote:
>>> Looking forward to any comments, opinions, and criticism ... ;-)
>>>
>
>> we have read your proposition and are very favorable to it.
> [snip description of some benefits and additional use case example]
>
>> I would also add that this proposal would also enhance introspection in
>> SystemC, as this would allow CAD tools to identify groups of ports and
>> also provide added value in this area.
>
> The current proposal is tries to not mess with the SystemC hierarchy
> directly. If you have a vector of two elements with name "vec" in the
> module "top", you would currently get the following child objects:
>
> top.vec // vector itself
> top.vec_0 // first element
> top.vec_1 // second element
>
> The reason for this has been
> - 5.15.1: Only module objects and process objects can have children.
> - Try not to break existing hierarchy traversal code, that relies on
> the first bullet.
>
> So as it stands currently, it may be difficult to directly identify
> the objects belonging to a particular vector, especially combined with
> delayed initialisation (see also standardised container comment, below).
>
>> Some comments now:
>>
>> - It would be beneficial for the class sc_port_vector to also provides
>> bind() and operator() methods that would call bind()/operator() on each
>> element of the vector. This would eliminate the need for possible
>> buggy for loops once and for all.
>
> Yes, I agree that this is very useful. Attached is our current
> implementation of the sc_port_vector class, which provides several
> bind() functions (and corresponding operator()). This enables bindings
> of (sub-)vectors, whenever elements in the two vectors are binding
> compatible (e.g. vector of ports to vector of channels).
>
>> - It would indeed be desirable to support derived types, including in
>> the sc_port_vector. One could then use this container to also support
>> TLM-2.0 sockets.
>
> Indeed. Polymorphic types are meant to be supported already, in case
> you have a Creator function (object), that creates and returns derived
> types. This may need some clarification in the wording for the
> standard, though.
>
>> A proposal: why not standardizing a common container for TLM-2.0
>> sockets? (this would be a variant of sc_port_vector/sc_vector
>> + instantiation functor, as sockets are basically inheriting from
>> sc_port or sc_export).
>
> Given that TLM is to be added to IEEE 1666, I think this might be a
> useful enhancement. For sc_export itself, a specialisation would then
> be needed as well, especially regarding the binding support.
>
>> - A minor remark: check the const and references things. For instance
>> sc_vector::init should take a const size_type as parameter (even if
>> the semantics is pass-by-value this helps the compiler),
>
> Sure, why not.
>
>> and the Creator functor should be passed at least by reference (if not
>> by const reference) to sc_vector::init<Creator>.
>
> For the Creator functor, I tried to follow the approach of the C++
> standard library (and Boost, etc) in such cases. The main reason for
> this is flexible support for function objects (apart from plain function
> pointers).
>
> - If you pass the functor by (non-const) reference, temporary objects
> can not be passed as argument (e.g. the ones return by (sc_)bind).
> - If you pass it by const-reference, the operator() of the functor
> has to be const as well.
>
> But since these are constructor calls that are only allowed during
> elaboration, it should not be a performance issue anyhow.
>
>> - Another question that we are asking ourselves: should the container
>> actually used really be implementation-dependent?
>> Why not standardizing on STL's std::vector, whose implementation is
>> already left to optimizations?
>
> When I first implemented this, it has been more or less an
> "elaboration-only" variant of a container like Boost's ptr_vector and
> has not been restricted to objects derived from sc_object.
>
> Since the module/port/channel/... use cases are by far the most
> frequent ones in SystemC, and those _are_ derived from sc_object, we
> could of course standardise the internal container to
> std::vector< sc_object* > and add a function
>
> std::vector< sc_object* > const & get_elements() const
>
> to improve the introspection possibilities.
>
> If we decide to put the elements as child objects of the vector itself
> (see above), it may even be a consequence of the then required
> implementation of get_child_objects() in the sc_vector class.
>
> Greetings from Oldenburg,
> Philipp
>
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.