Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by sonalidutta

  1. Hi,


    I want to access the unique process id of a SystemC process P inside process P. Can I do that? If yes, what is the API for that?


    The base class for all sc_process is class sc_process_b. sc_method_process and sc_thread_process are derived from it. sc_process class has a public member variable, called proc_id. This denotes the unique id of a process.


    My question is how to access this id inside the process itself. For example:


    Inside process P:


    std::cout << proc_id << std::endl;


    does not work!





    An assertion is an LTL formula with a set of sampling points that describes a formal property of your SystemC model under verification. In Assertion-based Dynamic Verification of SystemC models, each assertion is converted to a C++ monitor class. A C++ monitor class is just a C++ encoding of a deterministic finite automaton. The transition function of the DFA is encoded as a step() function in the monitor class.


    Now the question is when and how frequently to execute the step() function of a monitor class. This is where the sampling points come into the picture. You execute the step() function only when any of the specified set of sampling points occur during your simulation. In the above dissertation, it allows you to sample at different phases of the SystemC kernel, for example: when a new delta cycle begins, when a particular event is notified by the kernel or when a SystemC process suspends. This cannot be done with the unmodified version of the SystemC kernel since all these kernel informations are hidden from the user. So in the above work, the author puts a minimal patch on the SystemC kernel to expose the necessary kernel information.


    But this is not mandatory. You can also only sample at different points in your user model. For that you do not need to modify the SystemC kernel. But allowing sampling also at kernel phases adds to the monitoring power. So as a summary, it is not necessary to change the kernel to do assertion-based verification of SystemC. But since in SystemC (unlike SystemVerilog), the kernel plays a very important role in the simulation, if you change the kernel to expose certain information, it might be useful.


    Universal Verification Methodology (UVM) is a new "de-facto standard" for verification (based on Accellera's marketing materials) (Primer here: http://www.doulos.com/knowhow/sysverilog/uvm/tutorial_0/). UVM is a base class library for hooking up monitors and generating tests, but does not do anything about Kernel events or about generating monitors.

  3. Dear Alan,


    Thanks for you reply. I would like to see some example how to use SCV_EXTENSIONS_BASE_CLASS macro. The scv package or the manual doe not have any example.


    Also I want to do the following:


    1. Define a base class A.


    2. Define two classes B, C derived from A.


    3. I want to track the value changes of the member variables of class B and C. - So I need to define scv_extensions for them.


    4. Now I want to use polymorphism: use base class point A* to point derived class objects new B() and new C(). Also I want to define function f(A* a) that actually receives objects of type B and C and determines in the runtime what kind of object it is. It finally does type cast on a as: (B*)a or (C*)a to use methods defined in B or C.


    I wonder if this kind of polymorphism is doable with scv_smart_pointer<A>, scv_smart_pointer<B> , scv_smart_pointer<C>. It will be really helpful if I can see some example about the syntax and everything. The manual really doe snot show anything. I also have gone through all the example programs scv package provides.


    Can you let me know whom I can talk to regarding this in the developer's group?




  4. Companies like Intel, TI, Cadence, Synopsys are working actively on different SystemC projects, mainly using it to build firmware, hardware system prototypes to develop the software etc. 


    Also SystemC is still in research phase. The best deal is to work on some industrial project or in some research lab. Institutions having interesting SystemC projects to work on are hard to find, especially in India.

  5. Here is a few general questions about the limitations SCV might have:


    1. Hierarchical Types:


    To use scv_smart_ptr of class A, I need to define SCV_EXTENSIONS(A). Now suppose, class A is a subclass of class B.


    For example:


    class B{


    int attB1;


    int attB2;




    class A: public class B{


    int attA1;


    std::string attA2;




    Now how do I define SCV_EXTENSIONS(A)? Does SCV support this? Do I need to define SCV_EXTENSIONS( B ) too?


    2. C++ library types: std::vector, std::list, std::map ...


    SCV has already defined SCV_EXTENSIONS template class for C++ built-in types like int, float etc and also some systemC built-in types. That means we can create variables of type scv_smart_ptr<int> or scv_smart_ptr<float> etc.


    But can I create variable of type scv_smart_ptr<std::map> or scv_smart_ptr<std::list> or scv_smart_ptr<std::vector> etc? Is SCV_EXTENSIONS template class already defined for them or do I need to define it as I did for class A?




  6. Dear Alan,


    Thanks for the quick reply.


    I want to use SCV to call a callback function f() whenever any member variable of an object "a" of class A will be written a new value. Also f() will use the object "a" inside it.


    My guess is that I can take any of the following two approaches:


    Approach 1.

          - define SCV_EXTENSIONS(A).

          - instantiate a as:   scv_smart_ptr<A> a;

          - define callback function f() as:  

                   void f(scv_extensions_if& a_ext, scv_extensions_if::callback_reason r) {

                              if ( r == scv_extensions_if::VALUE_CHANGE) { //Use a_ext to do some operation


          - register callback f() to a as    a->register_cb(f)


    My question here is:

        1. How can I get a from a_ext? I need the object of type A or something similar inside f().


    Approach 2:

         - define each member variables "v" of A as scv_smart_ptr.

        - register callback f() with each of them in the constructor of A. The manual has an example on Page 46.


    My question here is:

        1. I like this approach better. But is there any way to get hold of object "a" inside callback f(). The object which is passed to it is a->v, not a. I need a.


    Does it mean I need to use approach 1? Or is there any other way?




  7. SystemC kernel simulates parallel execution of hardware. Processes suspends and resumes. A process can suspend itself and wait for an event to take place. When the event happens, that process resumes its execution. This is the most important power of SystemC. You cannot gain this advantage using flags, even inside the same module.

  8. Dear Alan,


    I installed fresh systemc-2.3.0 in /root/Desktop/systemc-2.3.0


    [root@localhost systemc-2.3.0]# pwd

    In Desktop I have created hello_world.cpp


    Now I run:

    [root@localhost Desktop]# g++ -I /root/Desktop/systemc2.3.0/include/ -L /root/Desktop/systemc2.3.0/lib-linux64/  -Xlinker -rpath -Xlinker /root/Desktop/systemc2.3.0/lib-linux64/ hello_world.cpp -lsystemc
    hello_world.cpp:1:21: error: systemc.h: No such file or directory
    hello_world.cpp:3: error: expected constructor, destructor, or type conversion before ‘(’ token



    But my adder model is running using it.


    The thing I observerd that the behavior of systemc-2.3.0 in terms of setting LD_LIBRARY_PATH automnatically is completely unpredictable. Sometimes it does, sometimes it does not.


    I installed the fresh systemc-2.3.0 1bout 8 times. Only 2 times it did not give the LD_LIBRARY_PATH issue and my systemc model ran fine.


    So it is not about my modification. As you pointed out correctly, there is some problem in systemc-2.3.0 itself. Can you report a bug?


    Also I am running as root. So it does not work for root user too!


    Regarding /etc/ld.so:


    There is a file called ld.so.conf and a directory callled ld.so.conf.d.


    But there is no file called ld.so


    And there is nothing added in any of these file.




  9. Alan,


    I changed the name from modified_systemc-2.3.0 to systemc-2.3.0 and reinstalled. But I still has the same issue. As you said I did:


    ldd addy and here is what I get:


    [root@localhost adders1]# ldd addy
            linux-vdso.so.1 =>  (0x00007fffefb72000)
            libsystemc-2.3.0.so => not found
            libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000032b3600000)
            libm.so.6 => /lib64/libm.so.6 (0x00002b666f186000)
            libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000032aee00000)
            libc.so.6 => /lib64/libc.so.6 (0x00002b666f409000)
            /lib64/ld-linux-x86-64.so.2 (0x00002b666ef68000)


    This is my installation path:


    [root@localhost lib-linux64]# pwd
    [root@localhost lib-linux64]# ls
    libsystemc-2.3.0.so  libsystemc.a  libsystemc.la  libsystemc.so
    [root@localhost lib-linux64]#

    As you can see, libsystemc-2.3.0.so exists!

  10. Here is my analysis:


    In you look at systemc-2.3.0/configure:


    you will see some variables are set in there:





    And there are many others like this. Search configure file for "systemc" and you will find them.


    My guess is that these variables are being used to setup default LD_LIBRARY_PATH. Since I have changed the package name from systemc-2.3.0 to modified_systemc-2.3.0, the default path does not work for me anymore. I will run some experiments now to see if I am right.




  11. Thank you for replying.



    There should be no confusion about LD_LIBRARY_PATH. It is a Linux runtime

    environment variable, to be set right before the simulation is executed. We do

    the following on a Fedora 17 machine.

    To compile:

    g++ -I. -I<absolute or relative path to SystemC 2.3.0 library/include -L.

    -L<absolute or relative path to SystemC 2.3.0 library/lib-linux -o

    <name of simulation executable> <SystemC executable source file name>

    -lsystemc -lm



    If you look at the Makefile in my earlier post I do the same thing.


    Provided the compilation step does not produce any errors, set the runtime

    environment variable, by first finding out the Linux shell being used:

    on bash shell:

    export LD_LIBRARY_PATH=<absolute or relative path to SystemC 2.3.0 library/lib-linux

    Now execute the simulation,



    This is what I do not want to do. Why do I need to export it explicitly? I do not need to do with systems-2.3.0. I only need it with my modified version modified_systemc-2.3.0.


    All of this is if SELinux is not activated, in which case it has to be de-activated

    temporarily(for duration of simulation) in the root/super user mode, by using the

    Linux ssyetm command 'setenforce'.

    Hope that helps.

  12. Hi Sonali,

      as an experiment I installed systemc-2.3.0 in my own directory. I then removed all references to Systemc LD_LIBRARY_PATH.  I then also

    get a linker error like yours.


    That's why I'm wondering why you do *not* get a linker error with your main build.


    My guess is that I have both systems-2.3.0 and modified_systemc-2.3.0 in the same path. So the linker by default finds the .so files in systemc-2.3.0/lib-linux64 and it does not complain. 


    But the adder Makefile points to the modified_systemc-2.3.0 and that is when it gives error.

    If you look in lib-linux64, do you see libsystemc.so and libsystemc.a for both your builds?





    Can you build a simple example using

    g++ -I/home/apf/systemc2.3.0/include/ -L/home/apf/systemc2.3.0/lib-linux64/  -Xlinker -rpath -Xlinker /home/apf/systemc2.3.0/lib-linux64/ hello_world.cpp -lsystemc

    Obviously change all the paths to point to your normal and modified SystemC distribution.


    Here's my little "hello world" program


    #include "systemc.h"
    SC_MODULE(Test) {
      void proc() {
        while (true) {
          cout << sc_time_stamp() << endl;
          wait(10, SC_NS);
      SC_CTOR(Test) {
    int sc_main(int argc, char ** argv) {
      Test t("t");
      sc_start(100, SC_NS);
      return 0;







     I will try this and let you know Alan. Thanks.

  13. Dear Alan,
    Thank you for your response.
    Unmodified systemc-2.3.0 automatically sets LD_LIBRARY_PATH. I did grep -r "systemc-2.3.0" * in uninstalled systemc-2.3.0 package to identify the potential place where I need to modify to set LD_LIBRARY_PATH automatically in my modified version of systemc-2.3.0. Here is the result:
    [root@localhost systemc-2.3.0]# grep -r "systemc-2.3.0" *
    examples/tlm/build-msvc/Makefile.config:SYSTEMC = C:\SystemC\systemc-2.3.0\msvc80
    examples/tlm/build-msvc/systemc.vsprops:                Value="C:\SystemC\systemc-2.3.0\msvc71"
    examples/tlm/build-msvc/MakefileVC9.config:SYSTEMC = C:\SystemC\systemc-2.3.0\msvc90
    examples/tlm/build-msvc/MakefileVC7.config:SYSTEMC = C:\SystemC\systemc-2.3.0\msvc71
    examples/tlm/build-unix/Makefile.config:SYSTEMC_HOME        ?= /usr/local/systemc-2.3.0
    examples/sysc/Readme_msvc80.txt:installation (e.g. C:\systemc-2.3.0\msvc80).
    INSTALL:  1. Change to the top level directory (systemc-2.3.0)
    INSTALL:     top level directory (systemc-2.3.0), configure the package e.g. as
    INSTALL:        > ../configure --prefix=/usr/local/systemc-2.3.0
    INSTALL:3. Select the 'New' icon and browse to: C:\systemc-2.3.0\msvc80\systemc\debug
    INSTALL:5. Select the 'New' icon and browse to: C:\systemc-2.3.0\src
    INSTALL:   the SystemC library:   ...\systemc-2.3.0\msvc80\systemc\debug'systemc.lib'

    I do not think modifying any of the above will solve my issue.
    Also regarding the Makefile I am using to run my adder model, I am not using -rpath or -WI. As you can see in my attached Makefile:
    I only modify the path of SYSTEMC_HOME that gets added to INCLUDE_DIRS and LIBRARY_DIRS. Please have a look at my Makefile.
    My guess is something I did not do (that I should have done!) while installing the modified systemc-2.3.0.
    I did autoconf anf automake.
    May be I need aclocal too! But aclocal gives me errors! So I did not do it.
    Any insight?




    It does not let me upload my Makefile. So I sopy paste it here:






    withobserver =     no
    usemonitor0 =     no    # automatically generated safety

    CC=        time /usr/bin/g++
    TARGET_ARCH =     linux64

    FLAGS = -O3 -w -Wno-deprecated \
            -D_VERBOSE_GLOBAL \

    VPATH =        /root/Desktop/CHIMP_ea/adders1

    CUSTOM_LOCAL =     /usr/local
    #SYSTEMC_HOME =    /root/Desktop/CHIMP_ea/systemc_with_modifications/systemc-2.2.0
    SYSTEMC_HOME = /root/Desktop/CHIMP_ea/patched_systemc-2.3.0
    #SYSTEMC_HOME = /root/Desktop/CHIMP_ea/systemc-2.3.0

    ## Include directories
    INCLUDE_DIRS =     $(SYSTEMC_HOME)/include ./ $(VPATH)


    ## Library directories


    ## SystemC static library
    LIB_SC = -lsystemc \

    ## Other static libraries

    LIBS = $(LIBDIR) $(LIB_SC) $(LIB_OTHERS:%=-l%)


    ## Example .cc files
    SRCS = $(wildcard ./*.cc )
    HDRS = $(wildcard ./*.h  )
    OBJS = adder.o debug_printer.o  driver.o  main.o

    # Optional flags depending on the monitors we want to turn on/off
    ifeq ($(withobserver), yes)

    ifeq ($(strip $(usemonitor0)), yes)
    OBJS += monitor.o
    MAIN_DEPS += monitor.cc

    addy: $(OBJS) $(HDRS)
        $(CC) -o addy $(OBJS) $(LIBS)

    main.o: main.cc $(HDRS) Makefile $(MAIN_DEPS)

        find . -name '*.[cc|c|h]' | xargs etags
        find $(INCLUDE_DIRS) -name '*.[cc|c|h]' | xargs etags -a

        @echo $(HDRS)

    #Standard Makefile stuff

        $(CC) $(CFLAGS) -c $<

        $(CC) $(CFLAGS) $(CPPFLAGS) -c $<

        $(CC) $(CFLAGS) -c $< -o $@


    distclean: clean
        /bin/rm -f \#* addy

        lint *.c

    REMOVE = /bin/rm -f *~ .*~ *.BAK .*.BAK *.o logfile

    #Standard Makefile stuff


  14. Hi,


    I am working on Assertion Based Dynamic Verification of SystemC models. To expose some states of the kernel to the runtime monitors I am doing some minimal modification to the SystemC-2.3.0 kernel.



    I added 4 new files:




    I also did some minimal modification(adding callbacks) to:






    I did the required modification to : systemc-2.3.0/src/systemc.



    For installation I modified:


    1. /systemc-2.3.0/src/sysc/kernel/Makefile.am to add the new 4 files I have added to kernel (see above for detail)

    2. /systemc-2.3.0/configure.in to add a new flag called -DDEBUG_PRINT_IN_SCHEDULER


    Now I ran:

    autoconf: This takes aclocal.m4 and configure.in as input and generates ./configure file as output.

    automake: This takes configure.in and Makefile.am as input and generates Makefile.in as output.


    Now I follow the steps in INSTALL file for the rest of the installation process.


    The modified systemC got installed successfully at: modified_systemc-2.3.0/


    Now I try to run a small systemC model adder using this modified SystemC. When I compile adder model with modified_systemc-2.3.0, it compiles without any warning or error. But when I run it, it gives me the following error:


    #  ./addy

    ./addy: error while loading shared libraries: libsystemc-2.3.0.so: cannot open shared object file: No such file or directory.


    But libsystemc-2.3.0.so is there at /modified_systemc-2.3.0/lib-linux64/libsystemc-2.3.0.so


    So I got the following workaround:



    # LD_LIBRARY_PATH=modified_systemc-2.3.0/lib-linux64

    # export LD_LIBRARY_PATH


    And now if I run ./addy, it runs fine.


    This problem does not occur while running ./addy using unmodified version of SystemC 2.3.0. My guess is that I missed setting some default path while modifying the systemc-2.3.0. So the paths that should be set by default is not set be default and need manual setting.


    Does anyone have any idea how I can fix it?


    Thanks and Regards


  15. Hi,


    Let us consider the following example:


    sc_event a, b;




           sensitive << a << b;



    My question is process p here is statically sensitive to (a and b ) OR (a or b )?


    I went through the relevant parts of 1666-2011_systemc_manual.pdf. But still I did not find the exact answer.


    If anyone knows the answer, it will be great!




  16. Hi Philipp,


    Yes. I ran ../configure before gmake. :)


    Probably you are right! But I will move on since everything is working now. Thanks for your help.


    I appreciate that you pointed out about the parameters of aclocal specifically -I config. Something I got to learn! So dealing with these nasty errors sometimes gives you valuable knowledge. Not that bad!




  17. Hi Philipp,


    Thanks for the reply.


    But autoreconf basically does nothing extra than running aclocal, automake and autoconf individually. But as you said, I tried to recreate the error. Here is what I did:


    1. I deleted autoconf-1.10 from my system using make distclean

    2. I installed autoconf-1.10.1

    3. Now I took a fresh systemc-2.3.0(configure.in and /src/sysc/kernel/Makefile.am modified)

    4. I ran autoreconf -v -i


    Here is the output:


    [root@localhost test]# autoreconf -v -i
    autoreconf: Entering directory `.'
    autoreconf: configure.in: not using Gettext
    autoreconf: running: aclocal -I config
    autoreconf: configure.in: tracing
    autoreconf: running: libtoolize --copy
    autoreconf: running: /usr/local/bin/autoconf
    autoreconf: configure.in: not using Autoheader
    autoreconf: running: automake --add-missing --copy --no-force
    autoreconf: Leaving directory `.'


    5. mkdir objdir


    6. cd objdir


    7. gmake


    [root@localhost objdir]# gmake
    Making all in src
    gmake[1]: Entering directory `/root/Desktop/CHIMP_ea/test/objdir/src'
    Making all in sysc
    gmake[2]: Entering directory `/root/Desktop/CHIMP_ea/test/objdir/src/sysc'
    Making all in kernel
    gmake[3]: Entering directory `/root/Desktop/CHIMP_ea/test/objdir/src/sysc/kernel'
    /bin/sh ../../../libtool --tag=CXX   --mode=compile g++ -DSC_INCLUDE_FX   -I. -I../../../../src/sysc/kernel -I../../../../src   -Wall -m64 -DSC_INCLUDE_FX -DDEBUG_PRINT_IN_SCHEDULER  -O3 -pthread -Wall -m64 -DSC_INCLUDE_FX -DDEBUG_PRINT_IN_SCHEDULER -O3 -MT sc_attribute.lo -MD -MP -MF .deps/sc_attribute.Tpo -c -o sc_attribute.lo ../../../../src/sysc/kernel/sc_attribute.cpp
    ../../../libtool: line 2089: ../../../../src/sysc/kernel/sc_attribute.cpp: Permission denied
    libtool: compile:  g++ -DSC_INCLUDE_FX -I. -I../../../../src/sysc/kernel -I../../../../src -Wall -m64 -DSC_INCLUDE_FX -DDEBUG_PRINT_IN_SCHEDULER -O3 -pthread -Wall -m64 -DSC_INCLUDE_FX -DDEBUG_PRINT_IN_SCHEDULER -O3 -MT sc_attribute.lo -MD -MP -MF .deps/sc_attribute.Tpo -c ""  -fPIC -DPIC -o .libs/sc_attribute.o

    g++: : No such file or directory
    g++: no input files
    gmake[3]: *** [sc_attribute.lo] Error 1
    gmake[3]: Leaving directory `/root/Desktop/CHIMP_ea/test/objdir/src/sysc/kernel'
    gmake[2]: *** [all-recursive] Error 1
    gmake[2]: Leaving directory `/root/Desktop/CHIMP_ea/test/objdir/src/sysc'
    gmake[1]: *** [all-recursive] Error 1
    gmake[1]: Leaving directory `/root/Desktop/CHIMP_ea/test/objdir/src'
    gmake: *** [all-recursive] Error 1


    I see no reason why g++ cannot read sc_attribute.cpp. I hope this helps.




  18. Dear Developer,


    Here is the solution.


    For installation I modified:


    1. /systemc-2.3.0/src/sysc/kernel/Makefile.am to add the new 4 files I have added to kernel (see above for detail)

    2. /systemc-2.3.0/configure.in to add a new flag called -DDEBUG_PRINT_IN_SCHEDULER


    Now I ran:


    autoconf: This takes aclocal.m4 and configure.in as input and generates ./configure file as output.

    automake: This takes configure.in and Makefile.am as input and generates Makefile.in as output.


    Now I follow the steps in INSTALL file for the rest of the installation process.


    I must mention here that systemc-2.3.0 package is not able to deal with any versions other than





    If I use other higher versions I need to do aclocal again to regenerate aclocal.m4 and that's when gmake gives wierd errors.


     For example:

    /bin/sh ../../../libtool --tag=CXX   --mode=compile g++ -DSC_INCLUDE_FX   -I. -I../../../../src/sysc/kernel -I../../../../src   -Wall -m64 -DSC_INCLUDE_FX -DDEBUG_PRINT_IN_SCHEDULER  -O3  -Wall -m64 -DSC_INCLUDE_FX -DDEBUG_PRINT_IN_SCHEDULER -O3 -MT sc_attribute.lo -MD -MP -MF .deps/sc_attribute.Tpo -c -o sc_attribute.lo ../../../../src/sysc/kernel/sc_attribute.cpp
    mv -f .deps/sc_attribute.Tpo .deps/sc_attribute.Plo
    mv: cannot stat `.deps/sc_attribute.Tpo': No such file or directory


    I do not know if it is some issue with the packaging or something else. It will be good if anyone from the developer group sheds some light on it.


    But using the above versions of automake and autoconf, the problem is solved!




  • Create New...