Skip Nav
Home » Forums » SystemC Forum

Icon - KMLM List KMLM List

View email archives for the history of this mailing list.

List Home All Archives Dates Threads Authors Subjects
systemc-forum - RE: [systemc-forum] simcontext error Message Thread: Previous | Next
  • To: "Bradley, Mike" <mike_bradley@xxxxxxxxxx>, "yoman yoman" <saynotosystemc@xxxxxxxxx>
  • From: "Bradley, Mike" <mike_bradley@xxxxxxxxxx>
  • Date: Wed, 27 Oct 2010 02:42:40 -0600
  • Cc: "Philipp A. Hartmann" <philipp.hartmann@xxxxxxxx>, <systemc-forum@xxxxxxxxxxxxxxxxx>
Send Email to systemc-forum@lists.systemc.org:
Send new message
Reply to this message
Ø  Also, not sure about your solution below; seems like "father<...>::" would 
better be replaced by "this->"

 

Sorry, misread that these are declarations, not calls, please disregard....

 

From: systemc-forum@xxxxxxxxxxxxxxxxx [mailto:systemc-forum@xxxxxxxxxxxxxxxxx] ;
On Behalf Of Bradley, Mike
Sent: Wednesday, October 27, 2010 4:40 AM
To: yoman yoman
Cc: Philipp A. Hartmann; systemc-forum@xxxxxxxxxxxxxxxxx
Subject: RE: [systemc-forum] simcontext error

 

Hi,

 

I think actually you may be better off not having father/mother derived from 
sc_module.  Just have traffic_generator inherit from sc_module.

 

Also, not sure about your solution below; seems like "father<...>::" would 
better be replaced by "this->"

 

-Mike

 

From: yoman yoman [mailto:saynotosystemc@xxxxxxxxx] ;
Sent: Wednesday, October 27, 2010 4:35 AM
To: Bradley, Mike
Cc: Philipp A. Hartmann; systemc-forum@xxxxxxxxxxxxxxxxx
Subject: Re: [systemc-forum] simcontext error

 

Hi Phillip/Mike,

 

Thanks for the reply. Firstly i'll like to apologise for wrong constructor call 
for father class that happened in just copy-pasting. I'm using 
gcc_3.4.3/gcc_4.1.1 and syc - OSCI_2.1/OSCI_2.2.0 and ius versions.

 

Well the way you told, error is eleiminated for simcontext and dont_initialize 
but not for sensitive. For sensitive i've to do declaration in the class as i 
did for simcontext.

 

 father<DATA_BUS_WIDTH_BYTES>::sensitive;

 father<DATA_BUS_WIDTH_BYTES>::sensitive_pos;

 father<DATA_BUS_WIDTH_BYTES>::sensitive_neg;

 

but these declarations need to be done in the class and not constructor.

 

i'll like to further extend my Q. Say I've another templated sc_module mother. 
Now both of these classes are virtually derived from sc_module and my 
traffic_generator is derived from both mother and father. Now in 
tarffic_generator class do I need to have above declarations both for father 
and mother classes or having only for one of them will do. 

 

I tried to compile both ways. Although it got compiled and run either way but I 
want to know what is logically correct way ?

 

Thanks. 

On Wed, Oct 27, 2010 at 1:05 PM, Bradley, Mike <mike_bradley@xxxxxxxxxx> wrote:

Hi,

Perhaps not as elegant; but also virtually deriving traffic_generator from 
sc_module also works:

Change   class traffic_generator :public father<DATA_BUS_WIDTH_BYTES>
To       class traffic_generator :public father<DATA_BUS_WIDTH_BYTES> , virtual 
sc_module

Or, I should say, no error message is generated...

-Mike




-----Original Message-----
From: systemc-forum@xxxxxxxxxxxxxxxxx [mailto:systemc-forum@xxxxxxxxxxxxxxxxx] ;
On Behalf Of Philipp A. Hartmann
Sent: Wednesday, October 27, 2010 3:15 AM
To: yoman yoman
Cc: systemc-forum@xxxxxxxxxxxxxxxxx
Subject: Re: [systemc-forum] simcontext error

On 27/10/10 08:00, yoman yoman wrote:
>
> I've a small module containing only one .h file. Contents of it are as
> below:

(Parts of) your problem should have been fixed in SystemC 2.2.0, the current 
stable version of OSCI's SystemC reference implementation.  You should consider 
to switch to this version, since this is not the only fix ...

Some further comments below.

> ************************************************
>
>
> #ifndef _TRAFFIC_GENERATOR_
> #define _TRAFFIC_GENERATOR_

You should not start your #include guards with a leading underscore.
Names starting with an underscore and are followed by a capital letter or 
another underscore are reserved to the C++ implementation.

