Jump to content


Popular Content

Showing most liked content since 12/17/2017 in all areas

  1. 3 points
    Because your "analyzer" instance is a local variable in the before_end_of_elaboration function, which gets destructed immediately, when the function returns. So there is no analyzer left to call the callback on later (same holds for the local signal sig2, btw.). You would need to allocate the module dynamically instead. You cannot alter/modify/redefine any existing port binding at any time. You can only add new bindings, including during before_end_of_elaboration. Hope that helps, Philipp
  2. 2 points
    In general, SystemC models should avoid using clocks altogether. This is good for many reasons assuming your goal is high speed behavioral models. SystemC is often used for implementing functionally accurate virtual platforms that allow software to be designed well ahead of hardware delivery. Thus appropriate use of next_trigger() is actually a great idea. There is no way to distinguish between static and dynamic triggering at the point of invocation. Clock is synthesizable and if that particular mode of design is your goal, then sc_clock is appropriate. There are no features of SystemC itself that will tell you if the code itself is synthesizable. The answer to that is highly tool dependent. I know synthesis tools that require no clock at all, and others that insist a clock be specified. Always keep in mind: SystemC is simply C++ syntax used with a library and a methodology to model hardware and software. C++ has no concept of synthesizability. You have to go beyond GCC/LLVM to find out if your code is synthesizable with a given synthesis tool.
  3. 2 points
    This question cannot be answered with respect to the SystemC standard as the issue is heavily implementation dependent. I am aware of implementations where SC_THREAD is faster than SC_METHOD and visa versa. It is also not a good basis for evaluating SystemC itself since the issue of simulation performance almost always comes down to how SystemC was used and how the modeler wrote their SystemC model. I do know an awful lot of folks use SystemC inappropriately (e.g. using it for modeling RTL, where VHDL or SystemVerilog are much better suited). IEEE 1666-2011 calls out the desired behavior, and not the implementation. Note: I did a presentation on SystemC myths many years ago at NASCUG that included the myth about whether or not one should favor SC_METHOD over SC_THREAD for performance reasons. It is quite simply a poor way of making a decision when attempting to obtain performance.
  4. 2 points

    Reading a binary File

    Yes, you can use C's fread() function for this purpose. However, you should not use malloc()/free() to handle allocation/deallocation of your buffers. Instead, use C++'s new/delete operators or even better a suitable standard container such as std::array<T, N> or std::vector<T>. C++'s <iostream> library also offers you the possibility to read/write binary data from/to files. SystemC is a C++ library. Therefore, I suggest that you get familiar with C++ first. Confer, e.g., to: https://isocpp.org/get-started http://www.cplusplus.com/reference/iolibrary/ https://stackoverflow.com/questions/8798127/binary-input-output-in-c
  5. 2 points
    This question in mostly about how the linker works on your platform, and not really specific to SystemC. Let me try to give a short summary: Yes, the "main" symbol is needed by the final application For every needed symbol, the linker looks in your object files first If the symbol is present there, the linker picks it up If not, the linker looks in the libraries given by the user (order/lookup is platform-specific) Repeat this for all required symbols (including "sc_main") So, if you define your own "main" in your application, SystemC's "main" will not be picked. This is actually a feature, as you can call "sc_elab_and_sim" manually from your "main" as well, if you want. Hope that helps, Philipp
  6. 2 points
    Yes, but you need to write the constructors yourself (don't use the SC_CTOR macro). Something like #include "systemc.h" SC_MODULE(mod) { int i; mod(sc_module_name nm) : sc_module(nm) { // ... } mod(sc_module_name nm, int i_) : sc_module(nm), i(i_) { // ... } }; If you use SC_THREAD or SC_METHOD you must also include the SC_HAS_PROCESS macro. Try looking up SC_HAS_PROCESS in 1666-2011 and you should find an example near there, regards Alan
  7. 2 points
    Manikanta's solution assumes temp is public. If not public, you can take the opposite approach and simply call sc_trace from within the module itself. You could even do it conditionally based on run-time command-line arguments: sc_core::sc_trace_file trace_file = 0; //< initialize to indicate not open top::before_end_of_elaboration() { for (int i=1; i<sc_argc(); ++i) { if ( trace_file == 0 && std::string(sc_core::sc_argv()[i]) == "-trace" ) trace_file = sc_core::sc_create_vcd_trace_file("your.vcd"); }//endfor } top::end_of_simulation() { if ( trace_file != 0 ) sc_core::sc_close_trace_file(trace_file); } ... extern sc_core::sc_trace_file trace_file; void dut::end_of_elaboration() { if (trace_file != 0) { sc_core::sc_trace(trace_file, temp,"temp"); } } Of course I am assuming fp is made public as shown, and that you have opened it before end of elaboration:
  8. 1 point

    Mingw Compile Issue

    Hello @Matthias Jung, It seems you are missing some of the compiler definition flags for the build: -DSC_BUILD ... etc. You can get the set of compiler flags for the SystemC library from the CMake generator(Only works with Makefile generator). # Using CMake to create compile_commands.json # SYSTEMC_SRC: SystemC source directory. cd $<SYSTEMC_SRC> # Create a build directory mkdir build cd build # Run CMake configuration for Make file generator. cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON .. Note: Also the quick thread library for user space thread support will not work on Windows since it is compatible only on Linux systems. Regards, Ameya Vikram Singh
  9. 1 point
    Yes, of course. An example would be modeling interrupts, which is often done with an sc_signal<bool>.
  10. 1 point
    Hi In TLM, I am connecting two modules with the Initiator socket and target socket. My question is that "Is that possible to have also signal based connection between the modules as well as the Socket based connection " ? Can we have communication in both ways in SystemC ? Thanks
  11. 1 point
    David Black

    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.
  12. 1 point
    Roman Popov

    Using sc_uint_base directly?

    I think this is true for Chisel, but not for MyHDL. Chisel is indeed uses Scala syntax overload magic to construct netlist out of library predefined primitives. But this makes Chisel somewhat inferior to Verilog/SystemC/MyHDL, because it does not support synthesizable behavioral blocks (AFAIK). MyHDL is essentially the same idea as SystemC, but implemented in dynamic interpreted language. To generate Verilog it uses both Python reflection capabilities, but also has a "compiler" for behavioral blocks. SystemC synthesis tools are not just a compilers. They also have built-in rudimentary C++ interpreters, to comprehend module constructor code, where binding and process creation happens. Well, I think they read this forum periodically. But there is no button "Include HLS vendors". The problem is that synthesizable SystemC subset is essentially a common denominator of what HLS tools already support. So any real HLS tool is more powerful than syn subset. To support "hardware construction" in synthesizable subset SystemC synthesis should draw inspiration from MyHDL. I can reformulate syn subset like this: During elaboration-time everything is allowed. I.e. constructor code and phase callbacks code can be arbitrary C++. All SystemC integer datatypes are supported. This gives elaboration-time defined bit-width. sc_vector is supported. This gives elaboration-time sized container. But only for sc_objects. What if I want elaboration-time defined ROM? Support elaboration time constants and constant vectors. Currently missing in SystemC library SC_METHOD/SC_THREADs are restricted the same way as they are today. To support this subset real C++ interpreter like Cling should be integrated into HLS tool. Another option would be using introspection information like MyHDL does. C++ does not have a standardized one, but Clang and G++ can dump DWARF debug information that is sufficient to extract netlist of SystemC design together with values of all data fields (including constants, sizes of containers, bit-widths ...) as demonstrated by simulator tools based on GDB. I don't see how if constexpr helps in this particular case. Can you please elaborate on a small example? I agree that compile-time programming is powerful and solves most of hardware parameterization cases. We use it everywhere indeed. Originally I also thought that compile-time meta-programming is a solution for this case too. It is indeed possible to construct modules recursively the way like std::tuple is implemented. But there are two issues: TMP code is hard to comprehend. It's not possible to iterate compile-time data structures at runtime ( inside THREADS/METHODS). Behavioral code that uses sc_vector of elaboration-time defined buses is much easier to write and comprehend.
  13. 1 point
    Philipp A Hartmann

    Using sc_uint_base directly?

    First of all, we need to distinguish between SystemC in general and its synthesizable subset. Whenever something is not explicitly covered by the current synthesizable subset, it's probably best to include the HLS vendors in the discussion. This almost certainly includes sc_signal<sc_uint_base>. Vendors may support this as signal type, if they can derive the width of the signal (statically) during elaboration. But in a fully generic fabric model, this might be difficult. IIRC, the main difference between SystemC and MyHDL or Chisel is that the latter basically create an explicit "netlist" in memory during elaboration. Basically, the synthesis rules/tool is already embedded in the language (kernel) itself, knowing how to generate the elaborated model to Verilog from memory. In SystemC, a synthesis tool is implemented more like a compiler, i.e. working at the language level directly. These are very different approaches with different benefits and limitations. When you refer to "runtime-defined bitwidths", you certainly mean "elaboration-defined", because the widths cannot change once the simulation has started. But sc_uint_base doesn't know about elaboration/simulation. In order to reduce the risk of width mismatches, you would need a custom channel as suggested by Torsten. But as you said, such custom channels are not supported well by HLS tools. Long story short: Having an "elaboration-sized" signal could definitely help for HLS use cases like yours. The simulation model could be implemented quite easily based on a signal specialization for sc_(u)int_base/sc_(u)nsigned. But as long as HLS tools doesn't support it, its usage would be fairly limited. Have you talked to HLS vendors about this already? Last, but not least, I think that C++17 constexpr, especially in combination with if constexpr and auto return type deduction, will provide most of the required features to write generic "hardware construction code" efficiently. Such models would then automatically be synthesizable by an C++17 capable HLS tool, as the code is evaluated during compile time already.
  14. 1 point
    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.
  15. 1 point
    You can use sc_bind() for this purpose, which is described in clause 5.5.6 of IEEE Std 1666-2011. Though, you might need to use sc_spawn instead of SC_THREAD to register your process with the SystemC kernel. If your compiler supports C++'11, you can also use a Lambda function instead of sc_bind(). Cf. to the Doulos white paper "What C++11 means to SystemC?" by David C. Black for details.
  16. 1 point

    Using sc_uint_base directly?

    I don't see any issue from the point of the LRM. From a methodology perspective, I think it depends on the abstraction level and use case you are targeting. On the side of modules representing actual hardware, I would probably prefer to have a port type stating clearly the width to have the compiler statically check for me the correct binding of ports and interfaces. For stimuli generators and monitors, a more generic base type is OK for me. Where it then interfaces with HW modules, I would insert a small adaptor. You may also consider to have a channel, which can bind to sc_int<W> and sc_int_base, and which then checks at elaboration time that the widths on all bound ports match.
  17. 1 point

    Errors in code

    From a quick glance into your source files, I see: Your headers are missing #include guards. You don't include SPPS.h in your header SPPS48.h, but your members M1, M2, and M3 are of type SPPS, which you define in SPPS.h I recommend that you don't use the header <systemc.h>, as it seriously pollutes your public namespace. Use header <systemc> instead and import only the symbols in your current namespace, which you actually use. Your constructor allocates manually memory for the members M1, M2, and M3 using "new", but lacks a destructor, which would release the objects using "delete". Anyway, this is not considered "Modern C++". Instead of raw pointers to objects of type SPPS, use a smart pointer. In your case, std::unique_ptr is probably the appropriate choice. All members of your SC_MODULE are exposed to public. This may be good for debugging, but it is better to only expose those members, which constitute the public interface of your module (i.e., at least the input/output ports, constructor, and destructor). Your SC_METHODs and SC_THREADs don't need to be public. Your approach to generate a clock signal in sc_main() is tedious the most. A clk signal of type sc_core::sc_clock is a more comfortable solution. To generate more comfortably complex stimuli, I recommend that you implement them in an own stimuli module. Therein, you can register an SC_THREAD, which performs the stimuli generation and which can easily wait for delays or event before proceeding to the next stimulus. In the same way a monitor for your output signal can be implemented. I repeat my recommendation to learn first the basics of modern C++ and to read a good book on SystemC to get more efficient in your modelling attempts!
  18. 1 point
    Alan's code snippet already shows you how to write constructors with additional arguments. The only thing, which is omitted in the snippet, but mentioned in his post is the necessary call to the SC_HAS_PROCESS macro with the name of the module class as argument so that you can use SC_THREADs and SC_METHODs in your module. I tend to write it just in front of the declaration of the first constructor. Thus, Alan's example would look like: #include "systemc.h" SC_MODULE(mod) { int i; SC_HAS_PROCESS(mod) mod(sc_module_name nm) : sc_module(nm) { // ... } mod(sc_module_name nm, int i_) : sc_module(nm), i(i_) { // ... } }; You can find more information in clause 5.2.6 to 5.2.8 of IEEE Std 1666-2011. I suggest that you read an introductory book on SystemC, e.g., "SystemC from the Ground Up" by David Black and Jack Donovan. Also, get familiar with C++: https://isocpp.org/get-started
  19. 1 point
    Hi Matthias, I would say, this is just an inadvertent editorial change. The normative text still explicitly includes this transition. I'll forward your finding to the Accellera/IEEE WGs to get this fixed in a future revision of IEEE 1666. Thanks for reporting, Philipp
  20. 1 point
    David Black

    redefinition of enum

    I concur with the idea of becoming more proficient in C++. This is the number one best way to improve your SystemC skills. It also helps to get good formal training on SystemC. Suggestions: Define your enum's inside your class declarations (e.g. inside a module). Then you enumeration items become CLASS_NAME::ENUM_NAME Adopt C++11 and use enum classes. See http://en.cppreference.com/w/cpp/language/enum for more details. Do both! Any serious C++ programmer should be using C++11 or C++14 by now unless restricted by some antiquated toolset. These are now well supported by modern versions of GCC, CLANG (LLVM), Microsoft Visual Studio, Oracle, and IBM. This even includes most embedded compilers.
  21. 1 point
    David Black

    How exactly sc_main works !!

    Just to add a bit to Philipp's excellent reply: In part this was done to support EDA tools that support co-simulation of SystemC with other languages (e.g. SystemVerilog and VHDL). The EDA tools themselves implement main and then they can dynamically link in your sc_main as needed. Of course if you really know how to control the linker, there are other means as well, but we don't need to go there.
  22. 1 point
    The draft standard SystemC CCI Configuration LRM is now available for public review. This standard defines both essential interfaces and convenience building blocks for configuring SystemC models in a way that enables compliant tools to setup, query, control, and track configuration information in a simple and effective manner. Supplemental materials in the review kit include an overview presentation, proof-of-concept implementation, and more than 20 examples. For more detailed information about SystemC CCI, read this article > Download the LRM here > The review period will remain open until March 18, 2018. Technical feedback and questions from the public can be posted here in this Community Forum or emailed to cci-review@lists.accellera.org.
  23. 1 point


    You're using 'var' as a variable name, but this is an SV keyword. Try naming your variable something different: fork automatic int idx = i; // ! `uvm_do_on(eseq_inst[var], p_sequencer.master_sequencer[var]) join_none
  24. 1 point
    Have a look here: https://isocpp.org/get-started
  25. 1 point
    If you use SC_THREAD that means that you are using sc_event under the hood. Because every SC_THREAD in SystemC has event that activates the process. You can for example spawn a SC_THREAD process to do delayed assignment like this: #include <systemc.h> struct spawned_assignment_demo : sc_module { SC_CTOR(spawned_assignment_demo) { SC_THREAD(test_thread); } sc_signal<int, SC_MANY_WRITERS> out{"out", 0}; void print_out_value() { cout << " out value = " << out.read() << " at " << sc_time_stamp() << "\n"; } void test_thread() { print_out_value(); sc_spawn([&]() { wait(10, SC_NS); out = 42; }); wait(5, SC_NS); print_out_value(); sc_spawn([&]() { wait(10, SC_NS); out = 124; }); wait(6, SC_NS); print_out_value(); wait(6, SC_NS); print_out_value(); } }; int sc_main (int argc, char**argv) { spawned_assignment_demo demo{"demo"}; sc_start(); sc_stop(); } Output will be as expected: out value = 0 at 0 s out value = 0 at 5 ns out value = 42 at 11 ns out value = 124 at 17 ns But when you call wait(10,SC_NS) you create timed event notification. You can use debugger to step into wait() to see what happens there.
  26. 1 point
    Bonus points for testing what happens when you change the constraint to the following: constraint c_1 { soft var1<100; }
  27. 1 point


    Welcome to the Accellera Systems Initiative forums. Please register to start new topics or reply to existing topics. We have resently migrated our UVM forums from UVMWorld to this site. If you were registered on the previous UVM forum site, you should be able to log into the forums using your username and password from the UVMWorld forums. If you had an account on both the UVMWorld forums and the Accellera forums and these accounts used the same email address, then log in with the username and password of the forums.accellera.org account, not your UVMWorld account. If you do not remember your password, you may reset it. If you have any questions about using the forums, click the Help button at the bottom of any forum page. If you need any help with your account and you are logged into the site, click the Messenger icon (a letter) in the upper right of your screen, click Compose New, enter “admin” in the Recipient’s Name field, compose your message, and then click Send. You may also send an email to admin@lists.accellera.org. Thank you, Accellera Systems Initiative