sc_vector proposal

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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.