RE: sc_vector proposal

You’re right on the timeout John... I reviewed Philipp’s document but did not posted the comments. Here they are:


· On the naming: I am okay with the sc_vector naming. To me, it is not that confusing with sc_vector_p. However,
if there is a strong consensus for something like sc_array, I would agree.



· On the constraints on T: I am in favor of requiring T to derive from sc_object. It indeed excludes the sc_event objects,

but I think we need to restrict a little the intent of this class, which I understand as for “structural” objects. And thus,

I concur with Philipp on implementing a get_child_objects() on the vector.



· On the object hierarchy: I also agree with John that sc_vector should not create an additional level in the object hierarchy. This is anyway consistent

with the fact that the sc_vector’s constructor takes as possible argument a prefix for the contained object, not a name for the vector

itself (which would not be very useful).



· On sc_vector’s creation during simulation: this has obvious links with the create_element() current [proposal] restriction of being

called only during elaboration. We could also choose to allow create_element() calls during the simulation [for supporting sc_objects],

even if the sc_vector has been created at elaboration time.
I am not in strong disagreement with the feature, but a clear drawback is that it creates confusion between an original intent of
“structural” use (for which the “elaboration” restriction is sound and well suited) and possible unspecified other uses based on
sc_object inherited user classes, that would exploit the 5.15.3 section’s possibility of instantiating sc_object during simulation.
Anyway, if we choose to allow creation during simulation for sc_object derived classes, I would suggest to make it very clear

in the norm that this is allowed only for “non-structural” elements (even if this is already implied by instantiation rules on sc_module,

sc_port classes).

Does anyone have a good example of sc_vector use with sc_object creation during simulation?



· On sc_port_vector: I agree with Philipp’s analysis that this class is not really needed anymore and this is best to make bind() available

at the sc_vector level. This is a bit confusing at first glance (because bind() cannot be used with any T), but this has the advantage
                of simplifying the class hierarchy. And again, this fits well with a “structural” intent for sc_vector.


Regards,

Jerome


From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Wednesday, November 03, 2010 12:03 AM
To: Philipp A Hartmann
Cc: P1666 Technical WG
Subject: Re: sc_vector proposal

All,

Time is running out on this one, through no fault of Philipp It would be good to get some input on Philipps' questions below.

For my two cents, I would like to see existing hierarchy traversal code working out-of-the-box. Hence I would tentatively suggest that sc_vector should not add another level of hierarchy. Also I think it reasonable to restrict the element types to being derived from sc_object, and hence being part of the object hierarchy. In other words, I am suggesting that sc_vector should be tied, conceptually, to the SystemC object hierarchy. If that means named events are excluded, so be it.

I think it would be good to allow sc_vector to be instantiated during simulation, as is the case for the object hierarchy (but not the module hierarchy)

Another question. Are we all okay with the name sc_vector (and the confusion with the deprecated sc_vector_p)?

John A


-----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
To: systemc-p1666-technical@eda.org
From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
Date: 10/21/2010 01:44AM
Cc: john.aynsley@doulos.com
Subject: 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<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.