Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Eyck

  1. TGC is 'The Good Core' family of RISC-V cores of MINRES Technolgis GmbH. The VP-Vibes organization at Github is for any project related to Virtual Prototypes. So the SystemC-Components library comes with SystemC utilities, components like register and generic bus targets as well as on-chip interconnect protocol definitions. The VPV-Peripherals provides peripherals which can be used in building VPs while the TGC-VP assembles all these components into a VP. Parts of the VP, in detail the ISS and its infrastructure, is being used as reference model to verify the RTL implementation(s). For this we use an insturction stream generator and a response checker (see also here).
  2. tri-state logic is not synthesizable. But if you use a 2-bit vector where one bit shows activity and one bit the value this can be synthesized... But it doubles the number af wires and depending on the gate logic the size of the logic. This may be wroked around by designing a custom cell for the standard cell library. After it is characterized the cell might be used by the synthesizer.
  3. Yes, you are writing 2 elements into the fifo in the same evaluation phase. This results in a single notification of the data wrtitten event. The returned value tells you if the write was succesfull or not. How to react on that depends on your model. At least you have to try it again at a later time (e.g. when the fifo has room for the new element). The delta cycle does not change. But I guess you mean when does the function return. For this you can consult the LRM. But in short: nb_write returns immediately, it is non-blockin (or nb). Therefore you can use it in an SC_METHOD. write is blocking which means internally wait is called and it returns once the element has been placed in the fifo. Therefor write can only be used in SC_THREAD since the call to wait() is not allowed in SC_METHOD.
  4. There are quite few more RISC-V ISS/VPs, all based on SystemC. E.g.: ETISS of TU München (https://github.com/VP-Vibes/etiss) TGC-VP of MINRES (https://github.com/VP-Vibes/TGC-VP)
  5. There are no SystemC specific profiling tools freely available. So either you use tools of well-know EDA vendors or used gprof, valgrind, ptrace, or alike to profile your simulation. Unfortunately they are not aware of sc_threads (or coroutines) so some creativity is needed to interpret the results. I would also put some emphasis on memory allocation and managment. If the footprint gets larger caches need to be more often flushed and this cost quite some time.
  6. The simplest solution would be to pass a pointer (or reference) to OS_Task or the TCB with task_create() and task_end(). A forward declaration alogn with the OS_API class should be sufficient. I don't know your requirements but it seems to me that your use of sc_module is sub-optimal for the purpose of modeling OS tasks. The reason is simple: you cannot create or delete sc_module after the elaboration phase. And OS tasks tend to be dynamic... So sc_object and sc_spawn might be a better solution. I assume that task_create() and task_end() always surround the behavior of a task. So why not move them into the OS_Task itself? If you pass then the TCB as pointer or by reference you could encapsulate the entire stuff of task handling in the OS_task class...
  7. I took your eample and pasted it at https://www.edaplayground.com/x/EtqQ From there is works without any hassle. You seem to have anything different in your code base than posted here.
  8. C++17 supports the inline static syntax (see https://en.cppreference.com/w/cpp/language/static). So you need to have a C++17 capable compiler and specify the language level accordingly. In C++14 this is not supported....
  9. tlm_fifo provides a blocking read called get() as well as an event to use: ok_to_get(). To block the writer you can use ok_to_put() which is triggered when the fifo is read.
  10. I had a look onto your code and it has several flaws: your condion variable not protected against spurious and lost wakeups you use one global condition variable for all threads. This is bad design... your simulation runs out of events. Since the SC kernel does not see any events during the start of your thread(s), it simply shuts down the simulation. So before your thread is alive there is no simulation at all diamond problem with multiple inheritance: ThreadSafeEvent inherits of sc_prim_channel and ThreadSafeEventIf where both inherit of sc_interface. So at least ThreadSafeEventIf needs to ingerit virtual. Instead of dealing with pthreads you should use std::thread and friends. This eases your life quite a lot an makes things easier Based on your example I created a working example at https://www.edaplayground.com/x/Nn9e using C++11. Make sure that in the field 'Compile Options' the option '-pthread' is given as well as c++11 or c++14 is selected
  11. Neither is the case. Between putting an element into the fifo and the element becoming available is at least a delta cycle. And this is by design as in hardware it takes some time for values to propagate. sc_core::sc_fifo exposes the same behavior. If you need immediate update you can use ordinary C++ containers like std::dequeue...
  12. But if you look into fir_const.h you see: coefs[0] = -6; coefs[1] = -4; coefs[2] = 13; coefs[3] = 16; coefs[4] = -18; coefs[5] = -41; coefs[6] = 23; coefs[7] = 154; coefs[8] = 222; coefs[9] = 154; coefs[10] = 23; coefs[11] = -41; coefs[12] = -18; coefs[13] = 16; coefs[14] = 13; coefs[15] = -4; which is just assignement, not declaration. coefs is declared as member variable of module fir: SC_MODULE(fir) { sc_in<bool> reset; sc_in<bool> input_valid; sc_in<int> sample; sc_out<bool> output_data_ready; sc_out<int> result; sc_in_clk CLK; sc_int<9> coefs[16]; SC_CTOR(fir) { SC_CTHREAD(entry, CLK.pos()); reset_signal_is(reset,true); #include "fir_const.h" } void entry(); }; In your code you declare and initialize a local variable: void ex::entry(){ double angles[...] = {...}; .... } which shadows your class member angels. As soon as the funtion ex::entry() finishes the local variable angels get destroyed. What you can do is just assigning it e.g.: void ex::entry(){ angles = {...}; .... } which is similar to the fir example you quated. As I mentioned earlier, you should make yourself familiar with variable life times and visibility.
  13. Did you install teh SCV? It is a separate library from SystemC...
  14. That's why it always better to use an unnamed enum as shown in the edaplayground example. This is typesafe and allows the compiler to check things.
  15. You are declaring angles local in the body of the constructor. Once this finishes they are destroyed as they are stack allocated. You are running into undefined behavior. This is basic C++, lifetime of variables. You need to declare angles as member of the class/SC_MODULE and only assign in teh constructor
  16. Your problem is the #define N 25 before including systemc.h since N is used as template parameter name in some systemc class templates. I put your code on edaplayground: https://www.edaplayground.com/x/s6Fu with a few minor changes and there it compiles and works....
  17. SystemC is a single-thread simulator and moreover not thread-safe due to various reasons. The problem you are facing is that you modify datastructures in the SystemC kernel (by calling notify() ) asyncronously since you are running it in another (OS-)thread. This might work in some case but in most cases it will not. To cut a long story short you cannot use sc_event to syncronize os-threads. But there are means to handle this case namely async_request_update(). To see an example you might check out https://stackoverflow.com/questions/49814756/async-request-update-example-in-systemc esp. the implementation of class ThreadSafeEvent. One remark: I strongly suggest to use C++11 and there std::thread since it makes your code more readable and abstracts from the underlying API. E.g. PThread is not a native Windows thread implementation rather belongs to some POSIX layer which might introduce additional issues.
  18. The example you are quoting is conversion to bit vector representation. LRM sections 7.10.14 and 7.10.18 specify sc_fix(ed) and there you find constructors accepting double as well as assignment operators for double. So you can do a direct assignment.
  19. Before inlcuding systemc.h you need to define SC_INCLUDE_FX: #define SC_INCLUDE_FX #include <systemc> using namespace sc_core; using namespace sc_dt; void test_overflow_modes() { sc_fixed<6, 4> a = -7; cout << " a in dec: " << a << endl; } ... You'll find that in the LRM...
  20. To me it looks like if the signal is not being properly constructed. But without additional code it is not possible to give more advise....
  21. In the follwoing linemyselector.out_fifo (ctrl_frame); myselector.out_fifo (ctrl_frame); You are trying to bind ctrl_frame to the sc_fifo_in port. And obviously ctrl_frame is neither a sc_fifo nor implements the sc_fifo_in_if.
  22. Answering your question without having a code example is difficult. You transmit a pointer to BasePort which does not contain the data. Therefore you do not see the data. At your signal sink you need to do a dynamic_cast<> to get a pointer to your Port Your approach to modeling is strange not to say wrong. What Do you want to model between your memory and adder? Actually you describe a signal carrying a pointer to a Port? Usually a signal carries a value (or a set of values aka a struct) and there will only be value changes which manifest as events. Or do you want to model a bus based communication? In that case you should use TLM2.0 sockets and payload which has quite some flexibility to adapt to particular needs keeping the semantics.
  23. Which compiler version do you use? _randomP is declared as mutable so it should be possible to assign to it even in const member functions. Or maybe you have a define named 'mutable'?
  24. Depends on the system youar eon and the compiler you are using. Here are a few options: https://stackoverflow.com/questions/2099692/easy-way-find-uninitialized-member-variables Unfortunately the reports ar not exhaustive so there is still some work ahead....
  25. No, you cannot run the SystemC simulator kernel as a Linux kernel module for sevberal reasons: SystemC requires quite some libraries (libc, libqt, ...) that are not available in kernel space You would taint the kernel and open up a security hole large as a gate. You would alos risk the system integrity. SystemC is simply not meant for such things. A proper design would make a distinction between (as little as possibel) code to run in kernel space providing interfaces (devices or shared memory) to interact with and a userspace application which could be the SystemC simulation e.g. running as a daemon. Even linux kernel hackers move everything into this direction... Yes, the simulation is a simple userspace process being constraint by the OS permissions. So it can use all resources a process is allowed. It can open socket connections and ports and whatever it needs. In the past I wrote some interface which allowed the SystemC simulation running on a Linux system to talk to another simulator running on a Windows host using network sockets (it also worked with UNIX domain sockets). And actually we are implementing a SystemC simulation talking to an FPGA on an accelerator card via device files. Unfortunately I'm not aware of freely available examples to do so. But if you have some C/C++ code to deal with the netlink sockets you can just embed this code into the simulator e.g. as part of a sc_module and tie it to the simulation phases (open the socket during start_of_simulation(), closing them during end_of_simulation()).
  • Create New...