sc_port, sc_export binding overload and base classes

Hello all,

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.

Regards,

Jerome

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