Re: Virtual bind operators

Philipp, Jerome, All,

Regarding the signature void bind ( sc_port<sc_signal_in_if<T>, 1>& );
note that this is explicitly restricted to binding to a port with N = 1,
because those are the semantics required for this port specialization
(signal ports cannot be multiports). I think we should keep this
restriction, i.e. not change the signature.

My original point was that, unlike every other operator()/bind pair, the
operator()/bind methods of sc_in<> , sc_in<bool> , and sc_in<sc_logic> are
explicitly required by the LRM to call the bind method of the base class.
I would agree that it would be more consistent to change the LRM to
mandate that sc_in<T>::operator() shall call this->bind, and that bind be
virtual. However, sc_in<T>::bind(...) cannot get called through a base
class ptr because there is no method with that signature in class
sc_port_b. That's fine with me.

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com
Cc:
Jerome CORNET <jerome.cornet@st.com>, "systemc-p1666-technical@eda.org"
<systemc-p1666-technical@eda.org>
Date:
18/10/2010 16:54
Subject:
Re: Virtual bind operators

John,

currently, sc_in<T> has three pairs of bind()/operator()

The first two are inherited from sc_port_b< sc_signal_in_if<T> >:

 void bind ( const sc_signal_in_if<T>& );
 void operator() ( const sc_signal_in_if<T>& );

 void bind ( sc_port<sc_signal_in_if<T>, 1>& );
 void operator() ( sc_port<sc_signal_in_if<T>, 1>& );

We could even consider to stop mentioning them explicitly and replace
them with:

  using sc_port< sc_signal_in_if<T>, 1 >::bind;
  using sc_port< sc_signal_in_if<T>, 1 >::operator();

But there's an additional pair to support binding to inout ports as
well, which is why we need the repetition or the using declaration:

 void bind ( sc_port<sc_signal_inout_if<T>, 1>& );
 void operator() ( sc_port<sc_signal_inout_if<T>, 1>& );

So this should probably be changed to

 virtual void bind( sc_port_b< sc_signal_inout_if<T> > & );
 void operator()( sc_port_b< sc_signal_inout_if<T> > & );

Similar for the specialisations for bool and sc_logic.
I have not checked this, though.

Thanks,
  Philipp

