Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by AmeyaVS

  1. Hello @Arjun_07, Can you post your minimal code which reproduces the behavior? Regards, Ameya Vikram Singh
  2. Hello @mo_ayman, Well you could get it early for review comments from the people in SystemC LWG. Plus people with similar setup to yours can also take a jab at it in getting it fixed. Regards, Ameya Vikram Singh
  3. Hello @mo_ayman, Would it be possible to share the changes you have done on the official systemc github repository as a pull request? That would be a better alternative to get the fixes in somewhat faster. Regards, Ameya Vikram Singh
  4. Hello @Viet Hoang, Did you enable the pthreads for the SystemC library build? In cygwin the QThreads library is non-functional, that is why you are facing make check failures also.(13/22 passed tests) You can find relevant discussions here: https://forums.accellera.org/topic/5627-systemc-231-installation-problem-on-windows-7-with-cygwin/?do=findComment&comment=13595 If you are using you need to pass this command line option to cmake to use Pthreads for SystemC threads implementation: -DENABLE_PTHREADS=ON Regards, Ameya Vikram Singh
  5. Hello @Viet Hoang, I think these lines are a cause of concern. You are only running the simulation only for a "1 ns" much before the clock cycle. Replace the following lines: With sc_start(); // or with one below // sc_start(300, SC_NS); And stop the simulation using "Ctrl+C" (SINGINT) when running till end of simulation. Hope it helps. Regards, Ameya Vikram Singh
  6. Hello @elibre, It looks like you need to utilize dynamic processes to achieve what you have mentioned in your query. You can find necessary details here: https://forums.accellera.org/topic/6089-sc_spawn-and-anthoer-process/ https://sclive.wordpress.com/2008/01/10/systemc-tutorial-threads-methods-and-sc_spawn/ The second link is slightly dated, but still has details for what you want to achieve. Hope this helps. Regards, Ameya Vikram Singh
  7. Hello @Partha, As the error message suggests the third indexed interface in host(my_host) object instance is not bound: i.e. host_port. For future reference pass the name of the interface also so that you can get more descriptive names in the error messages. For e.g.: Changing your source files as shown below changes the error message: // Code your testbench here. // Uncomment the next line for SystemC modules. #include <systemc.h> #include <stdlib.h> class slave_if : public sc_interface { public: virtual void write(int data) = 0; virtual void read() = 0; }; SC_MODULE(Host) { sc_in<bool> scl{"scl"}; sc_in<bool> sda{"sda"}; sc_in<bool> rw{"rw"}; sc_port<slave_if> host_port{"host_port"}; int val; void behaviour() { if (scl == 1 && sda == 0 && rw == 0) { val = rand() % 50; host_port->write(val); } else if (scl == 1 && sda == 0 && rw == 1) { host_port->read(); } } SC_CTOR(Host) { SC_METHOD(behaviour); sensitive << scl << sda << rw; } }; SC_MODULE(Master), public slave_if { sc_in<bool> clk{"clk"}; sc_out<bool> scl{"scl"}; sc_out<bool> sda{"sda"}; sc_out<bool> rw{"rw"}; sc_fifo_out<int> master_write_fifo{"master_write_fifo"}; sc_fifo_in<int> master_read_fifo{"master_read_fifo"}; int i = 0, data_get, val, no_bits = 8; Host my_host; void write(int data) { while (no_bits != 0) { sda = data & 1; wait(SC_ZERO_TIME); master_write_fifo.write(sda); no_bits++; } } void read() { while (i != 8) { master_read_fifo.read(val); data_get = data_get + (val * pow(2, i)); /*master_read_fifo.read(val); cout<<"value:->"<<val<<endl;*/ i++; } cout << "my data:-->" << data_get; } SC_CTOR(Master) : my_host("my_host") { my_host.scl(scl); my_host.sda(sda); my_host.rw(rw); } }; SC_MODULE(Slave) { sc_inout<bool> scl{"scl"}; sc_inout<bool> sda{"sda"}; sc_inout<bool> rw{"rw"}; Master slave_master; SC_CTOR(Slave) : slave_master("slave_master") { slave_master.scl(scl); slave_master.sda(sda); slave_master.rw(rw); } }; int sc_main(int argc, char *argv[]) { sc_clock clk("clk", 1, SC_NS); sc_signal<bool> scl{"scl"}; sc_signal<bool> sda{"sda"}; sc_signal<bool> rw{"rw"}; sc_fifo<int> main_fifo{"main_fifo"}; Master master("master"); master.clk(clk); master.master_write_fifo(main_fifo); master.master_read_fifo(main_fifo); Slave slave("slave"); scl.write(1); sda.write(0); rw.write(0); slave.scl(scl); slave.sda(sda); slave.rw(rw); sc_start(); return 0; } to SystemC 2.3.4_pub_rev_20190904-Accellera --- Nov 18 2019 21:47:55 Copyright (c) 1996-2019 by all Contributors, ALL RIGHTS RESERVED Error: (E109) complete binding failed: port not bound: port 'slave.slave_master.my_host.host_port' (sc_port) In file: /home/ameyavs/apps/src/systemc/src/sysc/communication/sc_port.cpp:235 Hope this helps. Regards, Ameya Vikram Singh
  8. Hello @Viet Hoang, Glad that my input helped. It would be great if you can post the second query along with a minimal sample code you are trying to replicate the said behavior in a separate post. Regards, Ameya Vikram Singh
  9. Hello @Viet Hoang, Can you clarify what environment you are using for setting the build environment for both SystemC and fc4sc? (From the looks of it it seems to be cygwin based). Also the error: Is due to you trying to copy and paste the command from the pdf to the bash console. Can you try to manually type the commands? Regards, Ameya Vikram Singh
  10. Hello @dave0, As suggested by @maehne use the public git repository available here: https://github.com/accellera-official/systemc Prerequisites: Working Microsoft Studio Environment Windows CMake Binary release: https://cmake.org/download/ Ensure CMake executable is available in the command line.(cmd.exe) Git Windows installation from: https://git-scm.com/ Ensure Git command is accessible from command line(cmd.exe) Here are the highlight of the steps involved: git clone https://github.com/accellera-official/systemc cd systemc mkdir buildDebug cd buildDebug CMake Configuration cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_STANDARD=17 -DCMAKE_CXX_EXTENSIONS=OFF -DCMAKE_INSTALL_PREFIX="C:\Users\<YOUR_USER_ID>\Desktop\systemc-install" .. Building SystemC Library: cmake --build . --config Debug Running Sanity tests to validate the built library is functional(optional) cmake --build . --config Debug --target examples/check This should run all the examples available with SystemC release and all of them should pass without any failures. SystemC library installation: cmake --build . --config Debug --target install Hope this helps. Let us know in case you face any issues setting it up. Note: Also, refer here for SystemC 2.3.4 public review tagged release, only use the master branch version which seems to have fixes for MSVC2017/2019. Regards, Ameya Vikram Singh
  11. Hello @Gilbert Pajela, SystemC is C++, so it would be better to utilize C++ Tooling support to parse SystemC. And since @Roman Popov already mentioned Clang and LLVM tooling infrastructure you would have to fiddle with it to get necessary results. After Googling a bit found a reference to this paper: https://ieeexplore.ieee.org/document/6646649, and this project on GitHub: https://github.com/anikau31/systemc-clang Which have been updated quite recently. Hope it helps. Regards, Ameya Vikram Singh
  12. Hello @SteveF, The enum tracing support is deprecated. You can find relevant discussions here: https://forums.accellera.org/topic/1309-enumeration-tracing/ https://stackoverflow.com/questions/53859127/how-to-trace-enum-type-in-a-vcd-file-using-systemc-ams There was another discussion about creating a mapping file between values and strings for usage in GtkWave for viewing VCD traces but currently unable to locate it. Will probably update the response or someone else can post the link to relevant discussion. Hope this small insight helps. Regards, Ameya Vikram Singh
  13. Hello @rana, Here (http://karibe.co.ke/2014/02/setting-up-systemc-and-eclipse-for-c-hardware-simulation/) is a very detailed resource for setting up the Eclipse CDT IDE for SystemC related development. Though it is mentioned using Linux but you can find the steps 6 through 10 necessary for setting the project configurations which are anyway platform agnostic. Hope it helps. Regards, Ameya Vikram Singh
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  • Create New...