Re: sc_port, sc_export binding overload and base classes

John, all,

Agreed on the IEEE norm/OSCI implementation relation, I never meant it
the other way.

I think that outside of the sc_port_b discussion, you agree that there
is a problem with the norm
on the sc_port::bind() and operator() methods argument, that clearly
prevent any strict implementation
to bind ports with compatible interface but different N arguments.
Clearly, the norm should document
something that can be implemented; anyway I saw that this is in your
list of errata.

In addition to the particular example I gave, there is also the need to
be able to manipulate a port object
without taking care of the N and POL template argument, but while taking
care of the IF argument.
A simple example is to be able to enumerate all ports of a given
interface in a SystemC platform and
operate on them (for instance to bind them to a particular module
instance).
In this case it is very desirable to have an intermediate class between
sc_port_base and sc_port, that also contain the bind()
and operator() methods, because there will be at some point a
dynamic_cast<intermediate_port_class<IF> *> occuring.

sc_port_b do exists in many SystemC implementations (not just the OSCI
ones), it could be a good idea at least
be inspired by the actual implementations on this particular topic.

I will also point out that the TLM-2.0 definition (and OSCI
implementation) do also need an intermediate port class
templatized on IF only, and that it also makes use of sc_port_b.

Cheers,

Jerome

On 3/11/2010 6:50 PM, john.aynsley@doulos.com wrote:
> Jerome, All,
>
> Just for background information for those who missed the first 1666
> standardization, you have to realize that the LRM is NOT to be
> considered the documentation for the OSCI simulator. The LRM is
> considered definitive, and the OSCI simulator (which is outside the
> scope of this IEEE group) a proof-of-concept implementation. (Personal
> note: I will fight to make sure that the OSCI simulator stays in line
> with the IEEE standard, but that is outside the scope of the 1666 WG.)
>
> In writing the LRM, there are several places where the class
> definitions differ from the OSCI source code. In particular, we
> deliberately collapsed some base classes into their derived classes,
> considering the actual class hierarchy of the implementation to be
> just an implementation artefact. sc_port_b was one such case.
>
> Cheers,
>
> John A
>
>
>
> From: david.long@doulos.com
> To: Jerome CORNET <jerome.cornet@st.com>
> Cc: owner-systemc-p1666-technical@eda.org,
> systemc-p1666-technical@eda.org
> Date: 03/03/2010 14:57
> Subject: Re: sc_port, sc_export binding overload and base classes
> Sent by: owner-systemc-p1666-technical@eda.org
>
>
> ------------------------------------------------------------------------
>
>
>
> Hi Jerome,
>
> >Maybe you misunderstood me, just have a look at one SystemC
> implementation and class sc_port_b.
>
> OK, I see what you are proposing now. When the current LRM was
> written, there was a pretty strong agreement that sc_port_b was a
> feature of the OSCI implementation, rather than a class that should be
> part of the standard. You are correct that as it stands,
> operator()(sc_port<IF,N>&) in the LRM does not reflect the way that
> the code is implemented in the OSCI distribution or the behaviour
> described in clause 5.11.3. I still think it would be better to find
> an alternative way to define the port-to-port binding methods in the
> LRM rather than adding an additional class but I do not feel strongly
> either way.
>
> Regards,
> Dave
>
>
> --
> Dr David Long
> Senior Consultant
>
> Doulos - Developing Design Know-how
> VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk *
> Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
> 1AW, UK
> Tel: + 44 (0)1425 471223 Email:
> david.long@doulos.com
> Fax: +44 (0)1425 471573 _http://www.doulos.com_ <http://www.doulos.com/>
>
> --------------------------------------------------------------------------------
> Doulos Ltd is registered in England and Wales with company no. 3723454
> Its registered office is 4 Brackley Close, Bournemouth International
> Airport,
> Christchurch, BH23 6SE, UK.
>
> This message may contain personal views which are not the views of
> Doulos, unless specifically stated.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *_MailScanner_* <http://www.mailscanner.info/>,
> and is
> believed to be clean.
>

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