Re: Virtual bind operators

John,

Im fine with the restricted interface for sc_in<T>::bind(). Do we need
to detect explicit calls to the inherited versions?

 sc_port< sc_signal_in_if<int>, 0 > in_multi;
 sc_in<int> in_single;

 // is the following allowed?
 static_cast< sc_port_b< sc_signal_in_if<int> > >
    ( in_single ).bind( in_multi );

Wrt to your second point, I'm not sure, if I understand you correctly.
I still think that the different bind() functions in sc_in<> should be
virtual (and be required to call the method of the base class). This is
more related to user-defined classes derived from sc_in, than actually
using sc_in<> via a base-class pointer.

Thanks,
  Philipp

On 19/10/10 10:27, john.aynsley@doulos.com wrote:
> 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.