Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 01/19/2018 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
    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
  3. 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
  4. 2 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.
  5. 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.
  6. 2 points
    Hello @ANKUR SAINI, If you are on Linux/UNIX with the Accellera release of SystemC library with the GNU toolchain, you can use the following tutorials for reference: https://sourceware.org/gdb/onlinedocs/gdb/Threads.html https://stackoverflow.com/questions/1695268/multi-threaded-debugging-tutorial-for-gdb-and-c Due to the co-operative multi-tasking implementation of the SystemC library available from Accellera as @Roman Popov has mentioned, much of the debugging tasks are easier since all threads synchronize with the main library thread. Let me know if it helps. Regards, Ameya Vikram Singh
  7. 2 points
    hle

    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?
  8. 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.
  9. 2 points
    maehne

    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]).
  10. 2 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. 1 point
    On the first question: Yes, you do need to keep the handle to the (terminating) process alive, if you continue to reference any related object like the terminated event. Otherwise, when the process terminates without any existing handles to it, the event will be destroyed together with the process instance itself and you're sensitive to a no-longer-existing event, causing the memory corruption. The crash itself is fixed in the master branch of the SystemC proof-of-concept simulator, but not released yet. This fix would then lead to removing the event from any waiting processes, though. So in this case, you would just miss the notification. On the second part: Which version of SystemC are you using? Can you confirm this with SystemC 2.3.2? Greetings from Duisburg, Philipp
  12. 1 point
    Hi, maybe I do not get the intent of your question but since SystemC is a C++ class library there is no separation between C++ and SystemC. What usually is separate are functional models and timed models as the latter one introduce a notion of time. As a functional model does not have this notion of time (only of sequence) care has to be taken to integrate a functional model into/with a timed model. Hope that helps
  13. 1 point
    TRANG

    Changing the width in sc_bv<W>

    In many cases , I cant use "const" I often use : #define or enum{}; you can try : #define WDW_SIZE 2 or enum {WDW_SIZE=2}; Best regards
  14. 1 point
    AmeyaVS

    wait in SC_CTOR()

    Hello @SystemCInDepth, The wait() call can only be used in SC_THREAD/SC_CTHREAD registered processes in SystemC library. You are trying to call wait even before the elaboration happens and you have started the simulation. It would be better if you could go through the book: SystemC from Ground Up by David Black to have a better understanding. Hope it helps. Regards, Ameya Vikram Singh
  15. 1 point
    maehne

    Using Debug mode.

    If you use the Makefile provided along the simple_fifo example, it should get compiled with debug symbols. On the console, you should see that the .cpp files get compiled with the "-g" switch. To actually make use of the debugging symbols, you have to execute the example in a debugger such as gdb (as Roman already pointed out). By the way, "make -d" does not influence which flags are passed to the C++ compiler. It just makes the output of make itself more verbose.
  16. 1 point
    Roman Popov

    Backtrace with sc_report_error()

    If you want to see stacktrace in LLDB, then just set a breakpoint in sc_report_error(). If you want to see a stacktrace when you run simulation without debugger, then use Boost::Stacktrace http://www.boost.org/doc/libs/1_65_1/doc/html/stacktrace.html
  17. 1 point
    Uwghiello

    Install SystemC on Visual Studio 2017

    I am trying to install systemC on visual studio 2017 but it seems that I cannot find the guide for it. So I had to follow the guide of installing systemC on VS2010 :( In fact, I have got systemC.lib but when I configured the project for systemC, i.e, the project->property->C/C++->Code Generation->Runtime Library->balabalabala... finished all of them and build solutions, there are some errors. So...what should I do? Totally confused because I know nothing about VS =_= PS: the guide is here
  18. 1 point
    Philipp A Hartmann

    User Guide for systemc 2.3.2

    Annex C in the SystemC standard lists some deprecated features. In the SystemC proof-of-concept implementation, you find detailed information about changes in the RELEASENOTES file, but mostly only relative to the previous version.
  19. 1 point
    Roman Popov

    SystemC and latency simulation

    No, there is no elegant way to simulate pipelines in SystemC. Commonly you just write a separate thread for each pipeline stage. Like you will do in Verilog/VHDL. 1) All HLS tools I've used do not convert SC_METHODs to pipelines. Only SC_THREADs can be converted to pipelines, if they follow some vendor-specific restrictions. 2) Yes, you can simulate latency by adding wait(N) to clocked SC_THREAD. However it will not simulate throughput. In general, this is a well known problem that HLS-generated code changes timing (expressed in clock cycles) of design. So HLS-generated code can even fail in tests that were working on input SystemC code. To avoid this, your inter-thread communication mechanisms should not depend on latency and throughput of generated hardware. You can also create latency/throughput constraints for HLS tool.
  20. 1 point
    Roman Popov

    adder - hierarchy- output issue

    Duolos website definetely has examples with mode than two modules or more than two signals: https://www.doulos.com/knowhow/systemc/tutorial/modules_and_processes/ What do you mean by "derived module" ? Word "derived" in C++ and SystemC is used in a context of OOP, i.e. class can be derived from one or more base classes.
  21. 1 point
    leoeltipo

    Socket binding to module itself

    Hello, I am new in the SystemC-TLM world. I am reading the LRM and looking at an example (chapter 13, systemc LRM, page 462). In the module constructor it is written ... init_socket.bind(*this); // Initiator socket bound to initiator itself ... The rest of the code is of no use for the sake of the question. I don't understand why the socket must be bound to the module itself. The example continues and the socket is bound to a target socket, but I don't get this one... Thank you in advance. Leo
  22. 1 point
    AmeyaVS

    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
  23. 1 point
    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...
  24. 1 point
    The "sc_export" part of each TLM-2.0 socket needs to be bound to an interface (tlm_bw_transport_if for an initiator, tlm_fw_transport_if for a target socket) in order to provide the implementation of the communication link. As you can see in the referenced example, the Initiator class inherits and implements the backwards interface: struct Initiator: sc_module, tlm::tlm_bw_transport_if<> // Initiator implements the bw interface As a result it can act as the "channel" to provide the behaviour for the sc_export part of the initiator socket. This pattern is a quite common idiom in the TLM-2.0 world, at least if you don't use the convenience sockets. So to answer your question: It's not the "module part" that is bound to the socket. The Initiator is-a backwards interface as well, and this "interface part" is bound. Greetings from Oldenburg, Philipp
  25. 1 point
    bhunter1972

    parsing using system verilog

    SV isn't the best language to parse with, but Python is! You should consider having your Python script output real SystemVerilog code that can then be loaded into the simulator instead. Consider: for (addr, data) in write_commands: print >>sv_file, " block.write_data('h%s, 'h%s);" % (to_hex(addr), to_hex(data)) etc.
×