Jump to content

Eyck

Members
  • Content Count

    197
  • Joined

  • Last visited

  • Days Won

    61

Everything posted by Eyck

  1. 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(TransactionExamp
  2. 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
  3. 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
  4. 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.
  5. 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
  6. 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.initi
  7. The is a memory using a sparse array as backing storage and having a tlm2.0 socket which you might want to use. You will find it at https://git.minres.com/SystemC/SystemC-Components/src/branch/master/incl/scc/memory.h.
  8. Hi Hai Dang, wait() takes a token from the semaphore (and waits for it if there is none) and post() puts a token back. In fact it decrements a counter until zero upon wait() and increments it upon post(), the initial value is given as constructor argument. Instantiating the semaphore with an initial value of one has the behavior of a mutex. So just posting the semaphore only increments it and obviously your program runs. If the code above fails then I would assume your initiators or targets have an issue since this is a proven pattern. Does the target call wait or does it just r
  9. If you can identify the condition of switching off clocks and the process being sensitive (and consuming the simulation time) you can enabel/disable the thread or method using the sc_process_handle as described here: BR
  10. You may use the tlm recorder of the SystemC components lib (SCC, esp. here: https://git.minres.com/SystemC/SystemC-Components/src/branch/master/incl/scv4tlm). This writes into a text database (the SCV default). You can view this e.g. with Impulse (https://toem.de/index.php/projects/impulse) or SCViewer (https://git.minres.com/VP-Tools/SCViewer, binaries here: https://github.com/Minres/SCViewer/releases). Basically you instantiate scc::tlm2_recorder_module and connect it's initiator and target sockets. to your target and initiator socket. Your sc_main should then look like: int sc_main
  11. I would stick with the two methods where the one calls enable() and disable() for the second mehtod. Why enable()/disable()? The LRM says (section 5.6.6): So with suspend() you still have the sensitivity handling in place while with disable() you don't. Moreover if there is an event while being supended it becomes immediately runnable. So falling edge of reset implies a process activation although there is not rising edge on clock. An implementation could look like: // class declaration: sc_core::sc_process_handle process_output_hndl; // constructor body: SC_METHOD(proce
  12. Hi, from the snippets I see it does not get clear what you are doing. Basically you would Instantiate the ordered_semphore scc:ordered_semaphore sem{1} and in b_transport() you wait() and post(): void Bus::b_transport(int id, tlm::tlm_generic_payload& trans, sc_core::sc_time& delay) { sc_dt::uint64 global_addr = trans.get_address(); int slaveid = this->address_to_slaveid(global_addr); if(slaveid < 0) { trans.set_response_status(tlm::TLM_ADDRESS_ERROR_RESPONSE); std::cout << "\e[1;31m" << this->name() <
  13. But what is the issue with running the simulation for 3*period? Best regards
  14. From the snippets you provide it looks ok. Assuming that bus_mutex is a sc_mutex this is you problem. sc_mutex does not do arbitration. It selects randomly which waiting thread to grant the lock (actually the next activated process base on an even notification) . But what you expect is arbitration. So either you write an arbiter or you may use and ordered semaphore with an initial counter value of 1. You may find an implementation here: https://git.minres.com/SystemC/SystemC-Components/src/branch/master/incl/scc/ordered_semaphore.h The semaphore grant access based on a queue. So even
  15. If you run a simulation until a certain point it time the kernel stops before evaluating the processes at this time point. So if you schedule an event for lets say 100ns and simulate for 100ns then the process being sensitive to this event will not be executed (yet). So this is intended behavior. BR
  16. My fault, SC_THREAD has a sensitivity list and you can call wait() for the default event. In my experience -and this guided my answer- it is better to have no sensitivity list and wait explicitly for events. When specifying a port in the sensitivity list you need to use an event finder (with .pos()) as the port is not bound yet and hence does not have an event associated. In the thread itself you can use the pos_edge event. So your code shown above is correct. BR
  17. Well, actually a scenaron having a sc_main linking various shared objects which in turn reference the SystemC library as shared object works. So I suspect you build process is somehow wrong. To help you here you would need to post the your build log or at least the linker calls for your user and util liba and for your executable. Best regards
  18. You should consult the LRM again.:SC_THREAD does not have a sensitivity list. Moreover you create a memory leak creating the transaction object using new and not deleting it. And your thread ends after 10 accesses. Basically you need to wait for the clock explicitly while (1) { // wait for the rising edge wait(clk.posedge_event()); tlm::tlm_generic_payload trans; // setup the transaction ... // execute the access i_socket->b_transport(*trans, delay); } In your solution the loop in your threads are based on timed delays hence it is not reactiong on your clocks at al
  19. Your trace function calls sc_trace(sc_trace_file *, sc_object*, const char*) which is not overloaded and hence issues the warning. You would need to test for each single template instance of sc_signal<T> and then call the appropriate sc_trace function. And example you can find in https://git.minres.com/SystemC/SystemC-Components/src/branch/master/src/tracer_base.cpp#L90. Or you may use the SystemC Components Library (SCC) as a whole since it provides already this functionality. Best regards
  20. At https://git.minres.com/DVCon2018/RISCV-VP/src/branch/develop/platform/src/rtl and https://git.minres.com/DVCon2018/RISCV-VP/src/branch/develop/platform/incl/sysc/rtl you may find some example of an integration of a cycle-based model (Verilator+Verilog RTL) into a VP using LT-style modelling. This is from last-years DVCon Europe (http://events.dvcon.org/events/proceedings.aspx?id=260--3-T). Best regards
  21. Adding to Davids answer: you can supply clocks to the modules having initiator and/or target sockets. This is can be done using the usual signal/sc_in/sc_out means as David mentioned. There is also the option to have 'tick-less' clock as David presented many years ago (http://www.nascug.org/events/12th/nascug12_david_black.pdf). This can also be achieved by distributing a signal just carrying the clock period as sc_time and caculating the time points in the modules. This way it is even possible to model timers or PWM (e.g. https://git.minres.com/DBT-RISE/DBT-RISE-RISCV/src/branch/develop
  22. Absolutely agreed. But to my experience folks try to avoid that as much as possible as it complicates the often already complicated protocol implementation. BR
  23. All of these relate to the concept of loosly-timed simulation. The basic principle behind this is that parts of the design can simulate larger time slices without returning control to the simulation kernel; the run ahead of the rest of the simulation. This is used e.g. for processors and alike as for quite some parts the do not interact with the rest of the design and create (a memory read does not really trigger any action other than returning some data). This way the simulation speed and hence the simulation performance can be drasticalliy improved but you trade performance for accuracy.
  24. Well, to me it is always helpful to think about sockets as a proxy or sophisticated function forwarder (in some sense similar lto sc_port). So you call b_transport on the initiator side and the socket forwards the call to the target and invokes b_transport there. HTH
  25. Well, in TLM1.0 there is even a tlm::tlm_fifo channel which provides something similar what you use. The sockets defined in TLM2.0 are more geared towards memory-mapped busses and provide facilities to model for speed (DMI, loosly-timed blocking interfaces) or accurracy (approximately-timed non-blocking interfaces). To achive this with pure SystemC provided classes takes some effort and it ends to be proprietary... BR -Eyck
×
×
  • Create New...