Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Eyck last won the day on December 22 2019

Eyck had the most liked content!


About Eyck

  • Rank
    Advanced Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Munich, Germany

Recent Profile Visitors

807 profile views
  1. You create 5 signals carrying a TraceVector. Doing so the default constructor is used which does reserve space for elements but has a size of 0... I can't tell where the assertion comes from. For those cases a debugger is pretty helpfull B-)
  2. As I wrote, I do not know Xcelium. But I would check the error in bpad_10634.err...
  3. First: you forgot the indicees into the arrays in your constructor and method. Second: the constructor of adder will not work. 'a' as well as the other ports are plain arrays of e.g. sc_in<sc_uint<4> > which does not have any constructor (and does not call any constructor of the elements). You may use as std::vector but this does not really solve the issue as std::vector just calls the default constructor of the element. You should use sc_core::sc_vector which allows named initialization as well as hierarchical binding: SC_MODULE(adder) { sc_core::sc_vectory<sc_in<sc_uint<4> > > a; sc_core::sc_vectory<sc_in<sc_uint<4> > > b; sc_core::sc_vectory<sc_out<sc_uint<5> > > c; void m_add() { for(size_t i=0;i<3;i++) { c[i].write(a[i].read() + b[i].read()); } } SC_CTOR(adder):a("a", 3), b("b", 3), c("c", 3){ SC_METHOD(m_add); for(size_t i=0;i<3;i++) { sensitive << a[i] << b[i]; } } ~adder() { } }; I don't know if Xcelium supports sc_vectors but I guess it does. HTH
  4. Yes, it can be compiled against SystemC 2.3.3. There are even packages for Conan (conan.io) available at bintray (https://bintray.com/minres/conan-repo) where SCV is built against SystemC 2.3.3 RB
  5. How did you build and isntall SystemC? If you use cmake the file is being copied....
  6. But even in this case you register the thread only in the (inheritance) leave module. You could do: dummy_master(sc_module_name name) : ahb_master(name) { cout<<"Executing new"<<endl; SC_THREAD(ahb_master::tick); sensitive << bus_grant.pos(); } for the default behavior.
  7. You are defining a thread in ahb_master and a thread in dummy_master where both have the same name (tick) but a different C++ signature (ahb_master::tick and dummy_master::tick). Actually defining the tick thread in ahb_master doesnt make any sense, moreover since it doesn't do anything it will be declared immediately after simulation start. BR
  8. Your memory management is wrong. At first you pull 1 tx from the memory manager and reuse it all the time. This means you are changing your transaction in the request phase while it is in the response phase of the previous access. So you need to use mm.alloc() for each off the accesses. The purpose of the memory manager is to take care when to release/re-use the transaction. And here your second issue comes: you should always call acquire()/release() in a balanced way but your lut only calls release(). What happens then is that the transaction is pushed into the pls deque in the memory manager. Eventually you have 2x the payload in the queue and upon destruction the memory manager tries to free it 2 times. BY inserting a pl.acquire() in line 42 of lut.cpp you do not get a segfault anymore. But you should also use pl = mm.alloc() for each transaction to be send. Otherwise you might run into hard to debug functional issues. A few general comments: For performance and readability reasons you should use std::copy instead of a for loop in lut.cpp lines 51ff and 56ff Your generator needs quite some rework. Since you have always similar procedure to send a transaction extract this into some helper function (containing mm.alloc() ;-). Secondly you might think about a for loop generating the accesses as they are fairly regular Best regards
  9. Why would you want to change the address after sending it? Actually only interconnect components are allowed to change the address of an transaction (this is what the standard says). I would alwys keep in mind how this is handled in haerdware.... One option to address this is to add an extension to your transaction holding the original adress and other information you need. But this comes at the cost of interoperability (if this is a criteria for you). BR
  10. Since you are talking about timing I would stick to a more AT like modeling style using the non-blocking transport functions. In this case you should use a memory manager (see section 14.5 of the IEEE standard). For this you need to implement the tlm::tlm_mm_interface (there a few implementations out there, you may google them). The mechanism works similar to a C++ shared pointer. The initiator always pulls a new transaction from the memeory manager and sends via its socket. Each component dealing with the transaction calls acquire() on the payload and release() once it is finished with it. Upon the last release() call the transaction is automatically returned to the memory manager and can be reused. HTH
  11. Well, the timer_tb gets a SC_THREAD which has exactly your sequence of writing to START and advancing time. The only difference is to use wait() instead of sc_start()...
  12. There is no such thing as CPU TLM modeling. Usually you write a C/C++ processor model with the needed accuracy (instruction accurate, cycle approximate, cycle accurate) and wrap it in a way that you translate memory accesses into TLM socket accesses. Along with that you need to manage to syncronization of the time of your model and the SystemC time (to run e.g. in loosly timed mode). Another task is to take the returned execution time of the bus accesses into account for the execution of the CPU model. This involves also the selection and implementation of the accesses (DMI & blocking or non-blocking). You can find a complete example of an instruction accurate VP at https://git.minres.com/DVCon2018/RISCV-VP (or https://git.minres.com/VP/RISCV-VP which is a newer version). The wrapper for the C++ model in SystemC can be found at https://git.minres.com/DVCon2018/RISCV-VP/src/branch/develop/riscv.sc/incl/sysc/core_complex.h To put it straight: doing this correctly is a non-trivial task as it is the implementation of a micro-architecture model of a CPU. One option is to build an instruction accurate ISS and add a microarchitecture model like it is done in the ESECS project (https://github.com/MIPS/esesc) BR
  13. It would be good if you could provide a description of the problem you see (or better error messages or alike) when building the unit. I see 2 things in your code: the statement labeled with '// sensitivity list' tm << START << TIMEOUT << CLOCK; is wrong. You did this already in the constructor (SC_CTOR(timer)) of your module. The sensitivity list of your timer is wrong. The thread should only wait for the positive edge of clock, start is a data signal which is sampled/read upon the rising edge of the clock I suggest to change the implementation from a coding style point of view: add a trace function to your timer module: void trace(sc_core::sc_trace_file* tf){ sc_trace(tf, clock, clock.name()); sc_trace(tf, start, start.name); sc_trace(tf, timeout, timeout.name()); sc_trace(tf, count, (std::string(name())+".count").c_str()); } The module knows what to trace, so in your sc_main you just call tm.trace(tf); usually it is beneficial to put the stimuli stuff into a separate unit. Either a testbench instantiating and wiring your module. Or into a stimuli module where you have at sc_main only the wiring. This increases re-usability. I personally prefer the testbench approach, this unifies sc_main(): int sc_main(int argc, char* argv[]) { // testbench timer_tb tmtb("timer_tb"); // tracing: sc_trace_file *tf = sc_create_vcd_trace_file("RESULT.vcd"); tmtb.trace(tf); // simulation sc_start(); sc_close_vcd_trace_file(tf); return(!sc_core::sc_stop_called()); } The timer_tb has to call sc_stop() once it is finished with stimuli. But this is a matter of taste. BR
  14. You cannot have a delay in end_of_elaboration() or start_of_simulation() since those are callback functions outside of the (timed) simulation cycle. One thing you could do is to start the gdb within a SC_THREAD where you have a wait(SC_ZERO_TIME) to let the updates settle: void start_gdb_thread(){ wait(SC_ZERO_TIME); start_my_gdb(); } BR
  15. You are initailaizing fl_ptr during consturction, not during execution. In generator.hpp you have: float* fl_ptr = reinterpret_cast<float*>(dmi_mem); //ovo sam ja pisao This never updates fl_ptr to the actual value of dmi_ptr. Actually your access should look like: if (dmi_valid) { dmi_mem = dmi.get_dmi_ptr(); //dmi_mem is pointer to ram[] array in memory.h float* fl_ptr = reinterpret_cast<float*>(dmi_mem); for (int i = 0; i != 20; ++i) fl_ptr[i] = 12.7; }
  • Create New...