Re: sc_vector proposal

John, All,

I have updated the proposal with the following changes:

 - Restrict template arguments to objects derived from sc_object

 - Add get_elements to sc_vector_base, and sc_vector_view

 - Standardise sc_vector_base for easier traversal.

 - Allow creation during simulation, iff element type does.

 - Dynamic resizing is still not supported.

 - Member-views via sc_view are supported for non-sc_objects,
   but get_elements() leads to a compiler error in that case.

Greetings from Oldenburg,
  Philipp

On 05/11/10 00:23, john.aynsley@doulos.com wrote:
> Philipp,
>
> Since the main use case is creating arrays-of-modules, arrays-of-ports etc, I am fine with disallowing dynamic re-sizing.
>
> Given the absence of voices raised against this proposal, I assume everyone wants it to happen! Could you provide me with a prototype implementation of your best guess at what the final thing will look like? I will then have a go at writing it up in the LRM.
>
> John A
>
> -----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
> To: Jerome CORNET <jerome.cornet@st.com>
> From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> Date: 11/04/2010 02:56PM
> Cc: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
> Subject: Re: sc_vector proposal
>
> Jerome, John, All,
>
> some feedback on the comments embedded below.
>
> On 03/11/10 11:05, Jerome CORNET wrote:
>>
>> · 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.
>
> Same here.
>
>> · 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'm fine with this. When we initially built the implementation the
> restriction has not been necessary, but it certainly fits better into
> the overall SystemC language to restrict elements to be "proper" SystemC
> objects.
>
>> I concur with Philipp on implementing a get_child_objects() on the vector.
>
> Since there seems to be consensus that we should not add extra levels
> in the hierarchy, I would propose to use another function name for this,
> since the elements are not "child objects" in the strict sense. Maybe
> 'get_elements' would be better?
>
> Shall we restrict the sc_view() technique to such (member) objects as
> well? This could keep the symmetry in the interface of sc_vector<T> and
> a corresponding sc_vector_view<T, & T::Member > by adding a
> 'get_elements' there as well.
>
> [snip]
>
>> · 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'm fine with creating vectors during simulation (if the elements
> support it). But I would prefer to tie the lifetime of the elements to
> the lifetime of the vector itself, and thus not supporting the dynamic
> expansion (or shrinking) of the vector.
>
> Having dynamically resizable vectors would require all kinds of
> dynamic checks during simulation and hamper the support of sc_vector for
> HLS tools. Init-only vectors can be supported by such tools quite
> easily (at least without custom Creator functors).
>
> Thanks,
> Philipp
>
> [snip remainder]
>
>> 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
>>
>
> [snip previous discussion]
>

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