> #include "systemc.h"
>
> template <unsigned int DATA_BUS_WIDTH_BYTES> class father:public
> sc_module {
>
> public:
>
> father(){}
>
> virtual void father_func(void)=0;
>
> };

Note, that you have a class template, that is used as a base class.

> template <unsigned int DATA_BUS_WIDTH_BYTES, unsigned int
> ID_WIDTH_BYTES> class traffic_generator :public
> father<DATA_BUS_WIDTH_BYTES> {

Here, you inherit from said templated base class in another class template.  
The compiler can't know yet (due to specialisations), what members or contents 
this base class template has.

> public:
>
> SC_HAS_PROCESS(traffic_generator);
>
> traffic_generator(sc_module_name name):
>
> sc_module(name),

This is invalid C++.  sc_module is not a direct base class of 
traffic_generator.  You can't invoke its constructor here.

> father<DATA_BUS_WIDTH_BYTES>("FATHER",2),

father<...> has no constructor taking two parameters.
You should not post code, that you haven't tried if its actually showing your 
problem...

> ACLK("ACLK"),

It's common coding style to reserve all-uppercase names to macros.

> ARESETn("ARESETn"){
>
> SC_THREAD( do_transaction );

The "simcontext" related error is somewhere hidden behind this macro.
As said above, this macro is fixed in the current public stable version.

> sensitive<<ACLK<<ARESETn;
> dont_initialize();

The same problems would occur with these two lines, though.
The cause for your error is the resolution of dependent names by your compiler. 
 See
http://www.parashift.com/c++-faq-lite/templates.html#faq-35.19 for an ;
explanation.

For sensitive and dont_initialize, you can fix this by prepending "this->" to 
the calls to make them template-dependent.

 For the 'simcontext'-related error, you should switch to SystemC 2.2.0.  If 
that's not possible, you can add

using father<DATA_BUS_WIDTH_BYTES>::simcontext;

to your class (or to the constructor before the SC_THREAD call).

Greetings from Oldenburg,
 Philipp


>
> }

> void end_of_elaboration(void){
>
> }
>
> void father_func(void){}
>
> ~traffic_generator(void) {}
>
> void do_transaction( void) {
>
> }
>
> public:
>
> sc_in < bool > ACLK;
>
> sc_in < bool > ARESETn;
>
> unsigned count;
>
> };
>
> #endif // _TRAFFIC_GENERATOR_
>
> *******************************************************************
>
> This code gets compiled with gcc_3.2.3 wbut with gcc_3.4.3 and higher
> versions it gives following error:
>
>
>
> **********************************************************************
> **
>
> In file included from src/main.cpp:1:
> /data/abc/users/aknis/SOCD/plt/top/include/traffic_generator.h: In
> constructor `traffic_generator<DATA_BUS_WIDTH_BYTES,
> ID_WIDTH_BYTES>::traffic_generator(sc_core::sc_module_name)':
> /data/abc/users/aknis/SOCD/plt/top/include/traffic_generator.h:21: error:
> there are no arguments to `simcontext' that depend on a template
> parameter, so a declaration of `simcontext' must be available
> /data/abc/users/aknis/SOCD/plt/top/include/traffic_generator.h:21: error:
> (if you use `-fpermissive', G++ will accept your code, but allowing
> the use of an undeclared name is deprecated)
> /data/abc/users/aknis/SOCD/plt/top/include/traffic_generator.h:21: error:
> `sensitive' undeclared (first use this function)
> /data/abc/users/aknis/SOCD/plt/top/include/traffic_generator.h:21: error:
> (Each undeclared identifier is reported only once for each function it
> appears in.)
> /data/abc/users/aknis/SOCD/plt/top/include/traffic_generator.h:21: error:
> `sensitive_pos' undeclared (first use this function)
> /data/abc/users/aknis/SOCD/plt/top/include/traffic_generator.h:21: error:
> `sensitive_neg' undeclared (first use this function)
> /data/abc/users/aknis/SOCD/plt/top/include/traffic_generator.h:23: error:
> there are no arguments to `dont_initialize' that depend on a template
> parameter, so a declaration of `dont_initialize' must be available
> make[1]: *** [obj/main.o] Error 1
> make[1]: Leaving directory
> `/data/abc/users/aknis/AKNIS/SocD_20Oct_7_6/build_exmp_new_27oct/plt/top'
> make: *** [everything] Error 2
> Exit 2
> **********************************************************************
> *****************
>
> can any one pls tell me why this error is coming and what is the
> solution for it ??
>
> Thanks in Advance for your time.
>


--
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/

 


By Date: Previous | Next Current Thread By Thread: Previous | Next