Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. I believe the original intent was to be able attach "attributes" in the general sense to modules, channels, ports, processes and other "objects", which could be used for unforeseen or unaddressed needs in the future. For instance, if you wanted to add power information to certain modules (e.g. static leakage), and then add some type of processing to analyze power consumption either dynamically or later. This has been used internally at a few companies and I hope the feature will stick around. Although, the CCI (Control, Configuration & Inspection) WG (Working Group) of Accellera may argue their "configuration" solution may better address these ideas. [Personally, I have not seen the current CCI solution to work on all platforms yet (implementation needs more work) and the documentation needs more work. I think there are some issues with the version of SystemC and C++ compiler features.] You download/install/test CCI from https://accellera.org/downloads/standards/systemc .
  3. I am trying to understand what is the intention behind using sc_attribute, what advantage does it give. From what I can read from the LRM it is just a container that binds classes to sc_objects, but for what purpose? When should I use them and when should I avoid them, any good advise out there?
  4. The behavior of SystemC matches what I expect, but is not what you are wanting to do. My suggestion of how to write the output holds; however, that will not fix the error. My suggestion does make it likely that you might wonder what the write() method does and not fall prey to the assumption that assignment is simply assignment. If you want to move the process to the end of the current delta-cycle, you can insert: wait(SC_ZERO_TIME); just prior to where you display the value after writing it. If you want to avoid two calls to the SC_METHOD process, add: dont_initialize(); after the SC_METHOD declaration. Do not apply this into the SC_THREAD though or that piece of code will never run. Suggestion: Get a book on SystemC such as SystemC: From the Ground Up (I might be biased 😉) and read its description of the simulator.
  5. Yesterday
  6. Hello Mr. Black, Thank you for the quick reply. I didn't quite understand what you exactly mean, but, I will try finding some material where i can learn how a co-operative multitasking event driven simulator works. But, did you mean to suggest that I use bus_o->write(VALUE); instead of bus_o = VALUE; I tried this, and I still get the same issue. The question that still haunts me is , why does busin in my datagen file updates after 1ns? I can already see the value in inputs.cpp at 0 NS. (Note : Inputs.cpp file receives busin value from datagen) If you mean to say that the behavior is correct and I don't have to modify anything in my code, then it's all good. Here, I am attaching datagen.h SC_MODULE(datagen) { public: sc_out<sc_bv<8>> busin_o; SC_CTOR(datagen); /*private:*/ void testgen(void); void asTakt(void); }; and inputs2.h SC_MODULE(inputs) { public: sc_in<sc_bv<8>> busin; sc_out<sc_bv<8>> pout; sc_out<sc_bv<8>> out; SC_CTOR(inputs); private: /* method*/ void mydesign(void); }; Please find the updated datagen.cpp, below void datagen::testgen(void) { busin_o->write("11111111"); cout<< "-------------------------------------"<< endl; cout << "In dataGen::testgen: @" << sc_time_stamp() << " Busin in datagen: "<< busin_o <<endl; wait(1,SC_NS); cout<< sc_delta_count() << endl; busin_o->write("00111111"); cout<< "-------------------------------------"<< endl; cout << "In dataGen::testgen: @" << sc_time_stamp() << " Busin in datagen: "<< busin_o <<endl; wait(1,SC_NS); busin_o->write("10000111"); cout<< "-------------------------------------"<< endl; cout << "In dataGen::testgen: @" << sc_time_stamp() << " Busin in datagen: "<< busin_o <<endl; wait(1,SC_NS); busin_o->write("11111110"); cout<< "-------------------------------------"<< endl; cout << "In dataGen::testgen: @" << sc_time_stamp() << " Busin in datagen: "<< busin_o <<endl; cout<<"Intended end of simulation"<< endl; sc_stop(); } And the inputs.cpp file still remains the same inputs::inputs(sc_module_name inst) : sc_module(inst) { cout<<"Constructor- inputs: "<< name() <<endl; SC_METHOD(mydesign); sensitive << busin; } void inputs::mydesign() { cout<< "-------------------------------------"<< endl; cout<<"Mydesign Activated @ "<<sc_time_stamp() <<endl; cout<< "-------------------------------------"<< endl; cout << "In Inputs::mydesign: @" << sc_time_stamp() << " Busin in Inputs: "<< busin <<endl; pout-> write(busin.read()); cout << "In Inputs::mydesign: @" << sc_time_stamp() << " pout in Inputs: "<< pout <<endl; } Please let me know if you find a problem with the code. Thanks a ton.
  7. hey. thanks for replying. the code that i posted was a snippet. it did include the wait() statement. so my questions still remains: 1. what is the right use case for SC_CTHREAD ? 2. why in my give example the simulation gets "stuck" ? thanks
  8. By default all processes are called once at time zero. Outputs on sc_signal are updated after the end of the delta cycle, which consumes no simulated time, but causes your method to be scheduled to run at the same time. What appear to be blocking assignments to the programmer's eyes are in fact non-blocking assignments that schedule updates to happen at the end of the current delta cycle. Assuming your bus_o is an sc_in<int>, which is a specialized sc_port< sc_signal_inout_if<int> >, then bus_o = VALUE; turns out to be equivalent to bus_o->write(VALUE); You need to learn how a co-operative multitasking event driven simulator works, and then you will fully understand.
  9. Hello All, I am a beginner in SystemC, and I really need your help in solving a timing issue. Please find my code attached : datagen::datagen(sc_module_name nm) :sc_module(nm) { cout<<"Constructor- datagen: "<< name() << endl; SC_THREAD(testgen); } void datagen::testgen(void) { busin_o="11111111"; cout<< "-------------------------------------"<< endl; cout << "In dataGen::testgen: @" << sc_time_stamp() << " Busin in datagen: "<< busin_o <<endl; wait(1,SC_NS); cout<< sc_delta_count() << endl; busin_o="00111111"; cout<< "-------------------------------------"<< endl; cout << "In dataGen::testgen: @" << sc_time_stamp() << " Busin in datagen: "<< busin_o <<endl; wait(1,SC_NS); busin_o="10000111"; cout<< "-------------------------------------"<< endl; cout << "In dataGen::testgen: @" << sc_time_stamp() << " Busin in datagen: "<< busin_o <<endl; wait(1,SC_NS); busin_o="11111110"; cout<< "-------------------------------------"<< endl; cout << "In dataGen::testgen: @" << sc_time_stamp() << " Busin in datagen: "<< busin_o <<endl; cout<<"Intended end of simulation"<< endl; sc_stop(); } /* inputs2*/ inputs::inputs(sc_module_name inst) : sc_module(inst) { cout<<"Constructor- inputs: "<< name() <<endl; SC_METHOD(mydesign); sensitive << busin; } void inputs::mydesign() { cout<< "-------------------------------------"<< endl; cout<<"Mydesign Activated @ "<<sc_time_stamp() <<endl; cout<< "-------------------------------------"<< endl; cout << "In Inputs::mydesign: @" << sc_time_stamp() << " Busin in Inputs: "<< busin <<endl; pout-> write(busin.read()); cout << "In Inputs::mydesign: @" << sc_time_stamp() << " pout in Inputs: "<< pout <<endl; } I have 2 issues The first one is that mydesign block is being called twice @ 0 NS . (Can be seen in the screenshot) The second is that the assignment of busin_o in the datagen file is happening with a delay of 1ns, whereas in inputs2.cpp, it is happening correctly. But again, the assignment of busin to pout is not happening at the same time as it happens after 1 ns. I am really confused as to why the behavior is like this. Any help is appreciated. I have a feeling that there is a small timing error somewhere, but I am not able to fix it. Please help me. All the codes are attached for further reference. top2.h top2.cpp main2.cpp inputs2.h inputs2.cpp datagen2.h datagen2.cpp
  10. Last week
  11. You are missing at minimum a single wait() in the infinite loop. SystemC is an event driven simulator and as such concurrency is modeled using co-operative multi-tasking. An infinite loop is an infinite loop. No pre-emption.
  12. Hey all. i am a novice user of SystemC, and couldn't find an answer to the following question? ive noticed that when ever i tried using SC_CTHREAD(proc_name, clk.pos()) -> the simulation time was increased significantly (to a level where it appeared to be stuck). what is the right use of SC_CTHREAD so that it doesnt jam the simulation? i am adding an example of what i did: SC_CTHREAD(monitor_intr_in, clk.pos()); ... void TMG_helper::monitor_intr_in() { while(true) { cout << "i am here" << endl; } } thank you in advance !
  13. True. It means that the updates should be made to sc_fifo.h: template <class T> inline void sc_fifo<T>::read( T& val_ ) { while( num_available() == 0 ) { sc_core::wait( m_data_written_event ); } bool read_success = sc_fifo<T>::nb_read(val_); if( !read_success ) { sc_assert( read_success ); } }
  14. The 2020 edition of the SystemC AMS user's guide is available here https://www.accellera.org/downloads/standards/systemc
  15. The Accellera SystemC AMS Working Group released the 2020 edition of the SystemC AMS User's Guide. You will find the user's guide on this page: https://www.accellera.org/downloads/standards/systemc This version of the user's guide is fully compatible with the SystemC AMS standard released as IEEE Std. 1666.1-2016. It describes all the features introduced in the SystemC AMS language standard during the last decade. For example, the user’s guide now explains the use of the dynamic timed data flow capabilities, to make AMS system simulations even more efficient and running even faster. The SystemC AMS Working Group is currently preparing the release of the user's guide application examples as separate download. Availability of these application examples will be communicated at a later stage. Please use this forum to post your questions or remarks on the user's guide.
  16. sc_assert does the same as the C std lib assert. You probably don't want to paste `expr` in the macro in case it has side effects (not that you should be doing that).
  17. Earlier
  18. Your DVCon paper discusses the use of UVM Connect with the scoreboard and reference models, but the code and documentation that is the part of your download makes no mention of UVM Connect. Is there any example code available that demonstrates the application of UVM Connect in conjunction with the scoreboard?
  19. Hi Patrick you can compile with -DSC_FXDIV_WL=128 to increase max precision of the div operation 100 | .3333333333333333333333333333330703796982596627315294238115724045901089311882969923317432403564453125 | 0b000000000.0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101 101 | .3333333333333333333333333333330703796982596627315294238115724045901089311882969923317432403564453125 | 0b000000000.01010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010 102 | .333333333333333333333333333333267594924564915682882355952893101147527232797074248082935810089111328125 | 0b000000000.010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101 103 | .333333333333333333333333333333267594924564915682882355952893101147527232797074248082935810089111328125 | 0b000000000.0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010 104 | .33333333333333333333333333333331689873114122892072058898822327528688180819926856202073395252227783203125 | 0b000000000.01010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101 105 | .33333333333333333333333333333331689873114122892072058898822327528688180819926856202073395252227783203125 | 0b000000000.010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010 106 | .3333333333333333333333333333333292246827853072301801472470558188217204520498171405051834881305694580078125 | 0b000000000.0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101 107 | .3333333333333333333333333333333292246827853072301801472470558188217204520498171405051834881305694580078125 | 0b000000000.01010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010 108 | .333333333333333333333333333333332306170696326807545036811763954705430113012454285126295872032642364501953125 | 0b000000000.010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101 109 | .333333333333333333333333333333332306170696326807545036811763954705430113012454285126295872032642364501953125 | 0b000000000.0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010 110 | .33333333333333333333333333333333307654267408170188625920294098867635752825311357128157396800816059112548828125 | 0b000000000.01010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101 111 | .33333333333333333333333333333333307654267408170188625920294098867635752825311357128157396800816059112548828125 | 0b000000000.010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010
  20. Yes, it can be compiled against SystemC 2.3.3. There are even packages for Conan (conan.io) available at bintray (https://bintray.com/minres/conan-repo) where SCV is built against SystemC 2.3.3 RB
  21. Hello, is SCV 2.0.1 usable with Systemc 2.3.3 ? The SCV page only mention SystemC 2.3.2 Thanks by advance
  22. Hi Anupam - Thank you for the feedback. Responses below: #1 - It seems the addressable register configuration is better categorized as an asset or part of the attack surface, not a type of IP Family. If this doesn't address your concern, please let me know. #2 - The scope is in reference to the Condition which may be different from the Asset's scope (e.g. the Condition could be located in another module). In the next release, we will clarify this. Thank you for bringing this to our attention. #3 - Oversight. Will include in the next release. Thanks, Brent
  23. Hi everyone, the link in this original post from 2012 has expired as the material is obsolete. Cadence has provided us with a new link to updated videos, which can be found here: https://www.youtube.com/user/CadenceDesign/search?query=SystemVerilog All of the videos at that link are open to the public and most of them are tutorials in the spirit of the original set.
  24. Hi Justin, Thanks for your reply. I don't have the modified code yet. But I'd like to make my proposal clearer as below. The problems with the factory are: An associative array lookup step needs to be done to retrieve instance override info of requested_type: uvm_factory_queue_class qc; qc = m_inst_override_queues.exists(requested_type) ? m_inst_override_queues[requested_type] : null; Iterate through m_override_info queue to check for override loop. Iterate through m_type_overrides queue to check for type override. Recursive calls of find_override_by_type() for the case of "B overrides A, C overrides B, etc": (in function find_override_by_type) // inst override; return first match; takes precedence over type overrides if (full_inst_path != "" && qc != null) for (int index = 0; index < qc.queue.size(); ++index) begin ... return find_override_by_type(qc.queue[index].ovrd_type,full_inst_path); // type override - exact match foreach (m_type_overrides[index]) begin if (m_type_overrides[index].orig_type == requested_type || ... return find_override_by_type(m_type_overrides[index].ovrd_type,full_inst_path); All above things happen for every creation of a UVM object which uses the factory. So I propose to put type override and instance override information in the type proxy itself (i.e, uvm_object_wrapper), so that we can get the override info directly from requested_type and no more lookup needed. It's responsibility of set_type_override_by_type() to do all the awful stuffs, because this method is called only once for each override setting. The override info inside uvm_object_wrapper should be: ovrd_insts [$]: a queue of {<instance-path>, <override-type>} pairs for instance override. ovrd_type: for type override. Set to this type when the type specialization is created or registered to the factory. affected_types [$]: a queue of types that are overriden by this type. Used like a linked-list pointer for set_type_override_by_type() to traverse in the mentioned case "B overrides A, C overrides B, etc". Pseudo code of set_type_override_by_type (original_type, override_type) is as below: function set_type_override_by_type (original_type, override_type) { __set_type_override_by_type (original_type, override_type); // add original_type into 'affected_types' of override_type override_type.affected_types.push_back(original_type); } function __set_type_override_by_type (original_type, override_type) { original_type.ovrd_type = override_type.ovrd_type; // note: ovrd_type defaults to the container type // until it is overriden. // set override for each affected_type of original_type. // may be recursive for each affected_type child of that affected_type, ... foreach original_type.affected_types[i] { if original_type.affected_types[i] == override_type.ovrd_type error("Override loop detected"); else __set_type_override_by_type(original_type.affected_types[i], override_type.ovrd_type) } } Pseudo code of create_object_by_type (): no more lookup or recursive calls to find the override type. function uvm_object create_object_by_type (uvm_object_wrapper requested_type, string parent_inst_path="", string name); // ... code to make full_inst_path from parent_inst_path, etc as in current uvm-1.2 code // instance override. takes precedence over type override. foreach requested_type.ovrd_insts[i] begin if(uvm_is_match(requested_type.ovrd_insts[i].full_inst_path, full_inst_path)) return requested_type.ovrd_insts[i].ovrd_type.create_object(name); end // type override return requested_type.ovrd_type.create_object(name); endfunction The modification for this point is rather simple, but it may impact other functionalities such as factory.print() and name-based override. So please give me some time to do the modification thoroughly. I'll get back when it's done. Best regards, Thien
  25. include/sysc/communication/sc_fifo.h:269:10: warning: unused variable ‘write_success’ [-Wunused-variable] bool write_success = sc_fifo<T>::nb_write(val_); include/sysc/communication/sc_fifo.h:226:10: warning: unused variable ‘read_success’ [-Wunused-variable] bool read_success = sc_fifo<T>::nb_read(val_); sc_fifo.h: bool write_success = sc_fifo<T>::nb_write(val_); sc_assert( write_success ); sc_report.h #if defined(NDEBUG) && !defined(SC_ENABLE_ASSERTIONS) // disable assertions #define sc_assert(expr) \ ((void) 0) .... i.e. expr is not addressed when assertions are disabled This is resolved with #if defined(NDEBUG) && !defined(SC_ENABLE_ASSERTIONS) // disable assertions #define sc_assert(expr) \ ((void)(expr)) ....
  26. Hi, while implementing a project I noticed that my calculations using sc_dt::sc_ufix won't get more accurate when increasing the fractional bit width. As you can see in the following example I'm increasing the number of fractional bits and calculate 1/3: #include <iostream> #include <iomanip> #include <systemc.h> int sc_main(int argc, char *argv[]) { { int i = 9; do { sc_fxtype_context evalContext(sc_fxtype_params(i, 8)); sc_dt::sc_ufix a = 1; sc_dt::sc_ufix b = 3; sc_dt::sc_ufix r = a / b; std::cout << std::setw(3) << std::setfill('0') << i - 8; std::cout << " | " << r << " | " << r.to_bin() << std::endl; i++; } while (i < 120); } return (0); } While the results look as expected at first, they won't change any more after the 64th fractional bit (output.txt). Why is this happening? I can use fractional bits >= 64 (e.g. by shifting to the right), but my calculations don't use them. None of them uses any bits beyond the 64th, thus increasing the fractional accuracy has no effect. Searching in the standard I wasn't able to find a restriction for calculations with finite-precision fixed-point numbers, only for different types (limited-precision fixed-point calculations like sc_dt::sc_ufix_fast for example should not exceed 53 bits).
  27. Thien- Agreed, there's a lot of performance lost in the factory, although we usually see that on the name-based side of town (as opposed to the type-based). Do you have a proposal/code edit that we could inspect and test? This sounds strikingly similar to an enhancement that we've been looking at on the uvm_callbacks side of town as well. -Justin PS- UVM 1.2 is technically deprecated at this point. Any changes would actually be ported forward to the next 1800.2 release.
  28. Hello David thanks so much for your quick answer, time and valuable support. The above code style show by you is really helpful for me and you are alright about it just work stricly for simulation purposes. But it works, making short size some of my header files and more esthetic. About the synthesis tool you are right up to my understanding, so I will give a try with another vendor HLS tool, cause that is something that I am trying to figure out with the actual project with the aim to get at the end a RTL from a relatively complex digital design in SystemC, but as you mention the standard is not enough to define how to implement, or may be not just the standard the vendors lag of a proper guidelines for this.
  1. Load more activity
  • Create New...