Jump to content

Eyck

Members
  • Content Count

    90
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by Eyck

  1. 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 return an annotated time? How did you setup your initiators? BR
  2. 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
  3. 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(int argc, char *argv[]) { scv_startup(); scv_tr_text_init(); scv_tr_db db("my_db.txlog"); scv_tr_db::set_default_db(&db); dut_mod dut("dut"); sc_start(1.0, SC_MS); return 0; } The database is closed upon destruction of the db object. Best regards
  4. 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(process_output); sensitive<<clk.pos()<<reset; SC_METHOD(process_output_enable); sensitive<<enable; // function implementation: void fir::process_output() { if(!process_output_hndl.valid()) process_output_hndl = sc_process_handle(sc_get_current_process_handle()); if (reset.read() == 0) { //reset sequence } else { //normal operation } } void fir::process_output_enable() { if (enable.read()) { if(process_output_hndl.valid()) process_output_hndl.enable(); } else { if(process_output_hndl.valid()) process_output_hndl.disable(); } } BR
  5. 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() << ": " << "\e[1;31mInvalid address " << global_addr << std::endl; return; } sc_dt::uint64 slave_addr = global_addr - this->starts[slaveid]; trans.set_address(slave_addr); // make sure we are allowed to get access sem.wait(); this->initiator_socket[slaveid]->b_transport(trans, delay); // return back the token so that others can access sem.post(); trans.set_address(global_addr); } BR
  6. Eyck

    timer with systemC

    But what is the issue with running the simulation for 3*period? Best regards
  7. 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 eventually you get first-comes-first-serves (FCFS) behavior, but all requestors have equal priority. Best regards
  8. Eyck

    timer with systemC

    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
  9. 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
  10. 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
  11. 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 all. Best regards
  12. 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
  13. 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
  14. 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/platform/incl/sysc/SiFive/pwm.h). This modelling style avoids the many context switches implied by toggling clocks. All this holds true for LT and PV modelling, if you think about AT modelling the story becomes different. But this is as usual: you trade speed for accuracy. BR
  15. 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
  16. 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. This domain (or part of the simulation) running ahead of the simulation kernel is temporally decoupled. As such it needs some mechanism to control its local time (the amount it is ahead of the simulation kernel). This is done by the quantum keeper, the quantum is the amount of time the decoupled domain is allowd to be ahead at max. To allow interaction with the rest of the design all interaction need to carry some information what the local time in the dcoupled domain is, this is called timing annotation. This information is needed to either schedule events in the simulation kernel to happen at the correct time or to decide to break the quantum which means the decoupled domain is stopped and control is returned to the simulation kern until it reaches the local time of the decoupled domain, they are in sync then. HTH
  17. 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
  18. 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
  19. Hi, TLM2.0 is used to model bus-like transactions as you have in APB, AHB, AXI or alike. It abstracts those transactions in to e.g. read and write with some attribites (liek protection and alike). This saves some from dealing with bit wiggling and, as you have less events, improves simulation performance. If you use in your scenarion fifo between your producer and consumer you are already using TLM as you abstract the transmission of more or less complex data as a write into the fifo. If you keep this style in your design you do transaction level modeling (TLM). If you are asking if it makes sense to use the TLM2.0 standard is a different question and depends on what aspects of your design do you need to represent in your model. If you have some kind bus structure (e.g. some micro processor or controller) then it is highly advisable to use TLM2.0. In that case your producer calls the transfer functions of the initiator socket and your consumer needs to react on the callbacks of the target socket. Actually this does not relate to your file structure but as a starting poitn I would suggest to study the lt example comign with the SysetmC distribution. You will find it under examples/tlm/lt, it contains 2 initiator_top mdouels, a bus and 2 lt_target modules. if you reduce the thing to just one initiator_top and one lt_target being directly connected you have your producer/consumer scenario. HTH
  20. Eyck

    Deleting a binding

    Hi, deleting a binding is not supported. You did not detail your scenario in terms of producer and consumer. Ports in itself are only some kind of a proxy or function-forewarder. So if you have a producer having a sc_out you cannot bind it to some sc_in port of a consumer. You alway have to have a signal in between. Or in terms of C++ a port just forwards function (an interface) but you need to have an element implementing or providing these functions (an implementation). Bottomline: To connect some producer/writer to a consumer/reader thus fowarding a signal write you need to have a signal in between. Best regards
  21. Eyck

    Binding ports and starting function

    You should not use new on arrays as this does not call the constructors. So instead of sc_in<bool> * task_finished; You should use sc_vector< sc_in<bool> > task_finished; and the constructor should the look like TaskSchedulerTemplate::TaskSchedulerTemplate(sc_module_name name, std::vector<PipelineLeon*> * _pipelines) : sc_module(name), task_finished("task_finished", number_of_pipelines), pipelines(_pipelines) { SC_METHOD( schedule_task ); sensitive << trigger_task_scheduler; dont_initialize(); for (vector<PipelineLeon*>::iterator pipeline = pipelines->begin() ; pipeline != pipelines->end() ; pipeline++ ){ task_finished[ (*pipeline)->get_cpu_index() ]( (*pipeline)->task_finished ); } SC_METHOD(task_finished_action); for (int i = 0; i< number_of_pipelines; i++) { sensitive << task_finished[i].pos(); } dont_initialize(); } sc_vector ensure that the constuctors of the sc_port are called properly. Moreover I would not bing the task_finished signals of the _pipeline vector in the constructor, this limits the reuse and the clarity of the design intent. So I suggest to move the for-loop to sc_main and remove the second constructor argument to TaskSchedulerTemplate::TaskSchedulerTemplate. BR -Eyck
  22. But since these are multi_passthru sockets the id indicates the number of the bound initiator socket (as the multi_passthru_target_socket can bind several sockets to one). BR
  23. You cannot not check typeid() against a string as this is compiler dependend. What you shoudl do is void write_out{ if(typeid(T) == typeid(sc_dt::sc_logic){ out.write(SC_LOGIC_Z); }else{ out.write(0); } } } But actually this is more a C++ related question, in my experience Stackoverflow is a good source of help. Cheers
  24. Well, without lnowing the implementation it is hard to tell. I suppose your initiator sockets are connected to target sockets at he bus and the initiator sockets of the bus are connected to the target sockets of your target components. All these sockets need to be bound to each other (by calling bind() or the operator() function). There is no concept of bind-by-name in SystemC. Maybe you should have a look here: https://www.doulos.com/knowhow/systemc/tlm2/tutorial__3/ Sockets need to be bound except they are declared with the appropriate binding policy (the 4th template of the sockets). If this is not the case you need to create dummy targets.
  25. In principle yes, but I would not call it LT or AT as it depends on hte use of a memory manager which can be used in any case. Cheers
×