Jump to content

David Black

  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by David Black

  1. 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!
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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 ); } } };
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. 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.
  13. sc_thread vs pthread

    SystemC follows event driven simulation semantics to simplify hardware modeling. In part, this means using a cooperative multi-tasking model rather than a modern pre-emptive model. In this respect, SystemC is like SystemVerilog and VHDL. This makes it easier to focus on the modeling aspects rather than worrying about mutexes, volatility and other interactions due to multicore and parallel processes. Advanced SystemC users can use OS threads for some tasks, but the synchronization aspects are up to the programmer. So SC_THREAD's are not pre-emptive (nor are SC_METHOD processes) and hence a straightforward SystemC model is single core single threaded from an OS/software point of view. Additionally, you should be aware that the SystemC scheduler is not thread-safe for the most part. If you make use of async_request_update(), you can use multicore and parallel processes to interact with SystemC events. This assumes you are an expert programmer and proficient with C++ (not for beginners). There have been and are some efforts underway to standardize parallelization in SystemC, but it is a volunteer effort and you need to be on the SystemC LWG group to participate. Some commercial entities have developments underway, but keeping those closed for the time being. Always keep in mind that SystemC is not freeware, but was created as part of a commercial coalition to standardize modeling across/between companies. Don't think of SystemC as a free simulator. Also, SystemC is often mistaken as a competitor/alternative to SystemVerilog/VHDL, which it is NOT. SystemC was intended for high-level modeling and abstractions above RTL. The ability to co-simulate with RTL is a requirement for some of the use-cases. SystemC is used quietly by many large corporations to augment specification and verification. It differs from the other languages in that it uses an off-the-shelf C++ compiler and has no requirement of a specialized compiler. This benefits companies with huge software development teams using SystemC Virtual Platform models for early software development. The downside of this approach is the C++ compiler has no understanding of the SystemC domain and has no way to make optimizations that SystemVerilog/VHDL do (e.g. clocks). That is one reason that SystemC coders are advised to avoid explicit clock models to gain performance. Keep the design at as high a level of abstraction as you can.
  14. using sc_vector to Pass an Array between Modules

    sc_vector was designed for use during elaboration. sc_vector semantics are based on std::vector. For that matter, why are you not using std::vector? Are you passing an elaboration call. Furthermore, you would simply pass variables by reference in C++ anyhow. For a 2-dimensional array you would simply use a vector of vectors. Your basic problem sounds like a severe lack of C++ basics.
  15. Executing Modules More than Once

    Q1: How are you declaring the processes? [Note: Seeing actual code would help a lot. Your descriptions are completely inadequate for anybody to understand exactly what you are asking.] Q2: What book are you using to get trained on using SystemC?
  16. You should set length to sizeof(Array). Also, where are you locating the array? It should be static or allocated on the heap and not passed on the stack (e.g. automatic variables are located on the stack).
  17. Use member data for the memory. Assuming your two modules are endian and floating point compatible, you can just do a normal TLM transfer using a simple cast to a character array. If your original array is float, then you need to use sizeof to get the proper depth. You did not note whether this is AT or LT, but that should not matter.
  18. Stack Size Overflow due to recursion

    Don't use recursion? Remember that the stack size applies to each process (SC_THREAD and SC_METHOD), and the machine you are running on needs to have enough memory to accommodate this. If you have 16 threads running with 1G stack, then you need a machine with 16G just for your threads.
  19. Yes, of course. An example would be modeling interrupts, which is often done with an sc_signal<bool>.
  20. Why there is no standard interface class in SystemC

    Java / C# interface is precisely what SystemC interface is. Your original question was more about port aggregation. The problem is that Verilog ports are really quite a different concept. To be sure , there are superficial similarities, SystemC is not an HDL. Mind you, it is quite easy to aggregate SystemC ports. Just define an aggregate class derived from sc_port. This would also allow you to crate aggregate methods (I.e. beyond simple bind). Just don’t expect this to be useable in synthesis. Perhaps a savvy EDA vendor will pickup on This if there is sufficient commercial interest, which I doubt.
  21. Memory Allocation In SystemC

    Using new and malloc are supported for the verification side of SystemC. In other words, when you are creating a validation simulation.
  22. SystemC is very well adopted already and has no need to provide free tools. Also, the purpose of Accellera is to develop standards for the EDA and engineering community, not free tools for academia. For this it has done quite well and continues to do an excellent job. Accellera is made up of volunteers from member companies and many of these do not get paid for their participation. In fact, there are very few that are paid staff for Accellera, and most of those are administrative only without the necessary skills to develop such tools. All contributions for Accellera are strictly volunteer and donations. More to the point, member companies develop and sell tools that do exactly what you are asking. So they have zero motivation to give away what they use to create income for themselves. So if you would like to develop such a tool on your own time and donate it, I am certain others would applaud your efforts; however, you should also not be surprized if your donation is rejected because it might hurt existing products of the member companies. If you would like to get a full time job with one of the member companies, do not be surprised to learn they expect you to have knowledge in SystemC to do some of the work you are hired for. Some companies might even send you to get trained. Finally, if you are interested in "free" tools that convert SystemC to Verilog, you might want to checkout Xilinx Corporation's VivadoHLS, which is as close to free as I think you will get for this type of very complex tool. It is restricted to developing code to be used inside Xilinx FPGA's and does a very decent job. You can also talk with other EDA companies about the possibility as a student of your university acquiring low cost versions of other commercial tools for use in graduate classes.
  23. SystemC for Hardware Design

    For synthesizable SystemC, there is a standard, but even so it is VERY vendor/software dependent. So the answers for using SystemC in a synthesizable context depend on which synthesis software you intend to use. Several companies often software for this (including, but no limited to, Cadence, Xilinx, Mentor (now Siemens)). In general, my experience is that most C/C++ is synthesizable subject to some simple restrictions (e.g. may not use the heap (i.e. new/delete/malloc/free), which also often means you will not be able to use very much of the STL, which is heavily dynamic. Polymorphism is restricted if not forbidden by most of the tools as well. That said, I have successfully synthesized huge designs fairly easily and with decent results.
  24. Simple Bus

    Simple Bus is just a couple of custom channels with fairly simple API. Decode occurs in the bus fabric after interrogating the slaves about their individual address maps. Execution of transfers takes place in the context of respective master threads (initiators). The only other process used is an arbiter. We teach this bus in Fundamentals of SystemC course, which you can learn about here <https://www.doulos.com/content/training/SysC_training.php>. Of course, most folks just skip Simple Bus and go for an implementation based on TLM 2.0. For a Simple Bus application, Loosely Timed would be the appropriate abstraction.
  25. Passing Arguments in the process in SystemC

    Before you go passing arguments to processes in SystemC, I would ask you to be careful of the lifetimes of your variables if passed by reference. Also consider that you could also pass values as class (module) member data.