On 18/10/10 17:38, john.aynsley@doulos.com wrote:
> Philipp, All,
>
> I agree with having "virtual bind" for sc_port_b, sc_export,
> tlm_analysis_port, tlm_base_initiator/target_socket, and
> multi_passthrough_initiator/target_socket
>
> I am not sure about sc_in<> etc, because as things stand bind() and
> operator() are each explicitly obliged to call sc_port_b::bind(). What
do
> you think?
>
> Thanks,
>
> John A
>
>
>
>
> From:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To:
> Jerome CORNET <jerome.cornet@st.com>
> Cc:
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>,
John
> Aynsley <john.aynsley@doulos.com>
> Date:
> 14/10/2010 09:17
> Subject:
> Re: Virtual bind operators
>
>
>
> Jerome,
>
> On 14/10/10 09:54, Jerome CORNET wrote:
>
> [snip]
>
>> If I understand well, with what you propose below, we would avoid
>> to write the using clause for the operator() and could focus on
> overloading
>> the bind() methods only?
>
> Exactly. If we require, that the operator() implementations call the
> corresponding virtual bind functions, you would only need to implement
> those.
>
> If we adopt this change, we should look at the other operator()/bind()
> pairs in
>
> - sc_export (5.12)
> - sc_in<> (6.8, 6.9, 6.10)
> - tlm_analysis_port (18.4.1) (not sure here)
> - tlm_base_initiator/target_socket (14.2.2)
>
> to make this consistent.
>
> Note, in 5.11.7 (sc_port::bind), there's a typo: "sc_export<T>::operator
> &" is missing the 'IF'
>
> Greetings from Oldenburg,
> Philipp
>
>>
>> -----Original Message-----
>> From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
>> Sent: Wednesday, October 13, 2010 10:04 PM
>> To: Jerome CORNET
>> Cc: systemc-p1666-technical@eda.org; John Aynsley
>> Subject: Re: Virtual bind operators
>>
>> Jerome, All,
>>
>> I'm not sure, if I understand the use-case correctly.
>> Consider the following example:
>>
>> template<typename IF>
>> struct my_port : sc_core::sc_port<IF>
>> {
>> typedef sc_core::sc_port<IF> base_port;
>>
>> // override port-interface binding
>> virtual void bind( IF& iface )
>> {
>> // do something special
>> // call base function
>> base_port::bind( iface );
>> }
>>
>> // still needed for port-port binding due to name-hiding
>> using base_port::bind;
>>
>> // inherit operator()
>> };
>>
>> Is this the use-case you had in mind?
>>
>> In that case, I would propose to make only bind() virtual and require
>> the operators to call exactly this virtual bind function (which is not
>> required as of now):
>>
>> template< typename IF >
>> struct sc_port_b
>> {
>> void operator()( IF& iface); // Effect: this->bind(iface)
>> void operator()(sc_port_b<IF> & port); // Effect: this->bind(port)
>>
>> virtual void bind(IF &);
>> virtual void bind(sc_port_b<IF> &);
>> };
>>
>> This would make the above example work, if the operator() functions are
>> required to call the virtual bind() function. Do I miss something? Is
>> there a reason, to make the operators virtual as well? We would still
>> want them to call their virtual bind() siblings, right?
>>
>> Thanks,
>> Philipp
>>
>> On 13/10/10 16:14, john.aynsley@doulos.com wrote:
>>> Jerome, All,
>>>
>>> The next item on the list is virtual bind operators. I include the
text
>
>>> from Jerome's original proposal below.
>>>
>>> Thoughts?
>>>
>>> John A
>>>
>>>
>>> Another area that can be improved with only minor changes is the
>>> sc_port/sc_export classes:
>>>
>>> * The various bind() and operator() methods are not declared virtual.
> This
>>> means that when someone wants to overload these methods in a user
class
>
>>> derived from sc_port or sc_export, he has to declare and provide
>>> implementation for all the variants. For instance the user could want
> to
>>> overload the sc_port binding to an interface, and he has to also
> declare
>>> and implement all the other bindings. This is a real pain when
>>> implementing user protocol classes derived from sc_port or sc_export.
>>>
>>> * Similarly, I would propose to declare virtual the various bind() and

>>> operator() methods in the TLM 2.0 sockets classes
>>> (tlm_base_initiator_socket and tlm_base_target_socket).
>>>
>>> * The class sc_port is template on IF (interface), N (max number of
>>> connections) and POL (policy), and derives from the sc_port_base
class.
>>>
>>> * The declaration of sc_port binding on another sc_port does not seems

>>> consistent:
>>> void bind(sc_port<IF, N> &);
>>>
>>> This means that a sc_port "templatized" with N=2 can only connect to
>>> another port that is "templatized" with the very same N whereas you
can
>
>>> logically connect a sc_port with N=2 to 2 sc_port that would have N=1
> (for
>>> instance). In this area, I have seen many implementations (including
> the
>>> reference OSCI implementation) that just don't comply with the norm in

>>> order to allow these logical connections.
>>>
>>> So, what is needed is something like this:
>>> virtual void bind("any_port" &);
>>> sc_port_base could be a candidate for "any_port" but it is not
template
> on
>>> IF. Actually, if we look at some implementations, we see that they do
> use
>>> an intermediate class called sc_port_b, that is template on IF.
>>>
>>> So the proposal is:
>>>
>>> - Standardize the class sc_port_b<IF>, that inherits from sc_port_base

> and
>>> that contains the following bind/operator functions:
>>>
>>> virtual void operator() (IF &);
>>> virtual void operator() (sc_port_b<IF> &);
>>>
>>> virtual void bind(IF &);
>>> virtual void bind(sc_port_b<IF> &);
>>>
>>> The class sc_port would then inherit from sc_port_b. This is just a
>>> standardization (+ virtual keyword) of what is already implemented in
> many
>>> simulators, including the OSCI reference one. Any user that implements

>>> class derived from sc_port will need that sc_port_b class for the same

>>> reason. A perfect example of that are the OSCI TLM 2.0 sockets, that
>>> explictly make use of sc_port_b (see tlm_base_initiator_socket_b and
>>> tlm_base_target_socket_b) to allow binding of sockets with different N

> and
>>> POL parameters, but with matching BUSWIDTH, FW_IF and BW_IF.
>>>
>>>
>>
>>
>
>

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