Jump to content


Popular Content

Showing content with the highest reputation since 01/14/2017 in all areas

  1. 4 points
    David Black

    system c beginner

    Here is a short list of topics in no particular order you need to be comfortable with in order to be have an easier time learning SystemC: [Note: Others might chime in with variations on this list (add/subtract), and this is not necessarily a complete list, but I am fairly certain if you are able to comfortably use the topics I list below, you will have very little trouble syntactically with learning SystemC. In addition to C++, it helps if you have some familiarity with event driven simulation (e.g. SystemVerilog or VHDL). Also, if you have deep knowledge in another OO language (e.g. Java or SystemVerilog), you might have an easier time learning the C++ part.] Difference between declaration and definition Pass by value vs pass by reference Use of const (5 distinct cases) Casting C++ style (4 types) Implicit vs explicit conversions Use of function overloading and how to deal with ambiguity issues Use of std::string Use of streaming I/O How to declare, define and use classes Definition of default constructor Purpose and syntax of copy constructor How to declare and use namespaces Operator overloading as member functions and global functions. The difference between overloading and overriding. Relationship between class and struct How to extend classes and multiple inheritance Purpose of public and private Storage types and lifetimes: static, automatic, dynamic How to properly use new and delete Use of pointers and understanding of issues with pointer arithmetic Use of arrays and issues Advantages and use of std::vector<> Use of try-catch and throw Use of initializer list in constructor and a proper understanding of the order of construction Polymorphism and RTTI RAII Rule of 4 (6 if using C++11 or later) How and where to define templates/generic programming (does not need to be deep knowledge - just the basics) Use of templates and nested templates. Definition of full and partial template specialization. Different types of constructors and destructors Use of virtual inheritance (hint: it's not polymorphism) Extra topics: More STL including at least std::map<>, std::set<> Boost Modern C++ users (2011 onward) should know about: nullptr Uniform initialization Use of auto Use of ranged for Lambda definition, binding and use constexpr std::unique_ptr<>, std::shared_ptr<>
  2. 3 points
    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.
  3. 3 points
    SystemC 2.3.2 (and later) does support a query whether an event was triggered in the previous delta cycle (or immediately in the current evaluation cycle). This is similar to the sc_signal<>::event() function. With this, you can ask every element in your array, whether it was triggered and may have caused a wakeup of the process. Of course, multiple events can have triggered simultaneously and will only cause a single wakeup of the process. for( const auto ev& : e ) { if ( ev.triggered() ) { // ... } } Hope that helps, Philipp
  4. 3 points
    Well, this topic could fill an entire book... If you implement a model the first question you should as is: What is the purpose of the model? Which questions should the simulation of the model answer? Looking at architectural exploration which goes quite often hand in hand with performance analysis the question is: does my HW/SW split and my HW partitioning satisfy my perfomance requirements (wrt. latency, thru-put, compute.efficiency, power,...). In this case you usually do not need to implement a particular functionality in detail rather something that 'behaves like' in terms of your requirements. E.g. if you need to check that your communication scheme (buses, arbiters, bridges etc.) fulfills the needed band with you use traffic generators but have a fairly accurate bus model, sometimes even at AT. And you need to implement the mechanisms to observer and extract the needed performance indicators to allow the analysis For software development the requirements are different. Here the maximum simulation speed is required so whereever possible you take short cuts. Bus transaction are not modelled anymore rather DMI is used (of course if functionality allows to do so e.g. when reading from/writing to a memory) and the entire model may run in LT mode which allowes parts to independently advance in time. Peripheral units may be modelled register-accurate but with out real functionality, i.e. a system control unit does not follow the needed scheme if changing e PLL frequency and alike. This might give you some high-level clue. There are many more things to it but all of them depend on the answer to the initial questions. Maybe the DCVon Europe 2017 tutorial on virtiual protorypes might provide a few more answers. You may find a PDF version of it at the MINRES site in the Publications and Papers section or at https://minres.com/downloads/VP_Tutorial_DVCon-2017.pdf as well as at the DVCon Europe website https://dvcon-europe.org/conference/history Best regards -Eyck
  5. 3 points
    David Black

    serial transmission

    [I assume that when you say "TLM", you mean SystemC TLM 2.0.] You need to understand the difference between modeling styles. TLM is precisely about not modeling at the level of RTL. The SystemC TLM 2.0 also has two different modeling styles: Loosely Timed (LT) and Approximately Timed (AT). Let's look at each using a specific case. Suppose you are modeling two UARTs operating at 9600 baud (bits per second) with 8-bits, no parity, and 1 stop bit to transfer the message "Hello World\n". This configuration results in 960 characters per second (1.042 ms/char), which is quite slow, so probably you would be transmitting/receiving characters slowly enough that most systems would either process them one at a time or provide a FIFO (e.g. 16 bytes) and only process empty/full events. There is one more question to answer though. Consider the diagram below. The connections between sender to UART and UART to receiver are clearly memory mapped for most systems. So there is no question of modeling. The connection UART to UART is not memory mapped, which means you need to create a custom protocol. Furthermore, for TLM, it actually requires to connections since communication can be invoked bi-directionally (for a full UART). You need to decide what is important to model. For a high level model and efficiency, I would either transfer as much data as I could. It might even make sense to use TLM 1.0 rather than TLM 2.0. Do you have the requirement to inject errors? For my example, you would configure the transmitter, and then transfer a burst of 12 characters into the transmit FIFO on one end of the transfer and generate an empty FIFO interrupt at 12.5 ms later. The receiver side would be similar. What about the UART/UART transaction? An efficient approach might be as follows: Create a required extension that carries the transmit configuration information (baud rate, bits, parity, etc.) Use TLM_WRITE_COMMAND because all transactions over this socket pair are initiated from the sender. The second pair in the opposite direction would do the same thing. Check and insist that the address always be 0 and the streaming width is 1. Byte enables would be illegal. Check that the configuration matches before accepting data. Place all received data into an unbounded queue and then indicate the size allowed by the hardware model. Send interrupts using the sc_signal when the received queue goes non-empty. Consider the error situation when the timing indicates characters would be lost due to FIFO full and timing of characters. You will have to decide how to deal with interrupts received in your thread process. Notice that I do not model at the bit level. If you wish to add bit-level error injection, then inject errors at the point of transmission.
  6. 3 points
    Philipp A Hartmann

    reset during wait(int)

    I agree with your conclusion that the observed behavior of the proof-of-concept implementation does not match the requirements of IEEE 1666-2011. I checked the code and it can be fixed by adding the check for resets to sc_thread_process.h (in the trigger_static() function): diff --git a/src/sysc/kernel/sc_thread_process.h b/src/sysc/kernel/sc_thread_process.h --- a/src/sysc/kernel/sc_thread_process.h +++ b/src/sysc/kernel/sc_thread_process.h @@ -485,5 +486,5 @@ sc_thread_process::trigger_static() #endif // SC_ENABLE_IMMEDIATE_SELF_NOTIFICATIONS - if ( m_wait_cycle_n > 0 ) + if ( m_wait_cycle_n > 0 && THROW_NONE == m_throw_status ) { --m_wait_cycle_n; I'll take this change to the language working group to get it fixed in a future version of the SystemC PoC kernel. Thanks for reporting! Greetings from Duisburg, Philipp
  7. 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
  8. 3 points

    Clock to Q Propagation Delay

    Hello, In SystemC you can use SC_THREAD's to model delays by using wait statements but you will incur performance penalty. Instead you can use event's and event queues to model delays using in SystemC as mentioned here: http://workspace.accellera.org/Discussion_Forums/helpforum/archive/msg/msg?list_name=help_forum&monthdir=200803&msg=msg00061.html You can replace the SC_THREAD example given in the above mentioned link with SC_METHOD removing the infinite while loop. Here's the modified example listed from the above mentioned link: template<typename T> class delay_transport : public sc_module { public: sc_in<T> in; sc_out<T> out; SC_HAS_PROCESS(delay_transport); delay_transport(sc_module_name name_, sc_time tdelay_) : sc_module(name_), tdelay(tdelay_), in("in"), out("out") { SC_METHOD(mi); sensitive << in.default_event(); SC_METHOD(mo); sensitive << eq; } sc_time tdelay; void mi() { val = in.read(); vq.push(val); eq.notify(tdelay); } void mo() { val = vq.front(); out.write(val); vq.pop(); } sc_event_queue eq; std::queue<T> vq; T val; }; Regards, Ameya Vikram Singh
  9. 3 points
    Actually, you can start a sequence in any phase. It is more important to understand the domain/scheduling relationships between the task based (i.e. runtime) phases. UVM undergoes a number of pre-simulation phases (build, connect, end_of_elaboration, start_of_simulation) that are all implemented with functions. Once those are completed, the task based phases begin. The standard includes two schedules. One is simply the run_phase, which starts executing at time zero and continues until all components have dropped their objections within the run_phase. The other schedule contains twelve phases that execute parallel to the run phase. They are: pre_reset, reset, post_reset, pre_config, config, post_config, pre_main, main, post_main, pre_shutdown, shutdown, and post_shutdown. They execute in sequence. Every component has the opportunity to define or not define tasks to execute these phases. A phase starts only when all components in the previous phase have dropped their objections. A phase continues to execute until all components have dropped their objections in the current phase. Many companies use the run_phase for everything because there are some interesting issues to consider when crossing phase boundaries. In some respects it may be easier to use uvm_barriers for synchronization. Drivers and monitors (things that touch the hardware) are usally run exclusively in the run_phase, but there is nothing to prevent them also having reset_phase, main_phase, etc...
  10. 3 points
    An other way to understand this is to look at SystemC/TLM as pure C++ code and see what is going on.. Let us assume that you have two classes, "Initiator" and "Target", that need to communicate with each other. Target implements a function called "transport" to be called by Initiator, and Initiator implements a function called "response" - that is called by target. For the sake of the explanation here, the payload itself is not important, which we will assume is plain "int" in both directions. You would normally do this as following: // Interface classes: class initiator_if { public: void response(int i) = 0; }; class target_if { public: void transport(int i) = 0; }; class Initiator : public initiator_if { public: // Implement the interface void response(int i) { cout << "Got: " << i << " from target" << endl; } void bind(target_if &_if) { // Store the pointer locally m_target = &_if; } }; class Target : public target_if { public: // Implement the interface void transport(int i) { cout << "Got: " << i << " from initiator " << endl; } void bind(initiator_if &_if) { // Store the pointer locally m_initiator = &_if; } }; Next we instantiate the objects and "bind" them: Initiator initiator; Target target; initiator.bind(target); target.bind(initiator); I hope you are seeing where we are going with this. What has been done above is a crude equivalent of sc_port binding. There is one problem however with the approach above. What if the class "Target" doesn't implement the target_if directly? Like so: class TargetGrandChild : public target_if { public: void transport(int i) { // Implement the interface.. cout << "Got " << i << " from initiator (in grand child)" << std::endl; } }; class TargetChild { public: TargetGrandChild gch; /* Other stuff.. */ }; class Target { public: TargetChild ch; /* Other stuff.. */ }; One way to deal with this is to change the way bind function is called: initiator.bind(target.ch.gch); This is ugly. Firstly, it makes the client of bind function dependent on an internal design aspect of the "Target" class. For example, if the Target class changes tomorrow (to let the TargetChild implement the "target_if" directly), the bind function call needs to change. Also, to allow the client to call the bind function as above, the elements "ch" and "gch" must be made public, which may not be necessarily a good thing. A way out is to have an additional indirection. Let us call this as simple_export (a very simplified version of sc_export): class simple_export : public target_if { public: void transport(int i) { // One level of indirection p_real_target->transport(i); } void bind(target_if &_if) { p_real_target = &_if; } private: target_if *p_real_target; }; The new version of the Target class now looks like the following: class TargetGrandChild : public target_if { public: void transport(int i) { // Implement the interface.. cout << "Got " << i << " from initiator (in grand child)" << std::endl; } }; class TargetChild { public: TargetGrandChild gch; /* Other stuff.. */ }; class Target { public: simple_export port; private: // private is ok TargetChild ch; /* Other stuff.. */ Target() { // Tell "export" where the real implementation is port.bind(ch.gch); } }; The initiator will be "bound" to the target like so: initiator.bind(target.port); So for the simple_export to work, you need two binds: First is where the initiator is bound to the simple_export instance Second is when the "real" implementation is bound to the simple_export instance The simple_export class acts like a bridge. It forward the calls from the initiator to the "real" implementation. In case the "Target" itself implements the interface, the bind would look like: class Target : public target_if { public: simple_export port; private: // private is ok TargetChild ch; /* Other stuff.. */ Target() { // Tell "export" where the real implementation is port.bind(*this); } }; I hope this explains the line you pointed out in the code. The TLM socket has both a port and an export. Please note that the code snips above does not correspond to how OSCI simulator actually implements sc_port/sc_export!
  11. 2 points

    sc_clock Doubt

    sc_clock triggers itself based on the period and the (in your case default) constructor settings. The period is the default_time_unit.
  12. 2 points

    TLM CPU modeling

    There is no such thing as CPU TLM modeling. Usually you write a C/C++ processor model with the needed accuracy (instruction accurate, cycle approximate, cycle accurate) and wrap it in a way that you translate memory accesses into TLM socket accesses. Along with that you need to manage to syncronization of the time of your model and the SystemC time (to run e.g. in loosly timed mode). Another task is to take the returned execution time of the bus accesses into account for the execution of the CPU model. This involves also the selection and implementation of the accesses (DMI & blocking or non-blocking). You can find a complete example of an instruction accurate VP at https://git.minres.com/DVCon2018/RISCV-VP (or https://git.minres.com/VP/RISCV-VP which is a newer version). The wrapper for the C++ model in SystemC can be found at https://git.minres.com/DVCon2018/RISCV-VP/src/branch/develop/riscv.sc/incl/sysc/core_complex.h To put it straight: doing this correctly is a non-trivial task as it is the implementation of a micro-architecture model of a CPU. One option is to build an instruction accurate ISS and add a microarchitecture model like it is done in the ESECS project (https://github.com/MIPS/esesc) BR
  13. 2 points
    You are initailaizing fl_ptr during consturction, not during execution. In generator.hpp you have: float* fl_ptr = reinterpret_cast<float*>(dmi_mem); //ovo sam ja pisao This never updates fl_ptr to the actual value of dmi_ptr. Actually your access should look like: if (dmi_valid) { dmi_mem = dmi.get_dmi_ptr(); //dmi_mem is pointer to ram[] array in memory.h float* fl_ptr = reinterpret_cast<float*>(dmi_mem); for (int i = 0; i != 20; ++i) fl_ptr[i] = 12.7; }
  14. 2 points
    Please be aware, that an sc_and_event_list does not imply that the events in the list are triggered at the same time. I would suggest to keep the only the clock sensitivity and act on the triggers in the body of the method instead: SC_METHOD(func2); sensitive << clk.pos(); dont_initialize(); // ... void func2() { if( nreset.posedge() ) { // nreset went high in this clock cycle // ... } } Alternatively, you can be sensitive to nreset.pos() and check for clk.posedge() (as a consistency check), if you don't have anything else to do in the body of the method. With this approach, you might be able to avoid unnecessary triggers of the method. Side note to Eyck: There's a small typo in the example above, which should should use "&=" to append to an sc_event_and_list. ev_list &= nreset;
  15. 2 points
    Unfortunately I'm not with a member company. I was hoping that I'd have read permissions regardless of my current affiliation. As a user I'd like to see the connection between discussions in the official forum, the issues reported to the issue management system, and the code being developed in response to that. The ability to immediately test that code and possibly give feedback as code comments or a pull request. More like Github, Gitlab and other platforms. Seems to me that this would be a more efficient way to give and get user feedback.
  16. 2 points
    David Black

    Systemc performance

    Perhaps you would like to share your code for measurements via GitHub? Measuring performance can be tricky to say the least. How you compile (compiler, version, SystemC version) and what you measure can really change results. Probably helps to specify your computer's specifications (Processor, RAM, cache, OS version) too. Processor (vendor, version) L1 cache size L2 cache size L3 cache size RAM OS (name, version) Compiler (name, version) Compiler switches (--std, -O) SystemC version SystemC installation switches How time is measured and from what point (e.g. start_of_simulation to end_of_simulation) Memory consumption information if possible This will help to make meaningful statements about the measurements and allow others to reproduce/verify your results. It is also important to understand how these results should be interpreted (taken advantage of) and compared. As with respect to TLM, it will get a lot more challenging. For example, what style of coding: Loosely Timed, Approximately Timed. Are sc_clock's involved?
  17. 2 points
    David Black

    sensitivity list

    You can only specify sensitivity on objects that have events or event finders directly accessible at the time of construction. Normally this means using either a suitable channel, port or explicit event. If you wrap your int's with a channel such as sc_signal<T>, you can do it. Example - https://www.edaplayground.com/x/5vLP
  18. 2 points
    The issue is likely caused because you access a port (via -> or for example calling functions like .read()) already inside the module constructor. You should only access ports after binding has completed, this means from within a SystemC process or in end_of_elaboration() / start_of_simulation() callbacks. Hope that helps, Philipp
  19. 2 points
    This means that a port is not bound to an interface. A port is just a kind of a forwarder of an interface. So if none is bound nothing can be forwarded. E.g. if you have a sc_in<bool> it forwards the sc_signal_in_if which allows you to read and wait for events. But there needs to be 'something on the other side' which is usually a signal (implementing the sc_signal_in_if) being bound to the socker. But without further information it is hard to provide more help. Best regards
  20. 2 points
    Thanks! I can reproduce the behavior and verified that removing the dynamic sensitivity in sc_thread_process::kill_process fixes the issue: void sc_thread_process::kill_process(sc_descendant_inclusion_info descendants ) { // ... if ( sc_is_running() && m_has_stack ) { m_throw_status = THROW_KILL; m_wait_cycle_n = 0; remove_dynamic_events(); // <-- add this line to avoid the exception simcontext()->preempt_with(this); } // ... } I'm not sure, if it is necessary to do the same for the static sensitivity. At least I haven't come up with a similar scenario, where the error is actually "incorrect".
  21. 2 points
    The problem is, when you integrate RTL IP into Loosely-Timed VP that way, the whole simulator will have a performance of cycle-accurate model. Because clock generator will be always on, and Verilated model will be triggered even if it is idle. So don't try to boot Linux with such a simulator. If your RTL IP supports power gating or clock gating, it is a good idea to disable clock generation when RTL IP is turned off. In that case you don't pay for what you don't use: you can boot your OS quickly and then enable clock generator when you start to debug IP-specific driver code.
  22. 2 points
    Hello @kallooran, What version of SystemC library are you using? This issue has been fixed in the release of SystemC-2.3.2. You can find the latest release of SystemC-2.3.3 here: http://accellera.org/downloads/standards/systemc Hope it helps. Regards, Ameya Vikram Singh
  23. 2 points
    David Black

    Seeking Feedback on Datatypes

    Actually, it adds a lot of value. std::array can be passed by reference in a function call and the function can then determine the proper size of the array. This is much better than passing pointers, the C standard. You can also copy an array, which should be synthesizable, which reduces coding and greatly improves readability. It should be possible to implement some #include <algorithm>s on std::array too. Also, you can have bounds checking for additional safety; although, that aspect is probably not synthesizable. Additionally, constexpr should be quite helpful for the synthesis aspect.
  24. 2 points
    Hi Ivan, instead of referring to the very old 2.01. LRM, I suggest to check the IEEE Std. 1666-2011 for SystemC, which could can download at no cost (sponsored by Accellera) via https://standards.ieee.org/findstds/standard/1666-2011.html. This document includes the normative answers to all of your questions. Yes, see section 5.10.8 of the aforementioned standard. Kind of, yes. This is called "time out", see section 4.2(.1) of the standard. The order to execution of processes in the runnable queue is entirely implementation-defined. See section Hope that helps, Philipp Disclaimer: I haven't checked all of your post for correctness and focused on the questions instead. .
  25. 2 points
    Yes, this change in behaviour of SystemC 2.3.2 with respect to SystemC 2.3.1 is intentional to better conform to IEEE Std 1666-2011, which states in clause 6.4.4 about signal writes under the SC_MANY_WRITERS policy: This fix by @Philipp A Hartmann is documented in the RELEASENOTES of SystemC 2.3.2:
  26. 2 points
    Hi Aarthi, if you just need to get the currently active module when hitting a breakpoint in you C++ code you might use the following command (assuming you use gdb): x sc_core::sc_get_current_process_b()->get_parent()->name() (see also here: https://stackoverflow.com/questions/18078226/how-to-get-sc-module-name-of-the-current-running-module#18123785) What it does is it calles the SystemC kernel function sc_get_current_process_b() which returns a pointer to sc_process_b (the base class of of sc_method_process and sc_thread_process). Inheriting from sc_obejt it also has a name() method so you could also do x sc_core::sc_get_current_process_b()->name() which just returns the full hierarchical name of the process. HTH -Eyck
  27. 2 points
    Hi Kevin, if you check here https://github.com/Minres/SystemC-Components/blob/master/incl/scc/utilities.h there are three macros which make live easier: #define TRACE_VAR(F, X) sc_core::sc_trace(F, X, std::string(this->name()) + "." #X) #define TRACE_ARR(F, X, I) sc_core::sc_trace(F, X[I], (std::string(this->name()) + "." #X "(" + std::to_string(I) + ")").c_str()); #define TRACE_SIG(F, X) sc_core::sc_trace(F, X, X.name()) They can be used with local variables and arrays as well with SystemC objects providing the name() funtion. This way tracing a signal becomes as easy as (assuming _STATE_ being a signal or port): TRACE_VAR(_trace_, top.dpu.idu.weight_reader.m_traffic_gen._STATE_); Pls. note: the first 2 macros are assumed to be used within a sc_module. HTH -Eyck
  28. 2 points
    David Black

    make check return fail

    I am able to reproduce the problem and will attempt a fix. Unless you are using async_request_update() in your code, you can safely ignore this problem for now. CORRECTION: While there is a bug with the following deprecated feature issue, this does not solve the problem. Stay tuned for a real fix. There is a bug in the implementation of SystemC due to Apple removing support for POSIX sem_init, which is a non-required API by the POSIX standard. See <https://stackoverflow.com/questions/1413785/sem-init-on-os-x/24617282> for details. [Pure speculation: I suspect the reason for removing support was that Apple has recently moved to an all 64-bit coding model. Potentially because they are positioning themselves to be able to port quickly to Arm v8A lacking Aarch32 on certain hardware.] When building on OSX using Cmake I noticed a clue: I use the adage, "A warning is usually a potential bug leading to a real error." Never ignore warnings from compilations. Yes, I know there is a lot of code out there with superfluous warnings. Shame on them for leaving them in. So if you see a warning, track it down. If it is truly a don't care (rarely), then it can be overridden with a #pragma. Almost all warnings can be fixed with proper coding. I am going to attempt a fix to sc_host_semaphore.h, but if you're in a hurry go to Linux.
  29. 2 points
    When reading the signal 'inter' right after writing to it (line 25 of the referenced code) you read the current value and not the scheduled (new) value. Writes to signals (as part of methods or threads) are executed in the evaluation phase of the simulation kernel while the value is assigned during the update phase of the kernel (see also https://ptolemy.berkeley.edu/projects/embedded/research/hsc/class/ee249/lectures/l10-SystemC.pdf?46). If you read a signal in the same evaluation phase you are writing to it, you will always get the current value, not the new (scheduled) value. If you have several assignments to the signal the last one will always win. I.e. lets assume you have a signale and a thread like: void thread(){ sig.write(42); wait(0, SC_NS); // advance by 1 delta cycle sig.write(1); cout<<"Sig is "<<sig.read()<<std::endl; sig.write(2); cout<<"Sig is "<<sig.read()<<std::endl; sig.write(3); cout<<"Sig is "<<sig.read()<<std::endl; wait(SC_ZERO_TIME); // same as the last wait(), advance by 1 delta cycle cout<<"Sig is "<<sig.read()<<std::endl; } you will get the output: Sig is 42 Sig is 42 Sig is 42 Sig is 3 because the update to sig will only happen during the wait() call. I hope this answers your question.
  30. 2 points
    Hi @vasu_c, thanks for finding this. The patch below should fix your issue if you want to try it out early. Apologies for the inconvenience. --- a/src/sysc/packages/qt/md/aarch64.s +++ b/src/sysc/packages/qt/md/aarch64.s @@ -59,8 +59,10 @@ qt_blocki: mov x0, sp // arg0 = old_sp mov sp, x3 // sp = new_sp + sub sp, sp, 160 // (*helper)(old_sp, a0, a1) blr x4 + add sp, sp, 160 // Callee-saved ldp x29, x30, [sp, #-16] // frame, link
  31. 2 points
    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.
  32. 2 points
    The Accellera SystemC Language Working Group has released the proposed SystemC 2.3.2 for testing and feedback from the community. This is a maintenance release with some new features including a foundation for C++11/14 enablement, a centralized global name registration enabling CCI naming requirements, new TLM socket and sc_signal base classes, and updated compiler and platform support including Windows DLL support and an experimental CMake build system. There are also many bug-fixes and general clean-up. Licensed under Apache 2.0, the release package contains the SystemC class library and the regression test suite. It can be downloaded here. The review period is open until May 31, 2017. Feedback is welcome and can be submitted either by email to review-systemc@lists.accellera.org or via this forum.
  33. 2 points

    reset during wait(int)

    IEEE 1666-2011 describes wait(int ) as follows: If my interpretation is correct, wait(3); should always be equivalent to wait(); wait(); wait(); However, after applying such an equivalent transformation to tests/systemc/kernel/reset_signal_is/test02/test02.cpp from the regression suite, I got a different simulation output (with systemc-2.3.2): Is this possibly a bug in the reference implementation?
  34. 2 points
    David Black

    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.
  35. 2 points

    sc_bitref usage

    The compiler has difficulties to decide which overload of the assignment operator it should use. You can help him by doing a static_cast<bool>(myint[7]).
  36. 2 points

    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
  37. 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.
  38. 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.
  39. 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
  40. 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
  41. 2 points
    Hi Jarodw, Thanks for your report. I can confirm and reproduce the issue in SystemC 2.3.2. It looks indeed like a regression compared to SystemC 2.3.0/1 that has been introduced by the fix for optionally unbound sockets, see: It seems, the SystemC regression tests didn't cover the hierarchical binding for the multi sockets, so it wasn't caught before the release. Your example can be fixed by changing line 228 in src/tlm_utils/multi_passthrough_target_socket.h: if (unbound && !m_hierarch_bind) return; // ^-- add check for hierarchical binding here Hope that helps, Philipp
  42. 2 points
    Philipp A Hartmann

    makefile SystemC

    You can check out the example Makefiles in the installation (examples/build-unix/Makefile.{config,rules} and e.g. examples/sysc/simple_bus/Makefile) as a starting point. The files in examples/build-unix are reasonably generic, and you may "just" need to adjust the settings in Makefile.config. In the project's Makefile itself, you then set the PROJECT variable and your SRCS (to point to your source files). Admittedly, documentation could be better (as usual), but you can ask here, if you have further questions. The CMake support included in SystemC 2.3.2 is still experimental and is mostly targeted for early adopters with CMake knowledge. Greetings from Duisburg, Philipp
  43. 2 points
    No, multiple inheritance is not supported in this case Here is quote from IEEE 1666-2011 So you have two options: Use composition instead of inheritance : in SystemC case this means you need to instantiate modules and bind their ports In some cases you can put some sc_objects in pure C++ classes (not sc_modules). This technique is commonly used for "port bundles". For example: struct clock_reset_if { sc_in_clk clk{"clk"}; sc_in<bool> rstn{"rstn"}; } struct some_module: sc_module, clock_reset_if { // ... } Unfortunately this approach does not work with SC_METHOD/SC_THREAD macros. But I think it should work with sc_spawn.
  44. 2 points
    Hello @Roman Popov, You can have a look here: Hope it helps. Regards, Ameya Vikram Singh
  45. 2 points
    Hi. Ameya is right. See SystemC LRM (ieee1666) Section 5.2.15: [...] it is associated with the most recently created process instance [...] I.e.: ONE process created most recently before calling dont_initialize is not execute. BTW: No process is executed in the constructor. But all processes, that are not marked as dont_initialize, are evaluated once at simulation start. Greetings Ralph
  46. 2 points

    SystemC-2.3.1a clang build fail

    Hi. There seems to be a problem with the '#if defined' expressions. MSYS gcc and clang define _WIN32, and in combination with using pthreads, SC_USE_PTHREADS is defined as well. Could you please evaluate possible fixes? E.g. adding '!defined(SC_USE_PTHREADS)' in line 33 of sc_cor_fiber.h? And could you please try with the public review version of SystemC 2.3.2 as well (http://www.accellera.org/downloads/drafts-review)? If this works, I can try to forward the issue to the SystemC developer working group. Greetings Ralph
  47. 2 points
    @daveW you can tryout the SystemC 2.3.2 draft release which fixes most of the issues while building under C++11/C++14 compilers. Have a look here: Regards, Ameya Vikram Singh
  48. 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
  49. 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:
  50. 2 points


    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
  • Create New...