• Content count

  • Joined

  • Last visited

1 Follower

About AmeyaVS

  • Rank
    Advanced Member
  • Birthday 02/28/1989

Profile Information

  • Gender
    Not Telling
  • Location

Contact Methods

  • Skype

Recent Profile Visitors

310 profile views
  1. Hello @katang, The error spawns from not specifying the namespace resolution correctly. Following code compiles without errors: NAME.h: #ifndef NAME_H_ #define NAME_H_ #include <systemc> SC_MODULE(NAME) { SC_CTOR(NAME); }; #endif // NAME_H_ NAME.cpp: #include "NAME.h" SC_HAS_PROCESS(NAME); NAME::NAME(sc_core::sc_module_name nm) //< Added sc_core namespace resolution. : sc_core::sc_module(nm) //< Added sc_core namespace resolution. {} Regards, Ameya Vikram Singh
  2. Hello @katang, It seems the macro NAME has not been defined. From the book they have mentioned about the file "NAME.h". There recommendation on providing simpler and cleaner declarations. Regards, Ameya Vikram Singh
  3. Hello @yosri, This is mostly a discussion forum. In-case you need help while having issues in implementing your design, then do post your queries here. While assuming members to straight away help you in your homework is too much to ask. Kindly show us some research input about the project and some implementation that you have written, and facing issues with them. It would be unwise to comment since one can have multiple implementation of the said requirement as it is too vague, plus show us some due diligence in researching about the topic you are working on. Regards, Ameya
  4. Hello @katang, Here is a modified source for Bit_Adder.h which emulates the delay between component/modules: #ifndef BIT_ADDER_H_ #define BIT_ADDER_H_ #include <systemc> #include <queue> template<typename T = bool> SC_MODULE(BIT_ADDER) { public: sc_core::sc_in<T> a, b, cin; sc_core::sc_out<T> sum, cout; SC_CTOR(BIT_ADDER): a("a") , b("b") , ci("cin") , sum("sum") , cout("cout") , delay(sc_core::sc_time(2, sc_core::SC_NS)) , eqSum("eqSum") , eqCarry("eqCarry") { SC_METHOD(do_add); sensitive << a << b << cin; dont_initialize(); SC_METHOD(drive_sum); sensitive << eqSum; dont_initialize(); SC_METHOD(drive_carry); sensitive << eqCarry; dont_initialize(); } void do_add(void) { T valA =; T valB =; T valCi =; T tmpCo = (valA & valB) | (valB & valCi) | (valA & valCi); T tmpSum = valA ^ valB ^ valCi; coq.push(tmpCo); sumq.push(tmpSum); eqSum.notify(delay); eqCarry.notify(delay); } void drive_sum(void) { T valSum = sumq.front(); sum.write(valSum); sumq.pop(); } void drive_carry(void) { T valCarry = coq.front(); cout.write(valCarry); coq.pop(); } private: sc_core::sc_time delay; sc_core::sc_event_queue eqSum; sc_core::sc_event_queue eqCarry; std::queue<T> sumq; std::queue<T> coq; }; // BIT_ADDER #endif // BIT_ADDER_H_ This should be drop-in replacement for your module. One thing you will have to change is the declaration where it would change something from: BIT_ADDER bitAdder to: BIT_ADDER<sc_logic> bitAdder Let us know if you need further clarification on how the module behavior is modeled. Regards, Ameya Vikram Singh
  5. Hello @katang, The way the SystemC library is configured by default it doesn't create system threads(OS threads). That is it uses "user-space library" for creating the notion of parallel execution of threads(in user-space). This depends on the platform and configuration option provided to SystemC kernel while building it. e.g: In Windows under Visual Studio it uses the fiber user space threading library for execution of SC_THREAD's/CTHREAD's. In UNIX/Linux you can use QuickThreads (User-space threading) which is selected by default while running the configuration option for SystemC library. As per the OS it only sees one thread of execution for the whole simulation. Note: In-case you have configured the SystemC library with pthreads in Linux/UNIX like environment then the debugger will show you multiple threads of execution. Even in that scenario you can look here for reference on gdb and multi-threaded debugging, by default on most Linux systems the GDB suspends other threads making it easier to narrow down thread racing condition(the OSCI SystemC kernel sceduler implementation is already synchronized with the main execution thread of the SystemC application). As per your question The answer is: Yes it is possible to run the SystemC simulation stepwise while is debugging mode. In-case you need more clarification let us know. Regards, Ameya Vikram Singh
  6. Hello @sumit_tuwien, If you can elaborate the use-case more, it would be better. It seems you are trying to implement your own channel interface, if my assumptions are right. If you are just looking for custom datatype which you need to push through the sc_in/out interface then this might not be required at all. Let us know. Regards, Ameya Vikram Singh
  7. Hello @sumit_tuwien, You can declare the sc_trace method as a friend function. Here is a small sample of what it might look like: # ifndef ALLESGUTE_H_ # define ALLESGUTE_H_ # include <cstdint> # include <systemc> template < typename T > class allesGute final : public sc_core::sc_object { private : T vData ; T someOtherVData ; public : explicit allesGute(const char* name_) : sc_core::sc_object { name_ } , vData { 0 } {} const char* kind() const override { return "allesGute" ; } // Helpers : T read() const { return vData ; } void write(const T& var_) { vData = var_ ; } ~allesGute() final = default ; allesGute(const allesGute& other) = delete ; allesGute& operator=(const allesGute& other) = delete ; allesGute(allesGute&& other) = delete ; allesGute&& operator=(allesGute&& other) = delete ; // Friend function declaration. // Don't inline the definition since you might face issues later due to aggressive compiler optimizations. friend void sc_trace(sc_core::sc_trace_file *tf, const allesGute<T>& tObj, const std::string& name); }; // Friend function definition. template<typename T> void sc_trace(sc_core::sc_trace_file *tf, const allesGute<T>& tObj, const std::string& name) { // Assuming the type T is traceable type. // If not then you'll have to implement the sc_trace friend function for type T. sc_trace(tf, tObj.vData, name + "_vData"); sc_trace(tf, tObj.someOtherVData, name + "_someOtherVData"); } # endif Let me know if this helps. Regards, Ameya Vikram Singh
  8. Hello @sumit_tuwien, Is the allesGute template class derived from sc_object? If yes, then it will be straightforward to find object using sc_find_object. While instantiating the allesGute object you would be providing the name (object name during construction), which will be registered with the SystemC kernel at the right hierarchical level. Hope this helps. Regards, Ameya Vikram Singh
  9. Hello @SRachuj, Please find the comment in-line: while (1) { sc_time t; std::cout << sc_get_curr_simcontext()->next_time(t) << ": " << t << std::endl; //< It hits the call to next_time(t) when the simulation has ended or did not even begin. sc_start(sc_time(1, SC_NS)); sleep(1); } You are calling the next_time(t): when the simulation has not even started so no events would be scheduled in the SystemC kernel. In the next pass once you have started the simulation for 1 ns. The simulation kernel will delete all the events which are scheduled after 1 ns. Try running putting the code in the module B. void t() { sc_time t; //< Added the sc_time state variable. while (1) { wait(in.value_changed_event()); std::cout << sc_get_curr_simcontext()->next_time(t) << ": " << t << std::endl; //< Added the next_time(t) in Module B. std::cout << "got: " << << std::endl; } } Regards, Ameya Vikram Singh
  10. Hello @makiso, The error message it-self is providing you hint about the port interface not bound. From chol.h (checkout the inline comments): ... SC_MODULE (chol) { public: // Inputs sc_in_clk clk; //< This probably is port_0 sc_in<bool> rst; //<This probably is port_1 sc_in<sc_fixed<16,10, SC_TRN, SC_WRAP> > chol_in_data[3][3] ; //< port_2 to port_11 // Output sc_out<sc_fixed<16,10, SC_TRN, SC_WRAP> > chol_out_data[3][3] ; //< port_12 to port_20 /* F */ void chol_main ( void ); //sc_fixed<32,16, SC_TRN, SC_WRAP> cholesky(sc_fixed<32,16, SC_TRN, SC_WRAP> *); // Constructor SC_CTOR (chol): // have initializer list here for your interfaces to help you in debugging the code. // e.g.: chol_out_data("chol_out_data") { SC_CTHREAD (chol_main, clk.pos() ); reset_signal_is(rst, false) ; sensitive << clk.pos(); } // Destructor ~chol() {} }; ... This following binding operation is incomplete(see commment inline): Note: Refer here for initialize list(checkout the example use-case): Try out these changes and let us know if it helped you. Regards, Ameya Vikram Singh
  11. Hello @SysC_Lrnr, @ralph.goergen is right you need to use sc_vector's for SystemC objects. Also use C++ built-in datatype's (bool, char, short int, int, etc.) to have better performance and better compiler optimizations. For small designs you would not feel the need but as you would add complexity to your SystemC simulation models you'll start noticing the difference. Regards, Ameya Vikram Singh
  12. Thank you @ralph.goergen for providing the SystemC LRM reference. Regards, Ameya Vikram Singh
  13. Hello @katang, It would be better that you start here from this tutorial: Then refer the earlier post for delay simulation: Checkout my reply to the post which references this: Finally check my comment on how to do away with the SC_THREAD to improve performance of the simulation: in-case you have more questions or need more elaboration on the answer let me know. Regards, Ameya Vikram Singh
  14. Hello @katang, I have just taken cursory look into it, I think you are confusing the sc_fifo implementation which is just a communication abstraction for use in SystemC. What I think you are looking at is a module based communication model. Have a look here for hierarchical channels: Let me know if this helps you. Regards, Ameya Vikram Singh