RE: sc_port, sc_export binding overload and base classes

John,

I reviewed this issue and agree with Jerome's proposal below:

"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 current definition in the LRM of "sc_port<IF, N, POL>::bind( sc_port<IF,N>& )" is not right.

Thanks,
-Bishnupriya

________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Wednesday, October 13, 2010 8:29 PM
To: david.long@doulos.com; Jerome CORNET; systemc-p1666-technical@eda.org
Subject: Re: sc_port, sc_export binding overload and base classes

Jerome, All,

Having looked back through the email trail, I have to agree with Jerome. I think the exclusion of sc_port_b from 1666 was a blind spot on our part. As Jerome says, as 1666 stands, you can only bind ports with the same <N>, which is plain wrong.

Can someone else please take a look at this issue and confirm?

Thanks,

John A

From: Jerome CORNET <jerome.cornet@st.com>
To: john.aynsley@doulos.com
Cc: owner-systemc-p1666-technical@eda.org, david.long@doulos.com, systemc-p1666-technical@eda.org
Date: 12/03/2010 13:17
Subject: 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<mailto: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<mailto:david.long@doulos.com>
To: Jerome CORNET <jerome.cornet@st.com><mailto:jerome.cornet@st.com>
Cc: owner-systemc-p1666-technical@eda.org<mailto:owner-systemc-p1666-technical@eda.org>, systemc-p1666-technical@eda.org<mailto: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<mailto: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<mailto: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<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.