Jump to content

Eyck

Members
  • Posts

    220
  • Joined

  • Last visited

  • Days Won

    65

Eyck last won the day on July 5

Eyck had the most liked content!

8 Followers

Contact Methods

  • Website URL
    http://www.minres.com/

Profile Information

  • Gender
    Male
  • Location
    Munich, Germany

Recent Profile Visitors

1,223 profile views

Eyck's Achievements

Advanced Member

Advanced Member (2/2)

99

Reputation

  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
×
×
  • Create New...