Jump to content


  • Content Count

  • Joined

  • Last visited

  1. I hope this description makes sense. In the model I'm working on (which is a port of an existing model in SystemVerilog), there are two threads (rx and tx) that modify some shared flags. I am working on getting my timing as close to the SystemVerilog model as possible, and currently there is a problem of falling behind a few cycles because each cycle, the rx runs after the tx, where in the SV model the tx runs after the rx. I believe that conceptually both threads are supposed to executing concurrently, so I know it may not make good sense to think of one thread executing before the other. So I am wondering what the best way to approach this is. Is there a way to change the order in which threads sensitive to the same clock signal are executed? OR, do I need to concentrate on the shared data and communicate between threads with events?
  2. I am wondering if there is a preferred (official or unofficial) coding and style convention in the SystemC community? I'm talking about things like variable and class names, member data prefixes, function parameter prefixes, automatic variable prefixes, etc. If there is no consensus feel free to comment on YOUR favorite!
  3. richpodraza

    Trouble with this addition operation...

    Thanks guys, this general idea is what I needed!
  4. I have two sc_bv<256> objects and am trying to add a range selection of each and store the result in a sc_bv<128>. Here is the code sc_bv<256> wdata; sc_bv<256> rdata; // wdata and rdata get populated here sc_bv<128> result; result = rdata.range(127, 0) + wdata.range(63, 0); // compiler error! I have tried things like to_uint() following the range() functions, but that doesn't give me the range I want (cuts it off at 32 bits) and I don't think even to_longuint() is enough. I tried to convert these to sc_bigint<128>, but that gives a compiler error too. sc_bigint<128> temp1 = rdata.range(127, 0); // compiler error! Can anyone recommend a solution? It seems trivial to me but I've been looking at this for a while and can't find one. Thanks!
  5. richpodraza

    Debugging an sc_lv related crash

    I eventually found my problem with this and of course it was a simple oversight. The code called resize() and clear() on a vector, in that order, and meant to do the opposite. However, the simulation wasn't crashing on accesses to the vector, it was crashing on an unrelated line, which is partly why it was so hard to spot! Thanks for the help along the way.
  6. richpodraza

    Debugging an sc_lv related crash

    Regarding the Rule of Three here, none of my classes in question are managing their own resources. My classes all consist of types either from std or systemc. My understanding is the default assignment/copy/destructors for these should be sufficient as those classes that make up my class implement the resource management. Is that correct?
  7. richpodraza

    Debugging an sc_lv related crash

    Thanks for the suggestions so far. I will try to reproduce in a smaller, manageable example and debug or post that. Also the tip about copy constructors and assignment operators is not something I've considered.
  8. I am struggling to resolve a crash in some code I'm working on. I don't want to post the code just yet because I think I would need to post a lot of it in order to provide all the relevant details. Here is a majorly simplified description: - There is a structure that contains some sc_bv fields, as well as a deque< sc_lv<32> > called data. - An instance of this structure is passed by constant reference to a function and is used to fill another buffer of the same size. - After the other buffer is filled, accesses to this structure's other fields in a cout << operation crash. Keep in mind this is a constant reference object and no changes are made to it. The same cout << operation works fine before the other buffer is filled. EDIT: in fact, completely separate objects show the same behavior where accesses to them before work but after crash. It seems like a memory problem. Now I know that is sparse information but based on the stacktrace below, can anyone hazard a guess about what's happening? So far I have verified that all the index values used when accessing both the deque and it's containing sc_lv objects are in-bounds, and I've verified that values within the structure are valid and print out before the buffer fill. Could I have a problem with my libc.so.6? Or another environment issue? A memory problem? Any suggestions on how to better debug this? Thanks! GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>... Reading symbols from /home/sc_hmc/sc_hmc...done. [New LWP 8994] warning: Can't read pathname for load map: Input/output error. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". Core was generated by `./sc_hmc'. Program terminated with signal 11, Segmentation fault. #0 0x0043b10f in ?? () from /lib/i386-linux-gnu/libc.so.6 (gdb) where #0 0x0043b10f in ?? () from /lib/i386-linux-gnu/libc.so.6 #1 0x0043dddc in malloc () from /lib/i386-linux-gnu/libc.so.6 #2 0x00e78627 in operator new(unsigned int) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #3 0x00e5d7d4 in std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #4 0x00e5eacf in std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #5 0x00e5ebfe in std::string::reserve(unsigned int) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #6 0x00e5f316 in std::string::operator+=(char) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #7 0x08051ed5 in sc_dt::sc_proxy<sc_dt::sc_bv_base>::to_string (this=0x8b5ebf4) at /home/systemc-2.3.0/include/sysc/datatypes/bit/sc_proxy.h:1325 #8 0x08053efa in sc_dt::sc_proxy<sc_dt::sc_bv_base>::print (this=0x8b5ebf4, os=...) at /home/systemc-2.3.0/include/sysc/datatypes/bit/sc_proxy.h:452 #9 0x080529f3 in sc_dt::operator<< <sc_dt::sc_bv_base> (os=..., a=...) at /home/systemc-2.3.0/include/sysc/datatypes/bit/sc_proxy.h:1524 #10 0x0805f678 in pkg_pkt::cls_req_pkt::build_pkt (this=0x8c19c70, cad=..., credit_return=@0x8b5eaf8: 512, tag0=@0x8b5ed04: 0, seq=@0x8b5ed24: 0) at pkt.svp.cpp:409 #11 0x0813921b in pkg_drv::cls_drv::run_tx (this=0x8b5ea58) at pkg_drv.sv.cpp:205 #12 0x0017becf in sc_core::sc_thread_cor_fn(void*) () from /home/systemc-2.3.0/lib-linux/libsystemc-2.3.0.so #13 0x00163494 in sc_cor_qt_wrapper () from /home/systemc-2.3.0/lib-linux/libsystemc-2.3.0.so #14 0x00183740 in ?? () from /home/systemc-2.3.0/lib-linux/libsystemc-2.3.0.so
  9. richpodraza

    Syncing multiple clocks

    Note, I've realized I can kind of solve my problem by scaling the clock periods up so the division is even. e.g. make the reference clock period 24000. For the sake of studying the concept though I am still interested in whether explicitly syncing clocks is supported or recommended in SystemC
  10. richpodraza

    Syncing multiple clocks

    I have roughly the following clock scheme set up double refclk_period = 8000; double ck1_ratio = 10; double ck2_ratio = 5; double ck3_ratio = 6; sc_clock refclk("refclk", refclk_period, SC_PS); sc_clock ck1("ck1", refclk_period/ck1_ratio, SC_PS); sc_clock ck2("ck2", refclk_period/ck2_ratio, SC_PS); sc_clock ck3("ck3", refclk_period/ck3_ratio, SC_PS); Then I have SC_THREADs sensitive to each clock's pos(). I've realized a problem which is that eventually ck3 will get quite out of sync since it does not divide the refclk period evenly. For example at 8000 ps, the SC_THREAD watching ck3 last hit at 7998 ps. Ideally all the clocks should be firing at 8000 ps. This has got to be a common problem. Is there a recommended way to sync clocks with SystemC? Thanks!