Eyck

If you need more flexibility than systemc-clang allows you may use libclang. This is a Python binding of the Clang library (some intro can be found here: https://shaharmike.com/cpp/libclang/ or here: https://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang). This way you can easily deal with the Clang AST and its cross references and alike. Best regards

Without concete code it is hard to give any advise. But it looks like that you redeclare a member function of your original module. BR

Again, in your case you model a burst read which means in reality data gets transfered in several beats (32 in your case). Since your model does not deal with timing you wont notice that, all you see is that your data gets transfered. Look, TLM2.0 implements a generic bus protocol. Most of the real-world protocols have a so called burst transfer (e.g. checkout the AMBA specs). So the way to model this in an abstract way is to have a bust with and the amount of bytes being transfered in on bus transaction not in one beat. This way it is also possible to describe byte and half-word transfers. HTH

Well, as the name says it is the data transfer with of the bus you are using. So in your case sending 128byte of data across bus having 32bits means you model a burst access having 32beats. Having said this you should notice that the bus width determines mainly the timing of a transaction. Unless you use timing for your transaction and rely on it (e.g. for performance modeling) it should not bother you. Best regrads

It is spelled 'sc_spawn_options' so you missed the trailing s

Without further context it is hard to give a helpful answer. You can try to do event1.notify(SC_ZERO_TIME)

boost::variant would be an option or you use a union. In the latter case you loose the type safety...

If you can you should do it this way. But if the source of the irq is outside of the LT domain you can only reduce the quantum.

In this case you would need to add some syncronization at the ingress and the egress of the NoC. One should run with the clock of the sender and the other with the clock of the receiver. Since SystemC does not have an 'undefined' state the syncronization between ingress and egress is fairly simple depending on the way you model the way the phits/flits are send thru the NoC BR

Well, this topic is not easy to solve. In C++ each template instantiation (like sc_in<bool>) is a separate class in the class hierachy. The common base class is sc_port_base and this is in this context more or less useless. Actually there I see 2 options: You store a sc_port_base pointer in your map and upon each write you check for the typeid of the specific template instance and down-cast it using dynamic_cast. This is inflexible and needs additional coding if you want to use new type. You store a writer function in your map which knows how to translate a generic value (like int or double) to the particular value. This might by a lambda which captures the port reference and therefore 'knows' hwo to write to this port. But in this case you would loose type safety as you have to store a generic function unless you can use std::variant. So your map would have to be declared as typedef std::map<std::string, std::function<void(unsigned)> Map0 or (C++17): typedef std::map<std::string, std::function<void(std::variant<bool, sc_dt::sc_uint<2>>> Map0 I personally would go for option 2 as it is simpler and more flexible... HTH

Another option is to use https://github.com/Minres/SystemC-Quickstart as a starting point. This gives you a cmake based project using conan to manage your libraries incl. SystemC (see README.md). Then you have 2 options (I call them 'Eclipse first' and 'CMake first'): either you install the cmake4eclipse Plugin (https://github.com/15knots/cmake4eclipse) via the Marketplace (https://marketplace.eclipse.org/content/cmake4eclipse) or you use cmake to generate your Eclipse project files via cmake -G"Eclipse CDT4 - Unix Makefiles" . I personally prefer the first approach since the latter has one drawback: if you add directory or files you have to add them in CMakeLists.txt, run the generator again and the have an updated Eclipse project.

Another option would be to use a resolved signal and connect all output ports to it. But this is already about techincal implementation options. The question to me is: what would you like to model? Is this the right way to model the intend? Best regards

Well, your interrpt is set in a SC_THREAD or SC_METHOD and these are active when the ISS thread sleeps. In that sense the sensing is immediate when the ISS thread wakes up. But since the ISS thread is ahead of the SystemC simulation when the irq is activated in SystemC there is no way to have an immediate sensing. This is the accuracy you give up to gain simulation speed: the delay until the ISS acts on an external event is determined by the quantum. On solution could be to use a dynamic quantum which changes in the course of the simulation: you start with a large quantum until you reach a certain point in simulation (e.g. until you booted the system) and then you lower the quantum to get more accuracy.

Each type of extension has an automatically assigned ordinal number which is available per extension as ID in the base class tlm_extension. So in your case you have 2 tlm_extensions defined somewhere. Under the hood this ID is used as an index into the m_extension array of the tlm::generic_payload. Best

@Philipp A Hartmann you are right, '|=' would imply and or list.

@Khushi This is not a good solution since this way you enforce a quantum from a component maybe deep in the hierarchy. This sacrifies compatibility and makes reuse pretty difficult. You should follow the guidlines outlined by David.

You would want to use an sc_event_and_list. See IEEE1666 section 5.8. As its intended use is with next_trigger() and wait() you would need to move the sensitivity into your method. So the constructor part becomes SC_METHOD(func2); and func2 should something like (snippet of your module): sc_core::sc_event_and_list ev_list; void end_of_elaboration(){ ev_list |= clk.posedge_event(); ev_list |= nreset; } void func2(){ next_trigger(ev_list); // your code here ... }

Well, the global quantum is as the name says global. So there is only one variable and it should be set at on central point. In many cases this is sc_main but it might also be some configuration unit. This depends on the requirement and implementation. I would refrain to set it in the initiators as then you dont know which one is the last one to set the quantum esp.if they want to set it to different values. Usually the leads to hard-to-debug problems. Best regards

Actually in my experience mixing various C++ standard levels is not advisable as they imply changes in libstdc++ which may lead to all sort of issues. So my general recomendation is to have the same setting in all libraries. Hence this general apporach. And conan_set_std() conan_set_std() will set the standard level to C++14 in this example.

Actually you need to add the library dirs to your cmake target liek this: link_directories(${CONAN_LIB_DIRS_GTEST}) add_executable(TransactionExample main.cpp) target_link_libraries(TransactionExample ${CONAN_LIBS}) Since the CMake setup in the example project is not 'conan only' things are a bit different (it can also be used with SYSTEMC_HOME env variable). If you rely entirely on conan you could simplify the CMakeLists.txt to cmake_minimum_required(VERSION 3.3) set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_SOURCE_DIR}/cmake) include(Conan) project(TransactionExample CXX) setup_conan() conan_set_std() conan_global_flags() add_executable(TransactionExample main.cpp) conan_target_link_libraries(TransactionExample) I updated the README in the Quickstart Project accordingly

You should use SystemCVerification/2.0.1@minres/stable instead of 2.0.0a. As these are binary packages (with source) there are version dependencies. TLM2.0 is part of SystemC so it comes automatically with the SystemC package. Actually I might want to start with: git clone https://github.com/Minres/SystemC-Quickstart cd SystemC-Quickstart/ mkdir build cd build/ cmake .. make This is all you need to start developing based on SystemC. More details to be found in the README.md

Hmm, not sure if I understand you correctly. Your C++ code has an entry function, right? If you just call this entry function from a SC_THREAD it runs in a thread context and can call wait to let other parts of the simulation continue. The other option you have is to run your C++ code in a second (OS) thread, e.g. a std::thread. This allows to use the usual syncronization primitives of the OS like mutexes and alike. BR

There are several ways to do this: you might use a different way to carry signals which are more TLM like. One option would be to use tlm_signal. The other common option is if your CPU writes into the register of your interrupt controller via TLM it carries the delay which is essentially the offset of the CPU local time to the SystemC kernel time. If you here just break the quantum and call a wait() so that the SystemC kernel can sync up and the signal change propagates you should be fine.

The sparse array of the memory I mentioned is implemented as paged memory with allocate on write semantics as @swami060. So you might have a look into this as example

Did you build the scv library? Just referencing the headers is not enough. Actually this should do the trick, if not posting the log might help. Moreover you should change your toplevel. your initiator socket connects to the target socket of the recorder, the intiator socket of the recorder connects to the your target socket. scv_startup(); scv_tr_text_init(); scv_tr_db db("my_db.txlog"); scv_tr_db::set_default_db(&db); top t ("dut"); scv4tlm::tlm2_recorder_module<> inst_mod("rec_module"); init->i_socket(inst_mod.target); inst_mod.initiator(targ->t_socket); sc_start(200,SC_NS);