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.