Jump to content

David Black

Members
  • Content count

    237
  • Joined

  • Last visited

  • Days Won

    49

David Black last won the day on March 8

David Black had the most liked content!

5 Followers

About David Black

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

920 profile views
  1. async_request_update() multiple events

    Remember that the SystemC OS thread is completely asynchronous to external threads and processes. Async_request_update() simply says to call update() once at the end of the delta cycle for a single object. So you can get multiple notifications within the same delta and only get one call-back. To keep from losing these you should setup a threadsafe mailbox/queue. Rather than just notify the event, you should also put an entry into the mailbox on each activation. Then your threadsafe update() method can see the multiple requests accurately.
  2. Changing the width in sc_bv<W>

    These questions have little to do with SystemC per se, and are really about C++. Templates are all about compile-time elaboration and template arguments must be compile-time computable. If you use C++11 or later, then various forms of constexpr functions may be available, but they are still compile-time issues. You could of course use sc_bv_base and its constructors, but keep in mind that modules, ports, and other "hardware" constructs are not allowed to be modified after end_of_elaboration. KEY POINT: To be an effective SystemC designer, you MUST be proficient at C++. Minimal C++ is NOT enough. Knowledge of C (even expert knowledge) is totally inadequate and in some cases downright harmful. Furthermore, really good SystemC often requires excellent C++ skills. Therefore, before you even consider learning much in SystemC, you really should invest in a solid C++ course. Expert SystemC practitioners take time to continually update their C++ skills. If this does not sound like fun to you, then I would advise choosing a different discipline.
  3. SystemC _ what is mean symbol "\" ??

    To be slightly more precise, the back-slash character (\) has two contexts. In this context, it is an escape character for CPP, the C Pre-Processor. It should only be used when using the pre-processor #define directive. Without \, the #define must be kept entirely on a single line. The other context for which \ is used, is inside literal strings and and character constants. Examples: "Hello world\r\n" and "\n". In these cases, it serves to provide an escape to introduce non-printable ASCII characters.
  4. define sc_main in VS 2017

    Don't change the default entry point and don't define main. Main is already pre-compiled inside the library!
  5. Passing collected events to sensitive

    You are specifically referring to static sensitivity. Perhaps you should consider using dynamic sensitivity instead. You can use sc_event_and_list and sc_event_or_list to build up appropriate sensitivities.
  6. This happens because sc_port overloads operator[]. You need to use sc_vector tlm::tlm_initiator_socket<32,tlm::tlm_base_protocol_types,0,SC_ZERO_OR_MORE_BOUND> Out; SC_MODULE(Target) { sc_core::sc_vector< tlm::tlm_target_socket<32,tlm::tlm_base_protocol_types,1,SC_ZERO_OR_MORE_BOUND> > In; SC_CTOR(Target) : In("In", 2) { ... } //< Number of elemements selected via sc_vector constructor } initiator_inst->Out.bind(target_inst->In); Note: Above is pseudo-code (i.e. not in all the right places), and I have not taken time to verify the detail, but the principle of using sc_vector is correct. You may need to consult the literature.
  7. Debugging Multi threaded program in SystemC

    The problem with using SC_METHOD is that it forces a style of coding that is harder to design/debug and slows down the design process. Schedule-wise SystemC is supposed to be written quickly. If you take too much time writing/debugging it, then it can become a counterproductive effort and you might as well write RTL alone. I usually characterize it as follows: Loosely-Timed models should be written in a matter of days (not weeks or months). Approximately-Timed models should be written in terms of a few weeks (not months). Anything longer means that either you are adding too much detail (which also slows down model execution) or you are not properly reusing other people's work (purchasing/acquiring pre-written models). So yes, I would use SC_METHOD when it's use is obvious/intuitive, but I would rather express ideas in the most natural manner to speed up development time, which often means using SC_THREAD.
  8. Backtrace with sc_report_error()

    Using your own report handler is a bit extreme; although, instructive. I suggest using the sc_report_handler::set_action() method. Please read the standards document (downloadable from IEEE via link on Accellera). It's quite readable.
  9. Debugging Multi threaded program in SystemC

    Ankur, I'm not sure where you got the advice that SC_THREADs are bad or cause context switching, because that is mostly just an old wives-tale. I did a study years ago that showed the difference between SC_METHODs and SC_THREADs is only 3%. Furthermore, it is a simulator implementation issue as the PoC implementation is only one of several. I know at least one implementation of the SystemC kernel actually had the advantage reversed (and it was faster than the PoC implementation). The real problem is context switching, which cannot be totally avoided in any case. Context switches occur everytime your SC_METHODs return or your SC_THREADs call sc_core::wait() even if indirectly (e.g. sc_fifo::read()). If you are having performance issues, you need to be profiling your code to identify the real problems. You can get rid of a lot of context switching if you simply elminate sc_clock's entirely from your design. Most engineers (esp. hardware focused) have a difficult time with this concept, but sc_clock causes two context switches per cycle and in many designs is entirely not needed. I did a presentation "Look Ma! No clocks!" (available somewhere under www.nascug.org) and demonstrated how a timer could be modeled accurately without clocks. A couple of other areas often missed are I/O and compiler switches. I/O is much bigger than context switching in terms of slowing down simulations, and yet still I often see engineers putting SC_REPORT_INFO (or worse: std::cout and printf) in their code to dump all the activity to aid debug. Except for phases before SC_SIMULATION, you should really use SC_REPORT_INFO_VERB with SC_DEBUG or equivalent. As to compile-time switches, -O3 is really quite decent once you have most bugs out, and you can leave debug -g on without worry.
  10. SC_METHOD and next_trigger() diagnostics

    Re. the error SC_METHOD is called repeatedly (every time an element of the static sensitivity list triggers); however, SC_METHOD processes must execute in single delta cycle (zero time). Blocking methods such as wait() is illegal there. Methods such as sc_fifo::write() call wait() and are therefore also illegal. To wait 10 ns, you can do something like this: #include <systemc> #include <iostream> struct Ex1 : sc_core::sc_module { Ex1( void ) { SC_HAS_PROCESS(Ex1); SC_METHOD(Method10ns); } void Method10ns( void ) { next_trigger( 10, SC_NS ); std::cout << "Now " << sc_core::sc_time_stamp() << sdt::endl; } }; SC_THREAD is called only one, and therefore normally contains an infinite loop to properly model hardware. Thus the above is coded more simply as: #include <systemc> #include <iostream> struct Ex1 : sc_core::sc_module { Ex1( void ) { SC_HAS_PROCESS(Ex1); SC_THREAD(Thread10ns); } void Thread10ns( void ) { for(;;) { std::cout << "Now " << sc_core::sc_time_stamp() << sdt::endl; wait( 10, SC_NS ); } } };
  11. SC_METHOD and next_trigger() diagnostics

    Re. SC_HAS_PROCESS That would appear to be an error in the text. The best place to put SC_HAS_PROCESS is inside the constructor as the first line in the body of the constructor. It is syntactically legal there and the only things using it are the SC_METHOD, SC_THREAD, and SC_CTHREAD macros.
  12. Backtrace with sc_report_error()

    I suspect your problem is not understanding that the default action for SC_ERROR is to throw an exception. So you have two choices: 1. Surround calls with a try/catch block. 2. Change the default action to SC_DISPLAY without SC_THROW. I would also suggest you use the SC_REPORT_ERROR() macro so that you get the file and line number where the call originated.
  13. How to initialize sc_fifo

    Your problem is C++ rather than SystemC. "Initialization" should be titled "construction". You either need to use the initializer list to invoke the constructor, or if you are using C++11, you can use uniform initializer syntax.
  14. Does system C support matrix of unknown size

    This has nothing to do with SystemC, but more to do with your declaration. You are declaring an array of pointers to integers on the stack. Stack in SystemC is 64k by default, which means you are limited to 64k/sizeof(int*). I suspect you intended to declare a pointer to an array of ints: int (*matrix)[]; // Pointer to array of int or int** matrix; I suggest you read at least one of the following: https://www.codeproject.com/Articles/7042/How-to-interpret-complex-C-C-declarations https://www.geeksforgeeks.org/complicated-declarations-in-c/ https://medium.com/@bartobri/untangling-complex-c-declarations-9b6a0cf88c96 For simplicity, I like the following tool: https://cdecl.org
  15. Getting a bit from bus

    First thing you need to realize is that sc_signal<> is not a wire and it is not a data type. sc_signal<> is a channel with a non-blocking write and a blocking read. You cannot "connect" a variable to a signal. You have to explicitly make the transfer each time the value changes. There is no equivalent to a Verilog continuous assignment. How do you know if a signal has changed? You have to explicitly watch/wait for the change using additional methods value_changed_event() or possibly posedge_event() if using sc_signal<bool> or sc_signal<sc_logic>. Due to overloading of operator=(), the innocuous looking busCON10 = var_bus_CON[10] turns into: busCON10.write(var_bus_CON[10].read()); which will not return a value until the end of the next delta cycle. Using a cout << busCON directly after this will yield the current delta's value.
×