Jump to content

AmeyaVS

Members
  • Content Count

    152
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by AmeyaVS

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. Hello @kallooran, Try setting the environment variable LD_LIBRARY_PATH as mentioned below: export LD_LIBRARY_PATH=$SYSTEMC_HOME/lib-linux64 # or this if the library containing the libsystemc.so is under $SYSTEMC_HOME/lib # export LD_LIBRARY_PATH=$SYSTEMC_HOME/lib Also what is the command line used to build the project? (Example as mentioned below) # e.g.: # Compilation $ g++ -Wall -g -I$SYSTEMC_HOME/include -c main.cpp # Linking $ g++ main.o -L$SYSTEMC_HOME/lib-linux64 -o sim -lsystemc Hope it helps. Regards, Ameya Vikram Singh
  15. Hello @kallooran, Can you post the command line you are using to build your models with? Also, if possible share the following environment variable also: echo $SYSTEMC_HOME echo $LD_LIBRARY_PATH Currently with the title above is not enough to provide an educated guess about the environment you are using. Regards, Ameya Vikram Singh
  16. Hello @kallooran, What version of SystemC library are you using? This issue has been fixed in the release of SystemC-2.3.2. You can find the latest release of SystemC-2.3.3 here: http://accellera.org/downloads/standards/systemc Hope it helps. Regards, Ameya Vikram Singh
  17. Hello @Aaron Yang, The sc_fixed is a datatype, which is evident from the error message you are getting: sc_dt::sc_fixed<16, 2> ^ | This denotes the sc_fixed is from the sc_datatype namespace. As @Roman Popov has mentioned in his answer you cannot make the process sensitive to a non-channel variable. Changing the line: sc_vector<sc_fixed<din_size, din_int>> in_val{"in_val", din_num_samples}; To: sc_vector<sc_signal<sc_fixed<din_size, din_int> > > in_val{"in_val", din_num_samples}; // or this // since it is not clear where the fir_main thread exists. sc_vector<sc_in<sc_fixed<din_size, din_int> > > in_val{"in_val", din_num_samples}; //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ // For this you will need to bind it with sc_vector of sc_signals of the datatype // sc_fixed< > type at the parent level module. At the core of the implementation the SystemC sensitive only takes in only sc_events. As for the overload it is better to create a utility header for development purposes which you can include in your project for development purposes. Better not to disturb the systemc.h header file inadvertently making it unusable due to bad edits. Hope this helps. Regards, Ameya Vikram Singh
  18. Hello @re1418ma, You can look at this example: http://forums.accellera.org/topic/5678-clock-to-q-propagation-delay/?do=findComment&comment=13657 Or this one which shows how to add delay in full adder: http://forums.accellera.org/topic/5715-delaying-simulated-execution/?do=findComment&comment=13844 Hope it helps. Regards, Ameya Vikram Singh
  19. Hello @re1418ma, This has been already discussed before here: http://forums.accellera.org/topic/5715-delaying-simulated-execution/ Hope it helps and if you have further questions please feel to ask. Regards, Ameya Vikram Singh
  20. Hello @Philipp A Hartmann, It seems to be an issue with this test scenario.(systemc/1666-2011-compliance/living_dead_bug) I tried running the regression test suite on another system and except for this test, all the other tests passes. Regards, Ameya Vikram Singh
  21. Hello @Philipp A Hartmann, I have probably seen this behavior in other regression tests also. But currently I do not recall all of them, this one was the first one to deadlock. I will try to run the regression test-suite with individual tests and post the results whenever I get a chance. Thanks and Regards, Ameya Vikram Singh
  22. Hello @Philipp A Hartmann, Thank you for your reply. Unfortunately even after applying the changes the issue still persists. In-case you need more inputs do let me know. Thanks and Regards, Ameya Vikram Singh
  23. Hello @Roman Popov, It seems the issue is consistent with multiple different Linux OS with recent versions of GLIBC. From what I could figure out was the internal implementation for pthread mutex and condition variables have been updated. I will try to find the discussion on the same, but for now I think it would be better if someone from working group could also provide some insight into the issue. Regards, Ameya Vikram Singh
  24. Hello @RaviS, You can download the Latest Eclipse package from their website which does work on Ubuntu 18.04. Eclipse CDT download the package most pertinent to your system.(e.g. Ubuntu 64-bit download the Linux 64-Bit package.) The Eclipse IDE is very well supported on latest Linux Environments. Regards, Ameya Vikram Singh
  25. Hello @Roman Popov, I did try it on Ubuntu 16.04 with GCC 5.4.0, and currently I do not observe this behavior. Probably some regression in the base system, I will try to narrow it down once I get some time. I just wanted to give a heads-up in-case there is an issue with the SystemC kernel. Since, most of the application packaged on these Linux systems do get some form of regression testing. Regards, Ameya Vikram Singh
×
×
  • Create New...