Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


karthickg last won the day on June 5 2019

karthickg had the most liked content!

Profile Information

  • Gender
    Not Telling
  • Location
    Bangalore, India

Recent Profile Visitors

1,365 profile views

karthickg's Achievements


Member (1/2)



  1. Maybe once co-routines are in C++20? https://en.cppreference.com/w/cpp/language/coroutines
  2. That still is a problem with SC_ONE_WRITER policy. Quoting from LRM (my emphasis): See the change if you declare sig as: sc_signal<bool, SC_MANY_WRITERS> sig;
  3. Check the documentation of SC_ONE_WRITER and SC_MANY_WRITERS in the LRM. The default value of the "WRITER_POLICY" in sc_signal is SC_ONE_WRITER.
  4. Are you only looking at disabling process_output from getting triggered when reset is on? In that case, it is as simple as: void fir::process_output() { if (reset.read() == 0) { //reset sequence next_trigger(reset.pos()); } else if (clk.read() == 0) { //Ignore the trigger just after reset is de-asserted and //sync to next clock edge next_trigger(clk.pos()); // Note: will work even if we comment out line above, due to static sensitivity } else { if(enable.read()) { //normal operation } } } But this may not really get you a significant improvement in itself. You may want to check what is going on in "normal operation" - and see if you can optimize that.
  5. I'm guessing you are trying to read the signal values immediately after calling write(). That won't return the values just written due to how update semantics work with primitive channels in SystemC. To make sure this is the cause of confusion, you can try creating a thread in your model where the signal values are written and read back after a delta-cycle wait: SC_MODULE(some_module) { sc_signal<pixel> p1; sc_signal<pixel> p2; void some_thread() { p1.write(pixel(1, 2, 3)); p2.write(pixel(4, 5, 6)); // Read and print p1 and p2 // Values won't be updated here wait(0, SC_NS); // Read and print p1 and p2 // Values will be updated here };
  6. Could be a CR-LF issue as well - in case the package was unzipped on Windows and then copied to the Ubuntu machine. Easiest way out will be to download the tar-ball again and unzip/untar on Ubuntu.
  7. It is possible to support "dynamic" model creation using SystemC, for example by reading command line parameters or a configuration file - if done before simulation starts. Once simulation starts, we can't create new models or add more ports. As an example, the following can be done: a. Have multiple top-levels, select one specific during a simulation run (using a command line argument or an environment variable or a config file, etc) b. Create models and connections "on the fly", based on a connection topology in a configuration file. An example can be, a network simulation where the number of end-stations change in every simulation run. c. Create bridges/switches that should add ports as and when connections are being made I do not know enough to answer to your questions in the later part of the post.
  8. Hi Bas, In trying to explain this a bit more, I looked up the double format. As per http://en.wikipedia.org/wiki/Double-precision_floating-point_format, the 8-byte double format can handle 15-17 significant decimal digits without loss of precision. When assigning, double d2 = (double) ull; the width of ull (4614 2566 5655 2045 848) is 19 significant decimal digits, which causes loss in precision.
  9. Hi Bas, Did you mean to say: double d = 3.1415926535897931; unsigned long long * ullp = (unsigned long long *) &d; out_port.write(*ullp); // sc_out<doubleunsigned long long> out_port; connected via sc_signal<doubleunsigned long long> to in_port unsigned long long ull = in_port.read(); // sc_in<doubleunsigned long long> in_port; connected via sc_signal<doubleunsigned long long> to out_port double * dp = (double *) &ull; Also, what is the output of sizeof(double) and sizeof(unsigned long long) in your case?
  10. [snip] SC_MODULE( sub_mod ) { sc_in<sc_bv<BUS_WIDTH> > in; . . sub_mod(sc_module_name nm,int BUS_WIDTH):sc_module(nm) { } }; The error has got nothing to do with SystemC, the code is not valid C++.. you can't use a constructor parameter ('int BUS_WIDTH') as a parameter to the template instance ('sc_in<sc_bv<BUS_WIDTH> >').
  11. The standard doesn't provide any "hooks" by which the user can control the order in which the processes must trigger. The standard only says (my emphasis):
  12. Hi Philipp, Thanks, I was curious to know why the standard doesn't implement set_sensitive for spawned processes, and your response clarifies that. The issue is not so much about having to use "wait(event_list)" instead of just "wait()" - that is not a disadvantage at all (for me). The main problem is different.. My design requires a spawned method to set a boolean flag (say, m_flag) whenever a certain event (say, m_event) fires. This can be easily done: // Where the method gets spawned sc_spawn_options opt; opt.set_sensitive(m_event); opt.dont_initialize(); // Note! opt.spawn_method(); sc_spawn(sc_bind(&my_module::flag_event, this, some_var), NULL, &opt); // .... // Method body: void my_module::flag_event(int some_var) { m_flag = true; next_trigger(); } However, if the method has to wait for sc_event_or_list, then set_sensitive can't be used, and so dont_initialize can't be used. The flag_event has to now distinguish between the invocation at start of simulation, and the subsequent invocations when an event in the or'd list fires: sc_spawn_options opt; opt.spawn_method(); m_did_initialize = false; // Note! sc_spawn(sc_bind(&my_module::flag_event, this, some_var), NULL, &opt); // .... // Method body: void my_module::flag_event(int some_var) { if(m_did_initialize) { m_flag = true; next_trigger(m_event_or_list); } else { m_did_initialize = true; next_trigger(m_event_or_list); } } This is just plain clumsy to read, and needs an extra if-check every time the method gets invoked. I can think of a way to eliminate the if-check at simulation time: by having one more spawned method, but that is even more clumsy code; not worth the run-time cost (in my case). So I guess I do not have any alternative here. Thanks for your inputs anyway.
  13. Hello, Thanks for your reply - after seeing which, I had to go back to the standard to check to ascertain what is allowed and what is not.. My understanding is as below.. Quoting from the specification: So - what you have written certainly applies to unspawned processes. For spawned processes, The only question that remains is, can set_sensitivity be called on processes spawned after start of simulation? I'm not able to find an explicit yes or no in the specification, however there is an example (page 66) that shows that set_sensitivity can be called after start of simulation.
  14. Try changing, //read what we have written: enable_s.write(0); address_en_s.write(1); wait(SC_ZERO_TIME); cout << "Output value: " << dataout_s.read() << endl; To, //read what we have written: enable_s.write(0); address_en_s.write(1); wait(SC_ZERO_TIME); wait(SC_ZERO_TIME); cout << "Output value: " << dataout_s.read() << endl; This is not the recommended solution! But only a step towards debugging the problem. Also, print the return value of sc_time_stamp() and sc_delta_count() in memory thread after wait(), and in the stimulus thread after each wait(SC_ZERO_TIME).
  • Create New...