Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by AmeyaVS

  1. AmeyaVS

    clocks in tlm

    Hello @shubham_v, This new post does not contribute anything new or relevant to the previous discussion. As already the answers and resources provided by @David Black and @Eyck, have sufficient details. It looks as if you want to get your homework done by forum members. Can you at least put an effort to showcase what you have implemented till now? and also where you are stuck so that forum members can help you out with some more suggestions. Regards, Ameya Vikram Singh
  2. Hello @aarone, Can you provide the initial logs from the SystemC kernel about the VCD timescale setting. Probably you are using the default VCD timescale, also the Warning itself is providing an insight that you need to revise the VCD timescale resolution. Hope it helps. Regards, Ameya Vikram Singh
  3. AmeyaVS


    Hello @charan, This is quite bold to copy the dll's into the systems core directory. It is usually a bad practice. Can you provide your build environment setup details(compilers, etc.)? Regards, Ameya Vikram Singh
  4. Hello @shoji, Can you share a small example?, where it can be reproduced easily. That would help in narrowing down the issue. Regards, Ameya Vikram Singh
  5. AmeyaVS

    Communication between multiple modules

    Hello @Jenkki_Menthol, The provided pseudo code and the description is not clear enough to provide any useful suggestions. Can you elaborate more on the exact problem statement probably with some very generic code to help you with some suggestions further? Regards, Ameya Vikram Singh
  6. Hello @chatbq, There is not enough context, probably the exception is being thrown from another module. Overall the code seems fine. You can try and see from where the exception is being thrown from the debugger. Regards, Ameya Vikram Singh
  7. AmeyaVS

    Error in "make check" Cygwin

    Hello @egroj97, This is a known issue on Cygwin(64-bit) with QuickThreads. You need to pass the command-line option: "--enable-pthreads" to the configure script. Kindly refer the discussion about this here: On another note running applications built from source on Cygwin(64-bit) it much slower than running then on native Linux even within a VM. If you have Windows 10 with WSL(Windows Subsystem for Linux) then you could probably try that route to build and install the SystemC library. But I have not tried that out myself, and currently I do not see it being supported/validated by the working group. Anyway it will be nice to know if the library is functional on top of WSL. Hope this helps. Regards, Ameya Vikram Singh
  8. Hello @katang, Here is a snippet from the SystemC release 2.3.3 file:(cmake/INSTALL_USING_CMAKE) containing reference to CMAKE_INSTALL_PREFIX CMAKE_INSTALL_PREFIX Root directory of the SystemC libraries installation (defaults to $ENV{SYSTEMC_HOME} if set to an absolute path and otherwise to either /opt/systemc/ (Unix-like platforms including CYGWIN), $ENV{ProgramFiles}/SystemC/ (on Windows systems), or ${CMAKE_INSTALL_PREFIX}/systemc. Anyway manually installing third party or other libraries in system path(like /usr or other path) is not advisable. I usually setup libraries/tools in my own user directories so as not to disturb other people working on the shared servers. Also I prefer to have a clean build workspace every time, i.e. I do not keep/reuse older build directories for my projects. Hope this helps. Regards, Ameya Vikram Singh
  9. Hello @katang, As per your comments: CMAKE_INSTALL_PREFIX is never left uninitialized, here is the official CMake documentation: https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX.html https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT.html Anyway it is a very bad idea to install in the systems default location: /usr/local or something similar. In-case you have multiple SystemC installations and if you are using the CMAKE_MODULE_PATH or CMAKE_PREFIX_PATH variable, then you would probably need to see in what order are the paths specified. Hope it helps. Regards, Ameya Vikram Singh
  10. Hello @katang, I am not an expert on this topic. But here is an article which summarizes the C++ Standard Changes after(C++98/03): https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/ One thing to understand is the standards body and the compiler teams came with solution to handle such underlying core changes, without the end user needing to completely rewriting their application and library implementations. With just a recompilation with newer standard flags gave most of the applications/libraries to start using the latest C++ standards features. Having a consistent compiler standards and other flags provides one with confidence that the application/library that one is shipping is meeting their expectations. And trust me you don't want to debug issues in library that got linked with slightly flags or slightly different API's and you are getting different run-time behavior of the application at every execution run(https://en.wikipedia.org/wiki/Heisenbug). Hope this helps. Regards, Ameya Vikram Singh
  11. Hello @katang, It seems the issue is due to mismatch between the C++ compiler flags between your SystemC build and your application. Can you check if they are consistent? Regards, Ameya Vikram Singh
  12. Hello @pmeyeratdatest, Can you specify the C++ Standard flag to the compilation command line parameters. # E.g.: g++ -std=c++11 <your_project_sources.cpp> -c <other_compiler_flags> Since It does not have any effect at link time. Thanks and Regards, Ameya Vikram Singh
  13. Hello @pmeyeratdatest, This line indicates the different command line parameters for the creation of the object files. Also, why are the library specified on the command line twice?(i.e. [-lscv and -lsystemc] and [../build/systemc-2.3.2/lib-linux64/libscv.a and ../build/systemc-2.3.2/lib-linux64/libsystemc.a] Can try this command, and let us know if the message changes g++-4.8 -g -Wall -ggdb -std=c++11 -O0 -D GCC48 -Wall ./main.o -o testCMD -L../build/systemc-2.3.2/lib-linux64 ../../CPP-NumericalMethods/libNumericalMethods.a ../build/systemc-2.3.2/lib-linux64/libscv.a ../build/systemc-2.3.2/lib-linux64/libsystemc.a -lscv -lsystemc -lpthread -lm Hope this helps. Regards, Ameya Vikram Singh
  14. Hello @mizi, Change the following lines in Makefile.defs: (lines 33 to 36) // From application/lib/%.so : application/src/%.o $(CC) -shared -W1,-soname,$@ -o $@ $< router/lib/%.so : router/src/%.o $(CC) -shared -W1,-soname,$@ -o $@ $< // To these lines: application/lib/%.so : application/src/%.o $(CC) -shared -Wl,-soname,$@ -o $@ $< router/lib/%.so : router/src/%.o $(CC) -shared -Wl,-soname,$@ -o $@ $< Notice the subtle difference between the command line parameter: -Wl (i.e. letter l not the number 1). Hope this helps. Regards, Ameya Vikram Singh
  15. Hello @mizi, You probably missed out on this: After taking a cursory look at the sources found following references: core/Controllers.cpp line 44: RT_ALGO: a global variable to the routing algorithm( 😞 ) Which has been initialized in config/default.h line 35 to a default value of XY. It seems you might need to integrate your algorithm following their design principles, which you can look into the existing classes of routing algorithm to figure out what all API's your algorithm need to provide to be compliant with the infrastructure. Hope this little insight helps. Best Regards, Ameya Vikram Singh
  16. Hello @mizi, Though I am not familiar with the Nirgam Simulator. But can you provide the answers to the following queries: Did you add your dependencies in the Makefiles/Build scripts? My next guess would be did you look into any documentation available for the simulator? Like running the simulation with various different configurations. Does it use command line options or config files or both? Even after changing those configuration files/command line options are you able to observe any change in simulation behavior? If the answer to the above query is no then you would probably need to get your hands dirty to understand the internals, and possibly modify the existing implementation to suite your needs. Hope this helps in someway. Regards, Ameya Vikram Singh
  17. Hello @mizi, Can you provide a minimal sample code and the environment details to reproduce the issue? With the current information it is very difficult to provide a solution/suggestion. Regards, Ameya Vikram Singh
  18. AmeyaVS


    Hello @ZEESHAN KHATIB, The BUSWIDTH template parameter denotes the underlying units of the transfers taking place. It can be thought of as 32-bit lines for carrying data at an RTL level when BUSWIDTH=32. At every cycle one can assume a 32-bit bus can transfer 32-bits(i.e. 4 bytes) of data. Now lets say we want to transfer about 1 GB of data using the TLM interface, It can be achieved easily using the generic payload. But then how would you maintain the timing consistency? With the attribute BUSWIDTH you can effectively approximate the time required to transfer the above mentioned data. If you want more details have a look at the references below about the usage of TLM interface for Serial modelling: http://forums.accellera.org/topic/6046-serial-transmission/ https://www.greensocs.com/sites/www.brightsocs.com/files/docs/GS_Serial.pdf Hope this small insight helps! Note: On another note let's assume you want to model an 8/16-bit computing systems would go about creating new interfaces? Also, with the RISC-V taking the lead in 128-bit CPU architecture, we might see CPU's with a big data buses. Best Regards, Ameya Vikram Singh
  19. AmeyaVS

    simple socket

    Hello @TRANG, By using sc_vector the sockets would be named as follows: initiator_socket[0] : " initiator_socket_0" initiator_socket [ 1] : " initiator_socket_1" initiator_socket [ 2] : " initiator_socket_2" initiator_socket [ 3] : " initiator_socket_3" or you can use something mentioned here in this answer to name the interfaces. It will be better to use the default naming scheme as it would make it consistent across the SystemC simulation. Hope it helps. Regards, Ameya Vikram Singh
  20. AmeyaVS

    simple socket

    Hello @TRANG, You probably need to change from this: sc_vector< simple_initiator_socket_tagged<Router >* > initiator_socket; to this: sc_core::sc_vector< tlm_utils::simple_initiator_socket_tagged<Router > > initiator_socket; And to understand the better use of sc_vector you can probably search and find many references on using sc_vector in the forum or on stackoverflow such as these ones: http://forums.accellera.org/topic/1849-array-of-sc_vector-binding-and-assembling-help/ https://stackoverflow.com/questions/35425052/how-to-initialize-a-systemc-port-name-which-is-an-array Hope these helps. Regards, Ameya Vikram Singh
  21. AmeyaVS

    Scope of SC_HAS_PROCESS

    Hello @Hook, The "systemc.h" header file actually include the "systemc" header, if you look at the source. Note: Reproduced below a section of the systemc.h header from SystemC release 2.3.3 202 using std::memset; 203 using std::strerror; 204 using std::strlen; 205 206 // deprecated strstream support 207 #if defined( SC_INCLUDE_STRSTREAM ) 208 #include <strstream> 209 210 using std::strstream; 211 using std::strstreambuf; 212 using std::istrstream; 213 using std::ostrstream; 214 215 #endif // SC_INCLUDE_STRSTREAM 216 217 // INCLUDE SYSTEMC DEFINITIONS for sc_dt AND sc_core NAMESPACES: 218 219 #include "systemc" 220 221 // USINGS FOR THE sc_dt NAMESPACE: 222 223 using sc_dt::SC_BIN; 224 using sc_dt::SC_BIN_SM; 225 using sc_dt::SC_BIN_US; But it also exports the symbols from the SystemC sc_core and sc_dt namespace in the global scope(as evident from the above snippet). You can find relevant discussion here: https://stackoverflow.com/questions/10269012/global-scope-vs-global-namespace https://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice It is generally considered a bad C++ coding guideline to export everything in the global scope. Hope it helps. Regards, Ameya Vikram Singh
  22. AmeyaVS

    What is SystemC library special in?

    Hello @Elvis Shera, The G++ Compiler 7.3.0 by default enables C++14, and your SystemC library is build using C++14 standard. You can change the line in your CMakeLists.txt to be: set(CMAKE_CXX_STANDARD 14) # enable C++14 standard and it should work now. Hope this helps. Regards, Ameya Vikram Singh
  23. AmeyaVS

    What is SystemC library special in?

    Hello @Elvis Shera, It seems your SystemC library has been build with different C++ standard flag. Can you post the output of following commands?: # Compiler version you are using g++ -v # Library Properties: nm -C $SYSTEMC_HOME/lib-linux64/libsystemc.so | grep api_version Regards, Ameya Vikram Singh
  24. AmeyaVS

    What is SystemC library special in?

    Hello @Elvis Shera, It seems the following line seems suspicious: The compiler flag -c is only required by gcc to create object files from translation units. Here's a quote from gcc documentation: For example, the -c option says not to run the linker. Then the output consists of object files output by the assembler. Try removing the option -c and try again. CMake would already handle the scenario internally. Hope this helps. Regards, Ameya Vikram Singh
  25. AmeyaVS

    What is SystemC library special in?

    Hello @Elvis Shera, Can you post the CMakeLists.txt you have for your example? It would be easier to suggest a solution. But If you want to take a look at minimal example of using CMake throughout for SystemC library, as well as building models you can have a look here: https://github.com/AmeyaVS/SystemC_ramblings/tree/master/src/01_SystemCTest Though to be honest it has been sometime since I have updated these, but basic concept are same. Hope it helps. Regards, Ameya Vikram Singh