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 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
--------------------------------------------------------------------------------
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, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.