Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything 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! Thanks Sonali
  2. In http://www.cs.rice.edu/CS/Verification/Theses/Archive/dtabakov_dissertation2010.pdf: 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? Regards Sonali
  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. This is an empty post. Not able to delete it.
  6. 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{ public: int attB1; protected: int attB2; ... }; class A: public class B{ public: int attA1; private: 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? Thanks Sonali
  7. 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? Thanks Sonali
  8. I would suggest you to read the systemC manual A to Z. It is very well-written. It is more like a book than manual. I learned it in that way. Also http://emedia.art.sunysb.edu/debt/downloads/books/System%20Design%20with%20SystemC.pdf is a good book for the initial stage.
  9. 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.
  10. You cannot use blocking calls in SC_METHOD process. If you really need to use it, use SC_THREAD process instead. SC_THREAD has all the expressive powers that SC_METHOD has.
  11. Dear all, I have some questions about usage of SCV. Is it the right place to post them? Thanks Sonali
  12. Dear Alan, I installed fresh systemc-2.3.0 in /root/Desktop/systemc-2.3.0 [root@localhost systemc-2.3.0]# pwd /root/Desktop/systemc-2.3.0 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 Wierd!!! 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. Thanks Sonali
  13. 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/Desktop/CHIMP_ea/systemc-2.3.0/lib-linux64 [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!
  14. Here is my analysis: In you look at systemc-2.3.0/configure: you will see some variables are set in there: PACKAGE=systemc VERSION=2.3.0 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. Regards Sonali
  15. Thank you for replying. If you look at the Makefile in my earlier post I do the same thing. 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.
  16. 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. Yes. I will try this and let you know Alan. Thanks.
  17. Hi, This was just a toy example. I was going through SystemC manual and had this doubt.
  18. 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? Thanks Sonali 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 \ -DSC_INCLUDE_DYNAMIC_PROCESSES \ -D_VERBOSE_GLOBAL \ -D_MONITOR_REPORT_FAIL_IMMEDIATELY \ -D_MONITOR_REPORT_PASS_IMMEDIATELY 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) INCDIR = $(INCLUDE_DIRS:%=-I %) ## Library directories LIBRARY_DIRS = $(SYSTEMC_HOME)/lib-$(TARGET_ARCH) LIBDIR = $(LIBRARY_DIRS:%=-L %) ## SystemC static library LIB_SC = -lsystemc \ ## Other static libraries LIB_OTHERS = LIBS = $(LIBDIR) $(LIB_SC) $(LIB_OTHERS:%=-l%) CFLAGS = $(FLAGS) $(INCDIR) ## 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) FLAGS += -DWITH_OBSERVER endif ifeq ($(strip $(usemonitor0)), yes) FLAGS += -DMONITOR_0 OBJS += monitor.o MAIN_DEPS += monitor.cc endif addy: $(OBJS) $(HDRS) $(CC) -o addy $(OBJS) $(LIBS) main.o: main.cc $(HDRS) Makefile $(MAIN_DEPS) etags: find . -name '*.[cc|c|h]' | xargs etags find $(INCLUDE_DIRS) -name '*.[cc|c|h]' | xargs etags -a check: @echo $(HDRS) #&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& #Standard Makefile stuff .cpp.o: $(CC) $(CFLAGS) -c $< .c.o: $(CC) $(CFLAGS) $(CPPFLAGS) -c $< .cc.o: $(CC) $(CFLAGS) -c $< -o $@ clean: $(REMOVE) distclean: clean /bin/rm -f \#* addy lint: lint *.c REMOVE = /bin/rm -f *~ .*~ *.BAK .*.BAK *.o logfile #Standard Makefile stuff #&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
  19. 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: mon_prototype.cpp/h mon_observer.cpp/h I also did some minimal modification(adding callbacks) to: sc_event.cpp/h sc_sim_context.cpp/h sc_object.cpp/h sc_thread_process.h 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 Sonali
  20. Hi, Let us consider the following example: sc_event a, b; .... SC_CTOR(...){ SC_THREAD(p); 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! Thanks Sonali
  21. 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! Thanks Sonali
  22. 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. Regards Sonali
  23. Thanks Alan. It will be really great at least for the beginners like me. I hate to spend time on fixing this kind of issues.
  24. 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 automake-1.10 autoconf-2.61 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! Regards Sonali
  • Create New...