Re: Proposal for IEEE 1666-2010: a container for modules, ports, and channels

On 3/9/2010 9:42 PM, Philipp A. Hartmann wrote:
> Looking forward to any comments, opinions, and criticism ... ;-)
>
Hello Philipp, all,

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?

Regards,

Jerome Cornet
STMicroelectronics

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